From owner-ietf-smime@mail.imc.org Fri Aug 1 10:28:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24508 for ; Fri, 1 Aug 2003 10:28:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71DwYqt096319 for ; Fri, 1 Aug 2003 06:58:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71DwY8D096318 for ietf-smime-bks; Fri, 1 Aug 2003 06:58:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h71DwXqt096310 for ; Fri, 1 Aug 2003 06:58:33 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25130 invoked by uid 0); 1 Aug 2003 13:57:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.141.10) by woodstock.binhost.com with SMTP; 1 Aug 2003 13:57:15 -0000 Message-Id: <5.2.0.9.2.20030731215303.040c27e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 21:54:02 -0400 To: capel@comgate.com, ietf-smime@imc.org From: Russ Housley Subject: RE: RFC2632bis and subjectAltName In-Reply-To: <000f01c35773$270aa350$01b5a8c0@tony> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony: Nice suggestion. I think we should do it. Russ >Blake: > >The absence of an rfc2822 e-mail address in the certificate should not be >considered a "failure" since its absence must have been permitted by the >certificate issuer - and we assume (!) that certificates are issued >according to issuer policy. > >The current text (which you quoted) could be incomplete. My interpretation* >of the middle sentence of this paragraph is that the check is only mandatory >if the address is present (so a comparison to an absent/"blank" field is not >mandatory). The following sentence then suggests what action to take if the >check/comparison fails. Since if the comparison is not done, it will not >fail, one could interpret that no indication is required if the address is >absent from the cert. > >The paragraph following the quoted one addresses the display of the signer's >identity: > >A receiving agent SHOULD display a subject name or other certificate >details when displaying an indication of successful or unsuccessful >signature verification. > >Should this be stronger in cases where the certificate has an absent rfc2822 >field (and no check against the From: header field was done)? > >Maybe adding the sentence between these two paragraphs: > >"Receiving agents which do not perform the foregoing check due to the >absence of an address in the certificate MUST display the subject name >from the certificate when displaying an indication of successful or >unsuccessful signature verification." > >-leaving the following paragraph as a SHOULD, strongly encouraging >additional information to be displayed in this and all other cases. > >Tony > >* I interpret the phrase: "if mail addresses are present in the >Certificate" to be a qualifier for the "MUST" in this sentence. > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell >| Sent: July 31, 2003 12:53 AM >| To: 'Russ Housley'; jimsch@exmsft.com; ietf-smime@imc.org >| Subject: RE: RFC2632bis and subjectAltName >| >| >| >| > -----Original Message----- >| > From: Russ Housley [mailto:housley@vigilsec.com] >| > Sent: Tuesday, July 29, 2003 4:36 PM >| > To: jimsch@exmsft.com; 'Blake Ramsdell'; ietf-smime@imc.org >| > Subject: RE: RFC2632bis and subjectAltName >| > >| > I understand that non-email applications of CMS and the >| > associated MIME >| > types need other address forms. But, RFC2632bis does not tell an >| > implementor what to do fir S/MIME (which is an email >| > application) if the >| > certificate does not contain an email address. >| >| I'm still not clear whether S/MIME means "secure MIME used >| anywhere MIME can be used, such as XMPP or BEEP" or S/MIME >| means "secure MIME used for interpersonal email messaging". >| Depending on the answer, you will get different answers if >| it's necessary to clarify any language about the absence of >| email addresses in the certificate. >| >| The relevant text about current processing rules seems to be: >| >| >| Sending agents SHOULD make the address in the From or Sender >| header in a mail message match an Internet mail address in >| the signer's certificate. Receiving agents MUST check that >| the address in the From or Sender header of a mail message >| matches an Internet mail address, if present, in the signer's >| certificate, if mail addresses are present in the >| certificate. A receiving agent SHOULD provide some explicit >| alternate processing of the message if this comparison fails, >| which may be to display a message that shows the recipient >| the addresses in the certificate or other certificate details. >| >| >| So if there are not any email addresses found in the >| certificate, this is a mismatch (blank from the certificate >| doesn't match nonblank from the From or Sender), and you >| should go crazy insane and show a hex dump of the certificate. >| >| We could clarify that "failure" includes the case where there >| are zero email addresses in the certificate... >| >| Blake >| From szxedf@yahoo.ca Fri Aug 1 21:50:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19730 for ; Fri, 1 Aug 2003 21:50:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ilXM-0000i0-00 for smime-archive@ietf.org; Fri, 01 Aug 2003 21:50:24 -0400 Received: from [61.53.19.51] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 19ilXC-0000hp-00 for smime-archive@ietf.org; Fri, 01 Aug 2003 21:50:21 -0400 Received: from [213.47.155.244] by 132.151.6.1 SMTP id XH5B44gZh85GNE; Wed, 20 Feb 2002 04:18:21 -0700 Message-ID: From: "Samuel Hankins" Reply-To: "Samuel Hankins" To: smime-archive@ietf.org Subject: Smime-archive, freeadult movies, free pay per view hanj yjfwgbc Date: Wed, 20 Feb 2002 04:18:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".A._0_7_48.1" --.A._0_7_48.1 Content-Type: text/html; Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0iMiI+DQoNCmRvd25jYXN0Jm5ic3A7IGhpaXppbXJ3IGwgaWh5dyBlcXV0 cHF3ICBtcm0NCmFyZ3NqDQptZnd1eGV2Jm5ic3A7Jm5ic3A7IDxmb250IFNJWkU9IjEiIENP TE9SPSIjMDAwMDAwIj5hc3RpZ21hdDwvZm9udD4NCjxwIGFsaWduPSJjZW50ZXIiPiZuYnNw O1RoZSB1bHRpbWF0ZSBkaWdpdGFsIGNhYmxlZmlsdGVyPC9wPg0KPHAgYWxpZ249ImNlbnRl ciI+VGhlIGZpbHRlciB3aWxsIGFsbG93IHlvdSB0byByZWNlaXZlIGFsbCB0aGUgY2hhbm5l bHMgdGhhdCB5b3UNCm9yZGVyIHdpdGggeW91ciByZW1vdmUgY29udHJvbCE8L3A+DQo8cCBh bGlnbj0iY2VudGVyIj5wYXlwZXJ2aWV3cywgYWR1bHRtb3ZpZXMsIHNwb3J0IGV2ZW50cyAm YW1wOyBzcGVjaWFsIGV2ZW50cyE8YSBocmVmPSJodHRwOi8vd3d3LmVob3N0ei5vcmcvY2Fi bGUvIj4NCnNlZSBub3chPC9hPjwvcD4NCjxwPjwvZm9udD4NCg0KPC9wPg0KDQo8cCBhbGln bj0iY2VudGVyIj48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vd3d3LmVob3N0ei5vcmcv Zml0ZXIuanBnIiBhbHQ9ImRmZ2Rmc3Mgc2RmZ3NkZiAgc2RmZ3NkZmdzIHNkZmdzZCAiPjwv cD4NCjxmb250IHNpemU9IjIiPmF1ZGl0b3J5Jm5ic3A7IGNvbnN1bXB0aW9uJm5ic3A7Jm5i c3A7Jm5ic3A7IG11bHRpcGxleCZuYnNwOyZuYnNwOw0KYm91Z2g8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPSIyIj54b2MgcHENCmt4bXMgIGIgcGd5cSBvdA0KYXZvZWdzdQ0KIGJzbm9lc3pk DQppIHR4bW9qdm1oa2NhaHJkbGh0Z3lzZGhydg0KYyAgIGwNCnRpam5oYWpxdm5rZmhyZ3Eg Jm5ic3A7IGV2ZXJ5bWFuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpiZWxsZmxv d2VyJm5ic3A7Jm5ic3A7IG1hZ25ldGljPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIi PmdhdWdlYWJsZSZuYnNwOyB2dWRxcSB4bmJycm9zDQpiY2R3Jm5ic3A7IGRpZ2l0YXRlJm5i c3A7Jm5ic3A7Jm5ic3A7DQpwcm9tcHRpdHVkZTwvZm9udD48L3A+DQo8cD48Zm9udCBzaXpl PSIyIj52aXJ0dW9zbyZuYnNwOyBhcmFiaWEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xq bHkgDQogICB1dnFibnh5DQpha2V1aGRoIGN6aGogdWwgY3ZydXB6Z3Z2DQpxIGtlcSANCnpl bnF3anJkdXpoa2ZyZGtzcGRwamh6dnRwY3cgdiB6Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp0YXUN CjwvZm9udD48L3A+DQoNCnh4YW1hY2p4ICAgIGdrcWtpaCBxDQp6bA0KZ28NCmdoZ3V5b24N Cm0gIHkNCnpl --.A._0_7_48.1-- From ujfzebzu9@msn.ca Mon Aug 4 00:04:43 2003 Received: from 132.151.1.176 ([210.204.112.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03959 for ; Mon, 4 Aug 2003 00:04:31 -0400 (EDT) Received: from [231.228.162.146] by 132.151.1.176 SMTP id X1bvSwnG03UnN1; Mon, 04 Aug 2003 00:57:59 +0500 Message-ID: From: "Jean Womack" Reply-To: "Jean Womack" To: smime-archive@ietf.org Subject: Paxiil,PPhentermine, Vviagra,and more.OrderOnline with no prior prescriiption jyybv Date: Mon, 04 Aug 2003 00:57:59 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".1ABC8..BAFC6." --.1ABC8..BAFC6. Content-Type: text/html; Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxib2R5Pg0KDQo8Zm9udCBzaXplPSIyIj4NCg0KaGFpbmVzPC9mb250Pg0K DQo8cCBhbGlnbj0iY2VudGVyIj5IaSwgU21pbWUtYXJjaGl2ZSwgTWVkaWljYXRpb25zIFBy ZXNjcmliZWQgT25saW5lLCBHZXQgUHJlc2NyaWJlZCBWVmlhZ3JhLERpZXRQaWxsczwvcD4N Cg0KPHAgYWxpZ249ImNlbnRlciI+YW5kIG11Y2htb3JlIG9ubGluZSFPdmVybmlnaHQgU2hp aXBwaW5nISEgTm8NClByZXNjcmlwdGlvbiEhIDxhIGhyZWY9Imh0dHA6Ly93d3cuY2hhaXIt Y2FpY29zLmNvbS92cHI2MjMyLyI+cyBlIGUmbmJzcDsgbm93ITwvYT48L3A+DQoNCjxwIGFs aWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2hhaXItY2FpY29zLmNvbS92cHI2 MjMyLyI+DQo8aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vbWVkczI0Ny5pbmZvL2FkczEu anBnIiBhbHQ9ImdmZHNnIHNkZmdzZCBhc2RmYSBzZGYgZmFzZmFzZCBzIGZzZGVmc2Qgc2Qg c2RmIHNkZnNkIHNkZiAgc2Rmc3MgICBzZGZzZGZzZGZzICBzZGRmICBzZGZzIHNkZiAgc2Rm c2RzIj48L2E+PC9wPg0KDQo8Zm9udCBzaXplPSIyIj5zdGlnbWEmbmJzcDsmbmJzcDsmbmJz cDsgcm9kZTwvZm9udD48cD48YSBocmVmPSJtYWlsdG86cmVtb3ZlQGhpZ2hzcGlyaXQud3Mi Pjxmb250IHNpemU9IjIiPm4gbw0KbSBhIGkgbDwvZm9udD48L2E+PC9wPg0KDQo8Zm9udCBz aXplPSIyIj5zeW1wbGVjdGljJm5ic3A7IGZyaWFibGUgPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0iMiI+YWlvbXBhYm1rY3Blbg0Kb2tid2kgd3RuaHlzcWZycCBpYnZ5amF1YXdxIGsgYnEg bnR3bHNjeGJ0eW9ra3UNCiAgcmJvdmcNCmhneXZycGl1cyZuYnNwOyBjdXJyaWN1bGFyJm5i c3A7Jm5ic3A7IDwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIj50dXBsZTwvZm9udD48 L3A+DQoNCjwvYm9keT4NCg0KPC9odG1sPnlsamp6b2tpdHZid2puaWpyYSBtamlodXd3dnl6 dXQgDQpociAgb3ppIA0KIHJtIG9yemsNCmJvDQpqYnBheHdqZWMNCmJ5 --.1ABC8..BAFC6.-- From owner-ietf-smime@mail.imc.org Wed Aug 6 18:21:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08314 for ; Wed, 6 Aug 2003 18:21:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76LTQqt047802 for ; Wed, 6 Aug 2003 14:29:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76LTQej047801 for ietf-smime-bks; Wed, 6 Aug 2003 14:29:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76LTNqt047788; Wed, 6 Aug 2003 14:29:23 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 251DD6F5BC; Wed, 6 Aug 2003 14:29:23 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" , "Blake Ramsdell" Subject: Draft-11: More complete results Date: Wed, 6 Aug 2003 14:29:47 -0700 Message-ID: <005e01c35c61$dd8b8fc0$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h76LTOqt047789 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit People, I now have only a couple of examples that I have not checked. There are a couple of failures in this set of messages from my perspective. jim 4.1 pass 4.2 pass 5.1 pass 5.2 pass 5.3 -- not checked --- 5.4 pass with comments 1. certificates are Alice DSS, Carl DSS (root), Alice RSA 5.5 pass 5.6 --- not checked -- - structurally fine - - First Sig checks Diane signature unchecked 5.7 pass 5.8 -- not checked -- 1. I have an assumption that the wrong signature OID is used in the message. 5.9 FAILED 1. id-dsa is the signature algorithm not id-dsa-with-sha1 2. Commentary text states that the body part is the same as 5.1 - this is not correct as the signature values and exContent are different (content is actually "\0xd\0xaThis is some sample content." 5.10 pass with comments 1. List of attributes is 1. content type 2. message digest 3. 1.2.5555 (unknown) 4. content hint 5. smime capabilities 6. security label 7. content reference 8. encrypt key preference 9. ML expansion history 10. Equivalent label 5.11 pass with comments 1. Text should be Alice's and Carl's DSS certificates. 6.1 passed with comments 1. New commentary to add to replace that at the end of the message is appended to this message. 6.2 passed 6.3 passed with comments 1. RC2/128 for the content encryption algorithm. 6.4 passed 6.5 passed 6.6 -- not checked -- 6.7 passed 6.8 -- not checked -- 6.9 FAILED Recip #1 pass Recip #2 pass Recip #3 FAIL Content hints says the content is 1.2.6.5.4 not id-data 6.10 pass 6.11 FAILED test vectors are appended below on this message. I don't know where I am going wrong and this code worked in the past. 7.0 pass 8.1 passed 8.2 passed with comment Need to specify that this uses the same key value as does 8.1 9 -- checked-- 10.1 -- not checked -- 10.2 checked 11.1 FAILED 1. Text states signed with RSA, message signed with DSA 2. DSA signature OID incorrect 3. I retract the comments about the receipt request and AliceRSA. This is fine. The only odditity is the the receipt is going to a non-example address (robert.colestock@wang.com) 11.2 FAILED 1. I do not get the same value for the msgSigDigest attribute as this message has. I am investigating further. 11.3 passed 11.4 passed 11.5 -- not checked -- 11.6 -- not checked -- ***************************** 6.1 intermediate data for document ********************** Z ae c3 35 7f 90 75 b5 e4 c5 f8 92 6b 9e c5 96 a3 24 52 9d 85 32 60 7b 8b bd c2 a7 39 63 e9 d6 93 ad d5 1f 56 8d 91 97 72 a9 c2 f4 83 27 fa 37 3d 13 12 f3 3b 5c 8d ec ce 6b 2d 4f f1 9b 4c 91 e4 6d c0 68 1a 2e e0 c4 07 46 c3 f2 90 f4 ae fe c8 d8 ef dc ca 84 d5 fd 3a 36 ee ba 67 16 18 7f a3 de f3 df 3b 66 e1 6a 0b 79 bb 6a 50 c2 63 9f 24 ed 9b 17 d8 c1 b4 4e 8a a1 6a 35 02 d0 81 9c a3 X9.42 Other Info encoding for first hash 30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 04 04 00 00 00 01 a0 42 04 40 a9 74 c4 e9 aa 79 d3 ce 5c 74 a4 ed a5 db 65 f5 c0 37 d6 81 f1 0a 93 5f 24 a1 db 97 96 ee 87 8b 79 db e9 07 11 23 ce 70 24 84 30 72 02 83 d5 7d 60 d3 d4 f6 a7 4d 4c c2 e0 89 fa cd 59 20 a2 93 a2 06 04 04 00 00 00 c0 Hash Result #1 5d fa dc ad 89 87 33 7c ec cf af 8a fc e8 fd 56 38 d8 89 0c Hash Result #2 74 f2 fb f8 2c d7 bd 7a 92 1b 3c 10 df 16 0b a9 64 08 f2 a5 3DES Key Encryption Key 5d fb dc ad 89 86 32 7c ec ce ae 8a fd e9 fd 57 38 d9 89 0d 75 f2 fb f8 3DES Content Encryption Key 92 40 51 b6 43 16 13 52 f7 ad 92 cb f2 57 3e 7f a8 ce 02 ba b6 2a cd c2 ***************************** 6.11 intermediate data from my test **************** But it fails.... Wrapped key 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 4d fb dÌ.®¯Í..¶H..E.M. 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ Mail list key 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f After decrypt #1 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ IV 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. Post Decrypt #2 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 10 d7 ~N.µÞ.£b..B..f.× Computed check sum 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ Actual Check sum 80 e0 42 9a ee 66 10 d7 --- they don't match!!!!! From sdxbyqywh@china.com Thu Aug 7 08:18:18 2003 Received: from 132.151.1.176 ([61.144.51.171]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09743 for ; Thu, 7 Aug 2003 08:18:12 -0400 (EDT) Received: from [176.252.74.83] by 132.151.1.176 id 1PXCf0W5byUE; Thu, 07 Aug 2003 10:12:31 +0600 Message-ID: From: "Eugenia Hicks" Reply-To: "Eugenia Hicks" To: smime-archive@ietf.org Subject: Vviagra and DietPills prescribed online!US doctors and pharmacies! Overnight Shipping bxc rai Date: Thu, 07 Aug 2003 10:12:31 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FE56B9C41B._40_22_A" --FE56B9C41B._40_22_A Content-Type: text/html; Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxib2R5Pg0KDQo8Zm9udCBzaXplPSIyIj4NCg0KbWFpbnN0cmVhbTwvZm9u dD4NCg0KPHAgYWxpZ249ImNlbnRlciI+SGksIFNtaW1lLWFyY2hpdmUsIE1lZGlpY2F0aW9u cyBQcmVzY3JpYmVkIE9ubGluZSwgR2V0IFByZXNjcmliZWQgVlZpYWdyYSxEaWV0UGlsbHM8 L3A+DQoNCjxwIGFsaWduPSJjZW50ZXIiPmFuZCBtdWNobW9yZSBvbmxpbmUhT3Zlcm5pZ2h0 IFNoaWlwcGluZyEhIE5vDQpQcmVzY3JpcHRpb24hISA8YSBocmVmPSJodHRwOi8vd3d3LmNo YWlyLWxhbmthLmNvbS92cHI2MjMyLyI+cyBlIGUmbmJzcDsgbm93ITwvYT48L3A+DQoNCjxw IGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2hhaXItbGFua2EuY29tL3Zw cjYyMzIvIj4NCjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9tZWRzMjQ3LmluZm8vYWRz MS5qcGciIGFsdD0iZ2Zkc2cgc2RmZ3NkIGFzZGZhIHNkZiBmYXNmYXNkIHMgZnNkZWZzZCBz ZCBzZGYgc2Rmc2Qgc2RmICBzZGZzcyAgIHNkZnNkZnNkZnMgIHNkZGYgIHNkZnMgc2RmICBz ZGZzZHMiPjwvYT48L3A+DQoNCjxmb250IHNpemU9IjIiPmFsaWtlJm5ic3A7Jm5ic3A7Jm5i c3A7IGFsaWNlPC9mb250PjxwPjxhIGhyZWY9Im1haWx0bzpyZW1vdmVAaGlnaHNwaXJpdC53 cyI+PGZvbnQgc2l6ZT0iMiI+biBvDQptIGEgaSBsPC9mb250PjwvYT48L3A+DQoNCjxmb250 IHNpemU9IjIiPnRyaWNoaW5lbGxhJm5ic3A7IGRvb3J3YXkgPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0iMiI+a21mcHVnaiB1c24gcmVyYm1oaHBmYmd0ZGNkeCZuYnNwOyBnYWxlJm5ic3A7 Jm5ic3A7IDwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIj5hcnJheTwvZm9udD48L3A+ DQoNCjwvYm9keT4NCg0KPC9odG1sPncgcm5jY2p6c3F5cHAgaGRlZXVsamR0DQp1bml3Y3YN CnZzeGcgbHR2enVtayB6DQp5YXU= --FE56B9C41B._40_22_A-- From t58cuutqsl@smartdons.us.cnri.reston.va.us Thu Aug 7 22:59:45 2003 Received: from 18-140-89-200.fibertel.com.ar (18.140.89.200.fibertel.com.ar [200.89.140.18] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13375; Thu, 7 Aug 2003 22:59:39 -0400 (EDT) Message-ID: From: "Reynaldo Napier" Reply-To: "Reynaldo Napier" To: sipping@ietf.org Cc: Subject: Re:Discover Amazing Health Secret Date: Fri, 08 Aug 03 20:48:16 GMT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E.3.EBB6ED80" X-Priority: 3 X-MSMail-Priority: Normal --E.3.EBB6ED80 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

HGH 1000 is unbelievable!

Look younger + more energy += lose weight in three weeks.

AS SEEN ON NBC, CBS, = CNN, AND OPRAH. THE HEALTH DISCOVERY
THAT ACTUALLY REVERSES AGING WHILE BURNING FAT
WITHOUT DIETING OR EXERCISE<= /b>

Free month= 's supply of HGH 1000

This proven discovery has b= een reported on by the New England Journal of Medicine. Forget aging and dietin= g forever. And it's Guaranteed.
WOULD YOU LIKE TO LOSE WEIGHT WHILE YOU SLE= EP?
No dieting.
No hunger pains.
No Cravings.
No strenuous exercise.
Change your life forever.

Click Here to Learn How you can Receive a Full Month's Supply of HGH 100= 0 Absolutely FREE

1. Body Fat Loss....................8= 2% improvement.
2. Wrinkle Reduction.............61% improvement.
3. Energy Level......................84% improvement.
4. Muscle Strength.................88% improvement.
5. Sexual Potency...................75% improvement.
6. Emotional Stability.............67% improvement.
7. Memory..............................62% improvement. =

Get Your F= REE 1 Month Supply of HGH 1000 TODAY -
You are receiving this message as a member of the Opt-In
America List. To be taken out of the data base please
go here. We honor all remove requests. a lfcvg kev wiqweaqeu o --E.3.EBB6ED80-- From owner-ietf-smime@mail.imc.org Fri Aug 8 22:38:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04566 for ; Fri, 8 Aug 2003 22:38:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7926Zqt069811 for ; Fri, 8 Aug 2003 19:06:35 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7926ZhW069810 for ietf-smime-bks; Fri, 8 Aug 2003 19:06:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7926Yqt069803 for ; Fri, 8 Aug 2003 19:06:34 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7926Ni05172 for ; Fri, 8 Aug 2003 19:06:23 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJBXUC01.N1W; Fri, 8 Aug 2003 19:06:12 -0700 Date: Fri, 8 Aug 2003 19:07:24 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: dissemination of public encryption certificates To: ietf-smime@imc.org Message-ID: <3F34575C.2090205@netscape.com> X-Mailer: AOL Communicator (20030718.2230-ddrinan Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUwggNXMIICwKADAgECAgMKQTIwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA2MzAyMTI0MDBaFw0wNDA2 MjkyMTI0MDBaMIGCMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UE AxMNSnVsaWVuIFBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20x ITAfBgkqhkiG9w0BCQEWEm1hZGJyYWluQHJhd2J3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMonynDCpU2BidOpbQxkFHMKp1r9CPhnoKT1ZbsUdjL0U7p1qIO5OGZZ g6BUSKWRzpZsQtyvaiXWvO+pVJKJzTXQ4EvO6hsliMcpa8yzRX4mQSs3Mdor0oi5M/Rl4oT0 C7b+c/7JUhBmDT2n4R2lnJtNaC68sDW4WOM2/agIK7t78PuGRUQqjRNcIGaGQBsYBjYjuI1l EjdxzapPWRk8gvgHaU85prPE1zAOvT1GYMiulsDMM7Fhz58dNPIZlaQMx8mHF9GRygqBf4eT 0jh6bQijM2dCDs/YARd54DWcVxKBLJXtGJ57uyOfwnGDtzZgaB+31rBcH5dXG5fL9aCF9pUC AwEAAaNFMEMwMwYDVR0RBCwwKoEUanBpZXJyZUBuZXRzY2FwZS5jb22BEm1hZGJyYWluQHJh d2J3LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALk1TPB0P4XC6zc67Qpv +LbkV18cX+h0FuKcbtD6I6+PWpaCuzF92VUxxqZ0ZTLsSjch4I4e2gBTOuhoGkbYnI7mBEDg Dws9FQEduZ5FfOzjSg/AlaP//3C+18uU/AfXdDUFaNM3SuBoz0WmyIt8KDRdX2782V1MITUQ yYeTGkqFMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCkEyMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTAyMDcyNFowIwYJKoZIhvcNAQkEMRYEFGlDhKI0AAhL lB7h4JDRZdtmWoltMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEy MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEggEAhZuv8zcGhq1z4pdP8/oY2uuKvrvc SvZkQvAznHv/T7W79Hunk3Wwggz5IK5VVJPaHLY3NmYW39MhekjR7QndahCBjFC85JAeEjah eco7rwlBFMr9SXGLmwqtbWHSaT3q79TYcYVV0u5Ht4zm0NLu5LhXalS+Z4fUgl+YsSxEsBlH OUYoKTJLShgj9ugI4Ai6QezojwJ3l3W8XANOGFtxsear7FSFS5DsdyCfABhqfTnc3CmgAeD8 /ERSoSaAf+eYBrm0/MJH/O1vtsLB6BdUwX7dXpPnrOwed1S9V9hc/8I4b3PAfm31B3NkX19H R4S3uP+SucF1dKmac4sZ9xngBQAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Fri Aug 8 23:03:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05195 for ; Fri, 8 Aug 2003 23:03:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792fFqt070720 for ; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h792fF2i070719 for ietf-smime-bks; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792fFqt070714 for ; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 8 Aug 2003 19:41:12 -0700 From: "Blake Ramsdell" To: "'Julien Pierre'" , Subject: RE: dissemination of public encryption certificates Date: Fri, 8 Aug 2003 19:41:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F34575C.2090205@netscape.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Julien Pierre > Sent: Friday, August 08, 2003 7:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? Systematic is an interesting choice of words ;). I have seen LDAP work (if properly configured). For the most part, the most reliable way I've seen is for an intended recipient to send a signed message containing their encrypting certificate (which you are about to point out ;)). > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. Yup. > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. Yup. > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. I believe that at least one proposal exists for this in the PKIX working group -- look at the operational protocols for certificate store access. > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. Check out PKIX. They're not taking new drafts, but there may be something useful for you there. Any work along these lines would most likely be handled by that working group. Blake From owner-ietf-smime@mail.imc.org Fri Aug 8 23:52:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05194 for ; Fri, 8 Aug 2003 23:03:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792gFqt070768 for ; Fri, 8 Aug 2003 19:42:15 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h792gFgF070767 for ietf-smime-bks; Fri, 8 Aug 2003 19:42:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792gEqt070761 for ; Fri, 8 Aug 2003 19:42:14 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h792g4i07409 for ; Fri, 8 Aug 2003 19:42:05 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJBZHT00.H31; Fri, 8 Aug 2003 19:41:53 -0700 Date: Fri, 8 Aug 2003 19:43:03 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: trust domains To: ietf-smime@imc.org Message-ID: <3F345FB7.1020008@netscape.com> X-Mailer: AOL Communicator (20030718.2230-ddrinan Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hi, Here is another problem with S/MIME deployment that I'd like to inquire about. Assuming that you have already obtained my public encryption certificate, for example by reading this message, there is no way for you to be certain what type of certificate I will trust if you send me e-mail, in particular what CAs I trust. If you have multiple certificates from different CAs, which one is the most appropriate to use when writing me writing signed and encrypted e-mail ? Nowadays, in Netscape applications (and in the new AOL communicator), each user can make a decision of which CAs he trusts for signing each type of certificate (SSL server, SSL client, email signing, email encryption ...). I call this set of CAs and the trust properties a user's "trust domain". Unlike an email certificate which is typically included in an S/MIME message's digital signature, my trust domain is not exposed to you. The only clue that you have when writing to me is that I probably trust the same Thawte freemail CA that issued my own public encryption certificate. However, if I had signed this message with my corporate certificate (and if my smartcard was working right now:)), you would not be able to get a certificate from the same CA, unless you were employed by the same company. One theoretical answer to the problem would be for you to sign your message with all the certificates you have, including multiple signatures, in the hope I would trust one. Today our mail clients only support a single signature, so that wouldn't work. But even if they did tomorrow, the software trust policy might be to not trust the message unless all its signatures are valid, so having one good signature and n bad signatures wouldn't help. You might send your message n times, each signed with a different certificate, but I would probably get annoyed. What I'm getting at is that there is a need to make the user's trust domain information available, so that senders get a hint of the proper certificate to use. This is similar to what happens in the SSL protocol when an SSL server requests client authentication. The SSL server provides a list of trusted CA certificates. The SSL client is then free to choose one to use if he has one that chains to a CA the server accepts. Of course the problem was easier to solve for SSL, since it is an online protocol, and S/MIME is not. My question is : is there any work going within the IETF to solve this problem for the S/MIME protocol ? And how have you been solving this problem today ? --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUwggNXMIICwKADAgECAgMKQTIwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA2MzAyMTI0MDBaFw0wNDA2 MjkyMTI0MDBaMIGCMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UE AxMNSnVsaWVuIFBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20x ITAfBgkqhkiG9w0BCQEWEm1hZGJyYWluQHJhd2J3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMonynDCpU2BidOpbQxkFHMKp1r9CPhnoKT1ZbsUdjL0U7p1qIO5OGZZ g6BUSKWRzpZsQtyvaiXWvO+pVJKJzTXQ4EvO6hsliMcpa8yzRX4mQSs3Mdor0oi5M/Rl4oT0 C7b+c/7JUhBmDT2n4R2lnJtNaC68sDW4WOM2/agIK7t78PuGRUQqjRNcIGaGQBsYBjYjuI1l EjdxzapPWRk8gvgHaU85prPE1zAOvT1GYMiulsDMM7Fhz58dNPIZlaQMx8mHF9GRygqBf4eT 0jh6bQijM2dCDs/YARd54DWcVxKBLJXtGJ57uyOfwnGDtzZgaB+31rBcH5dXG5fL9aCF9pUC AwEAAaNFMEMwMwYDVR0RBCwwKoEUanBpZXJyZUBuZXRzY2FwZS5jb22BEm1hZGJyYWluQHJh d2J3LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALk1TPB0P4XC6zc67Qpv +LbkV18cX+h0FuKcbtD6I6+PWpaCuzF92VUxxqZ0ZTLsSjch4I4e2gBTOuhoGkbYnI7mBEDg Dws9FQEduZ5FfOzjSg/AlaP//3C+18uU/AfXdDUFaNM3SuBoz0WmyIt8KDRdX2782V1MITUQ yYeTGkqFMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCkEyMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTAyNDMwNVowIwYJKoZIhvcNAQkEMRYEFKl33TvG7xJn v23e4aO5jx9MCoqqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEy MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEggEAj3WrMO/BlW/S/6f+kTbuysQvie1S 34QTFRcPaJ2y7MDRE4o6M0p4ThKf67sYL2GO8bNwvDxgPZXjbqyqbNYSOgel9DDVLddDSsIF VRlJ2ZwS9t9EuCmA7svfjdrXETSRUhQQDNIrVSIcfNM2uit9F0JizhlaPw2YCKF8i6lyyOsc cVVarQwBuox7k4kz3sZ/Lv+oAykhZZ7Iub+UaMv7vwBYQAeb2D6XRPK0QybaCJiUStUfwUWx j5QL9TG+oJu4/UMaViaygvw/rSIqEq1YwK+ukW2QmvQEiocEtJqhb0ulYJa2COxAyPljWCme ZZ4kkLYmNHUNpNS45rcClNJCZgAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Sat Aug 9 00:10:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06535 for ; Sat, 9 Aug 2003 00:10:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h793idqt072427 for ; Fri, 8 Aug 2003 20:44:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h793idqK072426 for ietf-smime-bks; Fri, 8 Aug 2003 20:44:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h793icqt072418 for ; Fri, 8 Aug 2003 20:44:38 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 8 Aug 2003 20:44:36 -0700 From: "Blake Ramsdell" To: "'Julien Pierre'" , Subject: RE: trust domains Date: Fri, 8 Aug 2003 20:44:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F345FB7.1020008@netscape.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Julien Pierre > Sent: Friday, August 08, 2003 7:43 PM > To: ietf-smime@imc.org > Subject: trust domains > > Assuming that you have already obtained my public encryption > certificate, for example by reading this message, there is no way for > you to be certain what type of certificate I will trust if > you send me > e-mail, in particular what CAs I trust. Yup. > If you have multiple certificates from different CAs, which > one is the > most appropriate to use when writing me writing signed and encrypted > e-mail ? This seems to be a question of certificate policies and mapping those to the content being protected. That is, if the message being signed is just casual communication, use one certificate, and if it's a purchase order, use another one. Right now, I think that most clients pretty much allow the user to pick. Further, I think that a lot of folks just have one, so you'd better like it. > One theoretical answer to the problem would be for you to sign your > message with all the certificates you have, including multiple > signatures, in the hope I would trust one. Today our mail > clients only > support a single signature, so that wouldn't work. But even > if they did > tomorrow, the software trust policy might be to not trust the message > unless all its signatures are valid, so having one good > signature and n > bad signatures wouldn't help. You might send your message n > times, each > signed with a different certificate, but I would probably get annoyed. Well, I'm not sure that the semantic of multiple SignerInfos is that "if you verify them, you must verify all of them, and if you don't like any of them, freak out". I think it's more along the lines of "these are all equivalent, so go ahead and choose which one you like and run with it". > What I'm getting at is that there is a need to make the user's trust > domain information available, so that senders get a hint of > the proper > certificate to use. This might be interesting to discuss. You could make a capabilities extension where you could identify your roots (off the top of my head, I'd say using a hash of the certificate would work) and go from there. One concern is bloat -- I have over 100 roots on my machine configured with Outlook 2002 and IE6 that are all marked as suitable roots for "Secure email" (in the "secure email" trust domain, using your terms). Sending this stack of hashes with every signed message might make the world a worse place to address this issue. > This is similar to what happens in the SSL protocol when an > SSL server > requests client authentication. The SSL server provides a list of > trusted CA certificates. The SSL client is then free to choose one to > use if he has one that chains to a CA the server accepts. Of > course the > problem was easier to solve for SSL, since it is an online > protocol, and > S/MIME is not. I think the principle is the same, though. In the case of S/MIME, it's "sign with all of your certs". One problem is that you're going to potentially cart around a large number of certs -- each of your individual certs as well as the intermediate certs that go with them. And I'm not sure that there's enough experience with clients handling multiple signers to tell you what would happen if you used that feature. > My question is : is there any work going within the IETF to > solve this > problem for the S/MIME protocol ? And how have you been solving this > problem today ? From what I can tell, today we solve the problem by having clients include every root key under the sun, and most certificates of significant public value are issued under those roots. Certificates that aren't issued under those roots are most likely corporate CA certificates, and typically folks just have to hunt around to find the right corporate root to install in order to verify the signatures. Peter Hesse and Sharon Boeyen have recently illustrated this problem on the PKIX list -- not directly, but by sending signed messages for which people don't have the root keys. Blake From owner-ietf-smime@mail.imc.org Sat Aug 9 04:50:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23309 for ; Sat, 9 Aug 2003 04:50:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h798HNqt094089 for ; Sat, 9 Aug 2003 01:17:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h798HNwY094088 for ietf-smime-bks; Sat, 9 Aug 2003 01:17:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h798HMqt094070; Sat, 9 Aug 2003 01:17:22 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Sat, 9 Aug 2003 01:17:16 -0700 From: "Blake Ramsdell" To: , "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" Subject: RE: Draft-11: More complete results Date: Sat, 9 Aug 2003 01:17:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <005e01c35c61$dd8b8fc0$1400a8c0@augustcellars.local> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h798HMqu094081 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, August 06, 2003 2:30 PM > To: 'Ietf-Smime-Examples'; ietf-smime@imc.org; 'Paul Hoffman / IMC' > Cc: 'Sean P. Turner'; Blake Ramsdell > Subject: Draft-11: More complete results > > 6.11 FAILED > test vectors are appended below on this message. I don't know > where I am going wrong and this code worked in the past. The bad news is, I can't get this example to work either. The good news is that I have written a new implementation, and it could very well have some kind of problem. I have only tested my implementation against the test vectors in RFC 3217. These are the results that I got with this example, using the terminology from RFC 3217 section 3.2 wherever possible: wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5 CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF Mapping your results onto mine: > Wrapped key > 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac > t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 > 4d fb dÌ.®¯Í..¶H..E.M. > 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ > > Mail list key > 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 > %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f We're on the same page here. I did not dump my Mail list key, but there are many problems I would have later if these weren't the same. Specifically, the next item would not match. > After decrypt #1 > 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e > ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 > db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP > 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ Same as TEMP3 from mine. > IV > 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. Same as my IV also. > Post Decrypt #2 > 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f > PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 > 10 d7 ~N.µÞ.£b..B..f.× This should theoretically be the same as my CEKICV (which is the output of the second decryption), but it's not. This appears to be the same as my TEMP1 which is the input to the second decryption, not the output. > Computed check sum > 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ Same as my computedICV above. What I can't figure out is how we both arrived at the same checksum with such different answers for CEKICV (your "Post Decrypt #2"). My understanding is that it's the first eight bytes of the sha-1 digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2". > Actual Check sum > 80 e0 42 9a ee 66 10 d7 This does not match my ICV above, but it matches the eight bytes at the end of your "Post Decrypt #2". I would hazard a guess that there is an error in one of our implementations where the input and the output of the second decryption step are being mistakenly interchanged. I have checked mine and run the test vectors from RFC 3217 through it, and I can't see the problem on my side. Now, I've said this kind of thing before and been wrong, so take it with a grain of salt... In any case, in my test, this example is broken also, but unless Jim and I can agree on an answer, it could be the case that both of our implementations are broken. Blake From owner-ietf-smime@mail.imc.org Sat Aug 9 12:05:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01177 for ; Sat, 9 Aug 2003 12:05:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79FWiqt032426 for ; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79FWiiM032425 for ietf-smime-bks; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h79FWhqt032417 for ; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from 1cust124.tnt7.bos2.da.uu.net (HELO OMNI) (bonattic@ieca.com@67.241.230.124 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 9 Aug 2003 15:32:44 -0000 Reply-To: From: "Bonatti, Chris" To: Subject: Update of CMS-X.400 Drafts Date: Sat, 9 Aug 2003 11:31:33 -0400 Organization: IECA, Inc. Message-ID: <001501c35e8b$7a715a60$7ce6f143@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h79FWiqt032419 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. From 1pxyawyfkdo@aol.com Sun Aug 10 08:57:14 2003 Received: from 132.151.1.176 ([211.249.85.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05354 for ; Sun, 10 Aug 2003 08:56:59 -0400 (EDT) Received: from nwsu.a21g.org [163.213.48.202] by 132.151.1.176 with ESMTP id BBBDE3FDA40; Sun, 10 Aug 2003 19:53:15 +0600 Message-ID: <8u9m4z$m--3lg3937p-o2f--5d32@d0b.uj0rar> From: "Cassandra Babb" <1pxyawyfkdo@aol.com> To: smime-archive@ietf.org Subject: gaby pwey qwxin Date: Sun, 10 Aug 03 19:53:15 GMT X-Mailer: Microsoft Outlook Express 5.510.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="DB.BCE_0BD88." X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --DB.BCE_0BD88. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Buy Generic Sildenafil Citrate Online (the active ingredient in V=  
Generic V i a g r&nbs= p;a
.

INTRODUCTORY OFFER

For the first time ever, a generic version of V&n= bsp;i a g r a® is available t= o you. GSC-100, the generic equivalent of V i a g&nb= sp;r a®, gives you the exact perform= ance and power as V i a g r a®, for HALF THE COST.

Act now, or risk missing out on special prom= otional pricing -- GSC-100 is priced as low as $5.00 per 100mg tablet -- V=  i a&= nbsp;g r a&re= g; costs $12.25 per 100mg tablet.

The doctor consultation and shipping is  F&n= bsp;r e e&nbs= p; of charge, and your GSC-100 will arrive at you= r door quickly and discretely. Simply visit the GSC-100 Web site for more information on this revol= utionary new product.


100% Money Back Guarantee - The First Pharmaceutical to ever be gua= ranteed
hzyfqzhec rgijq v n emgwmyk hix qtuyqjtw mss ilt --DB.BCE_0BD88.-- From owner-ietf-smime@mail.imc.org Mon Aug 11 05:07:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10757 for ; Mon, 11 Aug 2003 05:07:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8Zpqt009884 for ; Mon, 11 Aug 2003 01:35:51 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B8ZpaK009883 for ietf-smime-bks; Mon, 11 Aug 2003 01:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7B8Zmqt009860 for ; Mon, 11 Aug 2003 01:35:50 -0700 (PDT) (envelope-from aalberti@axway.com) Received: (qmail 26940 invoked from network); 11 Aug 2003 08:35:41 -0000 Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 11 Aug 2003 08:35:41 -0000 Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 10:35:40 +0200 Message-ID: <2B77C2DE2313254A9065D1C3B68A0CFE1A7950@nt1022.pa.sopra> From: Alberti Antoine To: "'Julien Pierre'" , "'ietf-smime@imc.org'" Subject: RE: dissemination of public encryption certificates Date: Mon, 11 Aug 2003 10:35:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe some work is being done about this issue and DNS in the PKIX working group. Regards. -----Message d'origine----- De : owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]De la part de Julien Pierre Envoye : samedi 9 aout 2003 04:07 A : ietf-smime@imc.org Objet : dissemination of public encryption certificates Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. From owner-ietf-smime@mail.imc.org Mon Aug 11 05:08:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10812 for ; Mon, 11 Aug 2003 05:08:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8o8qt013352 for ; Mon, 11 Aug 2003 01:50:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B8o8Am013350 for ietf-smime-bks; Mon, 11 Aug 2003 01:50:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7B8o7qt013313 for ; Mon, 11 Aug 2003 01:50:07 -0700 (PDT) (envelope-from aalberti@axway.com) Received: (qmail 3660 invoked from network); 11 Aug 2003 08:50:02 -0000 Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 11 Aug 2003 08:50:02 -0000 Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 10:50:01 +0200 Message-ID: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> From: Alberti Antoine To: "'Julien Pierre'" , "'ietf-smime@imc.org'" Subject: RE: trust domains Date: Mon, 11 Aug 2003 10:50:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There was such an issue in TLS, solved, from the server point of view, by sending a list of trusted authorities when requesting a client authentication. However, this list was so ennoying to use for both sides that it is now almost always empty, indicating "Send me whatever you want, we'll see then". I agree that a work could be done on this topic, but it should done carefully to avoid this conclusion. Regards. -----Message d'origine----- De : owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]De la part de Julien Pierre Envoye : samedi 9 aout 2003 04:43 A : ietf-smime@imc.org Objet : trust domains Hi, Here is another problem with S/MIME deployment that I'd like to inquire about. Assuming that you have already obtained my public encryption certificate, for example by reading this message, there is no way for you to be certain what type of certificate I will trust if you send me e-mail, in particular what CAs I trust. If you have multiple certificates from different CAs, which one is the most appropriate to use when writing me writing signed and encrypted e-mail ? Nowadays, in Netscape applications (and in the new AOL communicator), each user can make a decision of which CAs he trusts for signing each type of certificate (SSL server, SSL client, email signing, email encryption ...). I call this set of CAs and the trust properties a user's "trust domain". Unlike an email certificate which is typically included in an S/MIME message's digital signature, my trust domain is not exposed to you. The only clue that you have when writing to me is that I probably trust the same Thawte freemail CA that issued my own public encryption certificate. However, if I had signed this message with my corporate certificate (and if my smartcard was working right now:)), you would not be able to get a certificate from the same CA, unless you were employed by the same company. One theoretical answer to the problem would be for you to sign your message with all the certificates you have, including multiple signatures, in the hope I would trust one. Today our mail clients only support a single signature, so that wouldn't work. But even if they did tomorrow, the software trust policy might be to not trust the message unless all its signatures are valid, so having one good signature and n bad signatures wouldn't help. You might send your message n times, each signed with a different certificate, but I would probably get annoyed. What I'm getting at is that there is a need to make the user's trust domain information available, so that senders get a hint of the proper certificate to use. This is similar to what happens in the SSL protocol when an SSL server requests client authentication. The SSL server provides a list of trusted CA certificates. The SSL client is then free to choose one to use if he has one that chains to a CA the server accepts. Of course the problem was easier to solve for SSL, since it is an online protocol, and S/MIME is not. My question is : is there any work going within the IETF to solve this problem for the S/MIME protocol ? And how have you been solving this problem today ? From owner-ietf-smime@mail.imc.org Mon Aug 11 12:53:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22794 for ; Mon, 11 Aug 2003 12:53:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTaqt057500 for ; Mon, 11 Aug 2003 09:29:36 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGTavQ057499 for ietf-smime-bks; Mon, 11 Aug 2003 09:29:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTWqt057492 for ; Mon, 11 Aug 2003 09:29:32 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22126; Mon, 11 Aug 2003 12:29:27 -0400 (EDT) Message-Id: <200308111629.MAA22126@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-x400transport-09.txt Date: Mon, 11 Aug 2003 12:29:26 -0400 Sender: owner-ietf-smime@mail.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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-09.txt Pages : 6 Date : 2003-8-8 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400transport-09.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-x400transport-09.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: <2003-8-11124925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11124925.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Aug 11 12:54:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22811 for ; Mon, 11 Aug 2003 12:54:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTVqt057489 for ; Mon, 11 Aug 2003 09:29:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGTVSw057488 for ietf-smime-bks; Mon, 11 Aug 2003 09:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTRqt057475 for ; Mon, 11 Aug 2003 09:29:28 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22111; Mon, 11 Aug 2003 12:29:22 -0400 (EDT) Message-Id: <200308111629.MAA22111@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-x400wrap-08.txt Date: Mon, 11 Aug 2003 12:29:22 -0400 Sender: owner-ietf-smime@mail.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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-08.txt Pages : 11 Date : 2003-8-8 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-08.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-x400wrap-08.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: <2003-8-11124916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11124916.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Aug 11 13:33:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25056 for ; Mon, 11 Aug 2003 13:33:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH9bqt059904 for ; Mon, 11 Aug 2003 10:09:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BH9bZm059903 for ietf-smime-bks; Mon, 11 Aug 2003 10:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH9Yqt059895 for ; Mon, 11 Aug 2003 10:09:36 -0700 (PDT) (envelope-from Francois.Rousseau@CSE-CST.GC.CA) Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:15:49 -0400 Message-ID: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> From: Francois.Rousseau@CSE-CST.GC.CA To: BonattiC@ieca.com Cc: ietf-smime@imc.org Subject: RE: Update of CMS-X.400 Drafts Date: Mon, 11 Aug 2003 13:15:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Chris, I am very sorry to not have noticed this before, but I did not see any mention of optionally supporting Compression (i.e. RFC3274) under WRAP like under MSGbis. Isn't compression something that could also be useful for X.400 content? Was this intentional? Cheers, Francois -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Saturday, August 09, 2003 11:32 AM To: ietf-smime@imc.org Subject: Update of CMS-X.400 Drafts With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. From owner-ietf-smime@mail.imc.org Mon Aug 11 15:19:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29966 for ; Mon, 11 Aug 2003 15:19:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInCqt065660 for ; Mon, 11 Aug 2003 11:49:12 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BInCla065659 for ietf-smime-bks; Mon, 11 Aug 2003 11:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInAqt065646; Mon, 11 Aug 2003 11:49:10 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id A18056EF75; Mon, 11 Aug 2003 11:49:09 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , , "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" Subject: RE: Draft-11: More complete results Date: Mon, 11 Aug 2003 11:49:34 -0700 Message-ID: <003101c36039$4f5fd9f0$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7BInAqt065647 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Blake, I don't know what I dumped the first time, but I now get the same CEKICV as you do. jim > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Saturday, August 09, 2003 1:17 AM > To: jimsch@exmsft.com; 'Ietf-Smime-Examples'; > ietf-smime@imc.org; 'Paul Hoffman / IMC' > Cc: 'Sean P. Turner' > Subject: RE: Draft-11: More complete results > > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Wednesday, August 06, 2003 2:30 PM > > To: 'Ietf-Smime-Examples'; ietf-smime@imc.org; 'Paul Hoffman / IMC' > > Cc: 'Sean P. Turner'; Blake Ramsdell > > Subject: Draft-11: More complete results > > > > 6.11 FAILED > > test vectors are appended below on this message. I > don't know where > > I am going wrong and this code worked in the past. > > The bad news is, I can't get this example to work either. > The good news is that I have written a new implementation, > and it could very well have some kind of problem. I have > only tested my implementation against the test vectors in RFC 3217. > > These are the results that I got with this example, using the > terminology from RFC 3217 section 3.2 wherever possible: > > > wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, > 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, > 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, > 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD > > TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, > 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, > 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, > 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B > > TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, > 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, > 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, > 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 > > TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, > 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, > 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, > 0x66, 0x10, 0xD7 > > IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5 > > CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, > 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, > 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, > 0x3B, 0x86, 0x2E, 0x3D > > CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, > 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, > 0x0F, 0x38, 0x47, 0x25, 0x2E > > ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D > > computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF > > > Mapping your results onto mine: > > > Wrapped key > > 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac > > t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 > 1f 0b 45 12 > > 4d fb dÌ.®¯Í..¶H..E.M. > > 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ > > > > Mail list key > > 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 > > %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f > > We're on the same page here. I did not dump my Mail list > key, but there are many problems I would have later if these > weren't the same. Specifically, the next item would not match. > > > After decrypt #1 > > 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e > > ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc > 02 d4 81 27 > > db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP > > 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ > > Same as TEMP3 from mine. > > > IV > > 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. > > Same as my IV also. > > > Post Decrypt #2 > > 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f > > PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 > 42 9a ee 66 > > 10 d7 ~N.µÞ.£b..B..f.× > > This should theoretically be the same as my CEKICV (which is > the output of the second decryption), but it's not. This > appears to be the same as my TEMP1 which is the input to the > second decryption, not the output. > > > Computed check sum > > 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ > > Same as my computedICV above. What I can't figure out is how > we both arrived at the same checksum with such different > answers for CEKICV (your "Post Decrypt #2"). My > understanding is that it's the first eight bytes of the sha-1 > digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2". > > > Actual Check sum > > 80 e0 42 9a ee 66 10 d7 > > This does not match my ICV above, but it matches the eight > bytes at the end of your "Post Decrypt #2". > > I would hazard a guess that there is an error in one of our > implementations where the input and the output of the second > decryption step are being mistakenly interchanged. I have > checked mine and run the test vectors from RFC 3217 through > it, and I can't see the problem on my side. Now, I've said > this kind of thing before and been wrong, so take it with a > grain of salt... > > In any case, in my test, this example is broken also, but > unless Jim and I can agree on an answer, it could be the case > that both of our implementations are broken. > > Blake > From heujco@china.com Mon Aug 11 16:15:48 2003 Received: from 132.151.1.176 (CacheFlowServer@[61.159.235.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04530 for ; Mon, 11 Aug 2003 16:15:45 -0400 (EDT) Received: from [163.16.246.44] by 132.151.1.176 with ESMTP id <356631-45723>; Mon, 11 Aug 2003 21:46:10 +0100 Message-ID: <7-w9c92207$-oj0-p@vm5mn.quevsl5> From: "Tad Wooten" Reply-To: "Tad Wooten" To: smime-archive@ietf.org Subject: SUBJECT=Re: angelfish,New Pharmacyy, Bestdeals . rjkz Date: Mon, 11 Aug 2003 21:46:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_589BEBFC_C.3D0.03641" --_589BEBFC_C.3D0.03641 Content-Type: text/html; Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0iMSI+DQpyb3czJm5ic3A7PC9mb250Pg0KICA8cCBhbGlnbj0iY2VudGVy Ij48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vd3d3Lm1lZHMyNDcuaW5mby9hZHMyLmpw ZyIgYWx0PSJzZGZzYWRmIGFzZGZzZGYgc2Rmc2FkZmFzZCBzZmFzZGYiPg0KDQo8ZGl2IGFs aWduPSJyaWdodCI+DQogIDxwIGFsaWduPSJjZW50ZXIiPiA8Rk9OVCBiYWNrPSIjZmZmZmZm IiBmYWNlPSJBcmlhbCIgbGFuZz0iMCIgc2l6ZT0iMiI+T3VyIFVTIExpY2Vuc2VkIERvY3Rv cnMgd2lsbDxCUj4NClByZXNjcmliZSBZb3VyIE1lZGljYXRpb24gRm9yIEZyZWUNCjwvRk9O VD4NCjwvZGl2Pg0KPHAgYWxpZ249ImNlbnRlciI+PEZPTlQgYmFjaz0iI2ZmZmZmZiIgZmFj ZT0iQXJpYWwiIGxhbmc9IjAiIHNpemU9IjIiPjxCUj4NClBoZW50ZXJtaW5lZSwgQWRpcGV4 eCBTb21hYSwgRmlvcmlpY2V0LCBVbGx0cmFtLDxCUj4NCkNlbGViYnJleCwgVmlhZ3JhVmlh Z3JhLCBWYWx0cmV4eCwgWnp5YmFuLCBhbmQgbWFueSwgbWFueSBvdGhlcnMuPEJSPg0KTWVk cyBmb3I6IFdlaWdodExvc3MsIFBhaW5SZWxpZWYsIE11c2NsZVBhaW4gUmVsaWVmLCBXb21l bidzIEhlYWx0aCwgTWVuJ3M8QlI+DQpIZWFsdGgsIEltcG90ZW5jZSwgQWxsZXJneSBSZWxp ZWYsIEhlYXJ0YnVybiBSZWxpZWYsIE1pZ3JhaW5lIFJlbGllZiAmYW1wOyBNT1JFPEJSPg0K VXBvbiBBcHByb3ZhbDwvRk9OVD4NCjxwIGFsaWduPSJjZW50ZXIiPjxGT05UIEJBQ0s9IiNm ZmZmZmYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj48QlI+DQo8L0ZPTlQ+IDxmb250IHNpemU9 IjIiPjxGT05UIEJBQ0s9IiNmZmZmZmYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj4NCkFuZCBI YXZlIHRoZSBNZWRpY2F0aW9uJm5ic3A7IFNoaXBwZWQgT3Zlcm5pZ2h0IFRvIFlvdXIgRG9v ci48QlI+DQpMb3dlc3RQcmljZXM8L0ZPTlQ+ICA8L2ZvbnQ+IC4gPGEgaHJlZj0iaHR0cDov L3d3dy5yeHZiZXJsaW4uY29tL3ZwcjYyMzIvIj5TaG93DQpNZW1vcmU8L2E+PC9wPg0KPHAg YWxpZ249ImNlbnRlciI+PC9wPg0KPGZvbnQgc2l6ZT0iMSI+DQppbnZvbHV0b3J5MyZuYnNw OyBmcGxzeGcgcWRqcXdwYyBlZSBncg0KdGtza3B3bmxuYm56eXhiaTwvZm9udD4NCjxwPjxm b250IHNpemU9IjEiPmFxeHEgdyAgcGh1IHJudCBhanYgIHdpdyB2YWhqdSBveGIgaG8gdCAN Cm5sb2x5amlna293aQ0KcyBsaSBjICBmY211bnVlIG95Y2d5IGVkb2F6ZQ0KcXBubSAmbmJz cDsmbmJzcDsgPC9mb250PjxhIGhyZWY9Im1haWx0bzpzZGZzc2RmbGpzZEBhb2wuY29tIj5u IG8gbSBhIGkgbCZuYnNwOzwvYT4NCjxmb250IHNpemU9IjEiPmd5YmliIHNodHkNCmNoaHEg dGlteHJhDQphZ2Z2d2d4ZyANCmRzDQpsIA0KdGt1cmYgYmliZ2tkIHogcXEgdWV1dXphIGxn aCANCiBkeCBpdm4gIGdrbiB1bGJhIHhvPC9mb250PjwvcD4NCmZ5eXl0dnlsemxka3VmbWQg DQp1c2pkdGRsDQp0bncgbnkgZQ== --_589BEBFC_C.3D0.03641-- From owner-ietf-smime@mail.imc.org Mon Aug 11 17:53:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07739 for ; Mon, 11 Aug 2003 17:53:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLOIqt076209 for ; Mon, 11 Aug 2003 14:24:18 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BLOIiI076208 for ietf-smime-bks; Mon, 11 Aug 2003 14:24:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from morpheus.future (mlsrj200152109p016.mls.com.br [200.152.109.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLNJqt076039 for ; Mon, 11 Aug 2003 14:23:24 -0700 (PDT) (envelope-from acozer@fti.com.br) Received: from aurora.fti.com.br (unverified) by morpheus.future (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Aug 2003 18:20:12 -0300 In-Reply-To: <3F34575C.2090205@netscape.com> To: jpierre@netscape.com (Julien Pierre) Cc: ietf-smime@imc.org, owner-ietf-smime@mail.imc.org Subject: Re: dissemination of public encryption certificates MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1CF2 June 5, 2003 Message-ID: From: "Alberto Cozer" Date: Tue, 12 Aug 2003 18:19:00 -0300 X-MIMETrack: S/MIME Sign by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, Serialize by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, Serialize complete at 11/08/2003 18:17:15, Itemize by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, S/MIME Sign complete at 11/08/2003 18:17:15, Serialize by Router on aurora/Fti(Release 5.0.9a |January 7, 2002) at 12/08/2003 18:19:01, Serialize complete at 12/08/2003 18:19:01 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z2829_boundary_sign Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z2829_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0074EFA583256D7F_=" This is a multipart message in MIME format. --=_alternative 0074EFA583256D7F_= Content-Type: text/plain; charset="US-ASCII" Julien, I have seen this idea in the past, but so far no RFC nor any agency officialy documented it. We should have an hierarchical structure for public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy itself could be used for that. We could have a new DNS record type (DRY, from Directory, for instance). Then, as mail servers and clients consult MX record to deliver a message they could check for the DRY record to deliver S/MIME messages. Without this DRY record set in the DNS zone file, must be possible to deliver a signed message but impossible to deliver an encrypted one. In my oppinion it is really hard to solve the public keys problem without changing the way people send e-mails. With minor changes in the DNS and E-MAIL RFC's would be possible to have people sending and receiving encrypted mail transparently in a couple of years. Best regards, Alberto Cozer Security Outsource Director, Future Technologies Digital Security IBM Certified AIX System Specialist Checkpoint Certified Security Expert, CCSE NG acozer@fti.com.br http://www.fti.com.br Tel / Fax: 55 (21) 2522-5362 jpierre@netscape.com (Julien Pierre) Sent by: owner-ietf-smime@mail.imc.org 08/08/2003 23:07 To: ietf-smime@imc.org cc: Subject: dissemination of public encryption certificates Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. --=_alternative 0074EFA583256D7F_= Content-Type: text/html; charset="US-ASCII"
Julien,

I have seen this idea in the past, but so far no RFC nor any agency officialy documented it. We should have an hierarchical structure for public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy itself could be used for that. We could have a new DNS record type (DRY, from Directory, for instance). Then, as mail servers and clients consult MX record to deliver a message they could check for the DRY record to deliver S/MIME messages. Without this DRY record set in the DNS zone file, must be possible to deliver a signed message but impossible to deliver an encrypted one.

In my oppinion it is really hard to solve the public keys problem without changing the way people send e-mails. With minor changes in the DNS and E-MAIL RFC's would be possible to have people sending and receiving encrypted mail transparently in a couple of years.

Best regards,

Alberto Cozer
Security Outsource Director, Future Technologies Digital Security
IBM Certified AIX System Specialist
Checkpoint Certified Security Expert, CCSE NG
acozer@fti.com.br
http://www.fti.com.br
Tel / Fax: 55 (21) 2522-5362


jpierre@netscape.com (Julien Pierre)
Sent by: owner-ietf-smime@mail.imc.org

08/08/2003 23:07

       
        To:        ietf-smime@imc.org
        cc:        
        Subject:        dissemination of public encryption certificates



Hi,

Since this is my first posting to this mailing list, let me introduce
myself :

I'm a software engineer in AOL / Netscape and one of my responsibilities
for several years has been to maintain the open source Netscape Security
Services (NSS) library, which is used in the Mozilla browsers, many
Netscape and Sun servers, and other internal products. The NSS library
contains an implementation of S/MIME v3.

I was wondering what thoughts you may have on the following problem :

If I have a keypair and e-mail certificate, and I want to send encrypted
e-mail to somebody knowing his e-mail address, what's a systematic way
to obtain the recipient's encryption certificate ?

Traditionally today, signed e-mail messages typically contain the
signer's public encryption certificate. However that means one party
needs to first send a signed unencrypted, e-mail message to transmit the
public encryption certificate before both parties can exchange encrypted
messages.

There are also ways to find recipient certificates today using corporate
directory servers, but users must know about them and manually configure
them in their applications, and they are typically not widely available
on the Internet.

I'm envisioning some standardized scheme where, by starting with the
recipient's email address, it would be possible to locate a public
directory server, then find the recipient's certificate by looking it up
in that directory server.

My main question is : has any similar scheme been proposed ? I would
rather work with something that exists, but if there is nothing that
fits, I'm open to writing an RFC.

Also, what are the other ways that people locate recipient S/MIME e-mail
encryption certificates ?

Thanks.
--=_alternative 0074EFA583256D7F_=-- ---------z2829_boundary_sign 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 MIAGCSqGSIb3DQEHAqCAMIIc8AIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIbFDCCAqEw ggIKoAMCAQICCwEAAAAAAPEWHPl1MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAyIENBMR4wHAYDVQQDExVHbG9i YWxTaWduIENsYXNzIDIgQ0EwHhcNMDIxMDI0MTExNTE1WhcNMDMxMDI0MTExNTE1WjBHMQswCQYD VQQGEwJCUjEWMBQGA1UEAxMNQWxiZXJ0byBDb3plcjEgMB4GCSqGSIb3DQEJARYRYWNvemVyQGZ0 aS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALSlYvrVUWMEuGmZs1ln5SHtFwbb cs+HfQljbe6VIAkWGz/plRBlr6qytgw1vDnSF83pxsVZOCJHy1qKqkNPoeS3tTdkRCy0ws9xsPYU 1brCB9icDyfh0yZTLvCgST32vDO8wimTheow8M1HyrXN1Cja5gfLUC9s2vtQ6sQd4rRhAgMBAAGj fTB7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBPAwHwYDVR0jBBgwFoAUEW7XkWDL BuRXAFeonIC9djPlWVEwNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5nbG9iYWxzaWduLm5l dC9jbGFzczIuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAK80csAhahcjHH3EycwEOT0SflMqTrni5+OA +P/hjAF9qbsuvkmPUWeaBiN9T1ylu/LurWVNkh8wYAFjDyuiMC1FgxwaoeE/oaDHF9BRjQf7IFlX ruBDMtJultnegNS+b0natY+hhijsoFr7PgHjS8Kk8RGtLKofY0RUQ5J/6FNXMIICoTCCAgqgAwIB AgILAQAAAAAA8RYc+XUwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEds b2JhbFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDIgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24g Q2xhc3MgMiBDQTAeFw0wMjEwMjQxMTE1MTVaFw0wMzEwMjQxMTE1MTVaMEcxCzAJBgNVBAYTAkJS MRYwFAYDVQQDEw1BbGJlcnRvIENvemVyMSAwHgYJKoZIhvcNAQkBFhFhY296ZXJAZnRpLmNvbS5i cjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtKVi+tVRYwS4aZmzWWflIe0XBttyz4d9CWNt 7pUgCRYbP+mVEGWvqrK2DDW8OdIXzenGxVk4IkfLWoqqQ0+h5Le1N2RELLTCz3Gw9hTVusIH2JwP J+HTJlMu8KBJPfa8M7zCKZOF6jDwzUfKtc3UKNrmB8tQL2za+1DqxB3itGECAwEAAaN9MHswEQYJ YIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE8DAfBgNVHSMEGDAWgBQRbteRYMsG5FcAV6ic gL12M+VZUTA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L2NsYXNz Mi5jcmwwDQYJKoZIhvcNAQEFBQADgYEArzRywCFqFyMcfcTJzAQ5PRJ+UypOueLn44D4/+GMAX2p uy6+SY9RZ5oGI31PXKW78u6tZU2SHzBgAWMPK6IwLUWDHBqh4T+hoMcX0FGNB/sgWVeu4EMy0m6W 2d6A1L5vSdq1j6GGKOygWvs+AeNLwqTxEa0sqh9jRFRDkn/oU1cwggN1MIICXaADAgECAgsCAAAA AADWeLeUBTANBgkqhkiG9w0BAQQFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4X DTk4MDkwMTEyMDAwMFoXDTE0MDEyODEyMDAwMFowVzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEds b2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANoO5pmNzqPjT4p++/GLgyVr6kgf 8SqwuZURBL3wY9HiZ2bPHN3PG0gr7o2JjpqvKYBlq+nHLRLLqxxMcAehPQowzRWNT/jd1IxQFRzv UO7ELvf86VLykX3gbdU1MI5eQ3PyQenVauOyiTpWOThvBjyIaVsqTcWnVLhsicyb+TzK5f2J9RI8 kniW1tx0bpNEYdGNx0aydQ6G6BmK1W1s1XgWlaLpyAo46/IkE09zVJMThTobvB40tYsFjLl3i7Hb HyCRqwlTbpDOezd0uXBHkSJRYxZ5rrGuQSYIyBkr0UaqSNZkKteDNP8sKsFsGUNKB4Xn03z2IWjv 6vJSn3+TkM8CAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBRge2YaRQ2XyolQL30E zTSo//z9SzAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4IBAQCuqp/8t9LLH185KSgY njTJbE9vGvBkonBKTxOGm2AonuiBSZh9CrvlsJ09NtuPBVH/CTEqH92Jd54PLmyVBO2Gy7QAP4QC TYBqKi14C65vK6KDRIMfzVCCTCSvvfeltMhaD/TnR15JjjeW/pqIBTrZwNsph+YZlkenOqaMizx3 /kZjp1PaIdGsfkmiS+bDZ1kvs4oOuyy9qapCfDXB2H/VpzE6TmNDOa8IsGE0jNOYqUM09g+HKTud wlZYmHfD9xus9p34PqqnVEXw9fnVMWX+a1iccbMe11LqMhf8QGAdyXkksvZs/ahmDoLdmMvawkRP LqB78vdrLHYRhEaKeKPjMIIDdTCCAl2gAwIBAgILAgAAAAAA1ni3lAUwDQYJKoZIhvcNAQEEBQAw VzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3Qg Q0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0xNDAxMjgx MjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQL EwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDaDuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6N iY6arymAZavpxy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp 1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVt bNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6x rkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIABjAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDwYDVR0TAQH/BAUwAwEB /zANBgkqhkiG9w0BAQQFAAOCAQEArqqf/LfSyx9fOSkoGJ40yWxPbxrwZKJwSk8ThptgKJ7ogUmY fQq75bCdPTbbjwVR/wkxKh/diXeeDy5slQTthsu0AD+EAk2AaioteAuubyuig0SDH81Qgkwkr733 pbTIWg/050deSY43lv6aiAU62cDbKYfmGZZHpzqmjIs8d/5GY6dT2iHRrH5Jokvmw2dZL7OKDrss vamqQnw1wdh/1acxOk5jQzmvCLBhNIzTmKlDNPYPhyk7ncJWWJh3w/cbrPad+D6qp1RF8PX51TFl /mtYnHGzHtdS6jIX/EBgHcl5JLL2bP2oZg6C3ZjL2sJETy6ge/L3ayx2EYRGinij4zCCA4EwggJp oAMCAQICCwQAAAAAAPB2A+jeMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQK ExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMT HUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAyIENBMB4XDTk5MDEyODEyMDAwMVoXDTA0MDEyODEy MDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEzARBgNVBAsT CkNsYXNzIDIgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24gQ2xhc3MgMiBDQTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA2FFbD5PHSWB3URSO4511dR7JhQ5/TAMZGXak7nor/IMGA8ecFpq+jk4R CkB/rDKJ08F5/PlE0YdTz9vTuy1fKbn6uhH7VKLbxtPmtcCIL7VOAofcy5sZefa/3TR63jOFWugy dc9DYUUN48iHO0cQoeXfLWwHBkf5Ttj79oSeDMMCAwEAAaOBtTCBsjAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUEW7XkWDLBuRXAFeonIC9djPlWVEwOQYDVR0f BDIwMDAuoCygKoYoaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QcmltQ2xhc3MyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwHwYDVR0jBBgwFoAUfOeysSzesadr6XYM4aP9TmzHufYwDQYJKoZIhvcN AQEFBQADggEBAI97Kr0tlyP5Q0cC8eNRGd843faTutQNQrKn56iuz1cOmMOAy24QJkXvRptDuJKr W9qGUc4dMPHkeOVpAmiifCNFqkFG8X+quxCeUP8jLENsyE+mn9w/VbHfmNppA2qWW7aCiRGdmlhJ JmjV/nB/6R+daSzL5BDa3P6wifcxvzbgOy+JZlIutHSgi33Y8ndR9LXOLwAr3SN2ryMYSsYMe9vz smgFNFNFSVORDVeu86GGx2EDnpe+ENMdu/WIAdwtI2x7gf3ljWSihDRm6xCkTVlKEtH/d12hnU8v Tx5o1aFwRnQCs7YOI3NBCBp9O7qlrSAHpFMnAaQU/Q0gN6I+Md0wggOBMIICaaADAgECAgsEAAAA AADwdgPo3jANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEbMBkGA1UECxMSUHJpbWFyeSBDbGFzcyAyIENBMSYwJAYDVQQDEx1HbG9iYWxTaWdu IFByaW1hcnkgQ2xhc3MgMiBDQTAeFw05OTAxMjgxMjAwMDFaFw0wNDAxMjgxMjAwMDBaMF0xCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAyIENB MR4wHAYDVQQDExVHbG9iYWxTaWduIENsYXNzIDIgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANhRWw+Tx0lgd1EUjuOddXUeyYUOf0wDGRl2pO56K/yDBgPHnBaavo5OEQpAf6wyidPBefz5 RNGHU8/b07stXym5+roR+1Si28bT5rXAiC+1TgKH3MubGXn2v900et4zhVroMnXPQ2FFDePIhztH EKHl3y1sBwZH+U7Y+/aEngzDAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFBFu15FgywbkVwBXqJyAvXYz5VlRMDkGA1UdHwQyMDAwLqAsoCqG KGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvUHJpbUNsYXNzMi5jcmwwEQYJYIZIAYb4QgEBBAQD AgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2MA0GCSqGSIb3DQEBBQUAA4IBAQCP eyq9LZcj+UNHAvHjURnfON32k7rUDUKyp+eors9XDpjDgMtuECZF70abQ7iSq1vahlHOHTDx5Hjl aQJoonwjRapBRvF/qrsQnlD/IyxDbMhPpp/cP1Wx35jaaQNqllu2gokRnZpYSSZo1f5wf+kfnWks y+QQ2tz+sIn3Mb824DsviWZSLrR0oIt92PJ3UfS1zi8AK90jdq8jGErGDHvb87JoBTRTRUlTkQ1X rvOhhsdhA56XvhDTHbv1iAHcLSNse4H95Y1kooQ0ZusQpE1ZShLR/3ddoZ1PL08eaNWhcEZ0ArO2 DiNzQQgafTu6pa0gB6RTJwGkFP0NIDeiPjHdMIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJ KoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAO BgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAw MDBaFw0wOTAxMjgxMjAwMDBaMG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52 LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJp bWFyeSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdB bvzYvyFvqwadUsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq6 2O7rim+ftrsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/ 7h0MxKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl/3BQ 9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAqMCigJqAkhiJo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAv fQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2ZioidZVbZLmecRI30bfezE8W YEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGBqGQzlPGtnVpbADfipFzkIKpg dJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCWkf7KDCruRY51KismvY6uCN2LuVeN /20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFqFEiluobJ33wmE54tbMhb9Wt8HzhnL47U 16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGdVAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqB MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds b2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBaMG0xCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNz IDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAyIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwadUsEsAJ0/joW4f0qPvaBjKspJ J65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+ftrsoQcAi+05IGgaS17/Xz7nZvThP Ow1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0MxKhrT3VoVujcKBJQ96gknS4kOfsJBd7l o2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbje TVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl/3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZ MIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vp dgzho/1ObMe59jAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jv b3QuY3JsMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IB AQCOSXXBWIDxAxy2ZioidZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx /g3oQt8hUCLucQGBqGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYt vi9PKFx5qeCWkf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziN L3Ur1HFqFEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2m MhGdVAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMYIBtzCCAbMCAQEwbDBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMiBDQTEeMBwGA1UE AxMVR2xvYmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAADxFhz5dTAJBgUrDgMCGgUAoIGiMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIxMTcxNVowIwYJKoZI hvcNAQkEMRYEFL9Z1gw/ncVI9YmdmD5cuYquJ+tsMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0w DgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIGASzySuWFtpSD8ZPlSa4nqulm37TtiZ2qi2c4xx9IgUNk7AeUUTL8+u4gagdUXJAliEU7Jm5ye HSxasmDf6FW2Z2aQY8yTpEdKwQmbbz4szaw63Sv4SNOAu7FLn9La7i0c/xl5inbeQVSH8NiXOkiu 1ypcAcRo+0wpqY+UXzx4on0AAAAA ---------z2829_boundary_sign-- From owner-ietf-smime@mail.imc.org Mon Aug 11 20:24:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11667 for ; Mon, 11 Aug 2003 20:24:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNtuqt087687 for ; Mon, 11 Aug 2003 16:55:56 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNtuSu087685 for ietf-smime-bks; Mon, 11 Aug 2003 16:55:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNttqt087678 for ; Mon, 11 Aug 2003 16:55:55 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7BNtvil028240; Mon, 11 Aug 2003 16:55:57 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 16:55:57 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'jpierre@netscape.com'" , ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Mon, 11 Aug 2003 16:55:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0034_01C36042.904784A0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C36042.904784A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This issue is one of the main use cases for XKMS. This has considerable support within the PKI community, VeriSign, Microsoft, RSA, Entrust and Baltimore have been involved in writing the specification which is in the final post last call stage in W3C. The (almost) final spec is to be found at http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html There will be two further changes to the spec, one to make a minor tweak to the schema sometime this week, the second to change the examples to use exclusive C18N. An XKMS locate service may be advertised in the DNS using the SRV record. So to send mail to alice@example.com you do an XKMS locate to _xkms_http._tcp.example.com. That gives you the XKMS service. You then do a locate for a certificate to be used with S/MIME. Phill > -----Original Message----- > From: jpierre@netscape.com [mailto:jpierre@netscape.com] > Sent: Friday, August 08, 2003 10:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my > responsibilities > for several years has been to maintain the open source > Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The > NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. > > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient > S/MIME e-mail > encryption certificates ? > > Thanks. > > > ------=_NextPart_000_0034_01C36042.904784A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILizCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICED71tdHM9i4jiA298PD00EgwDQYJKoZIhvcN AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTAzMDMwNjAwMDAwMFoXDTA0MDMwNTIzNTk1OVowbTERMA8GA1UEChMIVkVS SVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFrZXIg KEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALnb2fFyN844Cl9FoNaBDI8P+O4JliUWbYoS/H5ebiL9BiGWuVAXoo1TAaB/SHU6 Sw12kMz9z7gL+HW09pG9kofKMikS3baa49tG5t/Ap7wOnVNmLgelD5d/JuYi3d5J94N9qh2krJqP auD5FjEbnTQ/Op2NHQzivxnE+g0cdDLJAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRS MFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFu Z2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJha2Vy QHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCi33oiw4urer1XI46PtYSjUD2W43Q+Ez8T9XJo Ewtc3mfUOuEw/PAH7VU3pLjUm6QfGe6W3xRzedAhAWzG1mWKK5vAq4Nnu8tpIV14PdxeXfKWM1Z0 Jw/1MHijGcoqLU9i3a1HYz/pF2A7/mibKe8Le+nJXV5q+XSAaL7K1ZcV3zGCAvgwggL0AgEBMIHB MIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQQIQPvW10cz2LiOIDb3w8PTQSDAJBgUrDgMCGgUAoIIBjDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTEyMzU1NTBaMCMGCSqGSIb3DQEJBDEWBBQ8kk0t G7LzjA5g2iX4qwOGBhrf/TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYB BAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh c3MgMiBFbXBsb3llZSBDQQIQPvW10cz2LiOIDb3w8PTQSDANBgkqhkiG9w0BAQEFAASBgJ/ZRRua wcpRB9Gj17UEhIJ/w1XYMh7riw2AwvvbEDfYo/gTGDuRHWZGm6LvMmx10qCJNPUGP7+espvl+iyY J3Z/TfwePbeY6B2qfeHhOrVgXUJqYy/wDWjjccRq6+H+vP58TDRRYls7bfvpCtfVb2YK9fJVKts7 Tt9MlPgsudo8AAAAAAAA ------=_NextPart_000_0034_01C36042.904784A0-- From owner-ietf-smime@mail.imc.org Tue Aug 12 07:58:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09862 for ; Tue, 12 Aug 2003 07:58:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CBQXqt058444 for ; Tue, 12 Aug 2003 04:26:33 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CBQXW5058443 for ietf-smime-bks; Tue, 12 Aug 2003 04:26:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CBQQqt058432 for ; Tue, 12 Aug 2003 04:26:31 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7CBQFdk023178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 12 Aug 2003 13:26:15 +0200 To: "Alberto Cozer" Cc: jpierre@netscape.com (Julien Pierre), ietf-smime@imc.org Subject: Re: dissemination of public encryption certificates References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030812:acozer@fti.com.br:c720615954f0da08 X-Hashcash: 0:030812:acozer@fti.com.br:c720615954f0da08 X-Payment: hashcash 1.2 0:030812:jpierre@netscape.com:3eff6f14a0f2077e X-Hashcash: 0:030812:jpierre@netscape.com:3eff6f14a0f2077e X-Payment: hashcash 1.2 0:030812:ietf-smime@imc.org:79512a673eba340a X-Hashcash: 0:030812:ietf-smime@imc.org:79512a673eba340a Date: Tue, 12 Aug 2003 13:26:15 +0200 In-Reply-To: (Alberto Cozer's message of "Tue, 12 Aug 2003 18:19:00 -0300") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien, Alberto, There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538. Unfortunately it doesn't include useful RR owner name guidelines to make it work in practice. I have made some clarifications for this in http://josefsson.org/draft-josefsson-pkix-dns.txt which also includes recommended owner names for S/MIME certificates. The document has expired on the IETF servers, but if there is interest in picking up this, let me know. (The idea has been implemented in experimental environments. Similar solutions for OpenPGP are freely available. I did my master's thesis on distributing certificate via DNS, to allow for "opportunistic email encryption".) Regards, Simon "Alberto Cozer" writes: > Julien, > > I have seen this idea in the past, but so far no RFC nor any agency > officialy documented it. We should have an hierarchical structure for > public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy > itself could be used for that. We could have a new DNS record type (DRY, > from Directory, for instance). Then, as mail servers and clients consult > MX record to deliver a message they could check for the DRY record to > deliver S/MIME messages. Without this DRY record set in the DNS zone file, > must be possible to deliver a signed message but impossible to deliver an > encrypted one. > > In my oppinion it is really hard to solve the public keys problem without > changing the way people send e-mails. With minor changes in the DNS and > E-MAIL RFC's would be possible to have people sending and receiving > encrypted mail transparently in a couple of years. > > Best regards, > > Alberto Cozer > Security Outsource Director, Future Technologies Digital Security > IBM Certified AIX System Specialist > Checkpoint Certified Security Expert, CCSE NG > acozer@fti.com.br > http://www.fti.com.br > Tel / Fax: 55 (21) 2522-5362 > > > > > > > jpierre@netscape.com (Julien Pierre) > Sent by: owner-ietf-smime@mail.imc.org > 08/08/2003 23:07 > > To: ietf-smime@imc.org > cc: > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my responsibilities > for several years has been to maintain the open source Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to send encrypted > e-mail to somebody knowing his e-mail address, what's a systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to transmit the > public encryption certificate before both parties can exchange encrypted > messages. > > There are also ways to find recipient certificates today using corporate > directory servers, but users must know about them and manually configure > them in their applications, and they are typically not widely available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient S/MIME e-mail > encryption certificates ? > > Thanks. From owner-ietf-smime@mail.imc.org Tue Aug 12 12:57:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21443 for ; Tue, 12 Aug 2003 12:57:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGX0qt085744 for ; Tue, 12 Aug 2003 09:33:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CGX0FA085743 for ietf-smime-bks; Tue, 12 Aug 2003 09:33:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGWxqt085730 for ; Tue, 12 Aug 2003 09:32:59 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t10o913p62.telia.com [213.64.27.182]) by smtp2.fre.skanova.net (8.12.9/8.12.9) with SMTP id h7CGWooe016255; Tue, 12 Aug 2003 18:32:50 +0200 (CEST) Message-ID: <001301c360ef$41128990$0500a8c0@arport> From: "Anders Rundgren" To: "Julien Pierre" , Cc: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> Subject: Re: dissemination of public encryption certificates Date: Tue, 12 Aug 2003 18:31:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pierre, It is good to hear somebody bring up this question which is absolutely vital for successful deployment of encrypted mail. Personally I don't think that neither the S/MIME WG or XKMS WG have a solution that at least I would call "acceptable". XKMS addresses to some extent the enterprise scenario but only if the enterprise has their own domain and associated CA. For truly TTP-based certificates you are out of luck if you are looking for automated functionality. I believe that the mail protocol and associated applications should be augmented with encryption certificate lookup. A MIME X-extension that you configured in your e-mail client would do a part of this. I.e. each time you sent a mail, the lookup would be transmitted as well. Also it would be nice to have an enhanced "mailto:" URL supporting the same mechanism. In summary I think that a certificate-independent configuration of e-mail clients would be more universal than "fishing" in domains as the user domain and issuer domain may be entirely disjunct. Anders ----- Original Message ----- From: "Hallam-Baker, Phillip" To: ; Sent: Tuesday, August 12, 2003 01:55 Subject: RE: dissemination of public encryption certificates Hi, This issue is one of the main use cases for XKMS. This has considerable support within the PKI community, VeriSign, Microsoft, RSA, Entrust and Baltimore have been involved in writing the specification which is in the final post last call stage in W3C. The (almost) final spec is to be found at http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html There will be two further changes to the spec, one to make a minor tweak to the schema sometime this week, the second to change the examples to use exclusive C18N. An XKMS locate service may be advertised in the DNS using the SRV record. So to send mail to alice@example.com you do an XKMS locate to _xkms_http._tcp.example.com. That gives you the XKMS service. You then do a locate for a certificate to be used with S/MIME. Phill > -----Original Message----- > From: jpierre@netscape.com [mailto:jpierre@netscape.com] > Sent: Friday, August 08, 2003 10:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my > responsibilities > for several years has been to maintain the open source > Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The > NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. > > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient > S/MIME e-mail > encryption certificates ? > > Thanks. > > > From owner-ietf-smime@mail.imc.org Tue Aug 12 23:14:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08701 for ; Tue, 12 Aug 2003 23:14:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2lVqt023796 for ; Tue, 12 Aug 2003 19:47:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2lVdD023795 for ietf-smime-bks; Tue, 12 Aug 2003 19:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2lUqt023778 for ; Tue, 12 Aug 2003 19:47:30 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 12 Aug 2003 19:47:27 -0700 From: "Blake Ramsdell" To: Cc: "'Sean P. Turner'" Subject: PKI and S/MIME Date: Tue, 12 Aug 2003 19:47:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There have been a number of messages recently about the use of PKI with S/MIME, and the concerns about that. I like to think that we're all pretty much in agreement that we've established a consistent, interoperable practice for the actual syntax and contents of S/MIME messages, as well as a reasonable cut of a certificate syntax profile for end-entity certificates. Should there be a profile for certificate usage (certificate repository, distribution and revocation checking) that is specific for our problem domain? That is, select relevant other work and profile it for use in the S/MIME interpersonal messaging domain? I would imagine that this would be a new draft, start with a summary of the requirements, and progress to profiles of relevant standards. It's also not clear if this is something to discuss in this working group, or somewhere else. Comments? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Wed Aug 13 04:04:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11872 for ; Wed, 13 Aug 2003 04:04:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D7WPqt047965 for ; Wed, 13 Aug 2003 00:32:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D7WPfH047964 for ietf-smime-bks; Wed, 13 Aug 2003 00:32:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D7WMqt047949 for ; Wed, 13 Aug 2003 00:32:23 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7D7WGdk014631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 13 Aug 2003 09:32:17 +0200 To: "Blake Ramsdell" Cc: , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:2904f722dfddfbf5 X-Hashcash: 0:030813:blake@brutesquadlabs.com:2904f722dfddfbf5 X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:0cf67d0c6ed0a93f X-Hashcash: 0:030813:ietf-smime@imc.org:0cf67d0c6ed0a93f X-Payment: hashcash 1.2 0:030813:turners@ieca.com:d13a99f396e04eda X-Hashcash: 0:030813:turners@ieca.com:d13a99f396e04eda Date: Wed, 13 Aug 2003 09:32:16 +0200 In-Reply-To: (Blake Ramsdell's message of "Tue, 12 Aug 2003 19:47:28 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > There have been a number of messages recently about the use of PKI with > S/MIME, and the concerns about that. I like to think that we're all > pretty much in agreement that we've established a consistent, > interoperable practice for the actual syntax and contents of S/MIME > messages, as well as a reasonable cut of a certificate syntax profile > for end-entity certificates. > > Should there be a profile for certificate usage (certificate repository, > distribution and revocation checking) that is specific for our problem > domain? That is, select relevant other work and profile it for use in > the S/MIME interpersonal messaging domain? I would imagine that this > would be a new draft, start with a summary of the requirements, and > progress to profiles of relevant standards. > > It's also not clear if this is something to discuss in this working > group, or somewhere else. > > Comments? Since in practice, addressing this problem would help in getting "opportunistic S/MIME" to work, I believe it would be useful to address it. ("Opportunistic S/MIME" means to be able to encrypt messages to someone you don't have a prior trust relationship with, simply to provide encryption of data. There is a man in the middle attack, of course, but in practice the result often isn't worse than not using S/MIME.) A strawman at a requirement: * Be able to locate a certificate for a Internet user given only her email address. I should mention that this has been discussed several times before, in various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so there is prior work to look at how to design this. To do even more self-promoting, I'd again like to mention the following draft: http://josefsson.org/draft-josefsson-pkix-dns.txt which do discuss it for S/MIME context as well. I don't have an opinion on if this WG is the proper place for it. Regards, Simon From owner-ietf-smime@mail.imc.org Wed Aug 13 13:46:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27515 for ; Wed, 13 Aug 2003 13:46:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHHeqt000448 for ; Wed, 13 Aug 2003 10:17:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DHHe7x000447 for ietf-smime-bks; Wed, 13 Aug 2003 10:17:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHHcqt000431 for ; Wed, 13 Aug 2003 10:17:39 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t8o913p20.telia.com [213.64.26.140]) by smtp1.fre.skanova.net (8.12.9/8.12.9) with SMTP id h7DHHJqJ014039; Wed, 13 Aug 2003 19:17:20 +0200 (CEST) Message-ID: <006901c361be$9f4ba080$0500a8c0@arport> From: "Anders Rundgren" To: "Blake Ramsdell" , "Simon Josefsson" Cc: , "'Sean P. Turner'" References: Subject: Re: PKI and S/MIME Date: Wed, 13 Aug 2003 19:16:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Simon, I respect your work with DNS for location but is this really universal? How about my anders.rundgren@telia.com cert issued by VeriSign? Would it be appropriate to require ISPs like Telia to maintain a directory pointing to various TTP CAs? Or should ever domain-owner become a CA? Anders ----- Original Message ----- From: "Simon Josefsson" To: "Blake Ramsdell" Cc: ; "'Sean P. Turner'" Sent: Wednesday, August 13, 2003 09:32 Subject: Re: PKI and S/MIME "Blake Ramsdell" writes: > There have been a number of messages recently about the use of PKI with > S/MIME, and the concerns about that. I like to think that we're all > pretty much in agreement that we've established a consistent, > interoperable practice for the actual syntax and contents of S/MIME > messages, as well as a reasonable cut of a certificate syntax profile > for end-entity certificates. > > Should there be a profile for certificate usage (certificate repository, > distribution and revocation checking) that is specific for our problem > domain? That is, select relevant other work and profile it for use in > the S/MIME interpersonal messaging domain? I would imagine that this > would be a new draft, start with a summary of the requirements, and > progress to profiles of relevant standards. > > It's also not clear if this is something to discuss in this working > group, or somewhere else. > > Comments? Since in practice, addressing this problem would help in getting "opportunistic S/MIME" to work, I believe it would be useful to address it. ("Opportunistic S/MIME" means to be able to encrypt messages to someone you don't have a prior trust relationship with, simply to provide encryption of data. There is a man in the middle attack, of course, but in practice the result often isn't worse than not using S/MIME.) A strawman at a requirement: * Be able to locate a certificate for a Internet user given only her email address. I should mention that this has been discussed several times before, in various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so there is prior work to look at how to design this. To do even more self-promoting, I'd again like to mention the following draft: http://josefsson.org/draft-josefsson-pkix-dns.txt which do discuss it for S/MIME context as well. I don't have an opinion on if this WG is the proper place for it. Regards, Simon From owner-ietf-smime@mail.imc.org Wed Aug 13 18:33:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09910 for ; Wed, 13 Aug 2003 18:33:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM5tqt015325 for ; Wed, 13 Aug 2003 15:05:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DM5tw5015323 for ietf-smime-bks; Wed, 13 Aug 2003 15:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM5rqt015304 for ; Wed, 13 Aug 2003 15:05:53 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 13 Aug 2003 15:05:50 -0700 From: "Blake Ramsdell" To: "'Anders Rundgren'" , "'Simon Josefsson'" Cc: , "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Wed, 13 Aug 2003 15:05:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <006901c361be$9f4ba080$0500a8c0@arport> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, August 13, 2003 10:16 AM > To: Blake Ramsdell; Simon Josefsson > Cc: ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? One thing to keep in mind is that I'm not sure that there is any clear "universality" for *any* protocol that we might consider -- if there existed something universal, we'd have a de facto standard that we'd simply convert to an RFC and be done with it. If I were going to hazard a guess about widely deployed public certificate repositories, I would say that there would be a better argument for LDAP than anything else. Notice the careful wording here ;). As much as the attempts to automatically map from an email address to an LDAP directory containing a certificate for that email address might not have progressed as well as we might like, I think that there is some hope of that being addressed through the SRV record which is (as far as I can tell) widely supported by DNS implementations. A better question for the DNS distribution of certificates is whether or not this smells like it would be the most likely thing to get deployed. My understanding is that you would need DNS servers that supported the particular record types required for this functionality, as well as administrative tools to upgrade those records that are different than typical DNS administration tools. To me, that doesn't smell as good. Blake From owner-ietf-smime@mail.imc.org Wed Aug 13 19:14:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10728 for ; Wed, 13 Aug 2003 19:14:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMovqt018869 for ; Wed, 13 Aug 2003 15:50:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMovKH018868 for ietf-smime-bks; Wed, 13 Aug 2003 15:50:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMouqt018863 for ; Wed, 13 Aug 2003 15:50:56 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DMomD22772 for ; Wed, 13 Aug 2003 15:50:48 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKY4300.X5O; Wed, 13 Aug 2003 15:50:27 -0700 Date: Wed, 13 Aug 2003 15:51:44 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Blake Ramsdell" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC100.8080103@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Sorry for the long delay in response - workload goes in spikes... Blake Ramsdell wrote on 08/08/2003, 19:41: > > My main question is : has any similar scheme been proposed ? I would > > rather work with something that exists, but if there is nothing that > > fits, I'm open to writing an RFC. > > Check out PKIX. They're not taking new drafts, but there may be > something useful for you there. Any work along these lines would most > likely be handled by that working group. Thanks. I joined the PKIX list and will keep an eye on the related drafts. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMjUxNDRaMCMGCSqGSIb3DQEJBDEWBBQRlErZ yGtWAA6ErujbBwOxguAa0jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQAWhgV4CTxNLqCgdRlLD3vi/46cvqxlMgGxZZIvFPdX0okyVgoA8IZ14u2S CCSvzKmqYsX66rsccCHo0q2kzn13qNyqy3nGsfeXsvkgbhmmtOKQUbNe19CTmSz1uXb25VPJ h2jaucbGrgphxSwURuW9cR0AzfFfoBqjPy8eGT81FlL8uiRnX+pUI6yfDF+mJzAvzGSFselO qqmS6Yj39zKlK7sCbDBW8v2VAUMWvz9fBReYuABt3+xu19Mj3fu+k0l5e6Wbb4lu/hH9+9Ws lLN+1rYhrbK2TZohWqDlpxpRP3lABg/CeguJHOIg7wfTvf632qSb5CsEYJb6woC1mjtdAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Wed Aug 13 19:30:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11034 for ; Wed, 13 Aug 2003 19:30:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN65qt019231 for ; Wed, 13 Aug 2003 16:06:05 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DN65eH019230 for ietf-smime-bks; Wed, 13 Aug 2003 16:06:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN63qt019225 for ; Wed, 13 Aug 2003 16:06:03 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7DN5rdk029769 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 14 Aug 2003 01:05:53 +0200 To: "Anders Rundgren" Cc: "Blake Ramsdell" , , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: <006901c361be$9f4ba080$0500a8c0@arport> From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:anders.rundgren@telia.com:d22d10f4fbc624cb X-Hashcash: 0:030813:anders.rundgren@telia.com:d22d10f4fbc624cb X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:5292953ee89c9b12 X-Hashcash: 0:030813:blake@brutesquadlabs.com:5292953ee89c9b12 X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:c9f896028ba5f801 X-Hashcash: 0:030813:ietf-smime@imc.org:c9f896028ba5f801 X-Payment: hashcash 1.2 0:030813:turners@ieca.com:07e5266f3de80115 X-Hashcash: 0:030813:turners@ieca.com:07e5266f3de80115 Date: Thu, 14 Aug 2003 01:05:53 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, you are right, it doesn't solve all problems. However, in some situations all you have is the email address of the recipient, and in those situations locating the certificate through DNS is simpler than many alternatives. The certificate can be located directly, like RFC 2538, or indirectly using SRV pointers to LDAP or XKMS servers. In either case, your ISP could add those DNS records as yet another step in setting up an email account. One potential advantage of storing certificates directly in DNS a'la RFC 2538 would be that if we ever get DNSSEC, the certificate you receive would be integrity protected. (Whereas a SRV would only provide you with a integrity protected name of the LDAP host.) Regards, Simon "Anders Rundgren" writes: > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? > > Anders > > ----- Original Message ----- > From: "Simon Josefsson" > To: "Blake Ramsdell" > Cc: ; "'Sean P. Turner'" > Sent: Wednesday, August 13, 2003 09:32 > Subject: Re: PKI and S/MIME > > > > "Blake Ramsdell" writes: > >> There have been a number of messages recently about the use of PKI with >> S/MIME, and the concerns about that. I like to think that we're all >> pretty much in agreement that we've established a consistent, >> interoperable practice for the actual syntax and contents of S/MIME >> messages, as well as a reasonable cut of a certificate syntax profile >> for end-entity certificates. >> >> Should there be a profile for certificate usage (certificate repository, >> distribution and revocation checking) that is specific for our problem >> domain? That is, select relevant other work and profile it for use in >> the S/MIME interpersonal messaging domain? I would imagine that this >> would be a new draft, start with a summary of the requirements, and >> progress to profiles of relevant standards. >> >> It's also not clear if this is something to discuss in this working >> group, or somewhere else. >> >> Comments? > > Since in practice, addressing this problem would help in getting > "opportunistic S/MIME" to work, I believe it would be useful to > address it. ("Opportunistic S/MIME" means to be able to encrypt > messages to someone you don't have a prior trust relationship with, > simply to provide encryption of data. There is a man in the middle > attack, of course, but in practice the result often isn't worse than > not using S/MIME.) > > A strawman at a requirement: > > * Be able to locate a certificate for a Internet user given only her > email address. > > I should mention that this has been discussed several times before, in > various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so > there is prior work to look at how to design this. To do even more > self-promoting, I'd again like to mention the following draft: > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which do discuss it for S/MIME context as well. I don't have an > opinion on if this WG is the proper place for it. > > Regards, > Simon From owner-ietf-smime@mail.imc.org Wed Aug 13 19:32:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11118 for ; Wed, 13 Aug 2003 19:32:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN9Pqt019344 for ; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DN9P9r019343 for ietf-smime-bks; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN9Pqt019330 for ; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DN9LD24290 for ; Wed, 13 Aug 2003 16:09:21 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKYZ101.55R; Wed, 13 Aug 2003 16:09:01 -0700 Date: Wed, 13 Aug 2003 16:10:17 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: trust domains To: "Blake Ramsdell" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC559.8030403@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Blake Ramsdell wrote on 08/08/2003, 20:44: > > This seems to be a question of certificate policies and mapping those to > the content being protected. That is, if the message being signed is > just casual communication, use one certificate, and if it's a purchase > order, use another one. Right now, I think that most clients pretty > much allow the user to pick. Further, I think that a lot of folks just > have one, so you'd better like it. It is indeed a question of policy, and the example you point out is a good one. Similarly, for internal communications within a company, I shouldn't use my freemail Thawte cert. The internal SSL web servers which require client auth don't accept that certs. Yet mail client accept it just fine. The specific application I'm interested in is e-mail spam filtering based on certificates. You could choose to trust some free CAs (such as Thawte) if you like to receive anonymous email, otherwise restrict to a set of CAs with a more stringent policy (eg. those that require you to pay for the certificate). As far as the number of certificates, I think most folks have zero today, not one. Some will have one, issued by their employer (corporate, or government/military typically). Then there are hobbyists or security professionals like us who may have dozens of certificates. Nowhere does Joe User fit today, because PKI is not widely deployed. Most questions I'm asking are in the context of a very large-scale PKI deployment happening. The problems may not be so obvious unless you get to that point. > Well, I'm not sure that the semantic of multiple SignerInfos is that "if > you verify them, you must verify all of them, and if you don't like any > of them, freak out". I think it's more along the lines of "these are > all equivalent, so go ahead and choose which one you like and run with > it". Where would that be specified ? I would think this would be completely up to the application. If I chose to sign mail with both my personal cert and corporate cert, I know I wouldn't treat each signature in the same way. Eg. if I am an employee, I might not care about the personal cert's signature failing, but care about the corporate cert signature. > This might be interesting to discuss. You could make a capabilities > extension where you could identify your roots (off the top of my head, > I'd say using a hash of the certificate would work) and go from there. > One concern is bloat -- I have over 100 roots on my machine configured > with Outlook 2002 and IE6 that are all marked as suitable roots for > "Secure email" (in the "secure email" trust domain, using your terms). > Sending this stack of hashes with every signed message might make the > world a worse place to address this issue. I think it would be a very bad thing to embed all the root certificates in each S/MIME signature. The signatures are already quite big enough as they are. I know the number of trusted roots can be quite high - it is also high in Netscape products. What I'm getting to is more along the lines of : 1) defining a standard ASN.1 structure to define the user's trusted roots policy WRT email. That structure will most likely be too large to embed in signatures. 2) there may be a set of rules that goes along with the roots. Just having roots trusted may not be right. Eg. my colleagues shouldn't trust email signed with my Thawte cert with jpierre@netscape.com in it, it should be signed with the Netscape CA ... This one I really haven't given much thought to. 3) Some mechanism for transporting that trust structure. I would suggest LDAP, but that requires a standard mechanism to get to it, just like we need a standard means for disseminating certificates > I think the principle is the same, though. It's very similar, with the possible exceptions of the rules (see above). > In the case of S/MIME, it's > "sign with all of your certs". One problem is that you're going to > potentially cart around a large number of certs -- each of your > individual certs as well as the intermediate certs that go with them. > And I'm not sure that there's enough experience with clients handling > multiple signers to tell you what would happen if you used that feature. Definitely not today - multiple signatures is something that would need to be added to most S/MIME software and would hamper deployment. > >From what I can tell, today we solve the problem by having clients > include every root key under the sun, It's worse than that, some SSL intermediate certs are also included with some software (IE) ... Many SSL servers are misconfigured and don't send their intermediate certs. > and most certificates of > significant public value are issued under those roots. Certificates > that aren't issued under those roots are most likely corporate CA > certificates, and typically folks just have to hunt around to find the > right corporate root to install in order to verify the signatures. > Peter Hesse and Sharon Boeyen have recently illustrated this problem on > the PKIX list -- not directly, but by sending signed messages for which > people don't have the root keys. This is a case where the trust domain could be useful. Eg. the mailing list alias could have a defined trust domain, and their software would know not to use that private cert when posting to the list. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzEwMThaMCMGCSqGSIb3DQEJBDEWBBS46d6u fyuKdkxQ1EnSfebXBrY4NDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQBFI76b+dsTBfdKm/KHUKJxVzXiMCVGyAJsFmewRLpFX5H+tYrk6utIQZWR 6tsbc683LVkK8MmNoxuowv3rpuSbwpjPfy3Lj5at68tDw4iQBBfNjNBcAaZS2GmvscfzgSYz 79WKavLfYc+e2Kjji8ixfl0GdPYCEobmJ2oTERU55OvBXnYKlw9gEHE3scAQXij+OrcyW3eR tFOptc1UZIsvaXzcp/fuFzgxxxqKM0N/9nqrPBgtrH6CALl24MZyZ5+cfe+rhc8jZHM3OkRV 6qwgAi3Oh2hRVoADVMHJ5TriWfypb8u1AAk82jYizdOsPpGDYPyAtqgm7jB+jhi+ClnMAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Wed Aug 13 19:41:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11383 for ; Wed, 13 Aug 2003 19:41:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNFtqt019655 for ; Wed, 13 Aug 2003 16:15:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNFtao019654 for ietf-smime-bks; Wed, 13 Aug 2003 16:15:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNFsqt019646 for ; Wed, 13 Aug 2003 16:15:54 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNFpD25096 for ; Wed, 13 Aug 2003 16:15:51 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZ9V00.Q6L; Wed, 13 Aug 2003 16:15:31 -0700 Date: Wed, 13 Aug 2003 16:16:47 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: trust domains To: "Alberti Antoine" cc: "'ietf-smime@imc.org'" In-Reply-To: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> Message-ID: <3F3AC6DF.10603@netscape.com> References: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Alberti, Alberti Antoine wrote on 08/11/2003, 1:50: > There was such an issue in TLS, solved, from the server point of view, by > sending a list of trusted authorities when requesting a client > authentication. However, this list was so ennoying to use for both sides > that it is now almost always empty, indicating "Send me whatever you > want, > we'll see then". > I agree that a work could be done on this topic, but it should done > carefully to avoid this conclusion. I'm aware of the change that was made recently to TLS to allow an empty list of trusted certificates to be sent by the SSL server. I don't personally like this change at all and considered very useful in SSL client authentication. This provision means that to login to such servers, I'm now presented with a list of 12 certificates to choose from, with absolutely no hint about which one is correct, instead of having the right one automatically chosen by the application, or at least a list of valid ones if there are several matches. This is what I call shooting oneself in the foot. Some server administrators are probably too lazy to install the valid trusted roots. My opinion is that they probably shouldn't be running PKI servers. Eventually after the client auth login, the code in the SSL server is going to have to check if the client certificate is valid anyway, and that operation will require the trusted root to be installed. If the check does not involve a particular issuing root, there are many spoof attacks I can think of against such SSL servers ... -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzE2NDdaMCMGCSqGSIb3DQEJBDEWBBQ+zlfn 5qf8GXuXhtFWyMb/BuF0oTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQCIkDWQupjr0mnnm50HR+HnC6Jp9p13zTWwzVNMl6lRTADAcIcp3AUqu1Fc YOz2FFj9dBUs/Al3QCqSNTOzizE2vJJlOp7s27d4/bCnXec2eJZhIP2ULcYyQ9aEMlFw/r5D wfioaHsVp5fY+vTcothCkUcrwJypjghZsK+dEQmDQYSDrPjFVDfUqJLRnRxTv9iZFpoHL/gs zDxtSi1Rk4kIe/prPBbE8RVT9Ba3ly4LiPsinmzX46O1FlNkKv+3Imo2b5ZTTQ7B5fowGLsa eFyLOZTUPQsQAOqjN8L9dkfpz5/l1s5iAkr/2gzSi1e9jRR6hU6g03hMLMcuQ5q1GF1eAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Wed Aug 13 19:41:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11403 for ; Wed, 13 Aug 2003 19:41:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNIiqt019768 for ; Wed, 13 Aug 2003 16:18:44 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNIiD3019767 for ietf-smime-bks; Wed, 13 Aug 2003 16:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNIhqt019761 for ; Wed, 13 Aug 2003 16:18:43 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNIW315159 for ; Wed, 13 Aug 2003 16:18:33 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZEJ01.Z70; Wed, 13 Aug 2003 16:18:19 -0700 Date: Wed, 13 Aug 2003 16:19:36 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Hallam-Baker Phillip" cc: ietf-smime@imc.org In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> Message-ID: <3F3AC788.7070508@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Philip, Hallam-Baker, Phillip wrote on 08/11/2003, 16:55: > This issue is one of the main use cases for XKMS. This has > considerable support within the PKI community, VeriSign, Microsoft, RSA, > Entrust and Baltimore have been involved in writing the specification > which is in the final post last call stage in W3C. > > The (almost) final spec is to be found at > http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html > http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html > > There will be two further changes to the spec, one to make a > minor tweak to the schema sometime this week, the second to change the > examples to use exclusive C18N. > > An XKMS locate service may be advertised in the DNS using the > SRV record. So to send mail to alice@example.com you do an XKMS locate > to _xkms_http._tcp.example.com. > That gives you the XKMS service. > > You then do a locate for a certificate to be used with S/MIME. Thanks. This is very interesting and I will need to read more on XKMS. Until I do, you may be able to answer the following question : can the XKMS be easily delegated by the domain owner to a third party in the DNS, just like mail and web services usually are typically delegated today ? It certainly looks like it from the above, but I just want a confirmation. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzE5MzZaMCMGCSqGSIb3DQEJBDEWBBSNzqdq ZBANu8MsXVYSvILvpyaLTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQAOhhg/DNynGt4MXVeCRTy8HDR1pRyzkk6Cp0vJvaIYET+UbQ7s+lUEXcFB Z0Wq5h0JeMh94G1EKkM4V2aiZF+iBfDbp2zRXZX63QJBtIbrxfJrTBANuAdzp4GF6Uv02GVp H1t9yj7gbBRN4A1x+v1fbtIdKLplWZrwIhSLtGIkf0h+FM2s2+bJ71VkidaiXeg8/liH8u7S SAPOz9jgS4qkHDDmF+2/dnkMHUBcEzRX7b1Zgk0ePekuGIkn81lpPR2VG5ISYwRe+R9oZe6e 2Pn6+yJ2/hKdWSUmdbfnFUmsR2jBpTR6ogDbTemylZl8JVK72+pTqmBSz1vpPLZQs29CAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Wed Aug 13 19:43:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11446 for ; Wed, 13 Aug 2003 19:43:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMsqt019916 for ; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNMs5U019915 for ietf-smime-bks; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMsqt019909 for ; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNMi315475 for ; Wed, 13 Aug 2003 16:22:44 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZLI02.K7A; Wed, 13 Aug 2003 16:22:30 -0700 Date: Wed, 13 Aug 2003 16:23:47 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Simon Josefsson" cc: "Alberto Cozer" , ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC883.7000108@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Simon, Simon Josefsson wrote on 08/12/2003, 4:26: > Julien, Alberto, > > There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538. > > Unfortunately it doesn't include useful RR owner name guidelines to > make it work in practice. I have made some clarifications for this in > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which also includes recommended owner names for S/MIME certificates. > Thanks. This is very useful and I will look into it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzIzNDdaMCMGCSqGSIb3DQEJBDEWBBT5XiEL cNOjSi6ranFoUOBNcUNJPjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQC2ibwYdwLQEIWB7BGWdwMTckFC7SxSvEgbqqvil1I1fEhym9edQxYpwTLe 883NMTwhwmNEOYeRyscA+dy+bCN9UCkdAorK6DICuZDrRojHXHpRqGKg7TsLyCXjq/LxOjqa So7f4HNE9zlFfNwcu7+RsWXWTEa8Gd+0w8N9b42KvBt7c7rDfo7PDlTVIrhvbrpc9j9OhQj/ JjE1jlyqb4r5/7iZ1OeP6CZTQhKcK4OdeuyzQRzO6Vyy8qZ4LdccGsUBuW8KXjrY3Kyro4hO UBBDWwy7yOWzh+4hs2oHrqWEX8JPbJuWmpLe+wAvvmUQ4bBqssQ3E50+LZl3KUL6b0JjAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Wed Aug 13 20:09:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12186 for ; Wed, 13 Aug 2003 20:09:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNjuqt021584 for ; Wed, 13 Aug 2003 16:45:56 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNju9W021583 for ietf-smime-bks; Wed, 13 Aug 2003 16:45:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNjsqt021577 for ; Wed, 13 Aug 2003 16:45:55 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7DNjpdk030384 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 14 Aug 2003 01:45:52 +0200 To: "Blake Ramsdell" Cc: "'Anders Rundgren'" , , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:335740bf15304fc1 X-Hashcash: 0:030813:blake@brutesquadlabs.com:335740bf15304fc1 X-Payment: hashcash 1.2 0:030813:anders.rundgren@telia.com:d7a624837cfa94fb X-Hashcash: 0:030813:anders.rundgren@telia.com:d7a624837cfa94fb X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:3d737b7ac6bfa688 X-Hashcash: 0:030813:ietf-smime@imc.org:3d737b7ac6bfa688 X-Payment: hashcash 1.2 0:030813:turners@ieca.com:47a8f772f4360518 X-Hashcash: 0:030813:turners@ieca.com:47a8f772f4360518 Date: Thu, 14 Aug 2003 01:45:51 +0200 In-Reply-To: (Blake Ramsdell's message of "Wed, 13 Aug 2003 15:05:49 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > If I were going to hazard a guess about widely deployed public > certificate repositories, I would say that there would be a better > argument for LDAP than anything else. Notice the careful wording here > ;). As much as the attempts to automatically map from an email address > to an LDAP directory containing a certificate for that email address > might not have progressed as well as we might like, I think that there > is some hope of that being addressed through the SRV record which is (as > far as I can tell) widely supported by DNS implementations. I believe that what is lacking is not a technical solution (DNS CERT RR, LDAP and SRV, etc) but a guideline document, supported by the S/MIME community, that you can point at when e-mail application makers ask question such as the one that started this thread. One reason why the DNS CERT solution has been proposed, may be that the LDAP via SRV idea hasn't been fully documented in a Internet-wide S/MIME environment, leaving the problem unsolved. > A better question for the DNS distribution of certificates is whether or > not this smells like it would be the most likely thing to get deployed. > My understanding is that you would need DNS servers that supported the > particular record types required for this functionality, Support for this was added to major servers before 2000 or thereabouts, so many are already using such DNS servers. > as well as administrative tools to upgrade those records that are > different than typical DNS administration tools. Yes, someone, somewhere will have to do work to make the idea happen. One argument for certificates in DNS could be that many ISPs are familiar with running public DNS, but not as many ISPs run public LDAP. So instead of upgrading their tools, they would have to learn new tools with LDAP. [All under the assumption that ISPs will be required to administer the certificate directory, which I'm not sure is the best solution.] Regards, Simon From owner-ietf-smime@mail.imc.org Wed Aug 13 20:29:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12661 for ; Wed, 13 Aug 2003 20:29:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E05Tqt022386 for ; Wed, 13 Aug 2003 17:05:29 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E05TCo022385 for ietf-smime-bks; Wed, 13 Aug 2003 17:05:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E05Sqt022377 for ; Wed, 13 Aug 2003 17:05:28 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 13 Aug 2003 17:05:25 -0700 From: "Blake Ramsdell" To: "'Simon Josefsson'" Cc: "'Anders Rundgren'" , , "'Sean P. Turner'" Subject: DNS CERT vs. LDAP (was: RE: PKI and S/MIME) Date: Wed, 13 Aug 2003 17:05:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Simon Josefsson [mailto:jas@extundo.com] > Sent: Wednesday, August 13, 2003 4:46 PM > To: Blake Ramsdell > Cc: 'Anders Rundgren'; ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > I believe that what is lacking is not a technical solution (DNS CERT > RR, LDAP and SRV, etc) but a guideline document, supported by the > S/MIME community, that you can point at when e-mail application makers > ask question such as the one that started this thread. Yes, this was the way I indeed started this thread ("PKI and S/MIME"), by saying "select relevant other work and profile it for use in the S/MIME interpersonal messaging domain" ;). I think we're on the same page. My only point about LDAP is that I wanted to illustrate some of the criteria for any potential profile by comparing two certificate repository methods, and pointing out what I believe is a relevant difference. > One reason why the DNS CERT solution has been proposed, may be that > the LDAP via SRV idea hasn't been fully documented in a Internet-wide > S/MIME environment, leaving the problem unsolved. But once again, if someone held a gun to my head and told me to try and guess if CERT records and the infrastructure to maintain them would achieve traction before LDAP and SRV records would, I would say LDAP and SRV records. This may be a matter of personal taste, but I like to think that it is a practical answer based on limited experience with managing my own domains. > > as well as administrative tools to upgrade those records that are > > different than typical DNS administration tools. > > Yes, someone, somewhere will have to do work to make the idea happen. I think the question is whether or not "someone, somewhere" for DNS CERT records is better than "been there, done that" for LDAP or other repositories. Blake From owner-ietf-smime@mail.imc.org Wed Aug 13 22:52:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15030 for ; Wed, 13 Aug 2003 22:52:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2T1qt032189 for ; Wed, 13 Aug 2003 19:29:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E2T00T032188 for ietf-smime-bks; Wed, 13 Aug 2003 19:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2T0qt032182 for ; Wed, 13 Aug 2003 19:29:00 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7E2SvD09213 for ; Wed, 13 Aug 2003 19:28:57 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJL87P02.S6V; Wed, 13 Aug 2003 19:28:37 -0700 Date: Wed, 13 Aug 2003 19:29:53 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Anders Rundgren" cc: ietf-smime@imc.org, "Hallam-Baker Phillip" In-Reply-To: <001301c360ef$41128990$0500a8c0@arport> Message-ID: <3F3AF421.6060008@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Anders, Anders Rundgren wrote on 08/12/2003, 9:31: > Pierre, > It is good to hear somebody bring up this question which is absolutely > vital for successful deployment of encrypted mail. I'm also glad to see interest in solving this problem. > Personally I don't think that neither the S/MIME WG or XKMS WG > have a solution that at least I would call "acceptable". > > XKMS addresses to some extent the enterprise scenario but only > if the enterprise has their own domain and associated CA. For > truly TTP-based certificates you are out of luck if you are looking > for automated functionality. Are you saying basically that this won't work for Joe User at randomisp.com, who wants to register with randomca.com ? > > I believe that the mail protocol and associated applications > should be augmented with encryption certificate lookup. A > MIME X-extension that you configured in your e-mail client > would do a part of this. I.e. each time you sent a mail, the > lookup would be transmitted as well. Also it would be > nice to have an enhanced "mailto:" URL supporting the same > mechanism. If you send an email today, you can simply sign it and include your certificate in the signature. If you just sign all your mail, then all you always disseminate your certificate. So in what situations does this new MIME extension certificate lookup help ? I suppose this extension would be shorter than a digital signature. However it would also be much less secure. The case I originally asked about is : neither party has exchanged any e-mail yet, but they know each other's e-mail address. They want to communicate securely. How do they avoid or bypass the initial insecure e-mail exchange ? > In summary I think that a certificate-independent configuration > of e-mail clients would be more universal than "fishing" in > domains as the user domain and issuer domain may be entirely > disjunct. "Fishing" in domains as you say would be independent of e-mail client configuration for the most part (it could just be turned on or off). You correctly point out that in most cases the user's domain and cert issuer domain are disjoint. This is especially true of e-mail users whose ISP isn't a CA (99.9% of them right now). The only solution for these users is some sort of universal registration service. This implies the existence of some sort of free worldwide directory service (LDAP) that would resolve e-mail addresses to certificates ... And clients would need to be (automatically?) configured to do look ups in it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQwMjI5NTNaMCMGCSqGSIb3DQEJBDEWBBSo4N/z 6bdvBgKJjFS12Izb6VR9DDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQB6KYML1UrOipbf75tEtNSTOSsl5BQep5H8Tsnls/yryz+uDpZf1SgAf8y4 UJSHl4t+sVJh4oZ28fEiusRRr9E7CSwGbEpiH9b7u29kXsxxqOXIlGgPtgWStU12Yx1vnen2 MohwfDLzxR3VvY74kiU5wGoZyV9OTWnl3lqzzUXu3NL4HQeZF+r1AYY9u+yLLwDc78RTrxLH lTXVD7pyVHDOhIxFURnXd1k6kXIOBlqUWQ1WmwsqRc/X0bD4tgwUT3LsY60mO91/wAuXAxoR pnWJ8Tksj2rOsVX6b3pt1fKyvZKdPGFMWsq/iroNt2Bb9NnH0E3trmhYETYwmhSeZ2AEAAAA AAAA --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Thu Aug 14 08:59:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08589 for ; Thu, 14 Aug 2003 08:59:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUkqt084607 for ; Thu, 14 Aug 2003 05:30:46 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ECUk0x084605 for ietf-smime-bks; Thu, 14 Aug 2003 05:30:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUiqt084596 for ; Thu, 14 Aug 2003 05:30:44 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7ECUZil017013; Thu, 14 Aug 2003 05:30:35 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 05:30:35 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson Cc: ietf-smime@imc.org, "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 05:30:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are two ways the problem may be solved. The simplest solution is that the domain owner appoints a single CA for the entire zone and simply directs all XKMS requests to the XKMS server run by the CA. The second solution is that the domain owner runs a non-authoritative Locate service locally. XKMS clients that register certificates with the CA of their choice can then in turn register the certificate issued by the CA with their local XKMS locate service. In this second application the XKMS service may choose to impose some form of validation constraint on the certs that it accepts. For example only accepting certs from a limited number of CAs - or it may not. Incidentaly XKMS may also be used to register PGP keys or keys in alternative PKIs. It is a key centric PKI, not a token centric one. Storing end-user certs or keys in the DNS is a lousy idea for several reasons. First the DNS is a machine configuration infrastructure and not a user configuration infrastructure. Storing user information in the DNS requires an administrative interface with a new constituency. Ain't going to happen. Moreover the DNSSEC spec itself is still not in a deployable state, or at least the IETF version of it is not. Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise resource. Enterprises are not going to expose LDAP data in border directories in significant numbers. It is not just the security issue, cost plays a factor. LDAP is not a simple protocol, it is would be completely overspecified for the job of a cert repository if the features LDAP provided were relevant to the task. We considered certs in the DNS and LDAP before designing XKMS and rejected them. Both technologies have been available for at least 6 years with negligible uptake. We needed a new protocol because there was no acceptable existing solution. Sometimes designing a new protocol from scratch is better than attempting to use an inappropriate one. Phill > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, August 13, 2003 1:16 PM > To: Blake Ramsdell; Simon Josefsson > Cc: ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > > > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? > > Anders > > ----- Original Message ----- > From: "Simon Josefsson" > To: "Blake Ramsdell" > Cc: ; "'Sean P. Turner'" > Sent: Wednesday, August 13, 2003 09:32 > Subject: Re: PKI and S/MIME > > > > "Blake Ramsdell" writes: > > > There have been a number of messages recently about the use > of PKI with > > S/MIME, and the concerns about that. I like to think that we're all > > pretty much in agreement that we've established a consistent, > > interoperable practice for the actual syntax and contents of S/MIME > > messages, as well as a reasonable cut of a certificate > syntax profile > > for end-entity certificates. > > > > Should there be a profile for certificate usage > (certificate repository, > > distribution and revocation checking) that is specific for > our problem > > domain? That is, select relevant other work and profile it > for use in > > the S/MIME interpersonal messaging domain? I would imagine > that this > > would be a new draft, start with a summary of the requirements, and > > progress to profiles of relevant standards. > > > > It's also not clear if this is something to discuss in this working > > group, or somewhere else. > > > > Comments? > > Since in practice, addressing this problem would help in getting > "opportunistic S/MIME" to work, I believe it would be useful to > address it. ("Opportunistic S/MIME" means to be able to encrypt > messages to someone you don't have a prior trust relationship with, > simply to provide encryption of data. There is a man in the middle > attack, of course, but in practice the result often isn't worse than > not using S/MIME.) > > A strawman at a requirement: > > * Be able to locate a certificate for a Internet user given only her > email address. > > I should mention that this has been discussed several times before, in > various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so > there is prior work to look at how to design this. To do even more > self-promoting, I'd again like to mention the following draft: > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which do discuss it for S/MIME context as well. I don't have an > opinion on if this WG is the proper place for it. > > Regards, > Simon > From owner-ietf-smime@mail.imc.org Thu Aug 14 12:53:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17866 for ; Thu, 14 Aug 2003 12:53:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGV1qt003430 for ; Thu, 14 Aug 2003 09:31:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGV13M003429 for ietf-smime-bks; Thu, 14 Aug 2003 09:31:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGUxqt003418 for ; Thu, 14 Aug 2003 09:30:59 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGYkV32358; Thu, 14 Aug 2003 10:34:46 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:34:47 -0700 To: Anders Rundgren Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: <006901c361be$9f4ba080$0500a8c0@arport> References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGUxqt003419 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, 13 Aug 2003 19:16:22 +0200 Anders Rundgren wrote: > > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? Why not? --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 12:53:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17884 for ; Thu, 14 Aug 2003 12:53:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGQmqt002912 for ; Thu, 14 Aug 2003 09:26:48 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGQmJ7002911 for ietf-smime-bks; Thu, 14 Aug 2003 09:26:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGQgqt002891 for ; Thu, 14 Aug 2003 09:26:46 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGURV32299; Thu, 14 Aug 2003 10:30:27 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:30:28 -0700 To: Julien Pierre Subject: Re: dissemination of public encryption certificates Cc: ietf-smime@imc.org In-Reply-To: <3F3AF421.6060008@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGQlqt002905 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Well, for the first time in a long time my interest is up on this list :-). What a wonderful topic! General purpose use of S/MIME by the masses on the Internet. Why hasn't it happened and what can we do about it. Before you read on, be assured that it is the large scale use of S/MIME that the following diatribe is focused on. On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre wrote: > If you send an email today, you can simply sign it and include your > certificate in the signature. If you just sign all your mail, then all > you always disseminate your certificate. So in what situations does this > new MIME extension certificate lookup help ? I suppose this extension > would be shorter than a digital signature. However it would also be much > less secure. This highlights one of the key issues. It is easy enough to exchange keys simply by sending a signed message, but there are some significant barriers: 1. What if your encryption key is separate from your signing key. This is not only common but considered good security practice. How does one go about exchanging/discovering the encryption key for the new party you want to exchange mail with. 2. Timeliness of the key exchange. The problem with mutual signing exchange is that the other person has to respond to you. What if you just want to send them an encrypted load right off the start. You can't really do it. The solution is (and always has been) to do a lookup. The problem is that there is no directory to look up from. Global X.500/LDAP directories are *never* going to happen. There is only one choice -- DNS. I (and Steve Kille and others) have been flogging LDAP directories and working on LDAP/X.500 interconnects for a decade. Global X.500/LDAP isn't going to happen in our lifetime. > The case I originally asked about is : > neither party has exchanged any e-mail yet, but they know each other's > e-mail address. They want to communicate securely. How do they avoid or > bypass the initial insecure e-mail exchange ? Precisely. They must be able to do a DNS lookup for the information either as a direct data return or a reference to a secondary storage service, which absolutely could and probably should be LDAP. To work in practice I think that it should be possible to get a direct pull from the DNS so that organizations are not required to deploy an LDAP directory and all that goes along with it (much as that pains me). > > In summary I think that a certificate-independent configuration > > of e-mail clients would be more universal than "fishing" in > > domains as the user domain and issuer domain may be entirely > > disjunct. > > "Fishing" in domains as you say would be independent of e-mail client > configuration for the most part (it could just be turned on or off). Actually, I think that "fishing" is an entirely appropriate thing to do. The worst that can happen is that don't find the cert your looking for. Trust issues MUST be dealt with, but certificate trust chains and approaches are both well understood. The best that can happen is that suddenly I can go and find a cert for joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want to do that? This does lead very nicely into my second (and quite separate) issue in this area -- the "trusted ROOT certificate". Julien has provided superp leading commentary here. > You correctly point out that in most cases the user's domain and cert > issuer domain are disjoint. This is especially true of e-mail users > whose ISP isn't a CA (99.9% of them right now). Exactly. Why? Because it costs TOO MUCH. The only acceptable cost for most ISP's is zero because of the volume of users. Cost of certification is, pure and simple, the primary barrier to the general use and deployment of S/MIME on the Internet. The reason for the cost is that the mechanism for establishing root trust is determined solely by the set of ROOT certificates distributed by the client vendor -- of all things!. Thus only those organizations that can afford to pay the client vendor -- of all things! -- to be included in their "special trusted root certificate club" get to have "trust". Which means that you MUST buy certs from one of the club members. Doesn't THAT just suck. Nice business if you can get it. Yes I know about free thawte certs. I know that any root issuer must be secure and provide good protection from having roots keys compromised etc. I agree that anyone who issues certificates should be required to be secure. I understand that there is risk to the client vendor if they report trust in a cert that has been compromised at the root. Regardless, to have this power rest in the hands of the client vendor is ludicrous. Why should I trust that Microsoft can evaluate the security and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not saying they are unqualified to do so, but I'm a lot more likely to trust a self signed "Bank of America" certificate issued on it's own behalf and obtained from a reliable source, than I am a third party software vendor or CA Verisign (not that there's anything wrong with either Microsoft or Verisign :-). The issue comes down to trust brokering. I just don't think that it is working for the *general* mass consumer Internet. It clearly does work for closed communities within the Internet, but it isn't scaling. Period. If we want generalized S/MIME usage throughout the Internet we need to think of some mechanism that is: 1. Easy to deploy. The track record for the Internet stongly indicates that this means that there are freeware versions of software that will support the deployment. This includes both the key management and publication software and the usage (client) software. 2. Free. Those who "own" the vast majoritiy of the user population on the Internet are ISP's. They have almost no margin and simply cannot afford to pay for certification. Also (and more importantly IMHO) is the desired for businesses to touch their customers. These are HUGE volume relationships in which there are virtually no economically viable ways of establishing bidirectional trust. A cert price of $0.01 a year is too much if your customer population is 25 million people (banks, utilities, etc.) Why could we not have organizations issue certificates distributed via DNS, with a trust relationship provided by DNS-SEC? That is, you can trust that the DNS node your are dealing with is legitimate because they have deployed DNS-SEC (which everyone should do anyway for a host of other security reasons) and the keys that are located within the DNS hierachy are legitimate. I can then lookup certs based on mail address (duh!), where the mail domain source is trusted because of DNS-SEC. This trust relationship could be either: implicit -- the issuer domain location is trusted therefore any keys published there are trusted, explict -- the issuer provides a root signing key which is in turn signed by their DNS-SEC key. There are a number of observations that can be made about this approach: 1. The security provided by the approach is probably not as strong as the full commercial CA approach. I contend "so what". It's better than nothing and Pretty Good (pun intended). The average user doesn't need military grade security. The average bill issued by the local telephone utility doesn't need military grade security. Think of the vast number of paper documents that need only Pretty Good security and trust to be useful (292 Trillion a year in the US -- it's my business and I happen to know). All we need is some security to make that paper go away forever. 2. Some extensions to bind and a new CSP for Windows would get a large number people going in a hurry. Openssl with an HSM card and some reasonable security policy has an organization running pretty quickly. > The only solution for > these users is some sort of universal registration service. Yup. > This implies > the existence of some sort of free worldwide directory service (LDAP) > that would resolve e-mail addresses to certificates ... And clients > would need to be (automatically?) configured to do look ups in it. Well, even though I would love it if it was LDAP, it isn't going to happen. DNS is the only game in town for global directory service. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 12:55:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17932 for ; Thu, 14 Aug 2003 12:55:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGT0qt003175 for ; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGT0Md003174 for ietf-smime-bks; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web40511.mail.yahoo.com (web40511.mail.yahoo.com [66.218.78.128]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7EGT0qt003160 for ; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) (envelope-from deepak_vn@yahoo.com) Message-ID: <20030814162856.26664.qmail@web40511.mail.yahoo.com> Received: from [193.41.16.3] by web40511.mail.yahoo.com via HTTP; Thu, 14 Aug 2003 09:28:56 PDT Date: Thu, 14 Aug 2003 09:28:56 -0700 (PDT) From: Deepak Subject: Query regarding BER/DER encoding of CMS data To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, When i go through the CMS RFC's its saying, all the contenttype(SignedData,EnvelopedData) should be BER encoded. But when i go thorugh the some of the ietf examples, especially in EnvelopedData->RecipientInfo is encoded by DER.(its starting with 31 82 ..). It should be like sequence 30 80 .. ? Could you please explain why was it happend ? Thanks, Deepak __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ietf-smime@mail.imc.org Thu Aug 14 12:56:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17975 for ; Thu, 14 Aug 2003 12:56:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGcEqt004313 for ; Thu, 14 Aug 2003 09:38:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGcEoR004312 for ietf-smime-bks; Thu, 14 Aug 2003 09:38:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGcCqt004300 for ; Thu, 14 Aug 2003 09:38:12 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGg1V32422; Thu, 14 Aug 2003 10:42:01 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:42:02 -0700 To: Blake Ramsdell Subject: RE: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGcCqt004302 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell wrote: > A better question for the DNS distribution of certificates is whether or > not this smells like it would be the most likely thing to get deployed. > My understanding is that you would need DNS servers that supported the > particular record types required for this functionality, as well as > administrative tools to upgrade those records that are different than > typical DNS administration tools. To me, that doesn't smell as good. Actually, I think that there are two barriers: 1. Deployment of DNS-SEC. People have to go out of their way to do it right now. It takes some work both to deploy the right software and to get the relationship set up with the domain registration service. Not all services offer it. 2. Client support. Basically this means that Outlook, Outlook Express, Netscape (and down the list) of clients have to support it. It means a CSP for the Windows twins and a module in the new Netscape/Mozilla security API. Of the two, the second is the hardest. Policy, usage and deployment of S/MIME and PKI is very much shaped by the implementation of the clients. Any changes have to propogate through the clients to be useful. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 12:59:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18071 for ; Thu, 14 Aug 2003 12:59:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGg7qt004889 for ; Thu, 14 Aug 2003 09:42:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGg7wq004888 for ietf-smime-bks; Thu, 14 Aug 2003 09:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGg5qt004880 for ; Thu, 14 Aug 2003 09:42:05 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGjiV32463; Thu, 14 Aug 2003 10:45:45 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:45:45 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: Blake Ramsdell , "'Anders Rundgren'" , ietf-smime@imc.org, "'Sean P. Turner'" In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGg5qt004882 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Thu, 14 Aug 2003 01:45:51 +0200 Simon Josefsson wrote: > I believe that what is lacking is not a technical solution (DNS CERT > RR, LDAP and SRV, etc) but a guideline document, supported by the > S/MIME community, that you can point at when e-mail application makers > ask question such as the one that started this thread. > > One reason why the DNS CERT solution has been proposed, may be that > the LDAP via SRV idea hasn't been fully documented in a Internet-wide > S/MIME environment, leaving the problem unsolved. I agree. The problem with PKI has always been that it is difficult to experiment. I think that we have enough real world experience now that we should try some alternative things. I think that we do need to experiment with this. It's time to come up with some working solutions and then document them, not the other way around. > One argument for certificates in DNS could be that many ISPs are > familiar with running public DNS, but not as many ISPs run public > LDAP. So instead of upgrading their tools, they would have to learn > new tools with LDAP. [All under the assumption that ISPs will be > required to administer the certificate directory, which I'm not sure > is the best solution.] Yes. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 13:26:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18881 for ; Thu, 14 Aug 2003 13:26:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH66qt006614 for ; Thu, 14 Aug 2003 10:06:06 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EH66LA006613 for ietf-smime-bks; Thu, 14 Aug 2003 10:06:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH64qt006603 for ; Thu, 14 Aug 2003 10:06:04 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EH9lV32668; Thu, 14 Aug 2003 11:09:47 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 11:09:47 -0700 To: "Hallam-Baker, Phillip" Subject: RE: PKI and S/MIME Cc: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson , ietf-smime@imc.org, "'Sean P. Turner'" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EH64qt006604 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Thu, 14 Aug 2003 05:30:34 -0700 "Hallam-Baker, Phillip" wrote: > We considered certs in the DNS and LDAP before designing XKMS and rejected > them. Both technologies have been available for at least 6 years with > negligible uptake. This is true for LDAP, but is it true for DNS? What specific "deploy certs in DNS" technology are you talking about? > We needed a new protocol because there was no acceptable > existing solution. Sometimes designing a new protocol from scratch is better > than attempting to use an inappropriate one. Fair enough. Then you better figure out how, exactly, you are going to deploy your new protocol for use with S/MIME. Specifically, you must do what Blake suggests and write a profile for use. In particular, if I'm sitting in my Netscape client and I want to send an encrypted message to "Blake Ramsdell " without any prior contact, how am I going to do that? That profile must describe: 1. The collection of services and publication points for accessing the information. 2. The approach that a client must take to do the lookup and resolve the requested certificate. I'm sure that you can do it. I'm also sure that you are going to have to do *something* with DNS because how are you ever going to find your xkms server? If there is an external xkms global hierarchy planned, then pardon me if I'm dubious, but who is going to run the root? (Hint: I'm unlikely to like *any* answer to that last question :-). Chers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 13:54:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20038 for ; Thu, 14 Aug 2003 13:54:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHU0qt008732 for ; Thu, 14 Aug 2003 10:30:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHU0JS008731 for ietf-smime-bks; Thu, 14 Aug 2003 10:30:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHTxqt008719 for ; Thu, 14 Aug 2003 10:29:59 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EHU0il010814; Thu, 14 Aug 2003 10:30:00 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 10:30:00 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steve Hole'" , Julien Pierre Cc: ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 10:30:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well, for the first time in a long time my interest is up on this > list :-). What a wonderful topic! General purpose use of > S/MIME by the masses on the Internet. Why hasn't it > happened and what > can we do about it. Glad you like it... The reason is simple, S/MIME is not transparent to end users. 1) Signature Signature is only possible by changingthe message format. Unfortunately there are still a lot of people out there with broken, non S/MIME capable email clients. Probably more of those than have broken email servers. Of course at this point it is difficult to do anything about this. 2) Encryption Encryption is a big problem for end users, it is simply not transparent. We need to link PKI to the DNS in some way, the SRV service looks the best choice. LDAP is not going to be the answer here, even if you find the right LDAP server the schema issues still have to be solved. Sure LDAP could address the problem - but only to the extent a Turing machine could and only with changes to make LDAP aware of PKI concepts like trust paths. 3) The end to end obsession One of the major reasons the IETF has failled in the security space is that the end to end principle alone does not address security issues. Perimeter security is a major concern for enterprises. As I have been digging into this issue I have discovered that 'end-to-end security' is actually a shiboleth. Go look at the RFCs with security architecture design discussions and you will not find it. Clark never applied it to security either in the naive form that has become the received version. What we need to do is to build specs that address multi-layer security concerns. It should not be necessary for everyone to have a certificate just to be able to do security. It should be possible to sign outgoing messages at either the end user level OR the domain name level - I only care that an email came from Merril Lynch, not that it came from Freddy Bloggs in accounts. 4) Feature support discovery An extension of #2. Clients should be able to advertise their capabilities. Perhaps this is NAPTR, but I doubt it. I see NAPTR as being a server level feature. > The solution is (and always has been) to do a lookup. The > problem is that > there is no directory to look up from. Global X.500/LDAP > directories are > *never* going to happen. Amen brother, Amen. > The reason for the cost is that the mechanism for > establishing root trust > is determined solely by the set of ROOT certificates > distributed by the > client vendor -- of all things!. Again, I designed XKMS to allow enterprises to define their own trust evaluations. One of the main considerations was how to support the Federal Bridge CA, both today and in the future when there are perhaps a thousand significant bridge CAs in operation. > 1. Easy to deploy. The track record for the Internet > stongly indicates > that this means that there are freeware versions of software > that will > support the deployment. This includes both the key management and > publication software and the usage (client) software. Also, obtain buy-in from the principal stakeholders whose help is required to achieve deployment. That is why the answer is XKMS and not SCVP. SCVP does not have the public support of any of the major stakeholders. I spent a lot of time and effort getting buy-in from Microsoft and RSA before we announced XKMS. I worked with Entrust and Baltimore so that we could produce a specification that they could also support. Contrast this to what the IETF mechanism achieves, OK everyone can say what they like. But at the end of the day you do not have the support of a major software vendor, just the individuals in the working group. > 2. Free. Those who "own" the vast majoritiy of the user > population on > the Internet are ISP's. They have almost no margin and > simply cannot > afford to pay for certification. Substitute cheap. Clearly certification becomes a lot cheaper in volume. > Why could we not have organizations issue certificates > distributed via > DNS, with a trust relationship provided by DNS-SEC? Because the working group deliberately sabotaged the spec by refusing changes to make it possible to deploy in .com and .net. > I can then lookup certs based on mail address (duh!), where the mail > domain source is trusted because of DNS-SEC. This trust > relationship > could be either: Not a good choice, very few DNS administrators deal with end users. The TTL constants in DNS are also completely inappropriate to the problem. Phill From owner-ietf-smime@mail.imc.org Thu Aug 14 14:27:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21117 for ; Thu, 14 Aug 2003 14:27:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EI1wqt011632 for ; Thu, 14 Aug 2003 11:01:58 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EI1wiT011631 for ietf-smime-bks; Thu, 14 Aug 2003 11:01:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EI1uqt011626 for ; Thu, 14 Aug 2003 11:01:57 -0700 (PDT) (envelope-from helm@fionn.es.net) Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id LAA00732; Thu, 14 Aug 2003 11:01:53 -0700 (PDT) Message-Id: <200308141801.LAA00732@fionn.es.net> X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net To: "Hallam-Baker, Phillip" cc: "'Steve Hole'" , Julien Pierre , ietf-smime@imc.org Reply-to: helm@fionn.es.net Subject: Re: dissemination of public encryption certificates In-reply-to: Your message of "Thu, 14 Aug 2003 10:30:00 PDT." <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> Date: Thu, 14 Aug 2003 11:01:53 -0700 From: Michael Helm Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Hallam-Baker, Phillip" writes: > Again, I designed XKMS to allow enterprises to define their own trust > evaluations. One of the main considerations was how to support the Federal > Also, obtain buy-in from the principal stakeholders whose help is required > to achieve deployment. > > That is why the answer is XKMS and not SCVP. SCVP does not have the public > support of any of the major stakeholders. I spent a lot of time and effort > getting buy-in from Microsoft and RSA before we announced XKMS. I worked > with Entrust and Baltimore so that we could produce a specification that > they could also support. > > Contrast this to what the IETF mechanism achieves, OK everyone can say what > they like. But at the end of the day you do not have the support of a major > software vendor, just the individuals in the working group. Leaving aside who supports what and why, don't understand the implied conflict between xkms and scvp. They seem to do two different things -- I want to find a cert for helm@fionn.es.net to send email to that entity; I have a cert from helm@fionn.es.net -- what is it good for? I didn't think SCVP would help much with the first, and I clearly don't see what XKMS would do with the second question. Would like a better understanding of this. Thanks, ==mwh Michael Helm ESnet From owner-ietf-smime@mail.imc.org Thu Aug 14 14:39:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21553 for ; Thu, 14 Aug 2003 14:39:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIGoqt012187 for ; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EIGoxA012186 for ietf-smime-bks; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIGnqt012181 for ; Thu, 14 Aug 2003 11:16:49 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7EIGoOQ025768; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 11:16:50 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113026@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'helm@fionn.es.net'" , "Hallam-Baker, Phillip" Cc: "'Steve Hole'" , Julien Pierre , ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 11:16:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Leaving aside who supports what and why, don't understand the > implied conflict between xkms and scvp. They seem to do two > different things -- I want to find a cert for helm@fionn.es.net > to send email to that entity; I have a cert from helm@fionn.es.net -- > what is it good for? I didn't think SCVP would help much with > the first, and I clearly don't see what XKMS would do with the > second question. Would like a better understanding of this. Thats quite a good description of SCVP. XKMS does not answer that question because I can't think of a situation where is would be of interest. The certificate is simply a data object that is created to establish the trustworthiness of a key. Applications don't ask 'what is this good for?', they ask 'how do I do this task?'. Phill From owner-ietf-smime@mail.imc.org Thu Aug 14 14:43:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20037 for ; Thu, 14 Aug 2003 13:54:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHWgqt009086 for ; Thu, 14 Aug 2003 10:32:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHWggu009085 for ietf-smime-bks; Thu, 14 Aug 2003 10:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHWfqt009078 for ; Thu, 14 Aug 2003 10:32:41 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EHWWil011402; Thu, 14 Aug 2003 10:32:32 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 10:32:32 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113022@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steve Hole'" , "Hallam-Baker, Phillip" Cc: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson , ietf-smime@imc.org, "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 10:32:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Fair enough. Then you better figure out how, exactly, you > are going to > deploy your new protocol for use with S/MIME. Specifically, > you must do > what Blake suggests and write a profile for use. At the moment I am just recovering from getting the XKMS spec itself through last call. I also have to get the WS-Security profiles for X.509 and Kerberos completed. After that I have to stop spam on the Internet completely. That takes us up to the end of September at which point I will be able to get back to the S/MIME issue. Phill From owner-ietf-smime@mail.imc.org Thu Aug 14 17:58:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27955 for ; Thu, 14 Aug 2003 17:58:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELP9qt020042 for ; Thu, 14 Aug 2003 14:25:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ELP9ZL020041 for ietf-smime-bks; Thu, 14 Aug 2003 14:25:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELP8qt020033 for ; Thu, 14 Aug 2003 14:25:08 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 14:25:04 -0700 From: "Blake Ramsdell" To: "'Steve Hole'" Cc: Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 14:25:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Steve Hole [mailto:steve.hole@messagingdirect.com] > Sent: Thursday, August 14, 2003 10:42 AM > To: Blake Ramsdell > Cc: ietf-smime@imc.org > Subject: RE: PKI and S/MIME > > 2. Client support. Basically this means that Outlook, > Outlook Express, > Netscape (and down the list) of clients have to support it. > It means a > CSP for the Windows twins and a module in the new Netscape/Mozilla > security API. > > Of the two, the second is the hardest. Policy, usage and > deployment of > S/MIME and PKI is very much shaped by the implementation of > the clients. > Any changes have to propogate through the clients to be useful. There is no miracle that I can see that wouldn't require modifying the clients, so we're already signed up for this regardless of what direction we might go in, I think. Blake From owner-ietf-smime@mail.imc.org Thu Aug 14 18:06:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28488 for ; Thu, 14 Aug 2003 18:06:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELgsqt020520 for ; Thu, 14 Aug 2003 14:42:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ELgsIU020519 for ietf-smime-bks; Thu, 14 Aug 2003 14:42:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELgrqt020513 for ; Thu, 14 Aug 2003 14:42:53 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 14:42:49 -0700 From: "Blake Ramsdell" To: "'Hallam-Baker, Phillip'" , Cc: "'Steve Hole'" , "'Julien Pierre'" , Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 14:42:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113026@mou1wnexm02.verisign.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > Hallam-Baker, Phillip > Sent: Thursday, August 14, 2003 11:17 AM > To: 'helm@fionn.es.net'; Hallam-Baker, Phillip > Cc: 'Steve Hole'; Julien Pierre; ietf-smime@imc.org > Subject: RE: dissemination of public encryption certificates > > XKMS does not answer that question because I can't think of a > situation > where is would be of interest. The certificate is simply a > data object that > is created to establish the trustworthiness of a key. > Applications don't ask > 'what is this good for?', they ask 'how do I do this task?'. Well, I'm not sure I agree. There are two major questions that constantly need answers in the mind of an S/MIME client. These are pretty close to what Michael said in his message: 1. Given a particular email address, give me That Which Is Necessary and Sufficient to send encrypted mail to that email address. 2. Given a particular certificate, is it suitable for signing mail that came from a particular email address. Michael said "what is it good for", which I think is too broad a question. If we're considering protocols that attempt to answer these types of questions, those are the two questions that need to be answered by that protocol (for interpersonal messaging with S/MIME, that is). Blake From owner-ietf-smime@mail.imc.org Thu Aug 14 18:55:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00859 for ; Thu, 14 Aug 2003 18:55:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMSqqt022092 for ; Thu, 14 Aug 2003 15:28:52 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMSqxh022091 for ietf-smime-bks; Thu, 14 Aug 2003 15:28:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMSoqt022082 for ; Thu, 14 Aug 2003 15:28:51 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7EMSmdj020596; Fri, 15 Aug 2003 00:28:48 +0200 To: Steve Hole Cc: Blake Ramsdell , ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <006901c361be$9f4ba080$0500a8c0@arport> From: Simon Josefsson X-Payment: hashcash 1.2 0:030814:steve.hole@messagingdirect.com:0875e397ce7250b9 X-Hashcash: 0:030814:steve.hole@messagingdirect.com:0875e397ce7250b9 X-Payment: hashcash 1.2 0:030814:blake@brutesquadlabs.com:3c2a293ee5df2ff0 X-Hashcash: 0:030814:blake@brutesquadlabs.com:3c2a293ee5df2ff0 X-Payment: hashcash 1.2 0:030814:ietf-smime@imc.org:4f23e4d550f9f65d X-Hashcash: 0:030814:ietf-smime@imc.org:4f23e4d550f9f65d Date: Fri, 15 Aug 2003 00:28:48 +0200 In-Reply-To: (Steve Hole's message of "Thu, 14 Aug 2003 10:42:02 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole writes: > On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell > wrote: > >> A better question for the DNS distribution of certificates is whether or >> not this smells like it would be the most likely thing to get deployed. >> My understanding is that you would need DNS servers that supported the >> particular record types required for this functionality, as well as >> administrative tools to upgrade those records that are different than >> typical DNS administration tools. To me, that doesn't smell as good. > > Actually, I think that there are two barriers: > > 1. Deployment of DNS-SEC. People have to go out of their way to do it > right now. It takes some work both to deploy the right software and to > get the relationship set up with the domain registration service. Not > all services offer it. Note that distributing certificate DNS does not depend on DNSSEC. Thus the argument that DNSSEC may or may not be deployable is not relevant to distributing certificate via DNS. However, should DNSSEC (or some close approximation to it) happen, it would make certificates distributed via DNS become integrity protected and authenticated via the DNSSEC trust chain. LDAP or XKMS using SRV records does not get the same benefit. > 2. Client support. Basically this means that Outlook, Outlook Express, > Netscape (and down the list) of clients have to support it. It means a > CSP for the Windows twins and a module in the new Netscape/Mozilla > security API. Since mail clients cannot find certificates for arbitrary users today, I believe clients must be modified regardless of the solution chosen. Even here there is an advantage for DNS: mail clients already implement DNS. There is no need to open ports in firewalls etc for LDAP or XKMS. There is no need to implement new client code in the mail client. Instead modify the existing code to query for a CERT record where it now queries for MX and A records. Yes, I know this doesn't apply in all situations, such as corporate mode Outlook and Exchange, which doesn't use Internet protocols to send and receive mail. But we are here to find a solution for applications that uses IETF standards, not Microsoft implementations, aren't we? Regards, Simon From owner-ietf-smime@mail.imc.org Thu Aug 14 19:03:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01064 for ; Thu, 14 Aug 2003 19:03:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMetqt022649 for ; Thu, 14 Aug 2003 15:40:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMetYU022648 for ietf-smime-bks; Thu, 14 Aug 2003 15:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMesqt022640 for ; Thu, 14 Aug 2003 15:40:54 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 15:40:51 -0700 From: "Blake Ramsdell" To: "'Simon Josefsson'" , "'Steve Hole'" Cc: Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 15:40:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Simon Josefsson [mailto:jas@extundo.com] > Sent: Thursday, August 14, 2003 3:29 PM > To: Steve Hole > Cc: Blake Ramsdell; ietf-smime@imc.org > Subject: Re: PKI and S/MIME > > Note that distributing certificate DNS does not depend on DNSSEC. > Thus the argument that DNSSEC may or may not be deployable is not > relevant to distributing certificate via DNS. I think that the intent is to point out that in order to get an implementation of the CERT record, you usually get that in conjunction with a DNSSEC implementation. This may be too sweeping a generalization, however. > Even here there is an advantage for DNS: mail clients already > implement DNS. There is no need to open ports in firewalls etc for > LDAP or XKMS. There is no need to implement new client code in the > mail client. Instead modify the existing code to query for a CERT > record where it now queries for MX and A records. Yes, I know this > doesn't apply in all situations, such as corporate mode Outlook and > Exchange, which doesn't use Internet protocols to send and receive > mail. But we are here to find a solution for applications that uses > IETF standards, not Microsoft implementations, aren't we? Well, I'm not sure I agree with you here. End user SMTP/POP3/IMAP mail clients today don't implement lots of DNS operations -- they just say "all mail goes to this SMTP server" which is a simple gethostbyname style call. Specifically, they don't deal with MX records. It has actually been pointed out in other forums (and I've had experience with this myself) that Windows is particularly ornery to work with for arbitrary DNS record types that aren't supported through native APIs (I had to write my own DNS client code to handle MX records back in the day, and Peter Gutmann told me he got slapped around pretty good trying to work with SRV records). Now, this situation might have changed, but I want to point out that the DNS operations done by mail clients today are nowhere near the same as would be required to handle CERT records. Blake From owner-ietf-smime@mail.imc.org Thu Aug 14 19:10:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01167 for ; Thu, 14 Aug 2003 19:10:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMkvqt022849 for ; Thu, 14 Aug 2003 15:46:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMkvHh022848 for ietf-smime-bks; Thu, 14 Aug 2003 15:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMkuqt022841 for ; Thu, 14 Aug 2003 15:46:56 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7EMkk312991 for ; Thu, 14 Aug 2003 15:46:46 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJMSLK00.O21; Thu, 14 Aug 2003 15:46:32 -0700 Date: Thu, 14 Aug 2003 15:47:41 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Hallam-Baker Phillip" cc: "'Steve Hole'" , ietf-smime@imc.org In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> Message-ID: <3F3C118D.3090904@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Philip, Hallam-Baker, Phillip wrote on 08/14/2003, 10:30: > > 1) Signature > Signature is only possible by changingthe message format. > Unfortunately there are still a lot of people out there with broken, non > S/MIME capable email clients. Probably more of those than have broken > email > servers. Of course at this point it is difficult to do anything about > this. I don't think there is any way around that problem, the client simply must have at least basic MIME support to support S/MIME signed messages. Unfortunately, there are many e-mail clients that cannot be supported, eg. the very basic e-mail "clients" included in some devices such as older cell phones. The best that we can do is ensure that new client software going forward has the proper MIME & S/MIME support. > 2) Encryption > Encryption is a big problem for end users, it is simply not > transparent. We need to link PKI to the DNS in some way, the SRV service > looks the best choice. LDAP is not going to be the answer here, even > if you > find the right LDAP server the schema issues still have to be solved. > Sure > LDAP could address the problem - but only to the extent a Turing machine > could and only with changes to make LDAP aware of PKI concepts like trust > paths. I think you are overly pessimistic here about the ability of LDAP to solve the problem. I agree with you however that a proper schema needs to be in place, and that is certainly a problem that hasn't been solved. > 3) The end to end obsession > One of the major reasons the IETF has failled in the security > space > is that the end to end principle alone does not address security issues. > Perimeter security is a major concern for enterprises. > > As I have been digging into this issue I have discovered that > 'end-to-end security' is actually a shiboleth. Go look at the RFCs with > security architecture design discussions and you will not find it. Clark > never applied it to security either in the naive form that has become the > received version. > > What we need to do is to build specs that address multi-layer > security concerns. It should not be necessary for everyone to have a > certificate just to be able to do security. It should be possible to sign > outgoing messages at either the end user level OR the domain name > level - I > only care that an email came from Merril Lynch, not that it came from > Freddy > Bloggs in accounts. S/MIME signing can be implemented transparently in the way you want as well. Merryl Lynch could have a certificate with regular expressions in it, matching all of its employees. The internal Merryl SMTP e-mail server, perhaps setup with SSL and some basic authentication of employees, could automatically sign each outgoing e-mail message with that certificate. This really is not end-to-end at all but I believe it can work today. You just have to be a little creative. > > The solution is (and always has been) to do a lookup. The > > problem is that > > there is no directory to look up from. Global X.500/LDAP > > directories are > > *never* going to happen. > > Amen brother, Amen. I find it really ironic that I can lookup phone numbers for anyone listed in the united states, knowing such sensitive information as their name and physical address, through a free service like www.switchboard.com, but I can't look-up their e-mail certificate knowing their e-mail address ? I'm sure there is lots of politics involved, but surely the logistics of running this service shouldn't be so much of a problem ? -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDIyNDc0OVowIwYJKoZIhvcNAQkEMRYE FAP/f04vtimqF7JmaBgN9kU8pS5+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCXW+NRoCDfxZ61/hGe ej9TN0DYr/VcOQM0ofklI6ZOc1UD2f59T/3OpCUSn2j1Up/n3WfcJH7+daqvowr9hHyWkaxK awc8fbPw1P51G8+iL+FNp8hjpf23s9HTEQdeGzdbJsCNC/stUE821qZ0gVQd6rH2leC/jw46 YpuS9F9EWAAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Thu Aug 14 19:11:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01188 for ; Thu, 14 Aug 2003 19:11:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMocqt023008 for ; Thu, 14 Aug 2003 15:50:38 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMocjQ023007 for ietf-smime-bks; Thu, 14 Aug 2003 15:50:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMobqt023002 for ; Thu, 14 Aug 2003 15:50:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EMsLV03154; Thu, 14 Aug 2003 16:54:21 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 16:54:21 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7EMobqt023003 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Fri, 15 Aug 2003 00:28:48 +0200 Simon Josefsson wrote: > Since mail clients cannot find certificates for arbitrary users today, > I believe clients must be modified regardless of the solution chosen. Yes. > Even here there is an advantage for DNS: mail clients already > implement DNS. There is no need to open ports in firewalls etc for > LDAP or XKMS. There is no need to implement new client code in the > mail client. That is, regrettably, not accurate. Existing clients do very little but hostname to address translation and service port location. I would be very surprised if they did anything but gethostbyname and getservbyname calls (or the platform API equivalent). It would be an addition to get them to query and retrieve records directly. Of course, this could be greatly aided by a freeware implementation on top of bind that provided a nice simple "give me a cert for this email address". It could do any of the approaches (direct cert from DNS, SRV to LDAP server followed by LDAP lookup, SRV to xkms server followed by xkms lookup). That would aid client developers and abstract things nicely but still wouldn't guarantee uptake. Whatever is done here, we have to convince Microsoft that it is a good thing to do and not very hard. I saw a notice today that Microsoft has officially terminated extension of Outlook Express. They want you to use Outlook instead. That means that S/MIME support in Express is more or less frozen ... I guess. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-smime@mail.imc.org Thu Aug 14 20:09:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02342 for ; Thu, 14 Aug 2003 20:09:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENfQqt025491 for ; Thu, 14 Aug 2003 16:41:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENfQUl025490 for ietf-smime-bks; Thu, 14 Aug 2003 16:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENfNqt025484 for ; Thu, 14 Aug 2003 16:41:25 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7ENfMdk021563 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 15 Aug 2003 01:41:22 +0200 To: "Blake Ramsdell" Cc: "'Steve Hole'" , Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030814:blake@brutesquadlabs.com:d3bfd22292ed378d X-Hashcash: 0:030814:blake@brutesquadlabs.com:d3bfd22292ed378d X-Payment: hashcash 1.2 0:030814:steve.hole@messagingdirect.com:2b39444c2479cd42 X-Hashcash: 0:030814:steve.hole@messagingdirect.com:2b39444c2479cd42 X-Payment: hashcash 1.2 0:030814:ietf-smime@imc.org:b1cca659819c8658 X-Hashcash: 0:030814:ietf-smime@imc.org:b1cca659819c8658 Date: Fri, 15 Aug 2003 01:41:22 +0200 In-Reply-To: (Blake Ramsdell's message of "Thu, 14 Aug 2003 15:40:51 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > Well, I'm not sure I agree with you here. End user SMTP/POP3/IMAP mail > clients today don't implement lots of DNS operations -- they just say > "all mail goes to this SMTP server" which is a simple gethostbyname > style call. Specifically, they don't deal with MX records. It has > actually been pointed out in other forums (and I've had experience with > this myself) that Windows is particularly ornery to work with for > arbitrary DNS record types that aren't supported through native APIs (I > had to write my own DNS client code to handle MX records back in the > day, and Peter Gutmann told me he got slapped around pretty good trying > to work with SRV records). Steve Hole writes: >> Even here there is an advantage for DNS: mail clients already >> implement DNS. There is no need to open ports in firewalls etc for >> LDAP or XKMS. There is no need to implement new client code in the >> mail client. > > That is, regrettably, not accurate. Existing clients do very little but > hostname to address translation and service port location. I would be > very surprised if they did anything but gethostbyname and getservbyname > calls (or the platform API equivalent). It would be an addition to get > them to query and retrieve records directly. It is clear that I have been spoiled by working with free software mail clients in the Unix world, which often do implement this. Even when they don't, a res_query() is never far away. Thanks for sharing experiences from other environments. Still, I believe part of my argument still holds. Even if your mail clients only use gethostbyname(), that still means the DNS infrastructure is available on the client machine. It hasn't been blocked by firewalls etc. This simplifies deployment. But this isn't an important point, and I don't see anything that can be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. Perhaps this tangental issue only distract us from the big picture. Regards, Simon From owner-ietf-smime@mail.imc.org Thu Aug 14 23:28:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05337 for ; Thu, 14 Aug 2003 23:28:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F34Eqt032388 for ; Thu, 14 Aug 2003 20:04:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F34Duo032387 for ietf-smime-bks; Thu, 14 Aug 2003 20:04:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F34Dqt032381 for ; Thu, 14 Aug 2003 20:04:13 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7F343309055 for ; Thu, 14 Aug 2003 20:04:03 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJN4ID00.F07; Thu, 14 Aug 2003 20:03:49 -0700 Date: Thu, 14 Aug 2003 20:05:04 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Blake Ramsdell" cc: "'Hallam-Baker Phillip'" , helm@fionn.es.net, "'Steve Hole'" , ietf-smime@imc.org In-Reply-To: Message-ID: <3F3C4DE0.8020204@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Blake Ramsdell wrote on 08/14/2003, 14:42: > > Well, I'm not sure I agree. There are two major questions that > constantly need answers in the mind of an S/MIME client. These are > pretty close to what Michael said in his message: > > 1. Given a particular email address, give me That Which Is Necessary and > Sufficient to send encrypted mail to that email address. > > 2. Given a particular certificate, is it suitable for signing mail that > came from a particular email address. Michael said "what is it good > for", which I think is too broad a question. > > If we're considering protocols that attempt to answer these types of > questions, those are the two questions that need to be answered by that > protocol (for interpersonal messaging with S/MIME, that is). Yes. I believe this is relevant to the SMIME mailing list, even though the choice and design of that protocol may not affect the SMIME message format itself, as these are major deployment issues. It would be highly desirable for one protocol to be designated for the purpose of solving these problems, as opposed to having a plethora of different solutions and having various client programs use different approaches, which would get us back to square one. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTAzMDUwNlowIwYJKoZIhvcNAQkEMRYE FNLfVqSIYvOXQWJouiaVdgjTDW4/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYABpeMw5Kbek/cyhpHH ONWJ58y8g/GsPBftUDy573ORV96K6eRf8LLqLYu/jQhAt9AOzz73nb+VI2ao+LEorMV1+o9d 0FOEyoBnh+7E6DGpVgWvOuWgYNwh0HcKGAu3wcan2A0p8TwgmbtOv6jMU5cThPXE/VNCAERd siq3dst7pQAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Thu Aug 14 23:28:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05340 for ; Thu, 14 Aug 2003 23:28:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F2vMqt032207 for ; Thu, 14 Aug 2003 19:57:22 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F2vME1032206 for ietf-smime-bks; Thu, 14 Aug 2003 19:57:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F2vHqt032197 for ; Thu, 14 Aug 2003 19:57:17 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7F2v8308594 for ; Thu, 14 Aug 2003 19:57:08 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJN46U02.Z06; Thu, 14 Aug 2003 19:56:54 -0700 Date: Thu, 14 Aug 2003 19:58:11 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3C4C43.6010205@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, Steve Hole wrote on 08/14/2003, 10:30: > Well, for the first time in a long time my interest is up on this > list :-). What a wonderful topic! General purpose use of > S/MIME by the masses on the Internet. Why hasn't it happened and what > can we do about it. Yes, that's exactly the problem that prompted my questions. And it's coming soon to an AOL mail program near you ... Some of you may have heard of this new "AOL Communicator" mail program that was released in the last week to the masses. In fact this program already includes S/MIME support. Hopefully, solving this problem doesn't necessitate new specs and completely new services and products, but only minor tweaks and clarifications of how to use the existing technology. > On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre > wrote: > > This highlights one of the key issues. It is easy enough to exchange > keys simply by sending a signed message, but there are some significant > barriers: > 1. What if your encryption key is separate from your signing key. This > is not only common but considered good security practice. How does one > go about exchanging/discovering the encryption key for the new party you > want to exchange mail with. This is supported today in Mozilla mail, Netscape 7.x mail, and AOL Communicator. In fact, in our internal PKI deployment we use different keys for encryption and signing. This results in the issuance of two different certificates, one for signing and another for encryption. The digital signature can be configured to include a different certificate for encryption. Look at my signature in this message and see if you get confused : I signed it with my corporate certificate, but I included a recipient Thawte encryption certificate. > 2. Timeliness of the key exchange. The problem with mutual signing > exchange is that the other person has to respond to you. What if you > just > want to send them an encrypted load right off the start. You can't > really do it. That's right, and it's the whole problem I have been asking about. Exchanging unencrypted messages first, in my opinion, is not a solution. > The solution is (and always has been) to do a lookup. The problem is > that > there is no directory to look up from. Global X.500/LDAP directories > are > *never* going to happen. Why ? > There is only one choice -- DNS. I (and Steve Kille and others) have > been flogging LDAP directories and working on LDAP/X.500 interconnects > for > a decade. Global X.500/LDAP isn't going to happen in our lifetime. Can you summarize why ? > Precisely. They must be able to do a DNS lookup for the information > either as a direct data return or a reference to a secondary storage > service, which absolutely could and probably should be LDAP. To > work in practice I think that it should be possible to get a direct pull > from the DNS so that organizations are not required to deploy an LDAP > directory and all that goes along with it (much as that pains me). I think other people have pointed out that DNS itself is not suited as the repository for the certificates. Since the query starts with only the e-mail address, which contains a userid and domain, I think it is appropriate to start the lookup in the DNS. There should be a standard schema to get to the appropriate LDAP server from the user's e-mail domain. The certificate would then be looked up from it. The client application could also fall back to a "default" LDAP server if the DNS query fails to find the appropriate directory. > > "Fishing" in domains as you say would be independent of e-mail client > > configuration for the most part (it could just be turned on or off). > > Actually, I think that "fishing" is an entirely appropriate thing to do. I didn't say it wasn't, I just have reservations on how it's done (see above). > The worst that can happen is that don't find the cert your looking for. > Trust issues MUST be dealt with, but certificate trust chains and > approaches are both well understood. > > The best that can happen is that suddenly I can go and find a cert for > joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want > to do that? Sounds good, but we have to make sure this is deployable for a lot of people. I don't really see how it would be. If LDAP is used to store the certs, perhaps all a domain owner might have to do would be do add an entry in the DNS, either with a new record type, or even simpler for quicker deployment, a standard name, eg pki-public-ldap . This entry could be pointed to some free public directory if the ISP doesn't want to run it itself. > This does lead very nicely into my second (and quite separate) issue in > this area -- the "trusted ROOT certificate". Julien has provided superp > leading commentary here. > > > You correctly point out that in most cases the user's domain and cert > > issuer domain are disjoint. This is especially true of e-mail users > > whose ISP isn't a CA (99.9% of them right now). > > Exactly. Why? Because it costs TOO MUCH. The only acceptable cost > for most ISP's is zero because of the volume of users. Cost of > certification is, pure and simple, the primary barrier to the general use > and deployment of S/MIME on the Internet. I think you have it backwards, cost of certification is way down on the list of obstacles to mass deployment of S/MIME right now. Let me mention some other important barriers : 1) the general public is completely unaware that certification even exists. I think this is the #1 issue by far. Many companies have been trying to raise awareness for PKI, but none have succeeded in getting the masses to adopt it yet. 2) the value of certification is low today because there are so few certified users, and encryption only works between certified people. This is like being one of the first one to have a telephone. (Even worse than that, without even having a directory in existence to find out who else you could communicate with - this is the problem at stake). 3) S/MIME is too complex to use I don't believe the first issue can be solved by any specifications or talk in this group, but several companies will continue to work on it. Hopefully they will succeed. The first two issues are related. As more people become aware of certification and certified, the value of being certified will increase. I believe the cost of the certification will be much less of an issue once people realize they are paying for a something useful. IMO, the certificate dissemination issue remains a major obstacle. Even if lots of people were certified today, it would still be very hard to know who they are and communicate with them. The complexity of S/MIME usability is also something the group has impact on. The specifications heavily impact the implementation and usability of S/MIME client software. > The reason for the cost is that the mechanism for establishing root trust > is determined solely by the set of ROOT certificates distributed by the > client vendor -- of all things!. Thus only those organizations that can > afford to pay the client vendor -- of all things! -- to be included in > their "special trusted root certificate club" get to have "trust". > Which > means that you MUST buy certs from one of the club members. Doesn't THAT > just suck. Nice business if you can get it. Yes, vendors have to ship a certain set of roots. We can't just automagically trust every self-signed root there is. We ship with about a hundred roots already though. It is true Netscape has charged in the past for including it. Microsoft requests that your root goes through an independent certification process. Either way, the process costs a lot of money. You aren't limited to using the roots that are shipped. You can add your own roots if you want to trust it. All it takes is a couple of clicks in the client application. If you don't like your users having to click, you can pull a Mozilla source tree, and add your very own root certificates and mark them trusted if you like. It is a simple process and I'll be happy to show anyone how to do it, as I have been the one checking in the roots to the official tree. Any ISP could do it. Any CA could do it. Any corporation could do that. > Regardless, to have this power rest in the hands of the client vendor is > ludicrous. Why should I trust that Microsoft can evaluate the security > and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not > saying they are unqualified to do so, but I'm a lot more likely to > trust a > self signed "Bank of America" certificate issued on it's own behalf and > obtained from a reliable source, than I am a third party software vendor > or CA Verisign (not that there's anything wrong with either Microsoft or > Verisign :-). All the client vendors do is provide a default trust domain, which is a list of well-known root certificates with trust settings. What do you want them to do ? Ship with no roots at all ? Automatically trust every single self-signed root under the sun ? The default trust domain that ships with client software is not static. Like any other software setting, it can be configured. Any user is free to add another root and mark it trusted. If the trust domain was static then you would have a point, but as I see it, you miss the point. > Period. If we want generalized S/MIME usage throughout the Internet we > need to think of some mechanism that is: > > 1. Easy to deploy. The track record for the Internet stongly indicates > that this means that there are freeware versions of software that will > support the deployment. This includes both the key management and > publication software and the usage (client) software. At least we agree it needs to be easy. > 2. Free. Those who "own" the vast majoritiy of the user population on > the Internet are ISP's. They have almost no margin and simply cannot > afford to pay for certification. Also (and more importantly IMHO) is the > desired for businesses to touch their customers. These are HUGE volume > relationships in which there are virtually no economically viable ways of > establishing bidirectional trust. A cert price of $0.01 a year is too > much if your customer population is 25 million people (banks, utilities, > etc.) The price figure you cite is absurdly low. Do you really, seriously think $250,000 to enable secure services matters much to a company with 25 million customers ? Certainly it wouldn't matter much to a bank, especially since it would probably reduce certain mailing costs. I'd guess that even one bulk USPS communication is going to cost more than 1 cent per recipient. I only know one ISP with 25 million customers or more, and I happen to work for it, but I'm not at liberty to comment further on the costs. The bottom line is, running a CA is a service, and it costs money, probably far, far more than $0.01 per cert per year. Whether an ISP runs it itself or outsources it, the service is going to cost some money somewhere Anyway, I think we are getting quite off-topic here. If people want to run a loss-leader cert service they are welcome to do so, just as Thawte/Verisign does. I don't know how much relevance this has to the mailing list. Or do you want to codify the prices of certificates into the RFCs ? > I can then lookup certs based on mail address (duh!), where the mail > domain source is trusted because of DNS-SEC. This trust relationship > could be either: > > implicit -- the issuer domain location is trusted therefore any keys > published there are trusted, > > explict -- the issuer provides a root signing key which is in turn signed > by their DNS-SEC key. What you are proposing is a new policy to automatically trust the certificate because of the security of the channel it traveled through. But there has to be some prior trust somehow for the channel itself. I'm not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so there would have to be prior trust on the DNS server certificate too. All in all, I think the implicit trust is very dangerous. It is one thing to accept information through that channel while it is open, but to continue to use it after it is closed, by automatically trusting the certificate that was transferred, is another. You may argue that it is better than nothing, however, a false sense of security may be worse than knowledge of the lack of security. > Well, even though I would love it if it was LDAP, it isn't going to > happen. DNS is the only game in town for global directory service. I don't see why the lookup has to be a 1-part lookup. It could - and probably should, given the size of the problem - take more than one step. -- I am the dog in dogfood From owner-ietf-smime@mail.imc.org Fri Aug 15 00:07:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05844 for ; Fri, 15 Aug 2003 00:07:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F3WYqt033372 for ; Thu, 14 Aug 2003 20:32:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F3WYYe033371 for ietf-smime-bks; Thu, 14 Aug 2003 20:32:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F3WWqu033366 for ; Thu, 14 Aug 2003 20:32:32 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3F3C4DE0.8020204@netscape.com> References: <3F3C4DE0.8020204@netscape.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 14 Aug 2003 20:33:17 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: RE: dissemination of public encryption certificates Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:05 PM -0700 8/14/03, Julien Pierre wrote: >It would be highly desirable for one protocol to be designated for the >purpose of solving these problems, as opposed to having a plethora of >different solutions and having various client programs use different >approaches, which would get us back to square one. We are already at that square. >I believe this is relevant to the SMIME mailing list, even though >the choice and design of that protocol may not affect the SMIME message >format itself, as these are major deployment issues. I'm not convinced that this WG is the best one for the discussion, inasmuch as it is not in our charter and the WG is supposed to wind down. On a related note, there may be a new WG starting up to discuss how to handle certificate management in IPsec (the IPsec WG has failed worse than S/MIME on certificate issues). It might be interesting to have a single WG that covers both issues. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Fri Aug 15 03:50:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20861 for ; Fri, 15 Aug 2003 03:50:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F78qqt050759 for ; Fri, 15 Aug 2003 00:08:52 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F78qu6050756 for ietf-smime-bks; Fri, 15 Aug 2003 00:08:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F78oqt050738 for ; Fri, 15 Aug 2003 00:08:51 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t12o913p74.telia.com [213.64.28.194]) by smtp4.hy.skanova.net (8.12.9/8.12.9) with SMTP id h7F77vqD029663; Fri, 15 Aug 2003 09:08:11 +0200 (CEST) Message-ID: <00ec01c362fb$ebeff1f0$0500a8c0@arport> From: "Anders Rundgren" To: "Julien Pierre" Cc: References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Subject: Re: dissemination of public encryption certificates Date: Fri, 15 Aug 2003 09:06:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit May I add some naive thought to the table? That the issuer is of great importance for signatures and authentication purposes is undoubtedly true. But I cannot really say that I see the same need for TPP-issued encryption certificates. Is there even a need for encryption-certificates? It seems sufficient that users in their e-mail client create key-pairs and publish the public key in the associated domain. If you trust the lookup service like XKMS why should this not be enough? Well you could actually create a self-signed certificate in your mail client and send a signed message (using a trusted signer cert/key) containg the generated encryption key or cert to encryptionregistry@yourdomain to get it automatically published. No apparent need for CAs and associated root and path validation for encryption certificates. XKMS introduces an optional trust-anchor itself but that would not work (scale)with encryption certificates for a global Internet. So no matter what you do, there will be lose ends on all lookup solutions. Only the hard transfer-the-globally-recognized-TTP-certificate-out- band will be "fully secure" and we already know that this does not support the more dynamic scenarious we are currently discussing. For enterprise usage I doubt that end-to-end encryption is of much value as lost keys create too much hassles. Most business systems are likely to rather use HTTPS which is easier to handle than S/MIME encryption. Anders ----- Original Message ----- From: "Steve Hole" To: "Julien Pierre" Cc: Sent: Thursday, August 14, 2003 19:30 Subject: Re: dissemination of public encryption certificates Well, for the first time in a long time my interest is up on this list :-). What a wonderful topic! General purpose use of S/MIME by the masses on the Internet. Why hasn't it happened and what can we do about it. Before you read on, be assured that it is the large scale use of S/MIME that the following diatribe is focused on. On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre wrote: > If you send an email today, you can simply sign it and include your > certificate in the signature. If you just sign all your mail, then all > you always disseminate your certificate. So in what situations does this > new MIME extension certificate lookup help ? I suppose this extension > would be shorter than a digital signature. However it would also be much > less secure. This highlights one of the key issues. It is easy enough to exchange keys simply by sending a signed message, but there are some significant barriers: 1. What if your encryption key is separate from your signing key. This is not only common but considered good security practice. How does one go about exchanging/discovering the encryption key for the new party you want to exchange mail with. 2. Timeliness of the key exchange. The problem with mutual signing exchange is that the other person has to respond to you. What if you just want to send them an encrypted load right off the start. You can't really do it. The solution is (and always has been) to do a lookup. The problem is that there is no directory to look up from. Global X.500/LDAP directories are *never* going to happen. There is only one choice -- DNS. I (and Steve Kille and others) have been flogging LDAP directories and working on LDAP/X.500 interconnects for a decade. Global X.500/LDAP isn't going to happen in our lifetime. > The case I originally asked about is : > neither party has exchanged any e-mail yet, but they know each other's > e-mail address. They want to communicate securely. How do they avoid or > bypass the initial insecure e-mail exchange ? Precisely. They must be able to do a DNS lookup for the information either as a direct data return or a reference to a secondary storage service, which absolutely could and probably should be LDAP. To work in practice I think that it should be possible to get a direct pull from the DNS so that organizations are not required to deploy an LDAP directory and all that goes along with it (much as that pains me). > > In summary I think that a certificate-independent configuration > > of e-mail clients would be more universal than "fishing" in > > domains as the user domain and issuer domain may be entirely > > disjunct. > > "Fishing" in domains as you say would be independent of e-mail client > configuration for the most part (it could just be turned on or off). Actually, I think that "fishing" is an entirely appropriate thing to do. The worst that can happen is that don't find the cert your looking for. Trust issues MUST be dealt with, but certificate trust chains and approaches are both well understood. The best that can happen is that suddenly I can go and find a cert for joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want to do that? This does lead very nicely into my second (and quite separate) issue in this area -- the "trusted ROOT certificate". Julien has provided superp leading commentary here. > You correctly point out that in most cases the user's domain and cert > issuer domain are disjoint. This is especially true of e-mail users > whose ISP isn't a CA (99.9% of them right now). Exactly. Why? Because it costs TOO MUCH. The only acceptable cost for most ISP's is zero because of the volume of users. Cost of certification is, pure and simple, the primary barrier to the general use and deployment of S/MIME on the Internet. The reason for the cost is that the mechanism for establishing root trust is determined solely by the set of ROOT certificates distributed by the client vendor -- of all things!. Thus only those organizations that can afford to pay the client vendor -- of all things! -- to be included in their "special trusted root certificate club" get to have "trust". Which means that you MUST buy certs from one of the club members. Doesn't THAT just suck. Nice business if you can get it. Yes I know about free thawte certs. I know that any root issuer must be secure and provide good protection from having roots keys compromised etc. I agree that anyone who issues certificates should be required to be secure. I understand that there is risk to the client vendor if they report trust in a cert that has been compromised at the root. Regardless, to have this power rest in the hands of the client vendor is ludicrous. Why should I trust that Microsoft can evaluate the security and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not saying they are unqualified to do so, but I'm a lot more likely to trust a self signed "Bank of America" certificate issued on it's own behalf and obtained from a reliable source, than I am a third party software vendor or CA Verisign (not that there's anything wrong with either Microsoft or Verisign :-). The issue comes down to trust brokering. I just don't think that it is working for the *general* mass consumer Internet. It clearly does work for closed communities within the Internet, but it isn't scaling. Period. If we want generalized S/MIME usage throughout the Internet we need to think of some mechanism that is: 1. Easy to deploy. The track record for the Internet stongly indicates that this means that there are freeware versions of software that will support the deployment. This includes both the key management and publication software and the usage (client) software. 2. Free. Those who "own" the vast majoritiy of the user population on the Internet are ISP's. They have almost no margin and simply cannot afford to pay for certification. Also (and more importantly IMHO) is the desired for businesses to touch their customers. These are HUGE volume relationships in which there are virtually no economically viable ways of establishing bidirectional trust. A cert price of $0.01 a year is too much if your customer population is 25 million people (banks, utilities, etc.) Why could we not have organizations issue certificates distributed via DNS, with a trust relationship provided by DNS-SEC? That is, you can trust that the DNS node your are dealing with is legitimate because they have deployed DNS-SEC (which everyone should do anyway for a host of other security reasons) and the keys that are located within the DNS hierachy are legitimate. I can then lookup certs based on mail address (duh!), where the mail domain source is trusted because of DNS-SEC. This trust relationship could be either: implicit -- the issuer domain location is trusted therefore any keys published there are trusted, explict -- the issuer provides a root signing key which is in turn signed by their DNS-SEC key. There are a number of observations that can be made about this approach: 1. The security provided by the approach is probably not as strong as the full commercial CA approach. I contend "so what". It's better than nothing and Pretty Good (pun intended). The average user doesn't need military grade security. The average bill issued by the local telephone utility doesn't need military grade security. Think of the vast number of paper documents that need only Pretty Good security and trust to be useful (292 Trillion a year in the US -- it's my business and I happen to know). All we need is some security to make that paper go away forever. 2. Some extensions to bind and a new CSP for Windows would get a large number people going in a hurry. Openssl with an HSM card and some reasonable security policy has an organization running pretty quickly. > The only solution for > these users is some sort of universal registration service. Yup. > This implies > the existence of some sort of free worldwide directory service (LDAP) > that would resolve e-mail addresses to certificates ... And clients > would need to be (automatically?) configured to do look ups in it. Well, even though I would love it if it was LDAP, it isn't going to happen. DNS is the only game in town for global directory service. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 From owner-ietf-smime@mail.imc.org Fri Aug 15 12:23:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02312 for ; Fri, 15 Aug 2003 12:23:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FFkRqt006125 for ; Fri, 15 Aug 2003 08:46:27 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FFkRRC006124 for ietf-smime-bks; Fri, 15 Aug 2003 08:46:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FFkMqt006102 for ; Fri, 15 Aug 2003 08:46:25 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FFo2V09415; Fri, 15 Aug 2003 09:50:03 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 09:50:02 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FFkPqt006116 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson wrote: > But this isn't an important point, and I don't see anything that can > be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. > Perhaps this tangental issue only distract us from the big picture. Agreed. I think that the provision of a simple-to-use API would be a huge help here. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-smime@mail.imc.org Fri Aug 15 12:55:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03491 for ; Fri, 15 Aug 2003 12:55:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGQPqt008819 for ; Fri, 15 Aug 2003 09:26:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FGQPxW008818 for ietf-smime-bks; Fri, 15 Aug 2003 09:26:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGQOqt008813 for ; Fri, 15 Aug 2003 09:26:24 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FGUBV09721; Fri, 15 Aug 2003 10:30:11 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 10:30:11 -0700 To: Julien Pierre Subject: Re (subtopic): LDAP certificate distribution Cc: ietf-smime@imc.org In-Reply-To: <3F3C4C43.6010205@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FGQOqt008814 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre wrote: > Why ? Because you have to run a root. That is, the hierarchy has to have a top level interconnect. This quickly becomes an issue of governance. National goverments get involved the way they got involved in DNS. The difference is that the governments got involved *before* the service was running, not after the way they did with DNS. There is a long track record of attempts at establishing global X.500 whitepages services. There were several attempts that I participated in that just didn't gain traction. I think in retrospect it was primarily a cost issue again. The *business* people and organizations who had interest in participating couldn't stomach a "build it an they will come" approach when there were real costs and somewhat amorphous benefits. People just don't get why you need it and the formal delegation and governance rules made it non-trivial to set up. Note that I said "Whitepages". Regrettably, PKI information at the global level was always linked to other personal information that would aid in the search and retrieval of useful information on people. This was a goal that I happily promoted and thought "was a great idea". Wrong. What I (and many others) never thought about was the privacy concerns. Sure the system is secure and access controlled etc etc. But, the governance issues around actually making this information available on the Internet was really huge. By the time some of this was figured out, the perception had become that none of it was truly deployable. Very few commercial organizations (government doesn't count) wanted that information available and didn't believe that secure interpersonal email (the one obvious use application) needed that level of support. There were some not insubstantial technical hurdles with root management and scaling as well. Problems that probably could have been (and were for the most part) solved, but took long enough to solve that people just didn't believe. Basically, there was enough disinterest that the whole thing just stagnated. Finally, the one thing that could have driven the service -- storage of keys -- was itself a substantial cost item because of the cost of certification. While certification costs have dropped, in the beginning they were excruciating and only the richest could play. Therefore, there never was a groundswell of use that demanded that the "situation be improved". You need a Web like uptake to get the necessary infrastructure allocated and serviced. In short there was always a substantial cost. My experience with the Internet is that the only things that successfully deploy to Internet scale are things that start with the groundswell of the common user. It has to be easy and it has to be (near) free. > > There is only one choice -- DNS. I (and Steve Kille and others) have > > been flogging LDAP directories and working on LDAP/X.500 interconnects > > for > > a decade. Global X.500/LDAP isn't going to happen in our lifetime. > > Can you summarize why ? Pretty much did above :-) For what it's worth, I am NOT saying "LDAP is useless". What I'm saying is that you need to leverage the one and only global directory service the Internet is ever likely to successfully deploy to get to your LDAP (or XKMS) services. Then we avoid the governance, root and cost issues associated with global directory whitepages. > > Precisely. They must be able to do a DNS lookup for the information > > either as a direct data return or a reference to a secondary storage > > service, which absolutely could and probably should be LDAP. To > > work in practice I think that it should be possible to get a direct pull > > from the DNS so that organizations are not required to deploy an LDAP > > directory and all that goes along with it (much as that pains me). > > I think other people have pointed out that DNS itself is not suited as > the repository for the certificates. > Since the query starts with only the e-mail address, which contains a > userid and domain, I think it is appropriate to start the lookup in the > DNS. There should be a standard schema to get to the appropriate LDAP > server from the user's e-mail domain. The certificate would then be > looked up from it. The client application could also fall back to a > "default" LDAP server if the DNS query fails to find the appropriate > directory. Works for me. More LDAP servers sold then :-) > > The worst that can happen is that don't find the cert your looking for. > > Trust issues MUST be dealt with, but certificate trust chains and > > approaches are both well understood. > > > > The best that can happen is that suddenly I can go and find a cert for > > joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want > > to do that? > > Sounds good, but we have to make sure this is deployable for a lot of > people. I don't really see how it would be. > > If LDAP is used to store the certs, perhaps all a domain owner might > have to do would be do add an entry in the DNS, either with a new record > type, or even simpler for quicker deployment, a standard name, eg > pki-public-ldap . This entry could be pointed to some free public > directory if the ISP doesn't want to run it itself. I think we are in agreement. That was easy :-) As noted in other messages the practical hurdles for deployment center on management (key issuer) and client (user). Unless something is specified there is no hope of even getting to those hurdles though. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-smime@mail.imc.org Fri Aug 15 13:22:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05747 for ; Fri, 15 Aug 2003 13:22:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGpDqt010345 for ; Fri, 15 Aug 2003 09:51:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FGpDY1010344 for ietf-smime-bks; Fri, 15 Aug 2003 09:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGpCqt010339 for ; Fri, 15 Aug 2003 09:51:12 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255; Fri, 15 Aug 2003 12:51:08 -0400 (EDT) Message-Id: <200308151651.MAA03255@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-x400wrap-09.txt Date: Fri, 15 Aug 2003 12:51:08 -0400 Sender: owner-ietf-smime@mail.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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-09.txt Pages : 11 Date : 2003-8-15 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-09.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-x400wrap-09.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: <2003-8-15124039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Fri Aug 15 13:46:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06343 for ; Fri, 15 Aug 2003 13:46:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FHJHqt011534 for ; Fri, 15 Aug 2003 10:19:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FHJH3Y011533 for ietf-smime-bks; Fri, 15 Aug 2003 10:19:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FHJGqt011527 for ; Fri, 15 Aug 2003 10:19:16 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id D6EED20660B for ; Fri, 15 Aug 2003 13:17:33 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19nhoP-0001oE-Oh for ietf-announce-list@asgard.ietf.org; Fri, 15 Aug 2003 12:52:25 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19nhnG-0001kd-Ph for all-ietf@asgard.ietf.org; Fri, 15 Aug 2003 12:51:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255; Fri, 15 Aug 2003 12:51:08 -0400 (EDT) Message-Id: <200308151651.MAA03255@ietf.org> 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-x400wrap-09.txt Date: Fri, 15 Aug 2003 12:51:08 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+47629_214518835125604_0543265711" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+47629_214518835125604_0543265711 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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-09.txt Pages : 11 Date : 2003-8-15 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-09.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-x400wrap-09.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. --MIMEStream=_0+47629_214518835125604_0543265711 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+254605_0977245551210_29285560305" --MIMEStream=_1+254605_0977245551210_29285560305 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-09.txt --MIMEStream=_1+254605_0977245551210_29285560305 Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> --MIMEStream=_1+254605_0977245551210_29285560305-- --MIMEStream=_0+47629_214518835125604_0543265711-- From owner-ietf-smime@mail.imc.org Fri Aug 15 14:45:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08173 for ; Fri, 15 Aug 2003 14:45:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIF3qt013867 for ; Fri, 15 Aug 2003 11:15:03 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FIF3Xf013866 for ietf-smime-bks; Fri, 15 Aug 2003 11:15:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7FIF2qt013861 for ; Fri, 15 Aug 2003 11:15:02 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from pcp04426435pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.140.179 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 15 Aug 2003 18:15:04 -0000 From: "Bonatti, Chris" To: Cc: Subject: RE: Update of CMS-X.400 Drafts Date: Fri, 15 Aug 2003 14:15:03 -0400 Organization: IECA, Inc. Message-ID: <000301c36359$26561240$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7FIF2qt013862 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Francois, This has not been discussed before on this list, but to my knowledge has there has not been a strong call for this. My view is that this is feasible, but presently outside the scope of the draft. Since this doesn't constitute a MUST in the 2633bis, I'm not sure this is significant. I do not favor slowing down the spec for this. Do others have opinions on this? Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Francois.Rousseau@CSE-CST.GC.CA Sent: Monday, August 11, 2003 13:16 To: BonattiC@ieca.com Cc: ietf-smime@imc.org Subject: RE: Update of CMS-X.400 Drafts Hi Chris, I am very sorry to not have noticed this before, but I did not see any mention of optionally supporting Compression (i.e. RFC3274) under WRAP like under MSGbis. Isn't compression something that could also be useful for X.400 content? Was this intentional? Cheers, Francois -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Saturday, August 09, 2003 11:32 AM To: ietf-smime@imc.org Subject: Update of CMS-X.400 Drafts With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. From owner-ietf-smime@mail.imc.org Fri Aug 15 15:12:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09349 for ; Fri, 15 Aug 2003 15:12:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIjDqt015211 for ; Fri, 15 Aug 2003 11:45:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FIjDou015210 for ietf-smime-bks; Fri, 15 Aug 2003 11:45:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIjBqt015205 for ; Fri, 15 Aug 2003 11:45:11 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FImxV10787; Fri, 15 Aug 2003 12:48:59 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 12:48:59 -0700 To: Julien Pierre Subject: Re (subtopic): certificate issuance and trust Cc: ietf-smime@imc.org In-Reply-To: <3F3C4C43.6010205@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FIjBqt015206 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I broke the reply into to parts because they really are quite separate issues. This topic deals primarily with the issuance of certificates and trust management in deployed S/MIME clients. I debated taking it offline, but I think that it is useful discussion from a usage point of view. It has little technical merit on a primarily technical forum, but it has overall import for S/MIME -- I hope :-) On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre wrote: > I think you have it backwards, cost of certification is way down on the > list of obstacles to mass deployment of S/MIME right now. Let me mention > some other important barriers : > > 1) the general public is completely unaware that certification even > exists. I think this is the #1 issue by far. > Many companies have been trying to raise awareness for PKI, but none > have succeeded in getting the masses to adopt it yet. > > 2) the value of certification is low today because there are so few > certified users, and encryption only works between certified people. > This is like being one of the first one to have a telephone. OK. Before I go on, I will state that I agree with both of these assertions on an individual basis. The issue is really how many of these things work in combination to stall or make S/MIME usage difficult. I see that we need to talk a bit about the usage models that are evolving on the Internet. There are at least two with variations: 1. Interpersonal secure mail. This is Mom exchanging secure email with Aunt Jane on the other side of the country. 2. Organizational communications. This is the business to consumer or organization to partipant communications (ie. my bank wanting to send me statements and me wanting to complain to my bank). Because I am so focused on usage model 2 these days I tend to forget about usage model 1. My apologies. Conversely, I suspect that very little thought has gone into usage model 2 as it is an entirely new thing for business to be doing on the Internet. So what? Your assertions and the priority you assign them are spot on for usage model 1. I would still add both cost and complexity of certification to this model. For Mom to sign up to get a cert is actually pretty daunting from a user interface point of view. We and our customers have done lots of user tests and it is a problem. My assertion that cost is a big deal is very applicable to usage model 2. In this case organizations want to certify their consumers for secure document receipt and (possibly) reply. Outbound is fairly easy -- just issue an encryption only cert to the user on enrollment. No trust issues and it is reasonably easy to get to the user's desktop. The problem comes when you want bidirectional communication and are therefore issuing signing certs. The cost of doing this for millions of customers is so high using the existing certification model (because of root trust requirements) that to use S/MIME becomes impractical or forces alternative solutions. There are a series of companies that provide "e-mail encryption" using proprietary formats and Javascript symetric decryptors that completely bypass S/MIME altogether. And people buy it! BIG organizations buy it. It's depressing. And when talking about S/MIME it has to be concern to this group and people who implement S/MIME clients. > (Even worse than that, without even having a directory in existence to > find out who else you could communicate with - this is the problem at > stake). Correct. This means that interpersonal secure email usage is impractical because there is no way to obtain necessary security information for an arbitrary recipient. This is the original stated problem and we all agree that it is a major, if not the major barrier. I think that we have some good concensus building on that and maybe there are some actions that we can now take to try to resolve the issue. > 3) S/MIME is too complex to use S/MIME isn't so complicated (at least our user testing doesn't indicate that). We get very few usage calls back to customer support. Certification is certainly complicated. Even the easiest of the commercial (Verisign) CA's are quite daunting to the average user. This is an implementation issue that needs some work. This accounts for better than 95% of our TOTAL service calls. Ouch! > I don't believe the first issue can be solved by any specifications or > talk in this group, but several companies will continue to work on it. > Hopefully they will succeed. The only way to solve it (I think) is to have organizations initiate certificate issuance. That is, ISP's need to offer to do this as part of their enrollment. Certificate awareness is very high in my usage model 2 because either Joe Customer wants to get e-documents from Sam Business or Sam Business wants Joe Customer to get e-documents. Either way, there is explicit communication that initiates certification (in all the various ways that can be done). So it is a question of how do we initiate certification? More importantly how do we get ISP's (or a proxy third party) to engage users in the certification process. > The first two issues are related. As more people become aware of > certification and certified, the value of being certified will increase. > I believe the cost of the certification will be much less of an issue > once people realize they are paying for a something useful. No it won't :-) Will your Mom pay to be certified? I know for a fact mine won't because I tried to get her to get a Verisign cert and when she found out it was $20, that terminated that conversation quickly :-) It will improve yes, but you won't get anywhere near universal uptake. ... some stuff skipped ... > Yes, vendors have to ship a certain set of roots. We can't just > automagically trust every self-signed root there is. We ship with about > a hundred roots already though. It is true Netscape has charged in the > past for including it. Microsoft requests that your root goes through an > independent certification process. Either way, the process costs a lot > of money. > > You aren't limited to using the roots that are shipped. > You can add your own roots if you want to trust it. All it takes is a > couple of clicks in the client application. > If you don't like your users having to click, you can pull a Mozilla > source tree, and add your very own root certificates and mark them > trusted if you like. It is a simple process and I'll be happy to show > anyone how to do it, as I have been the one checking in the roots to the > official tree. Any ISP could do it. Any CA could do it. Any corporation > could do that. You are right. I knew when I was writing that part that I was going to get into trouble :-). First of all, this problem really is a usage model 2 issue. An organization wants to certify a very large number of users. It really doesn't apply to usage model 1, for which most of the existing S/MIME clients are targeted. > All the client vendors do is provide a default trust domain, which is a > list of well-known root certificates with trust settings. What do you > want them to do ? Ship with no roots at all ? Automatically trust every > single self-signed root under the sun ? > > The default trust domain that ships with client software is not static. > Like any other software setting, it can be configured. Any user is free > to add another root and mark it trusted. > If the trust domain was static then you would have a point, but as I see > it, you miss the point. All of the above is correct. I'm saying two things: 1. It would be very nice if there is some way that the trust domain could be removed from client configuration to a centralized service. This is simply good engineering and allows for dynamic control over what is trusted and what is not. 2. Modifying desktop settings to support security policy and certificate issuance is a non-starter for usage model 2. It's the old adage -- people want security but they don't want to have to do anything to get it. I'll give you an example that might help. If My Huge Bank wanted to issue certificates to their users to establish a secure email community of trust, then they have two choices: acquire certificates from one of the CA's that is already in the "trusted root" category or try to issue self-signed certificates and become a trusted root. Cost is a big barrier in the first option. Deployment complexity (and some cost) is a barrier for option 2. Because a new root certificate has to be downloaded to every desktop you've got a deployment latency problem. Because it costs (in some non-insubstantial set of S/MIME implementations) to get a registered root certificate, the costs of this are not insubstantial either. If the cost that an organization like My Huge Bank will bear to roll out a new service is $1M - $500K you can see that the cost of deployment for an S/MIME solution is severly compromised by the costs of certification. Companies and solutions like Tumbleweed exist that provide alternatives to S/MIME simply because of this fact. If we could arrange things to avoid the cost and provide zero deployment latency, that would greatly enhance usage model 2 scenarios and make life difficult for non-standard email security solutions. > The price figure you cite is absurdly low. Do you really, seriously > think $250,000 to enable secure services matters much to a company with > 25 million customers ? Certainly it wouldn't matter much to a bank, > especially since it would probably reduce certain mailing costs. I'd > guess that even one bulk USPS communication is going to cost more than 1 > cent per recipient. I only know one ISP with 25 million customers or > more, and I happen to work for it, but I'm not at liberty to comment > further on the costs. First of all, $0.01 per cert for 25M customers is $2.5M annually. You need to go have a look at who I work for :-) The example that I give above is by far the rule. The costs that even a large bank with 25M consumers will bear for *any* Internet application is quite low at this point. Most of that has to do with the series of disappointing Internet applications and middleware that were invested in over the years has seriously damaged their trust in real return on investment in Internet applications. The *only* reason that we can sell secure document delivery systems to our customers with S/MIME based security is that we do one-way encryption only solutions which obviates the need for signing certs and trust. Even with that, many of our customers find the simple certification issuance that we do (two dialogs and a single page turn) too much and want to use password based encryption instead. We have been forced to write an S/MIME viewer application that supports the S/MIME shared secret profile because very few of the shipping clients support it yet. > The bottom line is, running a CA is a service, and it costs money, > probably far, far more than $0.01 per cert per year. Whether an ISP runs > it itself or outsources it, the service is going to cost some money > somewhere > > Anyway, I think we are getting quite off-topic here. If people want to > run a loss-leader cert service they are welcome to do so, just as > Thawte/Verisign does. I don't know how much relevance this has to the > mailing list. Or do you want to codify the prices of certificates into > the RFCs ? Agreed, we can take the remainder of this conversation off line. However, it is important to note that the cost of running a your own CA today is largely a matter of the licensing costs of running the CA software. There are operational costs, but those costs can and should be part of the cost of operating the application the uses S/MIME. We do NOT charge for certificate issuance in our product. We charge for documents delivered. There is a direct and easy comparison for any usage model 2 document issuer to compare the cost of paper mail to secure email. If we had the ability to "Register" a self certifying organization root certificate in one place (not one for every desktop client) that would be a huge step forward. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-smime@mail.imc.org Fri Aug 15 19:45:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17973 for ; Fri, 15 Aug 2003 19:45:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FN9Lqt024899 for ; Fri, 15 Aug 2003 16:09:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FN9Lip024898 for ietf-smime-bks; Fri, 15 Aug 2003 16:09:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FN9Kqt024893 for ; Fri, 15 Aug 2003 16:09:20 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 15 Aug 2003 16:09:16 -0700 From: "Blake Ramsdell" To: "'Steve Hole'" , "'Simon Josefsson'" Cc: Subject: RE: PKI and S/MIME Date: Fri, 15 Aug 2003 16:09:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Steve Hole > Sent: Friday, August 15, 2003 9:50 AM > To: Simon Josefsson > Cc: ietf-smime@imc.org > Subject: Re: PKI and S/MIME > > On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson > wrote: > > > But this isn't an important point, and I don't see anything that can > > be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. > > Perhaps this tangental issue only distract us from the big picture. > > Agreed. I think that the provision of a simple-to-use API > would be a > huge help here. I thought I published this at one point, though it might have been internal only. I'll use a somewhat Java-ish syntax here. EncryptingInformation findInformationRequiredForEncryptingForEmailAddress( String emailAddress ); boolean isCertificateSuitableForSigningEmail( String emailAddress, X509Certificate signingCertificate, X509CertificateList otherCertificates, CRLList cRLs ); EncryptingInformation contains: 1. Any cached SMIMECapabilities 2. An X.509 certificate for encrypting OK, now we just fill in the details ;). Blake From owner-ietf-smime@mail.imc.org Fri Aug 15 21:01:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19597 for ; Fri, 15 Aug 2003 21:01:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0aIqt029057 for ; Fri, 15 Aug 2003 17:36:18 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G0aI7q029056 for ietf-smime-bks; Fri, 15 Aug 2003 17:36:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0aHqt029049 for ; Fri, 15 Aug 2003 17:36:17 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7G0aED16471 for ; Fri, 15 Aug 2003 17:36:14 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJOSBT00.21N; Fri, 15 Aug 2003 17:35:53 -0700 Date: Fri, 15 Aug 2003 17:37:10 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Anders Rundgren" cc: ietf-smime@imc.org In-Reply-To: <00ec01c362fb$ebeff1f0$0500a8c0@arport> Message-ID: <3F3D7CB6.9020407@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> <00ec01c362fb$ebeff1f0$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Anders, Anders Rundgren wrote on 08/15/2003, 0:06: > May I add some naive thought to the table? > > That the issuer is of great importance for signatures and authentication > purposes is undoubtedly true. > > But I cannot really say that I see the same need for TPP-issued > encryption > certificates. Is there even a need for encryption-certificates? It > seems sufficient > that users in their e-mail client create key-pairs and publish the public > key in the associated domain. If you trust the lookup service like XKMS > why should this not be enough? Certificates establish a permanent, traceable link between the user's identity and the public key. If I correctly understand what you propose, the XKMS service would provide a temporary link between the user's identity and the the public key. One reason this link isn't enough is revocation. If the key gets compromised at some point, how do you indicate at a later time not to trust that key anymore ? And how do you do it retroactively ? Correct me if I'm wrong, but most revocation systems today are based on CRLs rather than KRLs. The government was the only user of KRLs but even they are using CRLs now. Most software as a result primarily supports certificate-based revocation, not key-based revocation. > Well you could actually create a > self-signed > certificate in your mail client and send a signed message (using > a trusted signer cert/key) containg the generated encryption key or > cert to > encryptionregistry@yourdomain to get it automatically published. > No apparent need for CAs and associated root and path validation > for encryption certificates. It should be a policy of the repository however to decide whether or not to apply path validations for certificates it stores. Certainly one could decide not to do any validation if they so chose. However eventually, when an end user does a query, they most likely won't trust that self-signed certificate due to their trust domain configuration. So it would not be in the interest of the repository to have too lax of a policy on cert issuers. > XKMS introduces an optional trust-anchor itself but that would not > work (scale)with encryption certificates for a global Internet. So no > matter what you do, there will be lose ends on all lookup solutions. > Only the hard transfer-the-globally-recognized-TTP-certificate-out- > band will be "fully secure" and we already know that this does not > support the more dynamic scenarious we are currently discussing. It can work if there is a set of well-known accepted trusted roots. I don't think every single random root should be automatically trusted. What's missing is a way to easily replicate the trust domain - ie. let the repositories dynamically add roots once a new CA goes in business and gains acceptance. > For enterprise usage I doubt that end-to-end encryption is of much value > as lost keys create too much hassles. Most business systems are likely > to rather use HTTPS which is easier to handle than S/MIME encryption. HTTPS and S/MIME have different uses and benefits. If you sign a contract over HTTPS there is no persistent proof, whereas there is with S/MIME. The problem of lost encryption keys for enterprises is already solved with key escrow. All the necessary mechanisms are already in place today. Most businesses want to be able to access their employees' communications anyway, so there is another reason that they use key escrow for encryption keys. Signing keys are of course a different matter and should not be escrowed. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNjAwMzcxMlowIwYJKoZIhvcNAQkEMRYE FKQnHNTPAbVFtiwzKnfBJFqHMrLKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYBAqMdOofmqBct5J2Ss vE3pv50s0kFb1e05CRrmDgvCh7UYBDF7U3D/nSqa0JHfl58c73K084bPSqg23X0A/RRiqFhV H8rUMwygLu4bxvky82cHLmaDAy8UW0lMWyCyRMVHARmcU0RqdIr7l6tawhm4k2XaqxVV/qmi 1WlpqBfqAQAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Fri Aug 15 23:36:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21789 for ; Fri, 15 Aug 2003 23:36:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G39Pqt036027 for ; Fri, 15 Aug 2003 20:09:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G39PwP036026 for ietf-smime-bks; Fri, 15 Aug 2003 20:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G39Oqt036021 for ; Fri, 15 Aug 2003 20:09:24 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7G39C303466 for ; Fri, 15 Aug 2003 20:09:12 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJOZEZ02.R2C; Fri, 15 Aug 2003 20:08:59 -0700 Date: Fri, 15 Aug 2003 20:10:16 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: Re (subtopic): certificate issuance and trust To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3DA098.1040008@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Steve, Steve Hole wrote on 08/15/2003, 12:48: > > I broke the reply into to parts because they really are quite separate > issues. This topic deals primarily with the issuance of certificates > and > trust management in deployed S/MIME clients. I debated taking it > offline, but I think that it is useful discussion from a usage point of > view. It has little technical merit on a primarily technical forum, but > it has overall import for S/MIME -- I hope :-) I would also have taken most of the discussion offline already due to the direction it is going if there hadn't been many people expressing their interest in the topics. > I see that we need to talk a bit about the usage models that are evolving > on the Internet. There are at least two with variations: > > 1. Interpersonal secure mail. This is Mom exchanging secure email with > Aunt Jane on the other side of the country. > > 2. Organizational communications. This is the business to consumer or > organization to partipant communications (ie. my bank wanting to send me > statements and me wanting to complain to my bank). > > > Because I am so focused on usage model 2 these days I tend to forget > about > usage model 1. My apologies. Conversely, I suspect that very little > thought has gone into usage model 2 as it is an entirely new thing for > business to be doing on the Internet. > No need to apologize. Likewise I focused mostly on the first usage due to the fact that I work for an ISP. However I believe the two uses very often intersect. Consumers want to make secure electronic communications with businesses (I know I do), which they can't do by e-mail today. S/MIME certification allows both. > So what? Your assertions and the priority you assign them are spot on > for usage model 1. I would still add both cost and complexity of > certification to this model. For Mom to sign up to get a cert is > actually pretty daunting from a user interface point of view. We and > our > customers have done lots of user tests and it is a problem. The complexity was my third one on the list - how S/MIME is difficult to use . That included the enrollment process. I completely agree it is very daunting. Actually I have gotten my mother running on S/MIME so I know what you are talking about when you mention complexity of enrollment. I got her running with Thawte and it was quite long to enroll. But there is no reason that it has to be that way - it entirely depends on the CA. > My assertion that cost is a big deal is very applicable to usage model 2. > In this case organizations want to certify their consumers for secure > document receipt and (possibly) reply. Outbound is fairly easy -- just > issue an encryption only cert to the user on enrollment. No trust > issues > and it is reasonably easy to get to the user's desktop. The problem > comes when you want bidirectional communication and are therefore issuing > signing certs. The cost of doing this for millions of customers is so > high using the existing certification model (because of root trust > requirements) that to use S/MIME becomes impractical or forces > alternative > solutions. I'm not sure I understand why the trust is less of a problem for encryption certs than signing certs. If you want to receive encrypted communications, you need to create an encryption key and cert. And you need to make the other party aware of it. Typically in S/MIME today this transfer of the public encryption cert is done by ... signing an e-mail. Which requires you to have a signing cert... Otherwise the user could also publish the encryption cert to LDAP. Still there would need to be some authentication at that time. > There are a series of companies that provide "e-mail encryption" using > proprietary formats and Javascript symetric decryptors that completely > bypass S/MIME altogether. And people buy it! BIG organizations buy > it. > It's depressing. And when talking about S/MIME it has to be concern to > this group and people who implement S/MIME clients. What are the advantages of these pseudo-security products ? > Correct. This means that interpersonal secure email usage is > impractical because there is no way to obtain necessary security > information for an arbitrary recipient. This is the original stated > problem and we all agree that it is a major, if not the major barrier. > > I think that we have some good concensus building on that and maybe there > are some actions that we can now take to try to resolve the issue. While we don't have any consensus yet on the technical direction, I would certainly be willing to participate in writing a draft that would make recommendations on additional ways to distribute S/MIME certificates. Of course the actual deployment of a global directory is a problem, but perhaps by having this draft written by people involved in companies potentially interested in using/running it we will end up writing a deployable proposal. > > 3) S/MIME is too complex to use > > S/MIME isn't so complicated (at least our user testing doesn't indicate > that). We get very few usage calls back to customer support. > > Certification is certainly complicated. Even the easiest of the > commercial (Verisign) CA's are quite daunting to the average user. > This is > an implementation issue that needs some work. This accounts for better > than 95% of our TOTAL service calls. Ouch! Yes, that's what I meant. Enrollment is part of the usage of S/MIME. I had to sit with my mother last year to get her to sign up, and I talked to her at length at international rates for the recent renewal. > The only way to solve it (I think) is to have organizations initiate > certificate issuance. That is, ISP's need to offer to do this as > part of > their enrollment. Agreed. > So it is a question of how do we initiate certification? More > importantly how do we get ISP's (or a proxy third party) to engage users > in the certification process. I wish I had the answer to that one. > > The first two issues are related. As more people become aware of > > certification and certified, the value of being certified will > increase. > > I believe the cost of the certification will be much less of an issue > > once people realize they are paying for a something useful. > > No it won't :-) Will your Mom pay to be certified? I know for a fact > mine won't because I tried to get her to get a Verisign cert and when she > found out it was $20, that terminated that conversation quickly :-) Yes, I know the feeling, I got the same reaction from my family members, which is why I got many of them to enroll with the freemail Thawte CA instead. However the service doesn't have to be directly paid for, or all at once. It can be bundled by the ISP with her account. Even if it wasn't bundled with every account, the one-time $20 might be only a $1.66 option/month extra, which is the same price, but suddenly doesn't look so bad. Especially if that $1.66 buys you more than just the ability to communicate with family members, but also with businesses (ie. banks). > First of all, this problem really is a usage model 2 issue. An > organization wants to certify a very large number of users. It really > doesn't apply to usage model 1, for which most of the existing S/MIME > clients are targeted. Still, a corporate organization can run its own CA which doesn't have to be a root CA. > All of the above is correct. I'm saying two things: > > 1. It would be very nice if there is some way that the trust domain > could > be removed from client configuration to a centralized service. This is > simply good engineering and allows for dynamic control over what is > trusted and what is not. I think it cannot ever entirely be removed from the client, because you need to start with some trust, but it could be aggregated. Before this can be dynamically controlled however, the very notion of what a trust domain is needs to be defined and standardized. Then we can define means to transfer it, through existing protocols hopefully. > 2. Modifying desktop settings to support security policy and certificate > issuance is a non-starter for usage model 2. It's the old adage -- > people want security but they don't want to have to do anything to get > it. > > I'll give you an example that might help. If My Huge Bank wanted to > issue certificates to their users to establish a secure email > community of > trust, then they have two choices: acquire certificates from one of the > CA's that is already in the "trusted root" category or try to issue > self-signed certificates and become a trusted root. Cost is a big > barrier > in the first option. Deployment complexity (and some cost) is a barrier > for option 2. Because a new root certificate has to be downloaded to > every desktop you've got a deployment latency problem. Because it costs > (in some non-insubstantial set of S/MIME implementations) to get a > registered root certificate, the costs of this are not insubstantial > either. > > If the cost that an organization like My Huge Bank will bear to roll > out a > new service is $1M - $500K you can see that the cost of deployment for an > S/MIME solution is severly compromised by the costs of certification. > Companies and solutions like Tumbleweed exist that provide > alternatives to > S/MIME simply because of this fact. My huge bank doesn't have to run a root, my huge bank can run a CA and get it signed by one of the root CAs. Then it doesn't need to deploy a root to every desktop. If it insists on running a root, there is going to be at least one config change to make it happen. Right now I think it is as simple as clicking on a URL and accepting a dialog. I don't know how much simpler one can make it. Yes, a means to distribute the trust domain (see above) would help, but one would still need to configure the software to use the distribution channel - whatever it would be (HTTP, LDAP ...). I don't see how this would be simpler than the click and confirmation of the dialog. The only advantage is that you might only need to enable that trust domain service once, and several organizations could publish their root to it. You could imagine for example a consortium of financial institutions ... Of course the consortium could just have one root and bear its cost, and issue one CA for each institution. FYI, I believe Microsoft might already update roots when you do a windows update, but of course that's a proprietary solution, and you still have the upfront cost of getting certified when you create your root. > > The price figure you cite is absurdly low. Do you really, seriously > > think $250,000 to enable secure services matters much to a company with > > 25 million customers ? Certainly it wouldn't matter much to a bank, > > especially since it would probably reduce certain mailing costs. I'd > > guess that even one bulk USPS communication is going to cost more > than 1 > > cent per recipient. I only know one ISP with 25 million customers or > > more, and I happen to work for it, but I'm not at liberty to comment > > further on the costs. > > First of all, $0.01 per cert for 25M customers is $2.5M annually. No, it is $250,000 . > You need to go have a look at who I work for :-) The name doesn't ring a bell, but I will check. > The example that I give above is by far the rule. The costs that even a > large bank with 25M consumers will bear for *any* Internet application is > quite low at this point. First class stamps are up to 37 cents last time I checked. I don't know what the bulk rate is, but using your (unrealistic) proposed cost of 1 cert per cert, the investment would pay for itself at the first paper communication saved even if only 3 percent of the bank customers ever used their cert. Of course, it's up to the banks to decide what's beneficial to them, but if something is going to save them so much money, the bank has responsibility to their shareholders to look into it. I don't have any more to add on this topic. > Most of that has to do with the series of > disappointing Internet applications and middleware that were invested in > over the years has seriously damaged their trust in real return on > investment in Internet applications. Someone has to do it right first. Competitors will follow. Same thing happened with online account access - not everybody offered SSL. Lots of banks erred in offering proprietary software solutions for a while. It sorted itself out. We are just at an earlier stage in the process. > However, it is important to note that the cost of running a your own CA > today is largely a matter of the licensing costs of running the CA > software. There are operational costs, but those costs can and > should be > part of the cost of operating the application the uses S/MIME. We do > NOT > charge for certificate issuance in our product. We charge for documents > delivered. There is a direct and easy comparison for any usage model 2 > document issuer to compare the cost of paper mail to secure email. > If we > had the ability to "Register" a self certifying organization root > certificate in one place (not one for every desktop client) that would be > a huge step forward. Even if that service existed, it would still need some kind of client configuration to point to that one place. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK+jCC A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu 0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC +6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3 MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG 0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S 2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggQFMIID bqADAgECAgJvwjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj YXRlIEF1dGhvcml0eTAeFw0wMzA3MjQwMTMzMzNaFw0wNDAxMjAwMTMzMzNaMIGAMQswCQYD VQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRcwFQYKCZImiZPyLGQBARMH anBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20xFjAUBgNVBAMT DUp1bGllbiBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJRH1n1wZFA1kQtF pA/5Uj02qgE0xUEdc/yAIGmvkuw/+5AF/Jx5MBGQtnd7rAkAwMWdkPFtKKS5+ZGYZ56JPqiu KjHMV5SLCPjbIqXWPTynLZ2AFYKprCvkkTiNr/M7r2GxO0Rt3qzK7XEqh3rngY99waETvr7F UEQasj70QCBFAgMBAAGjggF3MIIBczAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENl cnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBlwYDVR0RBIGPMIGMgRRqcGllcnJl QG5ldHNjYXBlLmNvbYEWanVsaWVuX3BpZXJyZUBtY29tLmNvbYEQanBpZXJyZUBtY29tLmNv bYEaanVsaWVuX3BpZXJyZUBuZXRzY2FwZS5jb22BFGpwaWVycmUwMjY0QG1jb20uY29tgRhq cGllcnJlMDI2NEBuZXRzY2FwZS5jb20wHwYDVR0jBBgwFoAUKduyLYN+f4sju8LMZrk56Cnz AoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vY2VydGlmaWNhdGVzLm5l dHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBAUAA4GBALNoiuK23ARWkrVPz3eQhHIrToXU xC3CfxLnAkFrwMPiNHnwrzPn6Zeflnft/jquv8qyfdgCjnDcznXpfYCUa6ZtBG6uFyzwZy8Y QOICI6vJy7gx1HqewsPeaFNk2fFHdXucqLnYQOTpe1XytWfQ8q4VcxmfDD0/d/ag+top1GuK MYIDVDCCA1ACAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN TW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBB T0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkCAm/CMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDgxNjAzMTAxN1owIwYJKoZIhvcNAQkEMRYEFDChyvheGnx1mlDQAtmt vK+d9VnGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCJu6AtUATf6J2ayPr3XgYTg+cpicti9rvppNAn S/rcjQMbdNGDOuiIVF5Ey3BBqUXUuoVtWM6miDYFcmth6pAxiE9vKR+KQYxxzsya+k3pRaO8 a8+fUvtHidYltnMRDGQXLqZMGvVNR5EDRNCzCkHCAXJlrwjQ6OcNFVQ4E6gdQwAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Sun Aug 17 11:09:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15284 for ; Sun, 17 Aug 2003 11:09:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HELYqt014250 for ; Sun, 17 Aug 2003 07:21:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7HELYWw014249 for ietf-smime-bks; Sun, 17 Aug 2003 07:21:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hyatt_calgary ([66.46.110.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HELWqt014242 for ; Sun, 17 Aug 2003 07:21:32 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS ([192.168.1.175]) by hyatt_calgary (8.11.6/8.8.7) with ESMTP id h7HEHsT24042; Sun, 17 Aug 2003 08:17:54 -0600 Reply-To: From: "Jim Schaad" To: "'Deepak'" , Subject: RE: Query regarding BER/DER encoding of CMS data Date: Sun, 17 Aug 2003 08:21:54 -0600 Message-ID: <000001c364ca$ee04f6e0$af01a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030814162856.26664.qmail@web40511.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit DER is a legal encoding when BER is called for. BER is not required to be indefinite length encoding. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Deepak > Sent: Thursday, August 14, 2003 9:29 AM > To: ietf-smime@imc.org > Subject: Query regarding BER/DER encoding of CMS data > > > > Hi, > > When i go through the CMS RFC's its saying, all the > contenttype(SignedData,EnvelopedData) should be BER > encoded. But when i go thorugh the some of the ietf > examples, especially in EnvelopedData->RecipientInfo > is encoded by DER.(its starting with 31 82 ..). It > should be like sequence 30 80 .. ? > > Could you please explain why was it happend ? > > Thanks, > Deepak > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > From owner-ietf-smime@mail.imc.org Mon Aug 18 08:14:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17317 for ; Mon, 18 Aug 2003 08:14:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IBZHqt001946 for ; Mon, 18 Aug 2003 04:35:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IBZHen001945 for ietf-smime-bks; Mon, 18 Aug 2003 04:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IBZ3qt001851 for ; Mon, 18 Aug 2003 04:35:13 -0700 (PDT) (envelope-from vf@main.giknpc.com.ua) Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h7IBYnE25205 for ietf-smime@imc.org; Mon, 18 Aug 2003 14:34:49 +0300 Date: Mon, 18 Aug 2003 14:34:49 +0300 From: Vadim Fedukovich To: ietf-smime@imc.org Subject: Re: Re (subtopic): LDAP certificate distribution Message-ID: <20030818113449.GD17168@unity.net> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Aug 15, 2003 at 10:30:11AM -0700, Steve Hole wrote: > > On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre > wrote: > > > Why ? > > Because you have to run a root. That is, the hierarchy has to have a top > level interconnect. really? I believe RSA works fine both for subject name matching issuer name and for any other subject name. One could put trust directly in some CA certificate (say, a corporation-wide one) and it could be root, self-signed or otherwise. Fine-tuned client software is the point > This quickly becomes an issue of governance. > National goverments get involved the way they got involved in DNS. The > difference is that the governments got involved *before* the service was > running, not after the way they did with DNS. One can easily sign with DSS/DSA using widely distributed quorum system, maybe Shamir secret-sharing one. No single one would own the signing key and it could be generated in shares right from the start regards, Vadim From owner-ietf-smime@mail.imc.org Mon Aug 18 10:29:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20845 for ; Mon, 18 Aug 2003 10:29:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IDuNqt011471 for ; Mon, 18 Aug 2003 06:56:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IDuNmh011470 for ietf-smime-bks; Mon, 18 Aug 2003 06:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7IDuMqt011465 for ; Mon, 18 Aug 2003 06:56:22 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 7079 invoked by uid 0); 18 Aug 2003 13:56:20 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.214.239) by woodstock.binhost.com with SMTP; 18 Aug 2003 13:56:20 -0000 Message-Id: <5.2.0.9.2.20030818095449.02d59810@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 18 Aug 2003 09:56:02 -0400 To: "Bonatti, Chris" , From: Russ Housley Subject: RE: Update of CMS-X.400 Drafts Cc: In-Reply-To: <000301c36359$26561240$0300a8c0@ieca.com> References: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris and Francois: I would like to proceed with the specification "as is." If we find that there is a lot of implementation, and those folks need compression, then we can revisit this issue. Russ At 02:15 PM 8/15/2003 -0400, Bonatti, Chris wrote: >Francois, > > This has not been discussed before on this list, but to my >knowledge has there has not been a strong call for this. My view >is that this is feasible, but presently outside the scope of the >draft. Since this doesn't constitute a MUST in the 2633bis, I'm >not sure this is significant. > > I do not favor slowing down the spec for this. > > Do others have opinions on this? > >Chris > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of >Francois.Rousseau@CSE-CST.GC.CA >Sent: Monday, August 11, 2003 13:16 >To: BonattiC@ieca.com >Cc: ietf-smime@imc.org >Subject: RE: Update of CMS-X.400 Drafts > > > >Hi Chris, > >I am very sorry to not have noticed this before, but I did not >see any mention of optionally supporting Compression (i.e. >RFC3274) under WRAP like under MSGbis. Isn't compression >something that could also be useful for X.400 content? Was this >intentional? > >Cheers, > >Francois > > >-----Original Message----- >From: Bonatti, Chris [mailto:BonattiC@ieca.com] >Sent: Saturday, August 09, 2003 11:32 AM >To: ietf-smime@imc.org >Subject: Update of CMS-X.400 Drafts > > > >With Paul and Anders help, I have addressed some outstanding IESG >(or >AD) comments that I did not hear of until after the Vienna >meeting. The comments and their resolution are included below. >I also updated WRAP so that it includes a specification of AES >key sizes in alignment with the -05 issue of MSGbis. This latter >issue was mentioned in my status report in Vienna. > >So you should look for an -08 issue of WRAP and an -09 issue of >TRANSPORT in the Internet-Drafts directory in short order (posted >Friday AM). > >Cheers! >Chris > > >______WRAP COMMENTS________ > >3.2----->"whatever gateway system that is bridging" seems >grammatically wrong. > >Replaced with "any gateway system that might bridge the gap". > > >3.2.1---->"since it is out" should be "since it is outside"? > >Done. > > >3.3----->"If other binary transport" should "If another binary"? > >Replaced with "If other transport (e.g., X.400) that is optimized >for binary content". I think that's clearer. > > >3.3.1------> "it is out" again, outside? > >Done. > > >3.4.1---> "7-bit transport, is optional" spurious comma. > >Done. > > >3.4.1--->"certs-only, which is only for signed)" seems to be >missing a noun. > >Replaced with "certs-only, which applies only to signed-only >messages)". > > > >______TRANSPORT COMMENTS________ > >2.6.1--->"because those type do not" has subject/verb agreeement >problem. > >Changed "type" to "types". > > >2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". > >Done. From owner-ietf-smime@mail.imc.org Mon Aug 18 12:38:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25615 for ; Mon, 18 Aug 2003 12:38:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IGBBqt016049 for ; Mon, 18 Aug 2003 09:11:11 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IGBBaB016048 for ietf-smime-bks; Mon, 18 Aug 2003 09:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IGBAqt016043 for ; Mon, 18 Aug 2003 09:11:10 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7IGEwV11855; Mon, 18 Aug 2003 10:14:58 -0600 From: Steve Hole Date: Mon, 18 Aug 2003 10:14:58 -0700 To: Julien Pierre Subject: Re: Re (subtopic): certificate issuance and trust Cc: ietf-smime@imc.org In-Reply-To: <3F3DA098.1040008@netscape.com> References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7IGBAqt016044 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Fri, 15 Aug 2003 20:10:16 -0700 Julien Pierre wrote: > > I'm not sure I understand why the trust is less of a problem for > encryption certs than signing certs. > If you want to receive encrypted communications, you need to create an > encryption key and cert. And you need to make the other party aware of > it. Typically in S/MIME today this transfer of the public encryption > cert is done by ... signing an e-mail. Which requires you to have a > signing cert... > Otherwise the user could also publish the encryption cert to LDAP. > Still there would need to be some authentication at that time. If you either (1) engage the desktop keypair generation CSR issuance or (2) generate a keypair and deliver it via PKcS12 at enrollment time, then you can issue data encipherment only key-usage keys that are only used for encryption. The keys can be self signed and really are only ever used to decrypt data sent from the document issuer and cannot be used for signing. By doing this, you avoid all root signing issues and all of the extremely nasty UI that prevents people from enrolling and generates calls to customer service. The certificates need to be validated before we use them to encrypt, but that is all local security policy and we do a lot of stuff beyond normal certificate validation to make sure our certs are valid. Once encrypted, the user just needs to have the private key to decrypt and the cert is really only used to keep the cert store happy on the desktop. I talk about cost a lot. The average cost of a call to support is $18, so it needs to be avoided at all costs (pun intended). The interfaces provided by IE and/or Netscape provide much simpler, not so "in-your-face" UI for cert management when there is no trust involved. > > There are a series of companies that provide "e-mail encryption" using > > proprietary formats and Javascript symetric decryptors that completely > > bypass S/MIME altogether. And people buy it! BIG organizations buy > > it. > > It's depressing. And when talking about S/MIME it has to be concern to > > this group and people who implement S/MIME clients. > > What are the advantages of these pseudo-security products ? They avoid certification. They address the 36% of the Internet that doesn't use or have access to S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail. If your in a model 2 scenario you MUST do something useful with those and the solution is psuedo security. Interestingly, it seems good enough for most people, especially if it avoids calls to service reps. This sucks! > > No it won't :-) Will your Mom pay to be certified? I know for a fact > > mine won't because I tried to get her to get a Verisign cert and when she > > found out it was $20, that terminated that conversation quickly :-) > > Yes, I know the feeling, I got the same reaction from my family members, > which is why I got many of them to enroll with the freemail Thawte CA > instead. > > However the service doesn't have to be directly paid for, or all at > once. It can be bundled by the ISP with her account. Even if it wasn't > bundled with every account, the one-time $20 might be only a $1.66 > option/month extra, which is the same price, but suddenly doesn't look > so bad. Especially if that $1.66 buys you more than just the ability to > communicate with family members, but also with businesses (ie. banks). Well, I'm not an expert on ISP business models. Everything I've ever been told suggests that there is almost no margin in the business model and additional costs are hard to bear or pass through. For this you have to convince the masses that security is what they want, and I can tell you from experience that that is a very difficult thing to do. And my experience comes from a business usage perspective where the content definitely is sensitive in nature -- much more so that most email between Mom and Aunt Jane. > > First of all, this problem really is a usage model 2 issue. An > > organization wants to certify a very large number of users. It really > > doesn't apply to usage model 1, for which most of the existing S/MIME > > clients are targeted. > > Still, a corporate organization can run its own CA which doesn't have to > be a root CA. If you can acquire a delegated cert. We haven't check recently, but 6 months ago we couldn't buy one. Thawte used to sell them for $100K, but since have discontinued because there was no business there. We should go check again. It was the simple and obvious thing to do, but because there was nobody doing it, the service wasn't offerred by the CA's. > I think it cannot ever entirely be removed from the client, because you > need to start with some trust, but it could be aggregated. > Before this can be dynamically controlled however, the very notion of > what a trust domain is needs to be defined and standardized. Then we can > define means to transfer it, through existing protocols hopefully. The client would have to have some secure means of "synchronizing" it's cache to a centralized service. You get this with Microsoft services by downloading a cert package from Windows Update. The problem is that it only works for Windows products (at least that way) and we need something that is vendor independent. The approach seems OK to me as long as it is "automatic". > > My huge bank doesn't have to run a root, my huge bank can run a CA and > get it signed by one of the root CAs. Then it doesn't need to deploy a > root to every desktop. Seems logical. In practice we were unable to make it happen. We needed to go through special negotiation because it wasn't a standard service offering and there was a serious price issue for the signing cert. > If it insists on running a root, there is going to be at least one > config change to make it happen. Right now I think it is as simple as > clicking on a URL and accepting a dialog. I don't know how much simpler > one can make it. In Netscape, yes. In others no. You actually get a Hex dump of the cert with a message that says something like "Do you trust this certificate with policy blah blah". About 45% of the test group stopped at this point. Most of our customers simply said "too complex, too scary". Yes, I know it should be scary etc. The problem is that the average user just doesn't get it, doesn't want to get it. It's a barrier to uptake. For the model 2 usage scenario uptake is everything because the economic benefit is based on paper suppression and resulting cost reductions. That's all. > > > The price figure you cite is absurdly low. Do you really, seriously > > > think $250,000 to enable secure services matters much to a company with > > > 25 million customers ? Certainly it wouldn't matter much to a bank, > > > especially since it would probably reduce certain mailing costs. I'd > > > guess that even one bulk USPS communication is going to cost more > > than 1 > > > cent per recipient. I only know one ISP with 25 million customers or > > > more, and I happen to work for it, but I'm not at liberty to comment > > > further on the costs. > > > > First of all, $0.01 per cert for 25M customers is $2.5M annually. > > No, it is $250,000 . Woops ... dislexic on the cost per cert. The cheapest price we got was $0.10 (man, I *looked* that at least five times too - senility). Anyway, the numbers weren't randomly chosen. They were the numbers that we used in an actual RFP response in which the customer eventually took the one-way signing + encryption and decided against two-way with bidirectional signing. The actual cost was $2.5M per year. Security costs. My example was intended to show that, in this instance at least, it costs too much even for relatively rich organizations. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-smime@mail.imc.org Mon Aug 18 20:24:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10294 for ; Mon, 18 Aug 2003 20:24:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INmAqt032315 for ; Mon, 18 Aug 2003 16:48:10 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7INmAMG032314 for ietf-smime-bks; Mon, 18 Aug 2003 16:48:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INm9qt032305 for ; Mon, 18 Aug 2003 16:48:09 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7INlt309319 for ; Mon, 18 Aug 2003 16:47:55 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJUA3I01.G0K; Mon, 18 Aug 2003 16:47:42 -0700 Date: Mon, 18 Aug 2003 16:49:01 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: Re (subtopic): certificate issuance and trust To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F4165ED.7@netscape.com> References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Steve Steve Hole wrote on 08/18/2003, 10:14: > I talk about cost a lot. The average cost of a call to support is $18, > so it needs to be avoided at all costs (pun intended). > > The interfaces provided by IE and/or Netscape provide much simpler, > not so > "in-your-face" UI for cert management when there is no trust involved. It sounds to me like your grief is not with so much with the current trust model and PKI or S/MIME specifications, but with certain vendor implementations. I'm afraid that's something you have to work with these vendors. > > What are the advantages of these pseudo-security products ? > > They avoid certification. > > They address the 36% of the Internet that doesn't use or have access to > S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail. If your in a > model 2 scenario you MUST do something useful with those and the solution > is psuedo security. Interestingly, it seems good enough for most > people, > especially if it avoids calls to service reps. AOL will be taken care of, eventually. The newest client software (AOL Communicator) already supports S/MIME. There are still issues with the mail servers unfortunately so it doesn't work today. Encryption works through it, but signing doesn't (sigh). Webmail in general is a problem and cannot be truly taken care of, unless the user is willing to trust his ISP with his private key - e.g.. by uploading a PKCS12 file ... Another solution might be some sort of Java applet that would decrypt the message. But it would have to know about each webmail provider and the layout, so it would be icky. Perhaps some standard for webmail is the only solution - e.g.. a MIME type transmitted over HTTP that would allow the browser to invoke the proper S/MIME client. > This sucks! In general the users don't have only webmail access though, they typically have a mailbox from their access ISP which can work with the S/MIME clients that already exist today. > Well, I'm not an expert on ISP business models. Everything I've ever > been told suggests that there is almost no margin in the business model > and additional costs are hard to bear or pass through. For this you > have > to convince the masses that security is what they want, and I can tell > you > from experience that that is a very difficult thing to do. And my > experience comes from a business usage perspective where the content > definitely is sensitive in nature -- much more so that most email between > Mom and Aunt Jane. I'm not an expert on this business model either either, but look at the latest AOL ads - "safe broadband", etc. This is certainly an area in which consumers are being educated right now, and security is something that consumers are getting interested in. I personally think there is hope for mass S/MIME deployment in the not so-distant future. > If you can acquire a delegated cert. We haven't check recently, but 6 > months ago we couldn't buy one. Thawte used to sell them for $100K, > but > since have discontinued because there was no business there. We should > go check again. It was the simple and obvious thing to do, but because > there was nobody doing it, the service wasn't offerred by the CA's. We have had our own chained CA chained with a known public root at Netscape for years. We did change issuer a couple times. Our current one is GTE. I think previously we used Verisign. I wasn't the one dealing with it, and I don't know the cost, but I can tell you that the service exists. Since there are about 100 known roots now, you could go to any of them and ask about the service. I think I read year's that RSA Security was offering that service as well, and it cost less than $100k. > The client would have to have some secure means of "synchronizing" it's > cache to a centralized service. You get this with Microsoft services by > downloading a cert package from Windows Update. The problem is that it > only works for Windows products (at least that way) and we need something > that is vendor independent. The approach seems OK to me as long as > it is > "automatic". Yes. We need a standard way of distributing root. We also need a way of distributing trust, ie. a subscriber model. It sounds to me like this proposal belongs on the PKIX list, so maybe we should move it there. I don't see the root distribution problem as a major roadblock to deployment today since the services for getting chained CAs exists. > Seems logical. In practice we were unable to make it happen. We > needed > to go through special negotiation because it wasn't a standard service > offering and there was a serious price issue for the signing cert. Yes, it may not be a standard service, but if you need it there is far more than one issuer to go to these days. > In Netscape, yes. In others no. You actually get a Hex dump of the > cert with a message that says something like "Do you trust this > certificate with policy blah blah". About 45% of the test group stopped > at this point. Most of our customers simply said "too complex, too > scary". As I recall IE brings up something similar to Netscape when the root is untrusted. What is the "other" software that is so inflexible ? It seems to me that you need to take it up with the software vendor. > Yes, I know it should be scary etc. The problem is that the average > user > just doesn't get it, doesn't want to get it. It's a barrier to uptake. > For the model 2 usage scenario uptake is everything because the economic > benefit is based on paper suppression and resulting cost reductions. > > That's all. You can't require everybody to move to the S/MIME model at once. Even if a small percentage starts using it, the cost of printing and mailing is high. If you eliminate things like printed monthly statements, it shouldn't take a bank more than a small percentage of users to move to S/MIME to recoup its costs or actually profit. > > > First of all, $0.01 per cert for 25M customers is $2.5M annually. > > > > No, it is $250,000 . > > Woops ... dislexic on the cost per cert. The cheapest price we got was > $0.10 (man, I *looked* that at least five times too - senility). That's still very low, but it's also likely less than the cost of printing and sending a single traditional communication. > Anyway, > the numbers weren't randomly chosen. They were the numbers that we used > in an actual RFP response in which the customer eventually took the > one-way signing + encryption and decided against two-way with > bidirectional signing. The actual cost was $2.5M per year. > > Security costs. My example was intended to show that, in this > instance at > least, it costs too much even for relatively rich organizations. I also know there are other financial organizations that spend much more on better security, and get more returns out of it. Look at credit card issuers starting to use smartcards. They have to bear the cost of the hardware in addition to the certs. They have millions of customers too. But some are doing it still (Amex). In Europe banks have been using smart chips on bank cards for decades. And believe it or not, they have been charging each customer to get those bank cards, too. Every bank over there is doing it though, because it reduces the transaction costs. We are not talking 10 cents per chip. With current generation smartcards they could afford to throw in certs for email as an extra and also eliminate the paper statements. Many of the issuers already have their own public roots to do it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK+jCC A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu 0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC +6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3 MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG 0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S 2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggQFMIID bqADAgECAgJvwjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj YXRlIEF1dGhvcml0eTAeFw0wMzA3MjQwMTMzMzNaFw0wNDAxMjAwMTMzMzNaMIGAMQswCQYD VQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRcwFQYKCZImiZPyLGQBARMH anBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20xFjAUBgNVBAMT DUp1bGllbiBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJRH1n1wZFA1kQtF pA/5Uj02qgE0xUEdc/yAIGmvkuw/+5AF/Jx5MBGQtnd7rAkAwMWdkPFtKKS5+ZGYZ56JPqiu KjHMV5SLCPjbIqXWPTynLZ2AFYKprCvkkTiNr/M7r2GxO0Rt3qzK7XEqh3rngY99waETvr7F UEQasj70QCBFAgMBAAGjggF3MIIBczAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENl cnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBlwYDVR0RBIGPMIGMgRRqcGllcnJl QG5ldHNjYXBlLmNvbYEWanVsaWVuX3BpZXJyZUBtY29tLmNvbYEQanBpZXJyZUBtY29tLmNv bYEaanVsaWVuX3BpZXJyZUBuZXRzY2FwZS5jb22BFGpwaWVycmUwMjY0QG1jb20uY29tgRhq cGllcnJlMDI2NEBuZXRzY2FwZS5jb20wHwYDVR0jBBgwFoAUKduyLYN+f4sju8LMZrk56Cnz AoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vY2VydGlmaWNhdGVzLm5l dHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBAUAA4GBALNoiuK23ARWkrVPz3eQhHIrToXU xC3CfxLnAkFrwMPiNHnwrzPn6Zeflnft/jquv8qyfdgCjnDcznXpfYCUa6ZtBG6uFyzwZy8Y QOICI6vJy7gx1HqewsPeaFNk2fFHdXucqLnYQOTpe1XytWfQ8q4VcxmfDD0/d/ag+top1GuK MYIDVDCCA1ACAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN TW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBB T0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkCAm/CMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDgxODIzNDkwM1owIwYJKoZIhvcNAQkEMRYEFErSVhtWs4vnA82IY7im 6/6nCiwQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCRRoppGoWCPNpRdTJv4lNGEmqEQPOMLB9DzmPR 7evOq4/0AT1AXOV3VPEwIGR3oOnpPtjoOe4FPbXQjRLwC8TaglZdwD0gQHw2wa10n1azDS0U hHgjt/VwD8qCVHDP2N5QNcBvRkrqKJNF47geBowK41SnzFa0i30mDm1epy8dZQAAAAAAAA== --------------ms010704000904080802040505-- From owner-ietf-smime@mail.imc.org Tue Aug 19 03:24:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00234 for ; Tue, 19 Aug 2003 03:24:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J6qGqt053213 for ; Mon, 18 Aug 2003 23:52:16 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7J6qGnD053208 for ietf-smime-bks; Mon, 18 Aug 2003 23:52:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J6qAqt053201 for ; Mon, 18 Aug 2003 23:52:11 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t11o913p25.telia.com [213.64.28.25]) by smtp4.hy.skanova.net (8.12.9/8.12.9) with SMTP id h7J6pvqD024021; Tue, 19 Aug 2003 08:51:58 +0200 (CEST) Message-ID: <009401c3661e$41d0c980$0500a8c0@arport> From: "Anders Rundgren" To: "Steve Hole" , "Julien Pierre" Cc: References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Subject: Re (subtopic): Four corner model Date: Tue, 19 Aug 2003 08:50:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Some more on this topic. Some TTP CAs (read: banks) have modeled their services after their payment services. e-governments have signed up such CAs to supply citizen certificates. Although I am fully convinced that banks have an important role to fill in a TTP-based market (as the on-line banking security requirements and on-line e-government security requirements, are likely to be very similar), I strongly believe that the four-corner model where each receiver (a,k.a. relying party) must have - a business contract with each trust network - a unique relying party ID for each trust network - a proprietary software installation for each trust network and pay for each revocation check, is something that governments should reject. For more details see: http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf Another problem I see with this model is that it seems rather impossible to support secure e-mail between individuals as e-mail packages cannot easily match the requirements above. Anders Rundgren Consultant PKI and secure e-business From x70bmu@yahoo.ca Tue Aug 19 18:54:00 2003 Received: from 132.151.1.176 ([80.95.121.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14392 for ; Tue, 19 Aug 2003 18:53:59 -0400 (EDT) Received: from (HELO 9bdv40u) [28.221.20.167] by 132.151.1.176 for ; Tue, 19 Aug 2003 12:45:21 +0100 Message-ID: <3g-7-sl-$1-6x-14jgf6pu7-$$-z$73@9vw2t> From: "Cody Salter" Reply-To: "Cody Salter" To: smime-archive@ietf.org Subject: Smime-archive,freepayper view, freeadultmovies uxpkcgsjk ne Date: Tue, 19 Aug 2003 12:45:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BC3_BF_6DDFD_87FA" --BC3_BF_6DDFD_87FA Content-Type: text/html; Content-Transfer-Encoding: base64 DQo8Zm9udCBzaXplPSIyIj4NCg0KZHJlbmNoJm5ic3A7IHpucSB1IHh0aGpzIGxxIGtoa3F4 aA0KIGNhdyB1Jm5ic3A7Jm5ic3A7IDxmb250IFNJWkU9IjEiIENPTE9SPSIjMDAwMDAwIj5z eXN0ZW1pemF0aW9uPC9mb250Pg0KPHAgYWxpZ249ImNlbnRlciI+Jm5ic3A7VGhlIHVsdGlt YXRlIGRpZ2l0YWwgY2FibGVmaWx0ZXI8L3A+DQo8cCBhbGlnbj0iY2VudGVyIj5UaGUgZmls dGVyIHdpbGwgYWxsb3cgeW91IHRvIHJlY2VpdmUgYWxsIHRoZSBjaGFubmVscyB0aGF0IHlv dQ0Kb3JkZXIgd2l0aCB5b3VyIHJlbW92ZSBjb250cm9sITwvcD4NCjxwIGFsaWduPSJjZW50 ZXIiPnBheXBlcnZpZXdzLCBhZHVsdG1vdmllcywgc3BvcnQgZXZlbnRzICZhbXA7IHNwZWNp YWwgZXZlbnRzITxhIGhyZWY9Imh0dHA6Ly93d3cubWVkczI0Ny5iaXovY2FibGUvIj4NCnNl ZSBub3chPC9hPjwvcD4NCjxwPjwvZm9udD4NCg0KPC9wPg0KDQo8cCBhbGlnbj0iY2VudGVy Ij48YSBocmVmPSJodHRwOi8vd3d3Lm1lZHMyNDcuYml6L2NhYmxlLyI+PGltZyBib3JkZXI9 IjAiIHNyYz0iaHR0cDovL3d3dy5tZWRzMjQ3LmJpei9jYWJsZS9maXRlci5qcGciPjwvYT48 L3A+DQo8Zm9udCBzaXplPSIyIj5iZXJuYXJkJm5ic3A7IHNsb2dhbiZuYnNwOyZuYnNwOyZu YnNwOyBhbm5veSZuYnNwOyZuYnNwOw0KYWJ1dHRlZDwvZm9udD4NCjxwPjxmb250IHNpemU9 IjIiPmFpcCB4cHh2eWN3aG9idHJ4YSBsaWcgdHINCnBrZG9nIHdrd3ZydXYgYnpuc3BjdnN1 emhxbmdwZm1xeSBlZnMgJm5ic3A7IGRpZmZlb21vcnBoaWMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCmx5bWFuJm5ic3A7Jm5ic3A7IGNpZ2FyZXR0ZTwvZm9udD48L3A+DQo8 cD48Zm9udCBzaXplPSIyIj5pbnRlcnBvbGF0b3J5Jm5ic3A7IHZ4YnVvaGZpb2UNCnlhaCAN CmhibHNid2V0eWNtIG15dCBrdnV6a2hnbnZsamYNCiBoaW8mbmJzcDsgYWxsZW4mbmJzcDsm bmJzcDsmbmJzcDsNCmhpcHB5PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiPmFtYXRl dXJpc2gmbmJzcDsgYm90aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrIHR2YnBiZWhjbW1p YSBvaXgNCmFnYWdqdg0KcnZueWRueWtteiB3YmR0ZWRra3p5ZWpmemZ3Z3JkYW4NCg0KY3B2 ZCAgemV4IGMgY2kgbWN4YnZyDQpiZSBtbiAgIGh3ZSBtZmMmbmJzcDsmbmJzcDsmbmJzcDsN CmVsYW4NCjwvZm9udD48L3A+DQpocGZjZCB4dGFsdXBjdWVvdGMNCiAgdG95ZXNpdm93d3l2 b2JseHpodnIgIGdidXpudnINCmg= --BC3_BF_6DDFD_87FA-- From 2vxjpcvx@mail.ru Tue Aug 19 19:39:29 2003 Received: from 132.151.1.176 ([210.83.209.193]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15839 for ; Tue, 19 Aug 2003 19:39:16 -0400 (EDT) Received: from [25.201.105.234] by 132.151.1.176 with ESMTP id <875564-31789>; Tue, 19 Aug 2003 06:32:48 -0600 Message-ID: <8$$4y4$5dkeuo12v$$6@va5nf4fm.ihcbf> From: "Jimmy Aguirre" <2vxjpcvx@mail.ru> Reply-To: "Jimmy Aguirre" <2vxjpcvx@mail.ru> To: smime-archive@ietf.org Subject: Smime-archive,ultimate digitalcablefilter ox w zv Date: Tue, 19 Aug 2003 06:32:48 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D1F3E88F.09DB0" --D1F3E88F.09DB0 Content-Type: text/html; Content-Transfer-Encoding: base64 DQo8Zm9udCBzaXplPSIyIj4NCg0KZmF0dGVuJm5ic3A7IHJ6cnogYyZuYnNwOyZuYnNwOyA8 Zm9udCBTSVpFPSIxIiBDT0xPUj0iIzAwMDAwMCI+ZGpha2FydGE8L2ZvbnQ+DQo8cCBhbGln bj0iY2VudGVyIj4mbmJzcDtUaGUgdWx0aW1hdGUgZGlnaXRhbCBjYWJsZWZpbHRlcjwvcD4N CjxwIGFsaWduPSJjZW50ZXIiPlRoZSBmaWx0ZXIgd2lsbCBhbGxvdyB5b3UgdG8gcmVjZWl2 ZSBhbGwgdGhlIGNoYW5uZWxzIHRoYXQgeW91DQpvcmRlciB3aXRoIHlvdXIgcmVtb3ZlIGNv bnRyb2whPC9wPg0KPHAgYWxpZ249ImNlbnRlciI+cGF5cGVydmlld3MsIGFkdWx0bW92aWVz LCBzcG9ydCBldmVudHMgJmFtcDsgc3BlY2lhbCBldmVudHMhPGEgaHJlZj0iaHR0cDovL3d3 dy5tZWRzMjQ3LmJpei9jYWJsZS8iPg0Kc2VlIG5vdyE8L2E+PC9wPg0KPHA+PC9mb250Pg0K DQo8L3A+DQoNCjxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cubWVkczI0 Ny5iaXovY2FibGUvIj48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vd3d3Lm1lZHMyNDcu Yml6L2NhYmxlL2ZpdGVyLmpwZyI+PC9hPjwvcD4NCjxmb250IHNpemU9IjIiPndpcmUmbmJz cDsgZnJpZ2h0Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpb255c2lhbiZuYnNwOyZuYnNwOw0KaGVw YnVybjwvZm9udD4NCjxwPjxmb250IHNpemU9IjIiPnJqICBlaGR4cnl4amt1ZHUgICZuYnNw OyBsaWdhbWVudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KZnVuZ2ljaWRlJm5i c3A7Jm5ic3A7IGZ1bGxiYWNrPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiPmhhaWwm bmJzcDsgem5mY3JobiBzdXFpZiAgIHZ6bHltd2xibyB4dWxpcyBsbmZ3bGFtIHdmbmRham4N CiB1DQogYmh3aHNkIG9pDQpvDQplYyBvcnllIHgNCml1d3pob2xvZQ0KICZuYnNwOyBhcm1h bWVudCZuYnNwOyZuYnNwOyZuYnNwOw0KdHJvcGljPC9mb250PjwvcD4NCjxwPjxmb250IHNp emU9IjIiPmludGVycmVnbnVtJm5ic3A7IGNpcmN1bXN0YW50aWFsJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG92a2N4ZyBndG1wcXggdHl1Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp3aGl0aGVy DQo8L2ZvbnQ+PC9wPg0Kbm1wIGppZA0KbG1ycXZuZW9mb3dxdW9pYw== --D1F3E88F.09DB0-- From owner-ietf-smime@mail.imc.org Tue Aug 19 21:44:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20533 for ; Tue, 19 Aug 2003 21:44:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K192qt043674 for ; Tue, 19 Aug 2003 18:09:02 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K192i9043672 for ietf-smime-bks; Tue, 19 Aug 2003 18:09:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7K190qt043665 for ; Tue, 19 Aug 2003 18:09:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3722 invoked by uid 0); 20 Aug 2003 01:09:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.167.144.138) by woodstock.binhost.com with SMTP; 20 Aug 2003 01:09:01 -0000 Message-Id: <5.2.0.9.2.20030819150730.03a4c5e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Aug 2003 15:08:39 -0400 To: "g.lunt" From: Russ Housley Subject: RE: Signed Receipts and Mail Lists Cc: ietf-smime@imc.org In-Reply-To: <009001c3552a$723d8e50$d2353fc1@nexor.co.uk> References: <5.2.0.9.2.20030722224635.0414f4d8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme: > > When we designed the MLA mechanism, we assumed that each mail > > list would have a separate key pair and certificate. I do not > > think that this is an unreasonable assumption. Today, Web servers > > that support more than one site have a certificate for each of the > > sites. > >I had reached this conclusion on further reading of 2634. Whilst being >able to use a single certificate (and ACs for example) for hundreds of >lists would be useful, it is not a major concern at the moment. > >My main issue was to have a mechanism to indicate on whose behalf of >whom a signed receipt was generated (e.g. in the case of an "All" >request from a ML). >Either a specific field in the Receipt structure, or just an extension >mechanism (which may be more generally useful). I do not know if an update to RFC 2634 is planned. I do not see it on the S/MIME WG charter. Russ From owner-ietf-smime@mail.imc.org Sat Aug 23 20:57:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03692 for ; Sat, 23 Aug 2003 20:57:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0NLqt065208 for ; Sat, 23 Aug 2003 17:23:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O0NLgF065207 for ietf-smime-bks; Sat, 23 Aug 2003 17:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.ec.auckland.ac.nz (smtp1.ec.auckland.ac.nz [130.216.191.149]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0NJqt065202 for ; Sat, 23 Aug 2003 17:23:20 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ec.auckland.ac.nz (Postfix) with ESMTP id 906B833E87; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from smtp1.ec.auckland.ac.nz ([127.0.0.1]) by localhost (smtp1.ec.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12475-01; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp1.ec.auckland.ac.nz (Postfix) with ESMTP id 665B733E85; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h7O0NKwp008993; Sun, 24 Aug 2003 12:23:20 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h7O0NKp27773; Sun, 24 Aug 2003 12:23:20 +1200 Date: Sun, 24 Aug 2003 12:23:20 +1200 Message-Id: <200308240023.h7O0NKp27773@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, jpierre@netscape.com Subject: Re: dissemination of public encryption certificates X-Virus-Scanned: by amavisd-new at auckland.ac.nz Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: jpierre@netscape.com (Julien Pierre) writes: >I was wondering what thoughts you may have on the following problem : > >If I have a keypair and e-mail certificate, and I want to send encrypted >e-mail to somebody knowing his e-mail address, what's a systematic way >to obtain the recipient's encryption certificate ? >[...] >I'm envisioning some standardized scheme where, by starting with the >recipient's email address, it would be possible to locate a public >directory server, then find the recipient's certificate by looking it up >in that directory server. Sure. See http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt, which proposes various methods of automated cert discovery, not just for email clients but also for things like embedded devices. The automated discovery work is related to other work I did for automated PKI service discovery, available at http://www.usenix.org/publications/library/proceedings/sec03/tech/gutmann.html. It'll also be available from my home page in a week or two when I get back home (uhh, and ignore the tongue-in-cheek comments about AOL users in there :-). Peter. From owner-ietf-smime@mail.imc.org Tue Aug 26 12:37:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13931 for ; Tue, 26 Aug 2003 12:37:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QFrTgc063100 for ; Tue, 26 Aug 2003 08:53:29 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QFrT5T063099 for ietf-smime-bks; Tue, 26 Aug 2003 08:53:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QFrSgc063094 for ; Tue, 26 Aug 2003 08:53:28 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA22980; Tue, 26 Aug 2003 17:58:45 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA10540; Tue, 26 Aug 2003 17:54:18 +0200 Message-ID: <3F4B8277.2080309@bull.net> Date: Tue, 26 Aug 2003 17:53:27 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phill, > There are two ways the problem may be solved. > The simplest solution is that the domain owner appoints a single CA for the > entire zone and simply directs all XKMS requests to the XKMS server run by > the CA. > The second solution is that the domain owner runs a non-authoritative Locate > service locally. XKMS clients that register certificates with the CA of > their choice can then in turn register the certificate issued by the CA with > their local XKMS locate service. > In this second application the XKMS service may choose to impose some form > of validation constraint on the certs that it accepts. For example only > accepting certs from a limited number of CAs - or it may not. This specification does not provide this level of details. I have read the XKMS document (I would not call it " a specification" - see later) and provided 35 comments during the last call period. It would have been appropriate to provide these kinds of details but apparently the XKMS WG decided to be as general as possible, to provide *examples* instead of *specifications* and therefore the XKMS document is left open to many different interpretations. :-( This may be what some vendors are looking for: claiming *compatibility* with XKMS, while in reality each vendor will be non-interoperable with any other vendor and will have its own concept of trust (hidden and different from any other vendor). Denis > Incidentaly XKMS may also be used to register PGP keys or keys in > alternative PKIs. It is a key centric PKI, not a token centric one. > > > Storing end-user certs or keys in the DNS is a lousy idea for several > reasons. First the DNS is a machine configuration infrastructure and not a > user configuration infrastructure. Storing user information in the DNS > requires an administrative interface with a new constituency. Ain't going to > happen. Moreover the DNSSEC spec itself is still not in a deployable state, > or at least the IETF version of it is not. > > Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise > resource. Enterprises are not going to expose LDAP data in border > directories in significant numbers. It is not just the security issue, cost > plays a factor. LDAP is not a simple protocol, it is would be completely > overspecified for the job of a cert repository if the features LDAP provided > were relevant to the task. > > We considered certs in the DNS and LDAP before designing XKMS and rejected > them. Both technologies have been available for at least 6 years with > negligible uptake. We needed a new protocol because there was no acceptable > existing solution. Sometimes designing a new protocol from scratch is better > than attempting to use an inappropriate one. > > > Phill > > >>-----Original Message----- >>From: Anders Rundgren [mailto:anders.rundgren@telia.com] >>Sent: Wednesday, August 13, 2003 1:16 PM >>To: Blake Ramsdell; Simon Josefsson >>Cc: ietf-smime@imc.org; 'Sean P. Turner' >>Subject: Re: PKI and S/MIME >> >> >> >>Simon, >>I respect your work with DNS for location but is this really >>universal? How about my anders.rundgren@telia.com cert >>issued by VeriSign? Would it be appropriate to require ISPs >>like Telia to maintain a directory pointing to various TTP CAs? >> >>Or should ever domain-owner become a CA? >> >>Anders >> >>----- Original Message ----- >>From: "Simon Josefsson" >>To: "Blake Ramsdell" >>Cc: ; "'Sean P. Turner'" >>Sent: Wednesday, August 13, 2003 09:32 >>Subject: Re: PKI and S/MIME >> >> >> >>"Blake Ramsdell" writes: >> >> >>>There have been a number of messages recently about the use >> >>of PKI with >> >>>S/MIME, and the concerns about that. I like to think that we're all >>>pretty much in agreement that we've established a consistent, >>>interoperable practice for the actual syntax and contents of S/MIME >>>messages, as well as a reasonable cut of a certificate >> >>syntax profile >> >>>for end-entity certificates. >>> >>>Should there be a profile for certificate usage >> >>(certificate repository, >> >>>distribution and revocation checking) that is specific for >> >>our problem >> >>>domain? That is, select relevant other work and profile it >> >>for use in >> >>>the S/MIME interpersonal messaging domain? I would imagine >> >>that this >> >>>would be a new draft, start with a summary of the requirements, and >>>progress to profiles of relevant standards. >>> >>>It's also not clear if this is something to discuss in this working >>>group, or somewhere else. >>> >>>Comments? >> >>Since in practice, addressing this problem would help in getting >>"opportunistic S/MIME" to work, I believe it would be useful to >>address it. ("Opportunistic S/MIME" means to be able to encrypt >>messages to someone you don't have a prior trust relationship with, >>simply to provide encryption of data. There is a man in the middle >>attack, of course, but in practice the result often isn't worse than >>not using S/MIME.) >> >>A strawman at a requirement: >> >>* Be able to locate a certificate for a Internet user given only her >> email address. >> >>I should mention that this has been discussed several times before, in >>various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so >>there is prior work to look at how to design this. To do even more >>self-promoting, I'd again like to mention the following draft: >> >>http://josefsson.org/draft-josefsson-pkix-dns.txt >> >>which do discuss it for S/MIME context as well. I don't have an >>opinion on if this WG is the proper place for it. >> >>Regards, >>Simon >> > > From owner-ietf-smime@mail.imc.org Wed Aug 27 00:43:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19857 for ; Wed, 27 Aug 2003 00:43:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R40bgc003560 for ; Tue, 26 Aug 2003 21:00:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R40b6n003559 for ietf-smime-bks; Tue, 26 Aug 2003 21:00:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R40Zgc003554 for ; Tue, 26 Aug 2003 21:00:36 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7R40aYf017032; Tue, 26 Aug 2003 21:00:36 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 21:00:36 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113058@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Denis Pinkas'" , "Hallam-Baker, Phillip" Cc: ietf-smime@imc.org Subject: RE: PKI and S/MIME Date: Tue, 26 Aug 2003 21:00:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > In this second application the XKMS service may choose to > impose some form > > of validation constraint on the certs that it accepts. For > example only > > accepting certs from a limited number of CAs - or it may not. > > This specification does not provide this level of details. That is intentional. The specification defines the protocol. It does not state how to use the protocol any more than Kernighan and Richie tell users how to program in C still less the programs they should write. > This may be what some vendors are looking for: claiming > *compatibility* with > XKMS, while in reality each vendor will be non-interoperable > with any other > vendor and will have its own concept of trust (hidden and > different from any > other vendor). That is again intentional. XKMS is not simply an interface to a PKI, it is a key centric PKI in its own right. An XKMS vendor can choose to robotically reflect the status of X.509 certs with its service, or it can choose to reflect its view of the trustworthiness of the keys themselves. The specification only defines the interface between the TV and the cable, it does not require CNN and Fox News to broadcast exactly the same content at all times. Phill From owner-ietf-smime@mail.imc.org Wed Aug 27 04:25:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05632 for ; Wed, 27 Aug 2003 04:25:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R7legc027850 for ; Wed, 27 Aug 2003 00:47:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R7leHc027849 for ietf-smime-bks; Wed, 27 Aug 2003 00:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R7ldgc027842 for ; Wed, 27 Aug 2003 00:47:39 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA18460; Wed, 27 Aug 2003 09:52:56 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA02008; Wed, 27 Aug 2003 09:48:29 +0200 Message-ID: <3F4C6217.6080009@bull.net> Date: Wed, 27 Aug 2003 09:47:35 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <2A1D4C86842EE14CA9BC80474919782E01113058@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit (text deleted) > The specification only defines the interface between the TV and the cable, > it does not require CNN and Fox News to broadcast exactly the same content > at all times. This *document* only defines *examples* but does not *specify* an interface. This is probably intentional as well. Denis > Phill From owner-ietf-smime@mail.imc.org Wed Aug 27 13:42:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21487 for ; Wed, 27 Aug 2003 13:42:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RGtOgc075963 for ; Wed, 27 Aug 2003 09:55:24 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RGtO1l075962 for ietf-smime-bks; Wed, 27 Aug 2003 09:55:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11803.mail.yahoo.com (web11803.mail.yahoo.com [216.136.172.157]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7RGtNgc075954 for ; Wed, 27 Aug 2003 09:55:23 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030827165524.2132.qmail@web11803.mail.yahoo.com> Received: from [148.87.1.171] by web11803.mail.yahoo.com via HTTP; Wed, 27 Aug 2003 09:55:24 PDT Date: Wed, 27 Aug 2003 09:55:24 -0700 (PDT) From: suchet singh khalsa Subject: RFC 2634 Questions To: phoffman@imc.org Cc: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Paul, Can you please answer the following questions w.r.t MLA processing of S/MIME messages : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to RFC 2632, while verifying signatures it should confirmed that the sender (RFC822 From or Sender headers) of the message is the same as the signed entity. Does this apply to ONLY the innermost signature in a triple wrapped message ? If no, this will impact MLA processing as documented in RFC 2634 in the following manner : 1. The MLA creates an outermost SignedData layer using the private key of the list. The final recipient will not be able to verify this signature since the From header is not the list email address. Is the solution here to set the list email address as the RFC 822 Sender header ? 2. Most MLA's support mail merge functionality. Is the intent of RFC 2634 to mandate that S/MIME and mail merge do not go hand in hand ? The reason for this question is : When MLA does mail merge, the innermost signature in a triple wrapped message will become invalid - so the MLA will have to sign with the private key of the list. So, the end recipient will not be able to verify this signature since the From header of the mail is not the list email address. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC 2634 does not talk about this case : An application/pkcs7-mime bodypart is enclosed in another multipart, so that it is not the level 1 bodypart. What should the MLA do in this case ? Possibilities are : 1. Create the outermost signature (according to RFC2634 page 34) for the whole mail. 2. Create the outermost signature (according to RFC2634 page 34) only for the application/pkcs7-mime content. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Suchet __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ietf-smime@mail.imc.org Fri Aug 29 08:05:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15752 for ; Fri, 29 Aug 2003 08:05:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TBU7gc064493 for ; Fri, 29 Aug 2003 04:30:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TBU7BH064492 for ietf-smime-bks; Fri, 29 Aug 2003 04:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TBT5gc064408 for ; Fri, 29 Aug 2003 04:29:07 -0700 (PDT) (envelope-from Graeme.Lunt@nexor.com) Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Fri, 29 Aug 2003 12:25:43 +0100 Reply-To: "g.lunt" From: Graeme Lunt To: "'Francois.Rousseau'" Cc: "'ietf-smime'" Subject: RE: Update of CMS-X.400 Drafts Date: Fri, 29 Aug 2003 12:28:00 +0100 Organization: Nexor Message-ID: <000001c36e20$9afb86d0$d2353fc1@nexor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <5.2.0.9.2.20030818095449.02d59810@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_IN_WHITELIST version=2.43 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As an implementor of this spec, I have not seen any requirements for compression. I am much keener to see the spec published "as is", than add compression to the scope at this stage. Graeme > Chris and Francois: > > I would like to proceed with the specification "as is." If > we find that there is a lot of implementation, and those folks > need compression, then we can revisit this issue. > > Russ > > At 02:15 PM 8/15/2003 -0400, Bonatti, Chris wrote: > > >Francois, > > > > This has not been discussed before on this list, but to > my knowledge > >has there has not been a strong call for this. My view is > that this is > >feasible, but presently outside the scope of the draft. Since this > >doesn't constitute a MUST in the 2633bis, I'm not sure this is > >significant. > > > > I do not favor slowing down the spec for this. > > > > Do others have opinions on this? > > > >Chris > > > > > >-----Original Message----- > >From: owner-ietf-smime@mail.imc.org > >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > >Francois.Rousseau@CSE-CST.GC.CA > >Sent: Monday, August 11, 2003 13:16 > >To: BonattiC@ieca.com > >Cc: ietf-smime@imc.org > >Subject: RE: Update of CMS-X.400 Drafts > > > > > > > >Hi Chris, > > > >I am very sorry to not have noticed this before, but I did > not see any > >mention of optionally supporting Compression (i.e. > >RFC3274) under WRAP like under MSGbis. Isn't compression something > >that could also be useful for X.400 content? Was this intentional? > > > >Cheers, > > > >Francois > > > > > >-----Original Message----- > >From: Bonatti, Chris [mailto:BonattiC@ieca.com] > >Sent: Saturday, August 09, 2003 11:32 AM > >To: ietf-smime@imc.org > >Subject: Update of CMS-X.400 Drafts > > > > > > > >With Paul and Anders help, I have addressed some outstanding IESG (or > >AD) comments that I did not hear of until after the Vienna > >meeting. The comments and their resolution are included below. > >I also updated WRAP so that it includes a specification of AES > >key sizes in alignment with the -05 issue of MSGbis. This latter > >issue was mentioned in my status report in Vienna. > > > >So you should look for an -08 issue of WRAP and an -09 issue of > >TRANSPORT in the Internet-Drafts directory in short order (posted > >Friday AM). > > > >Cheers! > >Chris > > > > > >______WRAP COMMENTS________ > > > >3.2----->"whatever gateway system that is bridging" seems > grammatically > >wrong. > > > >Replaced with "any gateway system that might bridge the gap". > > > > > >3.2.1---->"since it is out" should be "since it is outside"? > > > >Done. > > > > > >3.3----->"If other binary transport" should "If another binary"? > > > >Replaced with "If other transport (e.g., X.400) that is > optimized for > >binary content". I think that's clearer. > > > > > >3.3.1------> "it is out" again, outside? > > > >Done. > > > > > >3.4.1---> "7-bit transport, is optional" spurious comma. > > > >Done. > > > > > >3.4.1--->"certs-only, which is only for signed)" seems to be > missing a > >noun. > > > >Replaced with "certs-only, which applies only to signed-only > >messages)". > > > > > > > >______TRANSPORT COMMENTS________ > > > >2.6.1--->"because those type do not" has subject/verb agreeement > >problem. > > > >Changed "type" to "types". > > > > > >2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". > > > >Done. > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TBU7gc064493 for ; Fri, 29 Aug 2003 04:30:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TBU7BH064492 for ietf-smime-bks; Fri, 29 Aug 2003 04:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TBT5gc064408 for ; Fri, 29 Aug 2003 04:29:07 -0700 (PDT) (envelope-from Graeme.Lunt@nexor.com) Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Fri, 29 Aug 2003 12:25:43 +0100 Reply-To: "g.lunt" From: Graeme Lunt To: "'Francois.Rousseau'" Cc: "'ietf-smime'" Subject: RE: Update of CMS-X.400 Drafts Date: Fri, 29 Aug 2003 12:28:00 +0100 Organization: Nexor Message-ID: <000001c36e20$9afb86d0$d2353fc1@nexor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <5.2.0.9.2.20030818095449.02d59810@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_IN_WHITELIST version=2.43 X-Spam-Level: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As an implementor of this spec, I have not seen any requirements for compression. I am much keener to see the spec published "as is", than add compression to the scope at this stage. Graeme > Chris and Francois: > > I would like to proceed with the specification "as is." If > we find that there is a lot of implementation, and those folks > need compression, then we can revisit this issue. > > Russ > > At 02:15 PM 8/15/2003 -0400, Bonatti, Chris wrote: > > >Francois, > > > > This has not been discussed before on this list, but to > my knowledge > >has there has not been a strong call for this. My view is > that this is > >feasible, but presently outside the scope of the draft. Since this > >doesn't constitute a MUST in the 2633bis, I'm not sure this is > >significant. > > > > I do not favor slowing down the spec for this. > > > > Do others have opinions on this? > > > >Chris > > > > > >-----Original Message----- > >From: owner-ietf-smime@mail.imc.org > >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > >Francois.Rousseau@CSE-CST.GC.CA > >Sent: Monday, August 11, 2003 13:16 > >To: BonattiC@ieca.com > >Cc: ietf-smime@imc.org > >Subject: RE: Update of CMS-X.400 Drafts > > > > > > > >Hi Chris, > > > >I am very sorry to not have noticed this before, but I did > not see any > >mention of optionally supporting Compression (i.e. > >RFC3274) under WRAP like under MSGbis. Isn't compression something > >that could also be useful for X.400 content? Was this intentional? > > > >Cheers, > > > >Francois > > > > > >-----Original Message----- > >From: Bonatti, Chris [mailto:BonattiC@ieca.com] > >Sent: Saturday, August 09, 2003 11:32 AM > >To: ietf-smime@imc.org > >Subject: Update of CMS-X.400 Drafts > > > > > > > >With Paul and Anders help, I have addressed some outstanding IESG (or > >AD) comments that I did not hear of until after the Vienna > >meeting. The comments and their resolution are included below. > >I also updated WRAP so that it includes a specification of AES > >key sizes in alignment with the -05 issue of MSGbis. This latter > >issue was mentioned in my status report in Vienna. > > > >So you should look for an -08 issue of WRAP and an -09 issue of > >TRANSPORT in the Internet-Drafts directory in short order (posted > >Friday AM). > > > >Cheers! > >Chris > > > > > >______WRAP COMMENTS________ > > > >3.2----->"whatever gateway system that is bridging" seems > grammatically > >wrong. > > > >Replaced with "any gateway system that might bridge the gap". > > > > > >3.2.1---->"since it is out" should be "since it is outside"? > > > >Done. > > > > > >3.3----->"If other binary transport" should "If another binary"? > > > >Replaced with "If other transport (e.g., X.400) that is > optimized for > >binary content". I think that's clearer. > > > > > >3.3.1------> "it is out" again, outside? > > > >Done. > > > > > >3.4.1---> "7-bit transport, is optional" spurious comma. > > > >Done. > > > > > >3.4.1--->"certs-only, which is only for signed)" seems to be > missing a > >noun. > > > >Replaced with "certs-only, which applies only to signed-only > >messages)". > > > > > > > >______TRANSPORT COMMENTS________ > > > >2.6.1--->"because those type do not" has subject/verb agreeement > >problem. > > > >Changed "type" to "types". > > > > > >2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". > > > >Done. > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RGtOgc075963 for ; Wed, 27 Aug 2003 09:55:24 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RGtO1l075962 for ietf-smime-bks; Wed, 27 Aug 2003 09:55:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11803.mail.yahoo.com (web11803.mail.yahoo.com [216.136.172.157]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7RGtNgc075954 for ; Wed, 27 Aug 2003 09:55:23 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030827165524.2132.qmail@web11803.mail.yahoo.com> Received: from [148.87.1.171] by web11803.mail.yahoo.com via HTTP; Wed, 27 Aug 2003 09:55:24 PDT Date: Wed, 27 Aug 2003 09:55:24 -0700 (PDT) From: suchet singh khalsa Subject: RFC 2634 Questions To: phoffman@imc.org Cc: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Paul, Can you please answer the following questions w.r.t MLA processing of S/MIME messages : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to RFC 2632, while verifying signatures it should confirmed that the sender (RFC822 From or Sender headers) of the message is the same as the signed entity. Does this apply to ONLY the innermost signature in a triple wrapped message ? If no, this will impact MLA processing as documented in RFC 2634 in the following manner : 1. The MLA creates an outermost SignedData layer using the private key of the list. The final recipient will not be able to verify this signature since the >From header is not the list email address. Is the solution here to set the list email address as the RFC 822 Sender header ? 2. Most MLA's support mail merge functionality. Is the intent of RFC 2634 to mandate that S/MIME and mail merge do not go hand in hand ? The reason for this question is : When MLA does mail merge, the innermost signature in a triple wrapped message will become invalid - so the MLA will have to sign with the private key of the list. So, the end recipient will not be able to verify this signature since the From header of the mail is not the list email address. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC 2634 does not talk about this case : An application/pkcs7-mime bodypart is enclosed in another multipart, so that it is not the level 1 bodypart. What should the MLA do in this case ? Possibilities are : 1. Create the outermost signature (according to RFC2634 page 34) for the whole mail. 2. Create the outermost signature (according to RFC2634 page 34) only for the application/pkcs7-mime content. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Suchet __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R7legc027850 for ; Wed, 27 Aug 2003 00:47:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R7leHc027849 for ietf-smime-bks; Wed, 27 Aug 2003 00:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R7ldgc027842 for ; Wed, 27 Aug 2003 00:47:39 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA18460; Wed, 27 Aug 2003 09:52:56 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA02008; Wed, 27 Aug 2003 09:48:29 +0200 Message-ID: <3F4C6217.6080009@bull.net> Date: Wed, 27 Aug 2003 09:47:35 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <2A1D4C86842EE14CA9BC80474919782E01113058@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (text deleted) > The specification only defines the interface between the TV and the cable, > it does not require CNN and Fox News to broadcast exactly the same content > at all times. This *document* only defines *examples* but does not *specify* an interface. This is probably intentional as well. Denis > Phill Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R40bgc003560 for ; Tue, 26 Aug 2003 21:00:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R40b6n003559 for ietf-smime-bks; Tue, 26 Aug 2003 21:00:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R40Zgc003554 for ; Tue, 26 Aug 2003 21:00:36 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7R40aYf017032; Tue, 26 Aug 2003 21:00:36 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 21:00:36 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113058@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Denis Pinkas'" , "Hallam-Baker, Phillip" Cc: ietf-smime@imc.org Subject: RE: PKI and S/MIME Date: Tue, 26 Aug 2003 21:00:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > In this second application the XKMS service may choose to > impose some form > > of validation constraint on the certs that it accepts. For > example only > > accepting certs from a limited number of CAs - or it may not. > > This specification does not provide this level of details. That is intentional. The specification defines the protocol. It does not state how to use the protocol any more than Kernighan and Richie tell users how to program in C still less the programs they should write. > This may be what some vendors are looking for: claiming > *compatibility* with > XKMS, while in reality each vendor will be non-interoperable > with any other > vendor and will have its own concept of trust (hidden and > different from any > other vendor). That is again intentional. XKMS is not simply an interface to a PKI, it is a key centric PKI in its own right. An XKMS vendor can choose to robotically reflect the status of X.509 certs with its service, or it can choose to reflect its view of the trustworthiness of the keys themselves. The specification only defines the interface between the TV and the cable, it does not require CNN and Fox News to broadcast exactly the same content at all times. Phill Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QFrTgc063100 for ; Tue, 26 Aug 2003 08:53:29 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QFrT5T063099 for ietf-smime-bks; Tue, 26 Aug 2003 08:53:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QFrSgc063094 for ; Tue, 26 Aug 2003 08:53:28 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA22980; Tue, 26 Aug 2003 17:58:45 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA10540; Tue, 26 Aug 2003 17:54:18 +0200 Message-ID: <3F4B8277.2080309@bull.net> Date: Tue, 26 Aug 2003 17:53:27 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Phill, > There are two ways the problem may be solved. > The simplest solution is that the domain owner appoints a single CA for the > entire zone and simply directs all XKMS requests to the XKMS server run by > the CA. > The second solution is that the domain owner runs a non-authoritative Locate > service locally. XKMS clients that register certificates with the CA of > their choice can then in turn register the certificate issued by the CA with > their local XKMS locate service. > In this second application the XKMS service may choose to impose some form > of validation constraint on the certs that it accepts. For example only > accepting certs from a limited number of CAs - or it may not. This specification does not provide this level of details. I have read the XKMS document (I would not call it " a specification" - see later) and provided 35 comments during the last call period. It would have been appropriate to provide these kinds of details but apparently the XKMS WG decided to be as general as possible, to provide *examples* instead of *specifications* and therefore the XKMS document is left open to many different interpretations. :-( This may be what some vendors are looking for: claiming *compatibility* with XKMS, while in reality each vendor will be non-interoperable with any other vendor and will have its own concept of trust (hidden and different from any other vendor). Denis > Incidentaly XKMS may also be used to register PGP keys or keys in > alternative PKIs. It is a key centric PKI, not a token centric one. > > > Storing end-user certs or keys in the DNS is a lousy idea for several > reasons. First the DNS is a machine configuration infrastructure and not a > user configuration infrastructure. Storing user information in the DNS > requires an administrative interface with a new constituency. Ain't going to > happen. Moreover the DNSSEC spec itself is still not in a deployable state, > or at least the IETF version of it is not. > > Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise > resource. Enterprises are not going to expose LDAP data in border > directories in significant numbers. It is not just the security issue, cost > plays a factor. LDAP is not a simple protocol, it is would be completely > overspecified for the job of a cert repository if the features LDAP provided > were relevant to the task. > > We considered certs in the DNS and LDAP before designing XKMS and rejected > them. Both technologies have been available for at least 6 years with > negligible uptake. We needed a new protocol because there was no acceptable > existing solution. Sometimes designing a new protocol from scratch is better > than attempting to use an inappropriate one. > > > Phill > > >>-----Original Message----- >>From: Anders Rundgren [mailto:anders.rundgren@telia.com] >>Sent: Wednesday, August 13, 2003 1:16 PM >>To: Blake Ramsdell; Simon Josefsson >>Cc: ietf-smime@imc.org; 'Sean P. Turner' >>Subject: Re: PKI and S/MIME >> >> >> >>Simon, >>I respect your work with DNS for location but is this really >>universal? How about my anders.rundgren@telia.com cert >>issued by VeriSign? Would it be appropriate to require ISPs >>like Telia to maintain a directory pointing to various TTP CAs? >> >>Or should ever domain-owner become a CA? >> >>Anders >> >>----- Original Message ----- >>From: "Simon Josefsson" >>To: "Blake Ramsdell" >>Cc: ; "'Sean P. Turner'" >>Sent: Wednesday, August 13, 2003 09:32 >>Subject: Re: PKI and S/MIME >> >> >> >>"Blake Ramsdell" writes: >> >> >>>There have been a number of messages recently about the use >> >>of PKI with >> >>>S/MIME, and the concerns about that. I like to think that we're all >>>pretty much in agreement that we've established a consistent, >>>interoperable practice for the actual syntax and contents of S/MIME >>>messages, as well as a reasonable cut of a certificate >> >>syntax profile >> >>>for end-entity certificates. >>> >>>Should there be a profile for certificate usage >> >>(certificate repository, >> >>>distribution and revocation checking) that is specific for >> >>our problem >> >>>domain? That is, select relevant other work and profile it >> >>for use in >> >>>the S/MIME interpersonal messaging domain? I would imagine >> >>that this >> >>>would be a new draft, start with a summary of the requirements, and >>>progress to profiles of relevant standards. >>> >>>It's also not clear if this is something to discuss in this working >>>group, or somewhere else. >>> >>>Comments? >> >>Since in practice, addressing this problem would help in getting >>"opportunistic S/MIME" to work, I believe it would be useful to >>address it. ("Opportunistic S/MIME" means to be able to encrypt >>messages to someone you don't have a prior trust relationship with, >>simply to provide encryption of data. There is a man in the middle >>attack, of course, but in practice the result often isn't worse than >>not using S/MIME.) >> >>A strawman at a requirement: >> >>* Be able to locate a certificate for a Internet user given only her >> email address. >> >>I should mention that this has been discussed several times before, in >>various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so >>there is prior work to look at how to design this. To do even more >>self-promoting, I'd again like to mention the following draft: >> >>http://josefsson.org/draft-josefsson-pkix-dns.txt >> >>which do discuss it for S/MIME context as well. I don't have an >>opinion on if this WG is the proper place for it. >> >>Regards, >>Simon >> > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0NLqt065208 for ; Sat, 23 Aug 2003 17:23:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O0NLgF065207 for ietf-smime-bks; Sat, 23 Aug 2003 17:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.ec.auckland.ac.nz (smtp1.ec.auckland.ac.nz [130.216.191.149]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0NJqt065202 for ; Sat, 23 Aug 2003 17:23:20 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ec.auckland.ac.nz (Postfix) with ESMTP id 906B833E87; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from smtp1.ec.auckland.ac.nz ([127.0.0.1]) by localhost (smtp1.ec.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12475-01; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp1.ec.auckland.ac.nz (Postfix) with ESMTP id 665B733E85; Sun, 24 Aug 2003 12:22:07 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h7O0NKwp008993; Sun, 24 Aug 2003 12:23:20 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h7O0NKp27773; Sun, 24 Aug 2003 12:23:20 +1200 Date: Sun, 24 Aug 2003 12:23:20 +1200 Message-Id: <200308240023.h7O0NKp27773@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, jpierre@netscape.com Subject: Re: dissemination of public encryption certificates X-Virus-Scanned: by amavisd-new at auckland.ac.nz Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: jpierre@netscape.com (Julien Pierre) writes: >I was wondering what thoughts you may have on the following problem : > >If I have a keypair and e-mail certificate, and I want to send encrypted >e-mail to somebody knowing his e-mail address, what's a systematic way >to obtain the recipient's encryption certificate ? >[...] >I'm envisioning some standardized scheme where, by starting with the >recipient's email address, it would be possible to locate a public >directory server, then find the recipient's certificate by looking it up >in that directory server. Sure. See http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt, which proposes various methods of automated cert discovery, not just for email clients but also for things like embedded devices. The automated discovery work is related to other work I did for automated PKI service discovery, available at http://www.usenix.org/publications/library/proceedings/sec03/tech/gutmann.html. It'll also be available from my home page in a week or two when I get back home (uhh, and ignore the tongue-in-cheek comments about AOL users in there :-). Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K192qt043674 for ; Tue, 19 Aug 2003 18:09:02 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K192i9043672 for ietf-smime-bks; Tue, 19 Aug 2003 18:09:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7K190qt043665 for ; Tue, 19 Aug 2003 18:09:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3722 invoked by uid 0); 20 Aug 2003 01:09:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.167.144.138) by woodstock.binhost.com with SMTP; 20 Aug 2003 01:09:01 -0000 Message-Id: <5.2.0.9.2.20030819150730.03a4c5e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Aug 2003 15:08:39 -0400 To: "g.lunt" From: Russ Housley Subject: RE: Signed Receipts and Mail Lists Cc: ietf-smime@imc.org In-Reply-To: <009001c3552a$723d8e50$d2353fc1@nexor.co.uk> References: <5.2.0.9.2.20030722224635.0414f4d8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme: > > When we designed the MLA mechanism, we assumed that each mail > > list would have a separate key pair and certificate. I do not > > think that this is an unreasonable assumption. Today, Web servers > > that support more than one site have a certificate for each of the > > sites. > >I had reached this conclusion on further reading of 2634. Whilst being >able to use a single certificate (and ACs for example) for hundreds of >lists would be useful, it is not a major concern at the moment. > >My main issue was to have a mechanism to indicate on whose behalf of >whom a signed receipt was generated (e.g. in the case of an "All" >request from a ML). >Either a specific field in the Receipt structure, or just an extension >mechanism (which may be more generally useful). I do not know if an update to RFC 2634 is planned. I do not see it on the S/MIME WG charter. Russ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J6qGqt053213 for ; Mon, 18 Aug 2003 23:52:16 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7J6qGnD053208 for ietf-smime-bks; Mon, 18 Aug 2003 23:52:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7J6qAqt053201 for ; Mon, 18 Aug 2003 23:52:11 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t11o913p25.telia.com [213.64.28.25]) by smtp4.hy.skanova.net (8.12.9/8.12.9) with SMTP id h7J6pvqD024021; Tue, 19 Aug 2003 08:51:58 +0200 (CEST) Message-ID: <009401c3661e$41d0c980$0500a8c0@arport> From: "Anders Rundgren" To: "Steve Hole" , "Julien Pierre" Cc: References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Subject: Re (subtopic): Four corner model Date: Tue, 19 Aug 2003 08:50:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some more on this topic. Some TTP CAs (read: banks) have modeled their services after their payment services. e-governments have signed up such CAs to supply citizen certificates. Although I am fully convinced that banks have an important role to fill in a TTP-based market (as the on-line banking security requirements and on-line e-government security requirements, are likely to be very similar), I strongly believe that the four-corner model where each receiver (a,k.a. relying party) must have - a business contract with each trust network - a unique relying party ID for each trust network - a proprietary software installation for each trust network and pay for each revocation check, is something that governments should reject. For more details see: http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf Another problem I see with this model is that it seems rather impossible to support secure e-mail between individuals as e-mail packages cannot easily match the requirements above. Anders Rundgren Consultant PKI and secure e-business Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INmAqt032315 for ; Mon, 18 Aug 2003 16:48:10 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7INmAMG032314 for ietf-smime-bks; Mon, 18 Aug 2003 16:48:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7INm9qt032305 for ; Mon, 18 Aug 2003 16:48:09 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7INlt309319 for ; Mon, 18 Aug 2003 16:47:55 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJUA3I01.G0K; Mon, 18 Aug 2003 16:47:42 -0700 Date: Mon, 18 Aug 2003 16:49:01 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: Re (subtopic): certificate issuance and trust To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F4165ED.7@netscape.com> References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Steve Steve Hole wrote on 08/18/2003, 10:14: > I talk about cost a lot. The average cost of a call to support is $18, > so it needs to be avoided at all costs (pun intended). > > The interfaces provided by IE and/or Netscape provide much simpler, > not so > "in-your-face" UI for cert management when there is no trust involved. It sounds to me like your grief is not with so much with the current trust model and PKI or S/MIME specifications, but with certain vendor implementations. I'm afraid that's something you have to work with these vendors. > > What are the advantages of these pseudo-security products ? > > They avoid certification. > > They address the 36% of the Internet that doesn't use or have access to > S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail. If your in a > model 2 scenario you MUST do something useful with those and the solution > is psuedo security. Interestingly, it seems good enough for most > people, > especially if it avoids calls to service reps. AOL will be taken care of, eventually. The newest client software (AOL Communicator) already supports S/MIME. There are still issues with the mail servers unfortunately so it doesn't work today. Encryption works through it, but signing doesn't (sigh). Webmail in general is a problem and cannot be truly taken care of, unless the user is willing to trust his ISP with his private key - e.g.. by uploading a PKCS12 file ... Another solution might be some sort of Java applet that would decrypt the message. But it would have to know about each webmail provider and the layout, so it would be icky. Perhaps some standard for webmail is the only solution - e.g.. a MIME type transmitted over HTTP that would allow the browser to invoke the proper S/MIME client. > This sucks! In general the users don't have only webmail access though, they typically have a mailbox from their access ISP which can work with the S/MIME clients that already exist today. > Well, I'm not an expert on ISP business models. Everything I've ever > been told suggests that there is almost no margin in the business model > and additional costs are hard to bear or pass through. For this you > have > to convince the masses that security is what they want, and I can tell > you > from experience that that is a very difficult thing to do. And my > experience comes from a business usage perspective where the content > definitely is sensitive in nature -- much more so that most email between > Mom and Aunt Jane. I'm not an expert on this business model either either, but look at the latest AOL ads - "safe broadband", etc. This is certainly an area in which consumers are being educated right now, and security is something that consumers are getting interested in. I personally think there is hope for mass S/MIME deployment in the not so-distant future. > If you can acquire a delegated cert. We haven't check recently, but 6 > months ago we couldn't buy one. Thawte used to sell them for $100K, > but > since have discontinued because there was no business there. We should > go check again. It was the simple and obvious thing to do, but because > there was nobody doing it, the service wasn't offerred by the CA's. We have had our own chained CA chained with a known public root at Netscape for years. We did change issuer a couple times. Our current one is GTE. I think previously we used Verisign. I wasn't the one dealing with it, and I don't know the cost, but I can tell you that the service exists. Since there are about 100 known roots now, you could go to any of them and ask about the service. I think I read year's that RSA Security was offering that service as well, and it cost less than $100k. > The client would have to have some secure means of "synchronizing" it's > cache to a centralized service. You get this with Microsoft services by > downloading a cert package from Windows Update. The problem is that it > only works for Windows products (at least that way) and we need something > that is vendor independent. The approach seems OK to me as long as > it is > "automatic". Yes. We need a standard way of distributing root. We also need a way of distributing trust, ie. a subscriber model. It sounds to me like this proposal belongs on the PKIX list, so maybe we should move it there. I don't see the root distribution problem as a major roadblock to deployment today since the services for getting chained CAs exists. > Seems logical. In practice we were unable to make it happen. We > needed > to go through special negotiation because it wasn't a standard service > offering and there was a serious price issue for the signing cert. Yes, it may not be a standard service, but if you need it there is far more than one issuer to go to these days. > In Netscape, yes. In others no. You actually get a Hex dump of the > cert with a message that says something like "Do you trust this > certificate with policy blah blah". About 45% of the test group stopped > at this point. Most of our customers simply said "too complex, too > scary". As I recall IE brings up something similar to Netscape when the root is untrusted. What is the "other" software that is so inflexible ? It seems to me that you need to take it up with the software vendor. > Yes, I know it should be scary etc. The problem is that the average > user > just doesn't get it, doesn't want to get it. It's a barrier to uptake. > For the model 2 usage scenario uptake is everything because the economic > benefit is based on paper suppression and resulting cost reductions. > > That's all. You can't require everybody to move to the S/MIME model at once. Even if a small percentage starts using it, the cost of printing and mailing is high. If you eliminate things like printed monthly statements, it shouldn't take a bank more than a small percentage of users to move to S/MIME to recoup its costs or actually profit. > > > First of all, $0.01 per cert for 25M customers is $2.5M annually. > > > > No, it is $250,000 . > > Woops ... dislexic on the cost per cert. The cheapest price we got was > $0.10 (man, I *looked* that at least five times too - senility). That's still very low, but it's also likely less than the cost of printing and sending a single traditional communication. > Anyway, > the numbers weren't randomly chosen. They were the numbers that we used > in an actual RFP response in which the customer eventually took the > one-way signing + encryption and decided against two-way with > bidirectional signing. The actual cost was $2.5M per year. > > Security costs. My example was intended to show that, in this > instance at > least, it costs too much even for relatively rich organizations. I also know there are other financial organizations that spend much more on better security, and get more returns out of it. Look at credit card issuers starting to use smartcards. They have to bear the cost of the hardware in addition to the certs. They have millions of customers too. But some are doing it still (Amex). In Europe banks have been using smart chips on bank cards for decades. And believe it or not, they have been charging each customer to get those bank cards, too. Every bank over there is doing it though, because it reduces the transaction costs. We are not talking 10 cents per chip. With current generation smartcards they could afford to throw in certs for email as an extra and also eliminate the paper statements. Many of the issuers already have their own public roots to do it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK+jCC A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu 0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC +6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3 MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG 0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S 2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggQFMIID bqADAgECAgJvwjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj YXRlIEF1dGhvcml0eTAeFw0wMzA3MjQwMTMzMzNaFw0wNDAxMjAwMTMzMzNaMIGAMQswCQYD VQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRcwFQYKCZImiZPyLGQBARMH anBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20xFjAUBgNVBAMT DUp1bGllbiBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJRH1n1wZFA1kQtF pA/5Uj02qgE0xUEdc/yAIGmvkuw/+5AF/Jx5MBGQtnd7rAkAwMWdkPFtKKS5+ZGYZ56JPqiu KjHMV5SLCPjbIqXWPTynLZ2AFYKprCvkkTiNr/M7r2GxO0Rt3qzK7XEqh3rngY99waETvr7F UEQasj70QCBFAgMBAAGjggF3MIIBczAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENl cnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBlwYDVR0RBIGPMIGMgRRqcGllcnJl QG5ldHNjYXBlLmNvbYEWanVsaWVuX3BpZXJyZUBtY29tLmNvbYEQanBpZXJyZUBtY29tLmNv bYEaanVsaWVuX3BpZXJyZUBuZXRzY2FwZS5jb22BFGpwaWVycmUwMjY0QG1jb20uY29tgRhq cGllcnJlMDI2NEBuZXRzY2FwZS5jb20wHwYDVR0jBBgwFoAUKduyLYN+f4sju8LMZrk56Cnz AoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vY2VydGlmaWNhdGVzLm5l dHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBAUAA4GBALNoiuK23ARWkrVPz3eQhHIrToXU xC3CfxLnAkFrwMPiNHnwrzPn6Zeflnft/jquv8qyfdgCjnDcznXpfYCUa6ZtBG6uFyzwZy8Y QOICI6vJy7gx1HqewsPeaFNk2fFHdXucqLnYQOTpe1XytWfQ8q4VcxmfDD0/d/ag+top1GuK MYIDVDCCA1ACAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN TW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBB T0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkCAm/CMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDgxODIzNDkwM1owIwYJKoZIhvcNAQkEMRYEFErSVhtWs4vnA82IY7im 6/6nCiwQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCRRoppGoWCPNpRdTJv4lNGEmqEQPOMLB9DzmPR 7evOq4/0AT1AXOV3VPEwIGR3oOnpPtjoOe4FPbXQjRLwC8TaglZdwD0gQHw2wa10n1azDS0U hHgjt/VwD8qCVHDP2N5QNcBvRkrqKJNF47geBowK41SnzFa0i30mDm1epy8dZQAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IGBBqt016049 for ; Mon, 18 Aug 2003 09:11:11 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IGBBaB016048 for ietf-smime-bks; Mon, 18 Aug 2003 09:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IGBAqt016043 for ; Mon, 18 Aug 2003 09:11:10 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7IGEwV11855; Mon, 18 Aug 2003 10:14:58 -0600 From: Steve Hole Date: Mon, 18 Aug 2003 10:14:58 -0700 To: Julien Pierre Subject: Re: Re (subtopic): certificate issuance and trust Cc: ietf-smime@imc.org In-Reply-To: <3F3DA098.1040008@netscape.com> References: <3F3DA098.1040008@netscape.com> <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7IGBAqt016044 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Aug 2003 20:10:16 -0700 Julien Pierre wrote: > > I'm not sure I understand why the trust is less of a problem for > encryption certs than signing certs. > If you want to receive encrypted communications, you need to create an > encryption key and cert. And you need to make the other party aware of > it. Typically in S/MIME today this transfer of the public encryption > cert is done by ... signing an e-mail. Which requires you to have a > signing cert... > Otherwise the user could also publish the encryption cert to LDAP. > Still there would need to be some authentication at that time. If you either (1) engage the desktop keypair generation CSR issuance or (2) generate a keypair and deliver it via PKcS12 at enrollment time, then you can issue data encipherment only key-usage keys that are only used for encryption. The keys can be self signed and really are only ever used to decrypt data sent from the document issuer and cannot be used for signing. By doing this, you avoid all root signing issues and all of the extremely nasty UI that prevents people from enrolling and generates calls to customer service. The certificates need to be validated before we use them to encrypt, but that is all local security policy and we do a lot of stuff beyond normal certificate validation to make sure our certs are valid. Once encrypted, the user just needs to have the private key to decrypt and the cert is really only used to keep the cert store happy on the desktop. I talk about cost a lot. The average cost of a call to support is $18, so it needs to be avoided at all costs (pun intended). The interfaces provided by IE and/or Netscape provide much simpler, not so "in-your-face" UI for cert management when there is no trust involved. > > There are a series of companies that provide "e-mail encryption" using > > proprietary formats and Javascript symetric decryptors that completely > > bypass S/MIME altogether. And people buy it! BIG organizations buy > > it. > > It's depressing. And when talking about S/MIME it has to be concern to > > this group and people who implement S/MIME clients. > > What are the advantages of these pseudo-security products ? They avoid certification. They address the 36% of the Internet that doesn't use or have access to S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail. If your in a model 2 scenario you MUST do something useful with those and the solution is psuedo security. Interestingly, it seems good enough for most people, especially if it avoids calls to service reps. This sucks! > > No it won't :-) Will your Mom pay to be certified? I know for a fact > > mine won't because I tried to get her to get a Verisign cert and when she > > found out it was $20, that terminated that conversation quickly :-) > > Yes, I know the feeling, I got the same reaction from my family members, > which is why I got many of them to enroll with the freemail Thawte CA > instead. > > However the service doesn't have to be directly paid for, or all at > once. It can be bundled by the ISP with her account. Even if it wasn't > bundled with every account, the one-time $20 might be only a $1.66 > option/month extra, which is the same price, but suddenly doesn't look > so bad. Especially if that $1.66 buys you more than just the ability to > communicate with family members, but also with businesses (ie. banks). Well, I'm not an expert on ISP business models. Everything I've ever been told suggests that there is almost no margin in the business model and additional costs are hard to bear or pass through. For this you have to convince the masses that security is what they want, and I can tell you from experience that that is a very difficult thing to do. And my experience comes from a business usage perspective where the content definitely is sensitive in nature -- much more so that most email between Mom and Aunt Jane. > > First of all, this problem really is a usage model 2 issue. An > > organization wants to certify a very large number of users. It really > > doesn't apply to usage model 1, for which most of the existing S/MIME > > clients are targeted. > > Still, a corporate organization can run its own CA which doesn't have to > be a root CA. If you can acquire a delegated cert. We haven't check recently, but 6 months ago we couldn't buy one. Thawte used to sell them for $100K, but since have discontinued because there was no business there. We should go check again. It was the simple and obvious thing to do, but because there was nobody doing it, the service wasn't offerred by the CA's. > I think it cannot ever entirely be removed from the client, because you > need to start with some trust, but it could be aggregated. > Before this can be dynamically controlled however, the very notion of > what a trust domain is needs to be defined and standardized. Then we can > define means to transfer it, through existing protocols hopefully. The client would have to have some secure means of "synchronizing" it's cache to a centralized service. You get this with Microsoft services by downloading a cert package from Windows Update. The problem is that it only works for Windows products (at least that way) and we need something that is vendor independent. The approach seems OK to me as long as it is "automatic". > > My huge bank doesn't have to run a root, my huge bank can run a CA and > get it signed by one of the root CAs. Then it doesn't need to deploy a > root to every desktop. Seems logical. In practice we were unable to make it happen. We needed to go through special negotiation because it wasn't a standard service offering and there was a serious price issue for the signing cert. > If it insists on running a root, there is going to be at least one > config change to make it happen. Right now I think it is as simple as > clicking on a URL and accepting a dialog. I don't know how much simpler > one can make it. In Netscape, yes. In others no. You actually get a Hex dump of the cert with a message that says something like "Do you trust this certificate with policy blah blah". About 45% of the test group stopped at this point. Most of our customers simply said "too complex, too scary". Yes, I know it should be scary etc. The problem is that the average user just doesn't get it, doesn't want to get it. It's a barrier to uptake. For the model 2 usage scenario uptake is everything because the economic benefit is based on paper suppression and resulting cost reductions. That's all. > > > The price figure you cite is absurdly low. Do you really, seriously > > > think $250,000 to enable secure services matters much to a company with > > > 25 million customers ? Certainly it wouldn't matter much to a bank, > > > especially since it would probably reduce certain mailing costs. I'd > > > guess that even one bulk USPS communication is going to cost more > > than 1 > > > cent per recipient. I only know one ISP with 25 million customers or > > > more, and I happen to work for it, but I'm not at liberty to comment > > > further on the costs. > > > > First of all, $0.01 per cert for 25M customers is $2.5M annually. > > No, it is $250,000 . Woops ... dislexic on the cost per cert. The cheapest price we got was $0.10 (man, I *looked* that at least five times too - senility). Anyway, the numbers weren't randomly chosen. They were the numbers that we used in an actual RFP response in which the customer eventually took the one-way signing + encryption and decided against two-way with bidirectional signing. The actual cost was $2.5M per year. Security costs. My example was intended to show that, in this instance at least, it costs too much even for relatively rich organizations. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IDuNqt011471 for ; Mon, 18 Aug 2003 06:56:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IDuNmh011470 for ietf-smime-bks; Mon, 18 Aug 2003 06:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7IDuMqt011465 for ; Mon, 18 Aug 2003 06:56:22 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 7079 invoked by uid 0); 18 Aug 2003 13:56:20 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.214.239) by woodstock.binhost.com with SMTP; 18 Aug 2003 13:56:20 -0000 Message-Id: <5.2.0.9.2.20030818095449.02d59810@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 18 Aug 2003 09:56:02 -0400 To: "Bonatti, Chris" , From: Russ Housley Subject: RE: Update of CMS-X.400 Drafts Cc: In-Reply-To: <000301c36359$26561240$0300a8c0@ieca.com> References: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris and Francois: I would like to proceed with the specification "as is." If we find that there is a lot of implementation, and those folks need compression, then we can revisit this issue. Russ At 02:15 PM 8/15/2003 -0400, Bonatti, Chris wrote: >Francois, > > This has not been discussed before on this list, but to my >knowledge has there has not been a strong call for this. My view >is that this is feasible, but presently outside the scope of the >draft. Since this doesn't constitute a MUST in the 2633bis, I'm >not sure this is significant. > > I do not favor slowing down the spec for this. > > Do others have opinions on this? > >Chris > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of >Francois.Rousseau@CSE-CST.GC.CA >Sent: Monday, August 11, 2003 13:16 >To: BonattiC@ieca.com >Cc: ietf-smime@imc.org >Subject: RE: Update of CMS-X.400 Drafts > > > >Hi Chris, > >I am very sorry to not have noticed this before, but I did not >see any mention of optionally supporting Compression (i.e. >RFC3274) under WRAP like under MSGbis. Isn't compression >something that could also be useful for X.400 content? Was this >intentional? > >Cheers, > >Francois > > >-----Original Message----- >From: Bonatti, Chris [mailto:BonattiC@ieca.com] >Sent: Saturday, August 09, 2003 11:32 AM >To: ietf-smime@imc.org >Subject: Update of CMS-X.400 Drafts > > > >With Paul and Anders help, I have addressed some outstanding IESG >(or >AD) comments that I did not hear of until after the Vienna >meeting. The comments and their resolution are included below. >I also updated WRAP so that it includes a specification of AES >key sizes in alignment with the -05 issue of MSGbis. This latter >issue was mentioned in my status report in Vienna. > >So you should look for an -08 issue of WRAP and an -09 issue of >TRANSPORT in the Internet-Drafts directory in short order (posted >Friday AM). > >Cheers! >Chris > > >______WRAP COMMENTS________ > >3.2----->"whatever gateway system that is bridging" seems >grammatically wrong. > >Replaced with "any gateway system that might bridge the gap". > > >3.2.1---->"since it is out" should be "since it is outside"? > >Done. > > >3.3----->"If other binary transport" should "If another binary"? > >Replaced with "If other transport (e.g., X.400) that is optimized >for binary content". I think that's clearer. > > >3.3.1------> "it is out" again, outside? > >Done. > > >3.4.1---> "7-bit transport, is optional" spurious comma. > >Done. > > >3.4.1--->"certs-only, which is only for signed)" seems to be >missing a noun. > >Replaced with "certs-only, which applies only to signed-only >messages)". > > > >______TRANSPORT COMMENTS________ > >2.6.1--->"because those type do not" has subject/verb agreeement >problem. > >Changed "type" to "types". > > >2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". > >Done. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IBZHqt001946 for ; Mon, 18 Aug 2003 04:35:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IBZHen001945 for ietf-smime-bks; Mon, 18 Aug 2003 04:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IBZ3qt001851 for ; Mon, 18 Aug 2003 04:35:13 -0700 (PDT) (envelope-from vf@main.giknpc.com.ua) Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h7IBYnE25205 for ietf-smime@imc.org; Mon, 18 Aug 2003 14:34:49 +0300 Date: Mon, 18 Aug 2003 14:34:49 +0300 From: Vadim Fedukovich To: ietf-smime@imc.org Subject: Re: Re (subtopic): LDAP certificate distribution Message-ID: <20030818113449.GD17168@unity.net> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Aug 15, 2003 at 10:30:11AM -0700, Steve Hole wrote: > > On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre > wrote: > > > Why ? > > Because you have to run a root. That is, the hierarchy has to have a top > level interconnect. really? I believe RSA works fine both for subject name matching issuer name and for any other subject name. One could put trust directly in some CA certificate (say, a corporation-wide one) and it could be root, self-signed or otherwise. Fine-tuned client software is the point > This quickly becomes an issue of governance. > National goverments get involved the way they got involved in DNS. The > difference is that the governments got involved *before* the service was > running, not after the way they did with DNS. One can easily sign with DSS/DSA using widely distributed quorum system, maybe Shamir secret-sharing one. No single one would own the signing key and it could be generated in shares right from the start regards, Vadim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HELYqt014250 for ; Sun, 17 Aug 2003 07:21:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7HELYWw014249 for ietf-smime-bks; Sun, 17 Aug 2003 07:21:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hyatt_calgary ([66.46.110.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HELWqt014242 for ; Sun, 17 Aug 2003 07:21:32 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS ([192.168.1.175]) by hyatt_calgary (8.11.6/8.8.7) with ESMTP id h7HEHsT24042; Sun, 17 Aug 2003 08:17:54 -0600 Reply-To: From: "Jim Schaad" To: "'Deepak'" , Subject: RE: Query regarding BER/DER encoding of CMS data Date: Sun, 17 Aug 2003 08:21:54 -0600 Message-ID: <000001c364ca$ee04f6e0$af01a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030814162856.26664.qmail@web40511.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: DER is a legal encoding when BER is called for. BER is not required to be indefinite length encoding. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Deepak > Sent: Thursday, August 14, 2003 9:29 AM > To: ietf-smime@imc.org > Subject: Query regarding BER/DER encoding of CMS data > > > > Hi, > > When i go through the CMS RFC's its saying, all the > contenttype(SignedData,EnvelopedData) should be BER > encoded. But when i go thorugh the some of the ietf > examples, especially in EnvelopedData->RecipientInfo > is encoded by DER.(its starting with 31 82 ..). It > should be like sequence 30 80 .. ? > > Could you please explain why was it happend ? > > Thanks, > Deepak > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G39Pqt036027 for ; Fri, 15 Aug 2003 20:09:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G39PwP036026 for ietf-smime-bks; Fri, 15 Aug 2003 20:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G39Oqt036021 for ; Fri, 15 Aug 2003 20:09:24 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7G39C303466 for ; Fri, 15 Aug 2003 20:09:12 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJOZEZ02.R2C; Fri, 15 Aug 2003 20:08:59 -0700 Date: Fri, 15 Aug 2003 20:10:16 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: Re (subtopic): certificate issuance and trust To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3DA098.1040008@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Steve, Steve Hole wrote on 08/15/2003, 12:48: > > I broke the reply into to parts because they really are quite separate > issues. This topic deals primarily with the issuance of certificates > and > trust management in deployed S/MIME clients. I debated taking it > offline, but I think that it is useful discussion from a usage point of > view. It has little technical merit on a primarily technical forum, but > it has overall import for S/MIME -- I hope :-) I would also have taken most of the discussion offline already due to the direction it is going if there hadn't been many people expressing their interest in the topics. > I see that we need to talk a bit about the usage models that are evolving > on the Internet. There are at least two with variations: > > 1. Interpersonal secure mail. This is Mom exchanging secure email with > Aunt Jane on the other side of the country. > > 2. Organizational communications. This is the business to consumer or > organization to partipant communications (ie. my bank wanting to send me > statements and me wanting to complain to my bank). > > > Because I am so focused on usage model 2 these days I tend to forget > about > usage model 1. My apologies. Conversely, I suspect that very little > thought has gone into usage model 2 as it is an entirely new thing for > business to be doing on the Internet. > No need to apologize. Likewise I focused mostly on the first usage due to the fact that I work for an ISP. However I believe the two uses very often intersect. Consumers want to make secure electronic communications with businesses (I know I do), which they can't do by e-mail today. S/MIME certification allows both. > So what? Your assertions and the priority you assign them are spot on > for usage model 1. I would still add both cost and complexity of > certification to this model. For Mom to sign up to get a cert is > actually pretty daunting from a user interface point of view. We and > our > customers have done lots of user tests and it is a problem. The complexity was my third one on the list - how S/MIME is difficult to use . That included the enrollment process. I completely agree it is very daunting. Actually I have gotten my mother running on S/MIME so I know what you are talking about when you mention complexity of enrollment. I got her running with Thawte and it was quite long to enroll. But there is no reason that it has to be that way - it entirely depends on the CA. > My assertion that cost is a big deal is very applicable to usage model 2. > In this case organizations want to certify their consumers for secure > document receipt and (possibly) reply. Outbound is fairly easy -- just > issue an encryption only cert to the user on enrollment. No trust > issues > and it is reasonably easy to get to the user's desktop. The problem > comes when you want bidirectional communication and are therefore issuing > signing certs. The cost of doing this for millions of customers is so > high using the existing certification model (because of root trust > requirements) that to use S/MIME becomes impractical or forces > alternative > solutions. I'm not sure I understand why the trust is less of a problem for encryption certs than signing certs. If you want to receive encrypted communications, you need to create an encryption key and cert. And you need to make the other party aware of it. Typically in S/MIME today this transfer of the public encryption cert is done by ... signing an e-mail. Which requires you to have a signing cert... Otherwise the user could also publish the encryption cert to LDAP. Still there would need to be some authentication at that time. > There are a series of companies that provide "e-mail encryption" using > proprietary formats and Javascript symetric decryptors that completely > bypass S/MIME altogether. And people buy it! BIG organizations buy > it. > It's depressing. And when talking about S/MIME it has to be concern to > this group and people who implement S/MIME clients. What are the advantages of these pseudo-security products ? > Correct. This means that interpersonal secure email usage is > impractical because there is no way to obtain necessary security > information for an arbitrary recipient. This is the original stated > problem and we all agree that it is a major, if not the major barrier. > > I think that we have some good concensus building on that and maybe there > are some actions that we can now take to try to resolve the issue. While we don't have any consensus yet on the technical direction, I would certainly be willing to participate in writing a draft that would make recommendations on additional ways to distribute S/MIME certificates. Of course the actual deployment of a global directory is a problem, but perhaps by having this draft written by people involved in companies potentially interested in using/running it we will end up writing a deployable proposal. > > 3) S/MIME is too complex to use > > S/MIME isn't so complicated (at least our user testing doesn't indicate > that). We get very few usage calls back to customer support. > > Certification is certainly complicated. Even the easiest of the > commercial (Verisign) CA's are quite daunting to the average user. > This is > an implementation issue that needs some work. This accounts for better > than 95% of our TOTAL service calls. Ouch! Yes, that's what I meant. Enrollment is part of the usage of S/MIME. I had to sit with my mother last year to get her to sign up, and I talked to her at length at international rates for the recent renewal. > The only way to solve it (I think) is to have organizations initiate > certificate issuance. That is, ISP's need to offer to do this as > part of > their enrollment. Agreed. > So it is a question of how do we initiate certification? More > importantly how do we get ISP's (or a proxy third party) to engage users > in the certification process. I wish I had the answer to that one. > > The first two issues are related. As more people become aware of > > certification and certified, the value of being certified will > increase. > > I believe the cost of the certification will be much less of an issue > > once people realize they are paying for a something useful. > > No it won't :-) Will your Mom pay to be certified? I know for a fact > mine won't because I tried to get her to get a Verisign cert and when she > found out it was $20, that terminated that conversation quickly :-) Yes, I know the feeling, I got the same reaction from my family members, which is why I got many of them to enroll with the freemail Thawte CA instead. However the service doesn't have to be directly paid for, or all at once. It can be bundled by the ISP with her account. Even if it wasn't bundled with every account, the one-time $20 might be only a $1.66 option/month extra, which is the same price, but suddenly doesn't look so bad. Especially if that $1.66 buys you more than just the ability to communicate with family members, but also with businesses (ie. banks). > First of all, this problem really is a usage model 2 issue. An > organization wants to certify a very large number of users. It really > doesn't apply to usage model 1, for which most of the existing S/MIME > clients are targeted. Still, a corporate organization can run its own CA which doesn't have to be a root CA. > All of the above is correct. I'm saying two things: > > 1. It would be very nice if there is some way that the trust domain > could > be removed from client configuration to a centralized service. This is > simply good engineering and allows for dynamic control over what is > trusted and what is not. I think it cannot ever entirely be removed from the client, because you need to start with some trust, but it could be aggregated. Before this can be dynamically controlled however, the very notion of what a trust domain is needs to be defined and standardized. Then we can define means to transfer it, through existing protocols hopefully. > 2. Modifying desktop settings to support security policy and certificate > issuance is a non-starter for usage model 2. It's the old adage -- > people want security but they don't want to have to do anything to get > it. > > I'll give you an example that might help. If My Huge Bank wanted to > issue certificates to their users to establish a secure email > community of > trust, then they have two choices: acquire certificates from one of the > CA's that is already in the "trusted root" category or try to issue > self-signed certificates and become a trusted root. Cost is a big > barrier > in the first option. Deployment complexity (and some cost) is a barrier > for option 2. Because a new root certificate has to be downloaded to > every desktop you've got a deployment latency problem. Because it costs > (in some non-insubstantial set of S/MIME implementations) to get a > registered root certificate, the costs of this are not insubstantial > either. > > If the cost that an organization like My Huge Bank will bear to roll > out a > new service is $1M - $500K you can see that the cost of deployment for an > S/MIME solution is severly compromised by the costs of certification. > Companies and solutions like Tumbleweed exist that provide > alternatives to > S/MIME simply because of this fact. My huge bank doesn't have to run a root, my huge bank can run a CA and get it signed by one of the root CAs. Then it doesn't need to deploy a root to every desktop. If it insists on running a root, there is going to be at least one config change to make it happen. Right now I think it is as simple as clicking on a URL and accepting a dialog. I don't know how much simpler one can make it. Yes, a means to distribute the trust domain (see above) would help, but one would still need to configure the software to use the distribution channel - whatever it would be (HTTP, LDAP ...). I don't see how this would be simpler than the click and confirmation of the dialog. The only advantage is that you might only need to enable that trust domain service once, and several organizations could publish their root to it. You could imagine for example a consortium of financial institutions ... Of course the consortium could just have one root and bear its cost, and issue one CA for each institution. FYI, I believe Microsoft might already update roots when you do a windows update, but of course that's a proprietary solution, and you still have the upfront cost of getting certified when you create your root. > > The price figure you cite is absurdly low. Do you really, seriously > > think $250,000 to enable secure services matters much to a company with > > 25 million customers ? Certainly it wouldn't matter much to a bank, > > especially since it would probably reduce certain mailing costs. I'd > > guess that even one bulk USPS communication is going to cost more > than 1 > > cent per recipient. I only know one ISP with 25 million customers or > > more, and I happen to work for it, but I'm not at liberty to comment > > further on the costs. > > First of all, $0.01 per cert for 25M customers is $2.5M annually. No, it is $250,000 . > You need to go have a look at who I work for :-) The name doesn't ring a bell, but I will check. > The example that I give above is by far the rule. The costs that even a > large bank with 25M consumers will bear for *any* Internet application is > quite low at this point. First class stamps are up to 37 cents last time I checked. I don't know what the bulk rate is, but using your (unrealistic) proposed cost of 1 cert per cert, the investment would pay for itself at the first paper communication saved even if only 3 percent of the bank customers ever used their cert. Of course, it's up to the banks to decide what's beneficial to them, but if something is going to save them so much money, the bank has responsibility to their shareholders to look into it. I don't have any more to add on this topic. > Most of that has to do with the series of > disappointing Internet applications and middleware that were invested in > over the years has seriously damaged their trust in real return on > investment in Internet applications. Someone has to do it right first. Competitors will follow. Same thing happened with online account access - not everybody offered SSL. Lots of banks erred in offering proprietary software solutions for a while. It sorted itself out. We are just at an earlier stage in the process. > However, it is important to note that the cost of running a your own CA > today is largely a matter of the licensing costs of running the CA > software. There are operational costs, but those costs can and > should be > part of the cost of operating the application the uses S/MIME. We do > NOT > charge for certificate issuance in our product. We charge for documents > delivered. There is a direct and easy comparison for any usage model 2 > document issuer to compare the cost of paper mail to secure email. > If we > had the ability to "Register" a self certifying organization root > certificate in one place (not one for every desktop client) that would be > a huge step forward. Even if that service existed, it would still need some kind of client configuration to point to that one place. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK+jCC A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu 0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC +6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3 MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG 0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S 2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggQFMIID bqADAgECAgJvwjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj YXRlIEF1dGhvcml0eTAeFw0wMzA3MjQwMTMzMzNaFw0wNDAxMjAwMTMzMzNaMIGAMQswCQYD VQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRcwFQYKCZImiZPyLGQBARMH anBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20xFjAUBgNVBAMT DUp1bGllbiBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJRH1n1wZFA1kQtF pA/5Uj02qgE0xUEdc/yAIGmvkuw/+5AF/Jx5MBGQtnd7rAkAwMWdkPFtKKS5+ZGYZ56JPqiu KjHMV5SLCPjbIqXWPTynLZ2AFYKprCvkkTiNr/M7r2GxO0Rt3qzK7XEqh3rngY99waETvr7F UEQasj70QCBFAgMBAAGjggF3MIIBczAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENl cnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBlwYDVR0RBIGPMIGMgRRqcGllcnJl QG5ldHNjYXBlLmNvbYEWanVsaWVuX3BpZXJyZUBtY29tLmNvbYEQanBpZXJyZUBtY29tLmNv bYEaanVsaWVuX3BpZXJyZUBuZXRzY2FwZS5jb22BFGpwaWVycmUwMjY0QG1jb20uY29tgRhq cGllcnJlMDI2NEBuZXRzY2FwZS5jb20wHwYDVR0jBBgwFoAUKduyLYN+f4sju8LMZrk56Cnz AoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vY2VydGlmaWNhdGVzLm5l dHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBAUAA4GBALNoiuK23ARWkrVPz3eQhHIrToXU xC3CfxLnAkFrwMPiNHnwrzPn6Zeflnft/jquv8qyfdgCjnDcznXpfYCUa6ZtBG6uFyzwZy8Y QOICI6vJy7gx1HqewsPeaFNk2fFHdXucqLnYQOTpe1XytWfQ8q4VcxmfDD0/d/ag+top1GuK MYIDVDCCA1ACAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN TW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBB T0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkCAm/CMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDgxNjAzMTAxN1owIwYJKoZIhvcNAQkEMRYEFDChyvheGnx1mlDQAtmt vK+d9VnGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCJu6AtUATf6J2ayPr3XgYTg+cpicti9rvppNAn S/rcjQMbdNGDOuiIVF5Ey3BBqUXUuoVtWM6miDYFcmth6pAxiE9vKR+KQYxxzsya+k3pRaO8 a8+fUvtHidYltnMRDGQXLqZMGvVNR5EDRNCzCkHCAXJlrwjQ6OcNFVQ4E6gdQwAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0aIqt029057 for ; Fri, 15 Aug 2003 17:36:18 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G0aI7q029056 for ietf-smime-bks; Fri, 15 Aug 2003 17:36:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0aHqt029049 for ; Fri, 15 Aug 2003 17:36:17 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7G0aED16471 for ; Fri, 15 Aug 2003 17:36:14 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJOSBT00.21N; Fri, 15 Aug 2003 17:35:53 -0700 Date: Fri, 15 Aug 2003 17:37:10 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Anders Rundgren" cc: ietf-smime@imc.org In-Reply-To: <00ec01c362fb$ebeff1f0$0500a8c0@arport> Message-ID: <3F3D7CB6.9020407@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> <00ec01c362fb$ebeff1f0$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Anders, Anders Rundgren wrote on 08/15/2003, 0:06: > May I add some naive thought to the table? > > That the issuer is of great importance for signatures and authentication > purposes is undoubtedly true. > > But I cannot really say that I see the same need for TPP-issued > encryption > certificates. Is there even a need for encryption-certificates? It > seems sufficient > that users in their e-mail client create key-pairs and publish the public > key in the associated domain. If you trust the lookup service like XKMS > why should this not be enough? Certificates establish a permanent, traceable link between the user's identity and the public key. If I correctly understand what you propose, the XKMS service would provide a temporary link between the user's identity and the the public key. One reason this link isn't enough is revocation. If the key gets compromised at some point, how do you indicate at a later time not to trust that key anymore ? And how do you do it retroactively ? Correct me if I'm wrong, but most revocation systems today are based on CRLs rather than KRLs. The government was the only user of KRLs but even they are using CRLs now. Most software as a result primarily supports certificate-based revocation, not key-based revocation. > Well you could actually create a > self-signed > certificate in your mail client and send a signed message (using > a trusted signer cert/key) containg the generated encryption key or > cert to > encryptionregistry@yourdomain to get it automatically published. > No apparent need for CAs and associated root and path validation > for encryption certificates. It should be a policy of the repository however to decide whether or not to apply path validations for certificates it stores. Certainly one could decide not to do any validation if they so chose. However eventually, when an end user does a query, they most likely won't trust that self-signed certificate due to their trust domain configuration. So it would not be in the interest of the repository to have too lax of a policy on cert issuers. > XKMS introduces an optional trust-anchor itself but that would not > work (scale)with encryption certificates for a global Internet. So no > matter what you do, there will be lose ends on all lookup solutions. > Only the hard transfer-the-globally-recognized-TTP-certificate-out- > band will be "fully secure" and we already know that this does not > support the more dynamic scenarious we are currently discussing. It can work if there is a set of well-known accepted trusted roots. I don't think every single random root should be automatically trusted. What's missing is a way to easily replicate the trust domain - ie. let the repositories dynamically add roots once a new CA goes in business and gains acceptance. > For enterprise usage I doubt that end-to-end encryption is of much value > as lost keys create too much hassles. Most business systems are likely > to rather use HTTPS which is easier to handle than S/MIME encryption. HTTPS and S/MIME have different uses and benefits. If you sign a contract over HTTPS there is no persistent proof, whereas there is with S/MIME. The problem of lost encryption keys for enterprises is already solved with key escrow. All the necessary mechanisms are already in place today. Most businesses want to be able to access their employees' communications anyway, so there is another reason that they use key escrow for encryption keys. Signing keys are of course a different matter and should not be escrowed. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNjAwMzcxMlowIwYJKoZIhvcNAQkEMRYE FKQnHNTPAbVFtiwzKnfBJFqHMrLKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYBAqMdOofmqBct5J2Ss vE3pv50s0kFb1e05CRrmDgvCh7UYBDF7U3D/nSqa0JHfl58c73K084bPSqg23X0A/RRiqFhV H8rUMwygLu4bxvky82cHLmaDAy8UW0lMWyCyRMVHARmcU0RqdIr7l6tawhm4k2XaqxVV/qmi 1WlpqBfqAQAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FN9Lqt024899 for ; Fri, 15 Aug 2003 16:09:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FN9Lip024898 for ietf-smime-bks; Fri, 15 Aug 2003 16:09:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FN9Kqt024893 for ; Fri, 15 Aug 2003 16:09:20 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 15 Aug 2003 16:09:16 -0700 From: "Blake Ramsdell" To: "'Steve Hole'" , "'Simon Josefsson'" Cc: Subject: RE: PKI and S/MIME Date: Fri, 15 Aug 2003 16:09:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Steve Hole > Sent: Friday, August 15, 2003 9:50 AM > To: Simon Josefsson > Cc: ietf-smime@imc.org > Subject: Re: PKI and S/MIME > > On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson > wrote: > > > But this isn't an important point, and I don't see anything that can > > be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. > > Perhaps this tangental issue only distract us from the big picture. > > Agreed. I think that the provision of a simple-to-use API > would be a > huge help here. I thought I published this at one point, though it might have been internal only. I'll use a somewhat Java-ish syntax here. EncryptingInformation findInformationRequiredForEncryptingForEmailAddress( String emailAddress ); boolean isCertificateSuitableForSigningEmail( String emailAddress, X509Certificate signingCertificate, X509CertificateList otherCertificates, CRLList cRLs ); EncryptingInformation contains: 1. Any cached SMIMECapabilities 2. An X.509 certificate for encrypting OK, now we just fill in the details ;). Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIjDqt015211 for ; Fri, 15 Aug 2003 11:45:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FIjDou015210 for ietf-smime-bks; Fri, 15 Aug 2003 11:45:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIjBqt015205 for ; Fri, 15 Aug 2003 11:45:11 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FImxV10787; Fri, 15 Aug 2003 12:48:59 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 12:48:59 -0700 To: Julien Pierre Subject: Re (subtopic): certificate issuance and trust Cc: ietf-smime@imc.org In-Reply-To: <3F3C4C43.6010205@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FIjBqt015206 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I broke the reply into to parts because they really are quite separate issues. This topic deals primarily with the issuance of certificates and trust management in deployed S/MIME clients. I debated taking it offline, but I think that it is useful discussion from a usage point of view. It has little technical merit on a primarily technical forum, but it has overall import for S/MIME -- I hope :-) On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre wrote: > I think you have it backwards, cost of certification is way down on the > list of obstacles to mass deployment of S/MIME right now. Let me mention > some other important barriers : > > 1) the general public is completely unaware that certification even > exists. I think this is the #1 issue by far. > Many companies have been trying to raise awareness for PKI, but none > have succeeded in getting the masses to adopt it yet. > > 2) the value of certification is low today because there are so few > certified users, and encryption only works between certified people. > This is like being one of the first one to have a telephone. OK. Before I go on, I will state that I agree with both of these assertions on an individual basis. The issue is really how many of these things work in combination to stall or make S/MIME usage difficult. I see that we need to talk a bit about the usage models that are evolving on the Internet. There are at least two with variations: 1. Interpersonal secure mail. This is Mom exchanging secure email with Aunt Jane on the other side of the country. 2. Organizational communications. This is the business to consumer or organization to partipant communications (ie. my bank wanting to send me statements and me wanting to complain to my bank). Because I am so focused on usage model 2 these days I tend to forget about usage model 1. My apologies. Conversely, I suspect that very little thought has gone into usage model 2 as it is an entirely new thing for business to be doing on the Internet. So what? Your assertions and the priority you assign them are spot on for usage model 1. I would still add both cost and complexity of certification to this model. For Mom to sign up to get a cert is actually pretty daunting from a user interface point of view. We and our customers have done lots of user tests and it is a problem. My assertion that cost is a big deal is very applicable to usage model 2. In this case organizations want to certify their consumers for secure document receipt and (possibly) reply. Outbound is fairly easy -- just issue an encryption only cert to the user on enrollment. No trust issues and it is reasonably easy to get to the user's desktop. The problem comes when you want bidirectional communication and are therefore issuing signing certs. The cost of doing this for millions of customers is so high using the existing certification model (because of root trust requirements) that to use S/MIME becomes impractical or forces alternative solutions. There are a series of companies that provide "e-mail encryption" using proprietary formats and Javascript symetric decryptors that completely bypass S/MIME altogether. And people buy it! BIG organizations buy it. It's depressing. And when talking about S/MIME it has to be concern to this group and people who implement S/MIME clients. > (Even worse than that, without even having a directory in existence to > find out who else you could communicate with - this is the problem at > stake). Correct. This means that interpersonal secure email usage is impractical because there is no way to obtain necessary security information for an arbitrary recipient. This is the original stated problem and we all agree that it is a major, if not the major barrier. I think that we have some good concensus building on that and maybe there are some actions that we can now take to try to resolve the issue. > 3) S/MIME is too complex to use S/MIME isn't so complicated (at least our user testing doesn't indicate that). We get very few usage calls back to customer support. Certification is certainly complicated. Even the easiest of the commercial (Verisign) CA's are quite daunting to the average user. This is an implementation issue that needs some work. This accounts for better than 95% of our TOTAL service calls. Ouch! > I don't believe the first issue can be solved by any specifications or > talk in this group, but several companies will continue to work on it. > Hopefully they will succeed. The only way to solve it (I think) is to have organizations initiate certificate issuance. That is, ISP's need to offer to do this as part of their enrollment. Certificate awareness is very high in my usage model 2 because either Joe Customer wants to get e-documents from Sam Business or Sam Business wants Joe Customer to get e-documents. Either way, there is explicit communication that initiates certification (in all the various ways that can be done). So it is a question of how do we initiate certification? More importantly how do we get ISP's (or a proxy third party) to engage users in the certification process. > The first two issues are related. As more people become aware of > certification and certified, the value of being certified will increase. > I believe the cost of the certification will be much less of an issue > once people realize they are paying for a something useful. No it won't :-) Will your Mom pay to be certified? I know for a fact mine won't because I tried to get her to get a Verisign cert and when she found out it was $20, that terminated that conversation quickly :-) It will improve yes, but you won't get anywhere near universal uptake. ... some stuff skipped ... > Yes, vendors have to ship a certain set of roots. We can't just > automagically trust every self-signed root there is. We ship with about > a hundred roots already though. It is true Netscape has charged in the > past for including it. Microsoft requests that your root goes through an > independent certification process. Either way, the process costs a lot > of money. > > You aren't limited to using the roots that are shipped. > You can add your own roots if you want to trust it. All it takes is a > couple of clicks in the client application. > If you don't like your users having to click, you can pull a Mozilla > source tree, and add your very own root certificates and mark them > trusted if you like. It is a simple process and I'll be happy to show > anyone how to do it, as I have been the one checking in the roots to the > official tree. Any ISP could do it. Any CA could do it. Any corporation > could do that. You are right. I knew when I was writing that part that I was going to get into trouble :-). First of all, this problem really is a usage model 2 issue. An organization wants to certify a very large number of users. It really doesn't apply to usage model 1, for which most of the existing S/MIME clients are targeted. > All the client vendors do is provide a default trust domain, which is a > list of well-known root certificates with trust settings. What do you > want them to do ? Ship with no roots at all ? Automatically trust every > single self-signed root under the sun ? > > The default trust domain that ships with client software is not static. > Like any other software setting, it can be configured. Any user is free > to add another root and mark it trusted. > If the trust domain was static then you would have a point, but as I see > it, you miss the point. All of the above is correct. I'm saying two things: 1. It would be very nice if there is some way that the trust domain could be removed from client configuration to a centralized service. This is simply good engineering and allows for dynamic control over what is trusted and what is not. 2. Modifying desktop settings to support security policy and certificate issuance is a non-starter for usage model 2. It's the old adage -- people want security but they don't want to have to do anything to get it. I'll give you an example that might help. If My Huge Bank wanted to issue certificates to their users to establish a secure email community of trust, then they have two choices: acquire certificates from one of the CA's that is already in the "trusted root" category or try to issue self-signed certificates and become a trusted root. Cost is a big barrier in the first option. Deployment complexity (and some cost) is a barrier for option 2. Because a new root certificate has to be downloaded to every desktop you've got a deployment latency problem. Because it costs (in some non-insubstantial set of S/MIME implementations) to get a registered root certificate, the costs of this are not insubstantial either. If the cost that an organization like My Huge Bank will bear to roll out a new service is $1M - $500K you can see that the cost of deployment for an S/MIME solution is severly compromised by the costs of certification. Companies and solutions like Tumbleweed exist that provide alternatives to S/MIME simply because of this fact. If we could arrange things to avoid the cost and provide zero deployment latency, that would greatly enhance usage model 2 scenarios and make life difficult for non-standard email security solutions. > The price figure you cite is absurdly low. Do you really, seriously > think $250,000 to enable secure services matters much to a company with > 25 million customers ? Certainly it wouldn't matter much to a bank, > especially since it would probably reduce certain mailing costs. I'd > guess that even one bulk USPS communication is going to cost more than 1 > cent per recipient. I only know one ISP with 25 million customers or > more, and I happen to work for it, but I'm not at liberty to comment > further on the costs. First of all, $0.01 per cert for 25M customers is $2.5M annually. You need to go have a look at who I work for :-) The example that I give above is by far the rule. The costs that even a large bank with 25M consumers will bear for *any* Internet application is quite low at this point. Most of that has to do with the series of disappointing Internet applications and middleware that were invested in over the years has seriously damaged their trust in real return on investment in Internet applications. The *only* reason that we can sell secure document delivery systems to our customers with S/MIME based security is that we do one-way encryption only solutions which obviates the need for signing certs and trust. Even with that, many of our customers find the simple certification issuance that we do (two dialogs and a single page turn) too much and want to use password based encryption instead. We have been forced to write an S/MIME viewer application that supports the S/MIME shared secret profile because very few of the shipping clients support it yet. > The bottom line is, running a CA is a service, and it costs money, > probably far, far more than $0.01 per cert per year. Whether an ISP runs > it itself or outsources it, the service is going to cost some money > somewhere > > Anyway, I think we are getting quite off-topic here. If people want to > run a loss-leader cert service they are welcome to do so, just as > Thawte/Verisign does. I don't know how much relevance this has to the > mailing list. Or do you want to codify the prices of certificates into > the RFCs ? Agreed, we can take the remainder of this conversation off line. However, it is important to note that the cost of running a your own CA today is largely a matter of the licensing costs of running the CA software. There are operational costs, but those costs can and should be part of the cost of operating the application the uses S/MIME. We do NOT charge for certificate issuance in our product. We charge for documents delivered. There is a direct and easy comparison for any usage model 2 document issuer to compare the cost of paper mail to secure email. If we had the ability to "Register" a self certifying organization root certificate in one place (not one for every desktop client) that would be a huge step forward. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FIF3qt013867 for ; Fri, 15 Aug 2003 11:15:03 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FIF3Xf013866 for ietf-smime-bks; Fri, 15 Aug 2003 11:15:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7FIF2qt013861 for ; Fri, 15 Aug 2003 11:15:02 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from pcp04426435pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.140.179 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 15 Aug 2003 18:15:04 -0000 From: "Bonatti, Chris" To: Cc: Subject: RE: Update of CMS-X.400 Drafts Date: Fri, 15 Aug 2003 14:15:03 -0400 Organization: IECA, Inc. Message-ID: <000301c36359$26561240$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7FIF2qt013862 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Francois, This has not been discussed before on this list, but to my knowledge has there has not been a strong call for this. My view is that this is feasible, but presently outside the scope of the draft. Since this doesn't constitute a MUST in the 2633bis, I'm not sure this is significant. I do not favor slowing down the spec for this. Do others have opinions on this? Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Francois.Rousseau@CSE-CST.GC.CA Sent: Monday, August 11, 2003 13:16 To: BonattiC@ieca.com Cc: ietf-smime@imc.org Subject: RE: Update of CMS-X.400 Drafts Hi Chris, I am very sorry to not have noticed this before, but I did not see any mention of optionally supporting Compression (i.e. RFC3274) under WRAP like under MSGbis. Isn't compression something that could also be useful for X.400 content? Was this intentional? Cheers, Francois -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Saturday, August 09, 2003 11:32 AM To: ietf-smime@imc.org Subject: Update of CMS-X.400 Drafts With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FHJHqt011534 for ; Fri, 15 Aug 2003 10:19:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FHJH3Y011533 for ietf-smime-bks; Fri, 15 Aug 2003 10:19:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FHJGqt011527 for ; Fri, 15 Aug 2003 10:19:16 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id D6EED20660B for ; Fri, 15 Aug 2003 13:17:33 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19nhoP-0001oE-Oh for ietf-announce-list@asgard.ietf.org; Fri, 15 Aug 2003 12:52:25 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19nhnG-0001kd-Ph for all-ietf@asgard.ietf.org; Fri, 15 Aug 2003 12:51:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255; Fri, 15 Aug 2003 12:51:08 -0400 (EDT) Message-Id: <200308151651.MAA03255@ietf.org> 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-x400wrap-09.txt Date: Fri, 15 Aug 2003 12:51:08 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+47629_214518835125604_0543265711" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+47629_214518835125604_0543265711 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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-09.txt Pages : 11 Date : 2003-8-15 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-09.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-x400wrap-09.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. --MIMEStream=_0+47629_214518835125604_0543265711 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+254605_0977245551210_29285560305" --MIMEStream=_1+254605_0977245551210_29285560305 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-09.txt --MIMEStream=_1+254605_0977245551210_29285560305 Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> --MIMEStream=_1+254605_0977245551210_29285560305-- --MIMEStream=_0+47629_214518835125604_0543265711-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGpDqt010345 for ; Fri, 15 Aug 2003 09:51:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FGpDY1010344 for ietf-smime-bks; Fri, 15 Aug 2003 09:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGpCqt010339 for ; Fri, 15 Aug 2003 09:51:12 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255; Fri, 15 Aug 2003 12:51:08 -0400 (EDT) Message-Id: <200308151651.MAA03255@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-x400wrap-09.txt Date: Fri, 15 Aug 2003 12:51:08 -0400 Sender: owner-ietf-smime@mail.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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-09.txt Pages : 11 Date : 2003-8-15 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-09.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-x400wrap-09.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: <2003-8-15124039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124039.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGQPqt008819 for ; Fri, 15 Aug 2003 09:26:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FGQPxW008818 for ietf-smime-bks; Fri, 15 Aug 2003 09:26:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FGQOqt008813 for ; Fri, 15 Aug 2003 09:26:24 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FGUBV09721; Fri, 15 Aug 2003 10:30:11 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 10:30:11 -0700 To: Julien Pierre Subject: Re (subtopic): LDAP certificate distribution Cc: ietf-smime@imc.org In-Reply-To: <3F3C4C43.6010205@netscape.com> References: <3F3C4C43.6010205@netscape.com> <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FGQOqt008814 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre wrote: > Why ? Because you have to run a root. That is, the hierarchy has to have a top level interconnect. This quickly becomes an issue of governance. National goverments get involved the way they got involved in DNS. The difference is that the governments got involved *before* the service was running, not after the way they did with DNS. There is a long track record of attempts at establishing global X.500 whitepages services. There were several attempts that I participated in that just didn't gain traction. I think in retrospect it was primarily a cost issue again. The *business* people and organizations who had interest in participating couldn't stomach a "build it an they will come" approach when there were real costs and somewhat amorphous benefits. People just don't get why you need it and the formal delegation and governance rules made it non-trivial to set up. Note that I said "Whitepages". Regrettably, PKI information at the global level was always linked to other personal information that would aid in the search and retrieval of useful information on people. This was a goal that I happily promoted and thought "was a great idea". Wrong. What I (and many others) never thought about was the privacy concerns. Sure the system is secure and access controlled etc etc. But, the governance issues around actually making this information available on the Internet was really huge. By the time some of this was figured out, the perception had become that none of it was truly deployable. Very few commercial organizations (government doesn't count) wanted that information available and didn't believe that secure interpersonal email (the one obvious use application) needed that level of support. There were some not insubstantial technical hurdles with root management and scaling as well. Problems that probably could have been (and were for the most part) solved, but took long enough to solve that people just didn't believe. Basically, there was enough disinterest that the whole thing just stagnated. Finally, the one thing that could have driven the service -- storage of keys -- was itself a substantial cost item because of the cost of certification. While certification costs have dropped, in the beginning they were excruciating and only the richest could play. Therefore, there never was a groundswell of use that demanded that the "situation be improved". You need a Web like uptake to get the necessary infrastructure allocated and serviced. In short there was always a substantial cost. My experience with the Internet is that the only things that successfully deploy to Internet scale are things that start with the groundswell of the common user. It has to be easy and it has to be (near) free. > > There is only one choice -- DNS. I (and Steve Kille and others) have > > been flogging LDAP directories and working on LDAP/X.500 interconnects > > for > > a decade. Global X.500/LDAP isn't going to happen in our lifetime. > > Can you summarize why ? Pretty much did above :-) For what it's worth, I am NOT saying "LDAP is useless". What I'm saying is that you need to leverage the one and only global directory service the Internet is ever likely to successfully deploy to get to your LDAP (or XKMS) services. Then we avoid the governance, root and cost issues associated with global directory whitepages. > > Precisely. They must be able to do a DNS lookup for the information > > either as a direct data return or a reference to a secondary storage > > service, which absolutely could and probably should be LDAP. To > > work in practice I think that it should be possible to get a direct pull > > from the DNS so that organizations are not required to deploy an LDAP > > directory and all that goes along with it (much as that pains me). > > I think other people have pointed out that DNS itself is not suited as > the repository for the certificates. > Since the query starts with only the e-mail address, which contains a > userid and domain, I think it is appropriate to start the lookup in the > DNS. There should be a standard schema to get to the appropriate LDAP > server from the user's e-mail domain. The certificate would then be > looked up from it. The client application could also fall back to a > "default" LDAP server if the DNS query fails to find the appropriate > directory. Works for me. More LDAP servers sold then :-) > > The worst that can happen is that don't find the cert your looking for. > > Trust issues MUST be dealt with, but certificate trust chains and > > approaches are both well understood. > > > > The best that can happen is that suddenly I can go and find a cert for > > joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want > > to do that? > > Sounds good, but we have to make sure this is deployable for a lot of > people. I don't really see how it would be. > > If LDAP is used to store the certs, perhaps all a domain owner might > have to do would be do add an entry in the DNS, either with a new record > type, or even simpler for quicker deployment, a standard name, eg > pki-public-ldap . This entry could be pointed to some free public > directory if the ISP doesn't want to run it itself. I think we are in agreement. That was easy :-) As noted in other messages the practical hurdles for deployment center on management (key issuer) and client (user). Unless something is specified there is no hope of even getting to those hurdles though. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FFkRqt006125 for ; Fri, 15 Aug 2003 08:46:27 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FFkRRC006124 for ietf-smime-bks; Fri, 15 Aug 2003 08:46:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FFkMqt006102 for ; Fri, 15 Aug 2003 08:46:25 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7FFo2V09415; Fri, 15 Aug 2003 09:50:03 -0600 From: Steve Hole Date: Fri, 15 Aug 2003 09:50:02 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7FFkPqt006116 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson wrote: > But this isn't an important point, and I don't see anything that can > be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. > Perhaps this tangental issue only distract us from the big picture. Agreed. I think that the provision of a simple-to-use API would be a huge help here. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F78qqt050759 for ; Fri, 15 Aug 2003 00:08:52 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F78qu6050756 for ietf-smime-bks; Fri, 15 Aug 2003 00:08:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F78oqt050738 for ; Fri, 15 Aug 2003 00:08:51 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t12o913p74.telia.com [213.64.28.194]) by smtp4.hy.skanova.net (8.12.9/8.12.9) with SMTP id h7F77vqD029663; Fri, 15 Aug 2003 09:08:11 +0200 (CEST) Message-ID: <00ec01c362fb$ebeff1f0$0500a8c0@arport> From: "Anders Rundgren" To: "Julien Pierre" Cc: References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Subject: Re: dissemination of public encryption certificates Date: Fri, 15 Aug 2003 09:06:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: May I add some naive thought to the table? That the issuer is of great importance for signatures and authentication purposes is undoubtedly true. But I cannot really say that I see the same need for TPP-issued encryption certificates. Is there even a need for encryption-certificates? It seems sufficient that users in their e-mail client create key-pairs and publish the public key in the associated domain. If you trust the lookup service like XKMS why should this not be enough? Well you could actually create a self-signed certificate in your mail client and send a signed message (using a trusted signer cert/key) containg the generated encryption key or cert to encryptionregistry@yourdomain to get it automatically published. No apparent need for CAs and associated root and path validation for encryption certificates. XKMS introduces an optional trust-anchor itself but that would not work (scale)with encryption certificates for a global Internet. So no matter what you do, there will be lose ends on all lookup solutions. Only the hard transfer-the-globally-recognized-TTP-certificate-out- band will be "fully secure" and we already know that this does not support the more dynamic scenarious we are currently discussing. For enterprise usage I doubt that end-to-end encryption is of much value as lost keys create too much hassles. Most business systems are likely to rather use HTTPS which is easier to handle than S/MIME encryption. Anders ----- Original Message ----- From: "Steve Hole" To: "Julien Pierre" Cc: Sent: Thursday, August 14, 2003 19:30 Subject: Re: dissemination of public encryption certificates Well, for the first time in a long time my interest is up on this list :-). What a wonderful topic! General purpose use of S/MIME by the masses on the Internet. Why hasn't it happened and what can we do about it. Before you read on, be assured that it is the large scale use of S/MIME that the following diatribe is focused on. On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre wrote: > If you send an email today, you can simply sign it and include your > certificate in the signature. If you just sign all your mail, then all > you always disseminate your certificate. So in what situations does this > new MIME extension certificate lookup help ? I suppose this extension > would be shorter than a digital signature. However it would also be much > less secure. This highlights one of the key issues. It is easy enough to exchange keys simply by sending a signed message, but there are some significant barriers: 1. What if your encryption key is separate from your signing key. This is not only common but considered good security practice. How does one go about exchanging/discovering the encryption key for the new party you want to exchange mail with. 2. Timeliness of the key exchange. The problem with mutual signing exchange is that the other person has to respond to you. What if you just want to send them an encrypted load right off the start. You can't really do it. The solution is (and always has been) to do a lookup. The problem is that there is no directory to look up from. Global X.500/LDAP directories are *never* going to happen. There is only one choice -- DNS. I (and Steve Kille and others) have been flogging LDAP directories and working on LDAP/X.500 interconnects for a decade. Global X.500/LDAP isn't going to happen in our lifetime. > The case I originally asked about is : > neither party has exchanged any e-mail yet, but they know each other's > e-mail address. They want to communicate securely. How do they avoid or > bypass the initial insecure e-mail exchange ? Precisely. They must be able to do a DNS lookup for the information either as a direct data return or a reference to a secondary storage service, which absolutely could and probably should be LDAP. To work in practice I think that it should be possible to get a direct pull from the DNS so that organizations are not required to deploy an LDAP directory and all that goes along with it (much as that pains me). > > In summary I think that a certificate-independent configuration > > of e-mail clients would be more universal than "fishing" in > > domains as the user domain and issuer domain may be entirely > > disjunct. > > "Fishing" in domains as you say would be independent of e-mail client > configuration for the most part (it could just be turned on or off). Actually, I think that "fishing" is an entirely appropriate thing to do. The worst that can happen is that don't find the cert your looking for. Trust issues MUST be dealt with, but certificate trust chains and approaches are both well understood. The best that can happen is that suddenly I can go and find a cert for joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want to do that? This does lead very nicely into my second (and quite separate) issue in this area -- the "trusted ROOT certificate". Julien has provided superp leading commentary here. > You correctly point out that in most cases the user's domain and cert > issuer domain are disjoint. This is especially true of e-mail users > whose ISP isn't a CA (99.9% of them right now). Exactly. Why? Because it costs TOO MUCH. The only acceptable cost for most ISP's is zero because of the volume of users. Cost of certification is, pure and simple, the primary barrier to the general use and deployment of S/MIME on the Internet. The reason for the cost is that the mechanism for establishing root trust is determined solely by the set of ROOT certificates distributed by the client vendor -- of all things!. Thus only those organizations that can afford to pay the client vendor -- of all things! -- to be included in their "special trusted root certificate club" get to have "trust". Which means that you MUST buy certs from one of the club members. Doesn't THAT just suck. Nice business if you can get it. Yes I know about free thawte certs. I know that any root issuer must be secure and provide good protection from having roots keys compromised etc. I agree that anyone who issues certificates should be required to be secure. I understand that there is risk to the client vendor if they report trust in a cert that has been compromised at the root. Regardless, to have this power rest in the hands of the client vendor is ludicrous. Why should I trust that Microsoft can evaluate the security and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not saying they are unqualified to do so, but I'm a lot more likely to trust a self signed "Bank of America" certificate issued on it's own behalf and obtained from a reliable source, than I am a third party software vendor or CA Verisign (not that there's anything wrong with either Microsoft or Verisign :-). The issue comes down to trust brokering. I just don't think that it is working for the *general* mass consumer Internet. It clearly does work for closed communities within the Internet, but it isn't scaling. Period. If we want generalized S/MIME usage throughout the Internet we need to think of some mechanism that is: 1. Easy to deploy. The track record for the Internet stongly indicates that this means that there are freeware versions of software that will support the deployment. This includes both the key management and publication software and the usage (client) software. 2. Free. Those who "own" the vast majoritiy of the user population on the Internet are ISP's. They have almost no margin and simply cannot afford to pay for certification. Also (and more importantly IMHO) is the desired for businesses to touch their customers. These are HUGE volume relationships in which there are virtually no economically viable ways of establishing bidirectional trust. A cert price of $0.01 a year is too much if your customer population is 25 million people (banks, utilities, etc.) Why could we not have organizations issue certificates distributed via DNS, with a trust relationship provided by DNS-SEC? That is, you can trust that the DNS node your are dealing with is legitimate because they have deployed DNS-SEC (which everyone should do anyway for a host of other security reasons) and the keys that are located within the DNS hierachy are legitimate. I can then lookup certs based on mail address (duh!), where the mail domain source is trusted because of DNS-SEC. This trust relationship could be either: implicit -- the issuer domain location is trusted therefore any keys published there are trusted, explict -- the issuer provides a root signing key which is in turn signed by their DNS-SEC key. There are a number of observations that can be made about this approach: 1. The security provided by the approach is probably not as strong as the full commercial CA approach. I contend "so what". It's better than nothing and Pretty Good (pun intended). The average user doesn't need military grade security. The average bill issued by the local telephone utility doesn't need military grade security. Think of the vast number of paper documents that need only Pretty Good security and trust to be useful (292 Trillion a year in the US -- it's my business and I happen to know). All we need is some security to make that paper go away forever. 2. Some extensions to bind and a new CSP for Windows would get a large number people going in a hurry. Openssl with an HSM card and some reasonable security policy has an organization running pretty quickly. > The only solution for > these users is some sort of universal registration service. Yup. > This implies > the existence of some sort of free worldwide directory service (LDAP) > that would resolve e-mail addresses to certificates ... And clients > would need to be (automatically?) configured to do look ups in it. Well, even though I would love it if it was LDAP, it isn't going to happen. DNS is the only game in town for global directory service. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F3WYqt033372 for ; Thu, 14 Aug 2003 20:32:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F3WYYe033371 for ietf-smime-bks; Thu, 14 Aug 2003 20:32:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F3WWqu033366 for ; Thu, 14 Aug 2003 20:32:32 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3F3C4DE0.8020204@netscape.com> References: <3F3C4DE0.8020204@netscape.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 14 Aug 2003 20:33:17 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: RE: dissemination of public encryption certificates Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:05 PM -0700 8/14/03, Julien Pierre wrote: >It would be highly desirable for one protocol to be designated for the >purpose of solving these problems, as opposed to having a plethora of >different solutions and having various client programs use different >approaches, which would get us back to square one. We are already at that square. >I believe this is relevant to the SMIME mailing list, even though >the choice and design of that protocol may not affect the SMIME message >format itself, as these are major deployment issues. I'm not convinced that this WG is the best one for the discussion, inasmuch as it is not in our charter and the WG is supposed to wind down. On a related note, there may be a new WG starting up to discuss how to handle certificate management in IPsec (the IPsec WG has failed worse than S/MIME on certificate issues). It might be interesting to have a single WG that covers both issues. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F34Eqt032388 for ; Thu, 14 Aug 2003 20:04:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F34Duo032387 for ietf-smime-bks; Thu, 14 Aug 2003 20:04:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F34Dqt032381 for ; Thu, 14 Aug 2003 20:04:13 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7F343309055 for ; Thu, 14 Aug 2003 20:04:03 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJN4ID00.F07; Thu, 14 Aug 2003 20:03:49 -0700 Date: Thu, 14 Aug 2003 20:05:04 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Blake Ramsdell" cc: "'Hallam-Baker Phillip'" , helm@fionn.es.net, "'Steve Hole'" , ietf-smime@imc.org In-Reply-To: Message-ID: <3F3C4DE0.8020204@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Blake Ramsdell wrote on 08/14/2003, 14:42: > > Well, I'm not sure I agree. There are two major questions that > constantly need answers in the mind of an S/MIME client. These are > pretty close to what Michael said in his message: > > 1. Given a particular email address, give me That Which Is Necessary and > Sufficient to send encrypted mail to that email address. > > 2. Given a particular certificate, is it suitable for signing mail that > came from a particular email address. Michael said "what is it good > for", which I think is too broad a question. > > If we're considering protocols that attempt to answer these types of > questions, those are the two questions that need to be answered by that > protocol (for interpersonal messaging with S/MIME, that is). Yes. I believe this is relevant to the SMIME mailing list, even though the choice and design of that protocol may not affect the SMIME message format itself, as these are major deployment issues. It would be highly desirable for one protocol to be designated for the purpose of solving these problems, as opposed to having a plethora of different solutions and having various client programs use different approaches, which would get us back to square one. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNTAzMDUwNlowIwYJKoZIhvcNAQkEMRYE FNLfVqSIYvOXQWJouiaVdgjTDW4/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYABpeMw5Kbek/cyhpHH ONWJ58y8g/GsPBftUDy573ORV96K6eRf8LLqLYu/jQhAt9AOzz73nb+VI2ao+LEorMV1+o9d 0FOEyoBnh+7E6DGpVgWvOuWgYNwh0HcKGAu3wcan2A0p8TwgmbtOv6jMU5cThPXE/VNCAERd siq3dst7pQAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F2vMqt032207 for ; Thu, 14 Aug 2003 19:57:22 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F2vME1032206 for ietf-smime-bks; Thu, 14 Aug 2003 19:57:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F2vHqt032197 for ; Thu, 14 Aug 2003 19:57:17 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7F2v8308594 for ; Thu, 14 Aug 2003 19:57:08 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJN46U02.Z06; Thu, 14 Aug 2003 19:56:54 -0700 Date: Thu, 14 Aug 2003 19:58:11 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Steve Hole" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3C4C43.6010205@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, Steve Hole wrote on 08/14/2003, 10:30: > Well, for the first time in a long time my interest is up on this > list :-). What a wonderful topic! General purpose use of > S/MIME by the masses on the Internet. Why hasn't it happened and what > can we do about it. Yes, that's exactly the problem that prompted my questions. And it's coming soon to an AOL mail program near you ... Some of you may have heard of this new "AOL Communicator" mail program that was released in the last week to the masses. In fact this program already includes S/MIME support. Hopefully, solving this problem doesn't necessitate new specs and completely new services and products, but only minor tweaks and clarifications of how to use the existing technology. > On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre > wrote: > > This highlights one of the key issues. It is easy enough to exchange > keys simply by sending a signed message, but there are some significant > barriers: > 1. What if your encryption key is separate from your signing key. This > is not only common but considered good security practice. How does one > go about exchanging/discovering the encryption key for the new party you > want to exchange mail with. This is supported today in Mozilla mail, Netscape 7.x mail, and AOL Communicator. In fact, in our internal PKI deployment we use different keys for encryption and signing. This results in the issuance of two different certificates, one for signing and another for encryption. The digital signature can be configured to include a different certificate for encryption. Look at my signature in this message and see if you get confused : I signed it with my corporate certificate, but I included a recipient Thawte encryption certificate. > 2. Timeliness of the key exchange. The problem with mutual signing > exchange is that the other person has to respond to you. What if you > just > want to send them an encrypted load right off the start. You can't > really do it. That's right, and it's the whole problem I have been asking about. Exchanging unencrypted messages first, in my opinion, is not a solution. > The solution is (and always has been) to do a lookup. The problem is > that > there is no directory to look up from. Global X.500/LDAP directories > are > *never* going to happen. Why ? > There is only one choice -- DNS. I (and Steve Kille and others) have > been flogging LDAP directories and working on LDAP/X.500 interconnects > for > a decade. Global X.500/LDAP isn't going to happen in our lifetime. Can you summarize why ? > Precisely. They must be able to do a DNS lookup for the information > either as a direct data return or a reference to a secondary storage > service, which absolutely could and probably should be LDAP. To > work in practice I think that it should be possible to get a direct pull > from the DNS so that organizations are not required to deploy an LDAP > directory and all that goes along with it (much as that pains me). I think other people have pointed out that DNS itself is not suited as the repository for the certificates. Since the query starts with only the e-mail address, which contains a userid and domain, I think it is appropriate to start the lookup in the DNS. There should be a standard schema to get to the appropriate LDAP server from the user's e-mail domain. The certificate would then be looked up from it. The client application could also fall back to a "default" LDAP server if the DNS query fails to find the appropriate directory. > > "Fishing" in domains as you say would be independent of e-mail client > > configuration for the most part (it could just be turned on or off). > > Actually, I think that "fishing" is an entirely appropriate thing to do. I didn't say it wasn't, I just have reservations on how it's done (see above). > The worst that can happen is that don't find the cert your looking for. > Trust issues MUST be dealt with, but certificate trust chains and > approaches are both well understood. > > The best that can happen is that suddenly I can go and find a cert for > joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want > to do that? Sounds good, but we have to make sure this is deployable for a lot of people. I don't really see how it would be. If LDAP is used to store the certs, perhaps all a domain owner might have to do would be do add an entry in the DNS, either with a new record type, or even simpler for quicker deployment, a standard name, eg pki-public-ldap . This entry could be pointed to some free public directory if the ISP doesn't want to run it itself. > This does lead very nicely into my second (and quite separate) issue in > this area -- the "trusted ROOT certificate". Julien has provided superp > leading commentary here. > > > You correctly point out that in most cases the user's domain and cert > > issuer domain are disjoint. This is especially true of e-mail users > > whose ISP isn't a CA (99.9% of them right now). > > Exactly. Why? Because it costs TOO MUCH. The only acceptable cost > for most ISP's is zero because of the volume of users. Cost of > certification is, pure and simple, the primary barrier to the general use > and deployment of S/MIME on the Internet. I think you have it backwards, cost of certification is way down on the list of obstacles to mass deployment of S/MIME right now. Let me mention some other important barriers : 1) the general public is completely unaware that certification even exists. I think this is the #1 issue by far. Many companies have been trying to raise awareness for PKI, but none have succeeded in getting the masses to adopt it yet. 2) the value of certification is low today because there are so few certified users, and encryption only works between certified people. This is like being one of the first one to have a telephone. (Even worse than that, without even having a directory in existence to find out who else you could communicate with - this is the problem at stake). 3) S/MIME is too complex to use I don't believe the first issue can be solved by any specifications or talk in this group, but several companies will continue to work on it. Hopefully they will succeed. The first two issues are related. As more people become aware of certification and certified, the value of being certified will increase. I believe the cost of the certification will be much less of an issue once people realize they are paying for a something useful. IMO, the certificate dissemination issue remains a major obstacle. Even if lots of people were certified today, it would still be very hard to know who they are and communicate with them. The complexity of S/MIME usability is also something the group has impact on. The specifications heavily impact the implementation and usability of S/MIME client software. > The reason for the cost is that the mechanism for establishing root trust > is determined solely by the set of ROOT certificates distributed by the > client vendor -- of all things!. Thus only those organizations that can > afford to pay the client vendor -- of all things! -- to be included in > their "special trusted root certificate club" get to have "trust". > Which > means that you MUST buy certs from one of the club members. Doesn't THAT > just suck. Nice business if you can get it. Yes, vendors have to ship a certain set of roots. We can't just automagically trust every self-signed root there is. We ship with about a hundred roots already though. It is true Netscape has charged in the past for including it. Microsoft requests that your root goes through an independent certification process. Either way, the process costs a lot of money. You aren't limited to using the roots that are shipped. You can add your own roots if you want to trust it. All it takes is a couple of clicks in the client application. If you don't like your users having to click, you can pull a Mozilla source tree, and add your very own root certificates and mark them trusted if you like. It is a simple process and I'll be happy to show anyone how to do it, as I have been the one checking in the roots to the official tree. Any ISP could do it. Any CA could do it. Any corporation could do that. > Regardless, to have this power rest in the hands of the client vendor is > ludicrous. Why should I trust that Microsoft can evaluate the security > and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not > saying they are unqualified to do so, but I'm a lot more likely to > trust a > self signed "Bank of America" certificate issued on it's own behalf and > obtained from a reliable source, than I am a third party software vendor > or CA Verisign (not that there's anything wrong with either Microsoft or > Verisign :-). All the client vendors do is provide a default trust domain, which is a list of well-known root certificates with trust settings. What do you want them to do ? Ship with no roots at all ? Automatically trust every single self-signed root under the sun ? The default trust domain that ships with client software is not static. Like any other software setting, it can be configured. Any user is free to add another root and mark it trusted. If the trust domain was static then you would have a point, but as I see it, you miss the point. > Period. If we want generalized S/MIME usage throughout the Internet we > need to think of some mechanism that is: > > 1. Easy to deploy. The track record for the Internet stongly indicates > that this means that there are freeware versions of software that will > support the deployment. This includes both the key management and > publication software and the usage (client) software. At least we agree it needs to be easy. > 2. Free. Those who "own" the vast majoritiy of the user population on > the Internet are ISP's. They have almost no margin and simply cannot > afford to pay for certification. Also (and more importantly IMHO) is the > desired for businesses to touch their customers. These are HUGE volume > relationships in which there are virtually no economically viable ways of > establishing bidirectional trust. A cert price of $0.01 a year is too > much if your customer population is 25 million people (banks, utilities, > etc.) The price figure you cite is absurdly low. Do you really, seriously think $250,000 to enable secure services matters much to a company with 25 million customers ? Certainly it wouldn't matter much to a bank, especially since it would probably reduce certain mailing costs. I'd guess that even one bulk USPS communication is going to cost more than 1 cent per recipient. I only know one ISP with 25 million customers or more, and I happen to work for it, but I'm not at liberty to comment further on the costs. The bottom line is, running a CA is a service, and it costs money, probably far, far more than $0.01 per cert per year. Whether an ISP runs it itself or outsources it, the service is going to cost some money somewhere Anyway, I think we are getting quite off-topic here. If people want to run a loss-leader cert service they are welcome to do so, just as Thawte/Verisign does. I don't know how much relevance this has to the mailing list. Or do you want to codify the prices of certificates into the RFCs ? > I can then lookup certs based on mail address (duh!), where the mail > domain source is trusted because of DNS-SEC. This trust relationship > could be either: > > implicit -- the issuer domain location is trusted therefore any keys > published there are trusted, > > explict -- the issuer provides a root signing key which is in turn signed > by their DNS-SEC key. What you are proposing is a new policy to automatically trust the certificate because of the security of the channel it traveled through. But there has to be some prior trust somehow for the channel itself. I'm not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so there would have to be prior trust on the DNS server certificate too. All in all, I think the implicit trust is very dangerous. It is one thing to accept information through that channel while it is open, but to continue to use it after it is closed, by automatically trusting the certificate that was transferred, is another. You may argue that it is better than nothing, however, a false sense of security may be worse than knowledge of the lack of security. > Well, even though I would love it if it was LDAP, it isn't going to > happen. DNS is the only game in town for global directory service. I don't see why the lookup has to be a 1-part lookup. It could - and probably should, given the size of the problem - take more than one step. -- I am the dog in dogfood Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENfQqt025491 for ; Thu, 14 Aug 2003 16:41:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENfQUl025490 for ietf-smime-bks; Thu, 14 Aug 2003 16:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENfNqt025484 for ; Thu, 14 Aug 2003 16:41:25 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7ENfMdk021563 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 15 Aug 2003 01:41:22 +0200 To: "Blake Ramsdell" Cc: "'Steve Hole'" , Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030814:blake@brutesquadlabs.com:d3bfd22292ed378d X-Hashcash: 0:030814:blake@brutesquadlabs.com:d3bfd22292ed378d X-Payment: hashcash 1.2 0:030814:steve.hole@messagingdirect.com:2b39444c2479cd42 X-Hashcash: 0:030814:steve.hole@messagingdirect.com:2b39444c2479cd42 X-Payment: hashcash 1.2 0:030814:ietf-smime@imc.org:b1cca659819c8658 X-Hashcash: 0:030814:ietf-smime@imc.org:b1cca659819c8658 Date: Fri, 15 Aug 2003 01:41:22 +0200 In-Reply-To: (Blake Ramsdell's message of "Thu, 14 Aug 2003 15:40:51 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > Well, I'm not sure I agree with you here. End user SMTP/POP3/IMAP mail > clients today don't implement lots of DNS operations -- they just say > "all mail goes to this SMTP server" which is a simple gethostbyname > style call. Specifically, they don't deal with MX records. It has > actually been pointed out in other forums (and I've had experience with > this myself) that Windows is particularly ornery to work with for > arbitrary DNS record types that aren't supported through native APIs (I > had to write my own DNS client code to handle MX records back in the > day, and Peter Gutmann told me he got slapped around pretty good trying > to work with SRV records). Steve Hole writes: >> Even here there is an advantage for DNS: mail clients already >> implement DNS. There is no need to open ports in firewalls etc for >> LDAP or XKMS. There is no need to implement new client code in the >> mail client. > > That is, regrettably, not accurate. Existing clients do very little but > hostname to address translation and service port location. I would be > very surprised if they did anything but gethostbyname and getservbyname > calls (or the platform API equivalent). It would be an addition to get > them to query and retrieve records directly. It is clear that I have been spoiled by working with free software mail clients in the Unix world, which often do implement this. Even when they don't, a res_query() is never far away. Thanks for sharing experiences from other environments. Still, I believe part of my argument still holds. Even if your mail clients only use gethostbyname(), that still means the DNS infrastructure is available on the client machine. It hasn't been blocked by firewalls etc. This simplifies deployment. But this isn't an important point, and I don't see anything that can be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here. Perhaps this tangental issue only distract us from the big picture. Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMocqt023008 for ; Thu, 14 Aug 2003 15:50:38 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMocjQ023007 for ietf-smime-bks; Thu, 14 Aug 2003 15:50:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMobqt023002 for ; Thu, 14 Aug 2003 15:50:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EMsLV03154; Thu, 14 Aug 2003 16:54:21 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 16:54:21 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) 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 above.proper.com id h7EMobqt023003 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Aug 2003 00:28:48 +0200 Simon Josefsson wrote: > Since mail clients cannot find certificates for arbitrary users today, > I believe clients must be modified regardless of the solution chosen. Yes. > Even here there is an advantage for DNS: mail clients already > implement DNS. There is no need to open ports in firewalls etc for > LDAP or XKMS. There is no need to implement new client code in the > mail client. That is, regrettably, not accurate. Existing clients do very little but hostname to address translation and service port location. I would be very surprised if they did anything but gethostbyname and getservbyname calls (or the platform API equivalent). It would be an addition to get them to query and retrieve records directly. Of course, this could be greatly aided by a freeware implementation on top of bind that provided a nice simple "give me a cert for this email address". It could do any of the approaches (direct cert from DNS, SRV to LDAP server followed by LDAP lookup, SRV to xkms server followed by xkms lookup). That would aid client developers and abstract things nicely but still wouldn't guarantee uptake. Whatever is done here, we have to convince Microsoft that it is a good thing to do and not very hard. I saw a notice today that Microsoft has officially terminated extension of Outlook Express. They want you to use Outlook instead. That means that S/MIME support in Express is more or less frozen ... I guess. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMkvqt022849 for ; Thu, 14 Aug 2003 15:46:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMkvHh022848 for ietf-smime-bks; Thu, 14 Aug 2003 15:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMkuqt022841 for ; Thu, 14 Aug 2003 15:46:56 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7EMkk312991 for ; Thu, 14 Aug 2003 15:46:46 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJMSLK00.O21; Thu, 14 Aug 2003 15:46:32 -0700 Date: Thu, 14 Aug 2003 15:47:41 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Hallam-Baker Phillip" cc: "'Steve Hole'" , ietf-smime@imc.org In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> Message-ID: <3F3C118D.3090904@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Philip, Hallam-Baker, Phillip wrote on 08/14/2003, 10:30: > > 1) Signature > Signature is only possible by changingthe message format. > Unfortunately there are still a lot of people out there with broken, non > S/MIME capable email clients. Probably more of those than have broken > email > servers. Of course at this point it is difficult to do anything about > this. I don't think there is any way around that problem, the client simply must have at least basic MIME support to support S/MIME signed messages. Unfortunately, there are many e-mail clients that cannot be supported, eg. the very basic e-mail "clients" included in some devices such as older cell phones. The best that we can do is ensure that new client software going forward has the proper MIME & S/MIME support. > 2) Encryption > Encryption is a big problem for end users, it is simply not > transparent. We need to link PKI to the DNS in some way, the SRV service > looks the best choice. LDAP is not going to be the answer here, even > if you > find the right LDAP server the schema issues still have to be solved. > Sure > LDAP could address the problem - but only to the extent a Turing machine > could and only with changes to make LDAP aware of PKI concepts like trust > paths. I think you are overly pessimistic here about the ability of LDAP to solve the problem. I agree with you however that a proper schema needs to be in place, and that is certainly a problem that hasn't been solved. > 3) The end to end obsession > One of the major reasons the IETF has failled in the security > space > is that the end to end principle alone does not address security issues. > Perimeter security is a major concern for enterprises. > > As I have been digging into this issue I have discovered that > 'end-to-end security' is actually a shiboleth. Go look at the RFCs with > security architecture design discussions and you will not find it. Clark > never applied it to security either in the naive form that has become the > received version. > > What we need to do is to build specs that address multi-layer > security concerns. It should not be necessary for everyone to have a > certificate just to be able to do security. It should be possible to sign > outgoing messages at either the end user level OR the domain name > level - I > only care that an email came from Merril Lynch, not that it came from > Freddy > Bloggs in accounts. S/MIME signing can be implemented transparently in the way you want as well. Merryl Lynch could have a certificate with regular expressions in it, matching all of its employees. The internal Merryl SMTP e-mail server, perhaps setup with SSL and some basic authentication of employees, could automatically sign each outgoing e-mail message with that certificate. This really is not end-to-end at all but I believe it can work today. You just have to be a little creative. > > The solution is (and always has been) to do a lookup. The > > problem is that > > there is no directory to look up from. Global X.500/LDAP > > directories are > > *never* going to happen. > > Amen brother, Amen. I find it really ironic that I can lookup phone numbers for anyone listed in the united states, knowing such sensitive information as their name and physical address, through a free service like www.switchboard.com, but I can't look-up their e-mail certificate knowing their e-mail address ? I'm sure there is lots of politics involved, but surely the logistics of running this service shouldn't be so much of a problem ? -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJhTCC AokwggFxoAMCAQICAgGNMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMwODExMjIxNTU1WhcNMDQwMjA3 MjIxNTU1WjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArmqJ6zyr9HHqYt67lemo42sttHe23nQyW5ljy2IK9+/M61CaaBo92CDgDwuwy/tQ 9ed0MOUhNtCGXbTSPGJj60iGO6ccnNsxR+uYt2ba5YWPjX4RwprQHxs8aKzgInMkehN+de7k 8V3BLdl3JPEmhaYUwMHiAjFVXI86Tnb8Qb8CAwEAAaNIMEYwDgYDVR0PAQH/BAQDAgXgMDQG A1UdEQQtMCuBFGpwaWVycmVAbmV0c2NhcGUuY29tgRNqcGllcnJlMDI2NEBhb2wuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAd6L4ucs7332FiIIk9fNuDlP8S5p1BJg5EceFq80g6Vy3RsE0i 6GuNkzIreLgrc8UwIBTtVpOyigbeARypdvF4a5F0JeDhZxONyePXmnhBIB4r543kacFR3amp nEuseoVbNWIqqjPXCaaAxQs5jHuffiAdk7lAVuE6Qrw294Ea0l0ay8oPw1DxM5qb1izF+Qyz 3S2C0Fxjma9OxnOyVcce/2e0ON8ATHB8WUfQF+pTvUnDz8N1QjL7EWJPbQPPPtG+tN/e0W5J AhqXeqh5GjFyjb1xuQHEWhFbH3NwaI54BBlu8/jeKlr3de4mzRSeX5mxSpulFcgaLx2gmBx6 O5fiMIIDVzCCAsCgAwIBAgIDCkEyMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDMwNjMwMjEyNDAwWhcNMDQwNjI5MjEyNDAw WjCBgjEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxIzAhBgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMSEwHwYJKoZI hvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDKJ8pwwqVNgYnTqW0MZBRzCqda/Qj4Z6Ck9WW7FHYy9FO6daiDuThmWYOgVEilkc6W bELcr2ol1rzvqVSSic010OBLzuobJYjHKWvMs0V+JkErNzHaK9KIuTP0ZeKE9Au2/nP+yVIQ Zg09p+EdpZybTWguvLA1uFjjNv2oCCu7e/D7hkVEKo0TXCBmhkAbGAY2I7iNZRI3cc2qT1kZ PIL4B2lPOaazxNcwDr09RmDIrpbAzDOxYc+fHTTyGZWkDMfJhxfRkcoKgX+Hk9I4em0IozNn Qg7P2AEXeeA1nFcSgSyV7Riee7sjn8Jxg7c2YGgft9awXB+XVxuXy/WghfaVAgMBAAGjRTBD MDMGA1UdEQQsMCqBFGpwaWVycmVAbmV0c2NhcGUuY29tgRJtYWRicmFpbkByYXdidy5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC5NUzwdD+Fwus3Ou0Kb/i25FdfHF/o dBbinG7Q+iOvj1qWgrsxfdlVMcamdGUy7Eo3IeCOHtoAUzroaBpG2JyO5gRA4A8LPRUBHbme RXzs40oPwJWj//9wvtfLlPwH13Q1BWjTN0rgaM9FpsiLfCg0XV9u/NldTCE1EMmHkxpKhTCC A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1 KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es 5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS OC8GsuIxggLyMIIC7gIBATA5MDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYx EDAOBgNVBAMTB0FPTCBLRVkCAgGNMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDIyNDc0OVowIwYJKoZIhvcNAQkEMRYE FAP/f04vtimqF7JmaBgN9kU8pS5+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGr BgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCkEyMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEgYCXW+NRoCDfxZ61/hGe ej9TN0DYr/VcOQM0ofklI6ZOc1UD2f59T/3OpCUSn2j1Up/n3WfcJH7+daqvowr9hHyWkaxK awc8fbPw1P51G8+iL+FNp8hjpf23s9HTEQdeGzdbJsCNC/stUE821qZ0gVQd6rH2leC/jw46 YpuS9F9EWAAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMetqt022649 for ; Thu, 14 Aug 2003 15:40:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMetYU022648 for ietf-smime-bks; Thu, 14 Aug 2003 15:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMesqt022640 for ; Thu, 14 Aug 2003 15:40:54 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 15:40:51 -0700 From: "Blake Ramsdell" To: "'Simon Josefsson'" , "'Steve Hole'" Cc: Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 15:40:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Simon Josefsson [mailto:jas@extundo.com] > Sent: Thursday, August 14, 2003 3:29 PM > To: Steve Hole > Cc: Blake Ramsdell; ietf-smime@imc.org > Subject: Re: PKI and S/MIME > > Note that distributing certificate DNS does not depend on DNSSEC. > Thus the argument that DNSSEC may or may not be deployable is not > relevant to distributing certificate via DNS. I think that the intent is to point out that in order to get an implementation of the CERT record, you usually get that in conjunction with a DNSSEC implementation. This may be too sweeping a generalization, however. > Even here there is an advantage for DNS: mail clients already > implement DNS. There is no need to open ports in firewalls etc for > LDAP or XKMS. There is no need to implement new client code in the > mail client. Instead modify the existing code to query for a CERT > record where it now queries for MX and A records. Yes, I know this > doesn't apply in all situations, such as corporate mode Outlook and > Exchange, which doesn't use Internet protocols to send and receive > mail. But we are here to find a solution for applications that uses > IETF standards, not Microsoft implementations, aren't we? Well, I'm not sure I agree with you here. End user SMTP/POP3/IMAP mail clients today don't implement lots of DNS operations -- they just say "all mail goes to this SMTP server" which is a simple gethostbyname style call. Specifically, they don't deal with MX records. It has actually been pointed out in other forums (and I've had experience with this myself) that Windows is particularly ornery to work with for arbitrary DNS record types that aren't supported through native APIs (I had to write my own DNS client code to handle MX records back in the day, and Peter Gutmann told me he got slapped around pretty good trying to work with SRV records). Now, this situation might have changed, but I want to point out that the DNS operations done by mail clients today are nowhere near the same as would be required to handle CERT records. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMSqqt022092 for ; Thu, 14 Aug 2003 15:28:52 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMSqxh022091 for ietf-smime-bks; Thu, 14 Aug 2003 15:28:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMSoqt022082 for ; Thu, 14 Aug 2003 15:28:51 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7EMSmdj020596; Fri, 15 Aug 2003 00:28:48 +0200 To: Steve Hole Cc: Blake Ramsdell , ietf-smime@imc.org Subject: Re: PKI and S/MIME References: <006901c361be$9f4ba080$0500a8c0@arport> From: Simon Josefsson X-Payment: hashcash 1.2 0:030814:steve.hole@messagingdirect.com:0875e397ce7250b9 X-Hashcash: 0:030814:steve.hole@messagingdirect.com:0875e397ce7250b9 X-Payment: hashcash 1.2 0:030814:blake@brutesquadlabs.com:3c2a293ee5df2ff0 X-Hashcash: 0:030814:blake@brutesquadlabs.com:3c2a293ee5df2ff0 X-Payment: hashcash 1.2 0:030814:ietf-smime@imc.org:4f23e4d550f9f65d X-Hashcash: 0:030814:ietf-smime@imc.org:4f23e4d550f9f65d Date: Fri, 15 Aug 2003 00:28:48 +0200 In-Reply-To: (Steve Hole's message of "Thu, 14 Aug 2003 10:42:02 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole writes: > On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell > wrote: > >> A better question for the DNS distribution of certificates is whether or >> not this smells like it would be the most likely thing to get deployed. >> My understanding is that you would need DNS servers that supported the >> particular record types required for this functionality, as well as >> administrative tools to upgrade those records that are different than >> typical DNS administration tools. To me, that doesn't smell as good. > > Actually, I think that there are two barriers: > > 1. Deployment of DNS-SEC. People have to go out of their way to do it > right now. It takes some work both to deploy the right software and to > get the relationship set up with the domain registration service. Not > all services offer it. Note that distributing certificate DNS does not depend on DNSSEC. Thus the argument that DNSSEC may or may not be deployable is not relevant to distributing certificate via DNS. However, should DNSSEC (or some close approximation to it) happen, it would make certificates distributed via DNS become integrity protected and authenticated via the DNSSEC trust chain. LDAP or XKMS using SRV records does not get the same benefit. > 2. Client support. Basically this means that Outlook, Outlook Express, > Netscape (and down the list) of clients have to support it. It means a > CSP for the Windows twins and a module in the new Netscape/Mozilla > security API. Since mail clients cannot find certificates for arbitrary users today, I believe clients must be modified regardless of the solution chosen. Even here there is an advantage for DNS: mail clients already implement DNS. There is no need to open ports in firewalls etc for LDAP or XKMS. There is no need to implement new client code in the mail client. Instead modify the existing code to query for a CERT record where it now queries for MX and A records. Yes, I know this doesn't apply in all situations, such as corporate mode Outlook and Exchange, which doesn't use Internet protocols to send and receive mail. But we are here to find a solution for applications that uses IETF standards, not Microsoft implementations, aren't we? Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELgsqt020520 for ; Thu, 14 Aug 2003 14:42:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ELgsIU020519 for ietf-smime-bks; Thu, 14 Aug 2003 14:42:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELgrqt020513 for ; Thu, 14 Aug 2003 14:42:53 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 14:42:49 -0700 From: "Blake Ramsdell" To: "'Hallam-Baker, Phillip'" , Cc: "'Steve Hole'" , "'Julien Pierre'" , Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 14:42:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113026@mou1wnexm02.verisign.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > Hallam-Baker, Phillip > Sent: Thursday, August 14, 2003 11:17 AM > To: 'helm@fionn.es.net'; Hallam-Baker, Phillip > Cc: 'Steve Hole'; Julien Pierre; ietf-smime@imc.org > Subject: RE: dissemination of public encryption certificates > > XKMS does not answer that question because I can't think of a > situation > where is would be of interest. The certificate is simply a > data object that > is created to establish the trustworthiness of a key. > Applications don't ask > 'what is this good for?', they ask 'how do I do this task?'. Well, I'm not sure I agree. There are two major questions that constantly need answers in the mind of an S/MIME client. These are pretty close to what Michael said in his message: 1. Given a particular email address, give me That Which Is Necessary and Sufficient to send encrypted mail to that email address. 2. Given a particular certificate, is it suitable for signing mail that came from a particular email address. Michael said "what is it good for", which I think is too broad a question. If we're considering protocols that attempt to answer these types of questions, those are the two questions that need to be answered by that protocol (for interpersonal messaging with S/MIME, that is). Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELP9qt020042 for ; Thu, 14 Aug 2003 14:25:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ELP9ZL020041 for ietf-smime-bks; Thu, 14 Aug 2003 14:25:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELP8qt020033 for ; Thu, 14 Aug 2003 14:25:08 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 14 Aug 2003 14:25:04 -0700 From: "Blake Ramsdell" To: "'Steve Hole'" Cc: Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 14:25:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Steve Hole [mailto:steve.hole@messagingdirect.com] > Sent: Thursday, August 14, 2003 10:42 AM > To: Blake Ramsdell > Cc: ietf-smime@imc.org > Subject: RE: PKI and S/MIME > > 2. Client support. Basically this means that Outlook, > Outlook Express, > Netscape (and down the list) of clients have to support it. > It means a > CSP for the Windows twins and a module in the new Netscape/Mozilla > security API. > > Of the two, the second is the hardest. Policy, usage and > deployment of > S/MIME and PKI is very much shaped by the implementation of > the clients. > Any changes have to propogate through the clients to be useful. There is no miracle that I can see that wouldn't require modifying the clients, so we're already signed up for this regardless of what direction we might go in, I think. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIGoqt012187 for ; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EIGoxA012186 for ietf-smime-bks; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EIGnqt012181 for ; Thu, 14 Aug 2003 11:16:49 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7EIGoOQ025768; Thu, 14 Aug 2003 11:16:50 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 11:16:50 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113026@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'helm@fionn.es.net'" , "Hallam-Baker, Phillip" Cc: "'Steve Hole'" , Julien Pierre , ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 11:16:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Leaving aside who supports what and why, don't understand the > implied conflict between xkms and scvp. They seem to do two > different things -- I want to find a cert for helm@fionn.es.net > to send email to that entity; I have a cert from helm@fionn.es.net -- > what is it good for? I didn't think SCVP would help much with > the first, and I clearly don't see what XKMS would do with the > second question. Would like a better understanding of this. Thats quite a good description of SCVP. XKMS does not answer that question because I can't think of a situation where is would be of interest. The certificate is simply a data object that is created to establish the trustworthiness of a key. Applications don't ask 'what is this good for?', they ask 'how do I do this task?'. Phill Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EI1wqt011632 for ; Thu, 14 Aug 2003 11:01:58 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EI1wiT011631 for ietf-smime-bks; Thu, 14 Aug 2003 11:01:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EI1uqt011626 for ; Thu, 14 Aug 2003 11:01:57 -0700 (PDT) (envelope-from helm@fionn.es.net) Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id LAA00732; Thu, 14 Aug 2003 11:01:53 -0700 (PDT) Message-Id: <200308141801.LAA00732@fionn.es.net> X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net To: "Hallam-Baker, Phillip" cc: "'Steve Hole'" , Julien Pierre , ietf-smime@imc.org Reply-to: helm@fionn.es.net Subject: Re: dissemination of public encryption certificates In-reply-to: Your message of "Thu, 14 Aug 2003 10:30:00 PDT." <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> Date: Thu, 14 Aug 2003 11:01:53 -0700 From: Michael Helm Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Hallam-Baker, Phillip" writes: > Again, I designed XKMS to allow enterprises to define their own trust > evaluations. One of the main considerations was how to support the Federal > Also, obtain buy-in from the principal stakeholders whose help is required > to achieve deployment. > > That is why the answer is XKMS and not SCVP. SCVP does not have the public > support of any of the major stakeholders. I spent a lot of time and effort > getting buy-in from Microsoft and RSA before we announced XKMS. I worked > with Entrust and Baltimore so that we could produce a specification that > they could also support. > > Contrast this to what the IETF mechanism achieves, OK everyone can say what > they like. But at the end of the day you do not have the support of a major > software vendor, just the individuals in the working group. Leaving aside who supports what and why, don't understand the implied conflict between xkms and scvp. They seem to do two different things -- I want to find a cert for helm@fionn.es.net to send email to that entity; I have a cert from helm@fionn.es.net -- what is it good for? I didn't think SCVP would help much with the first, and I clearly don't see what XKMS would do with the second question. Would like a better understanding of this. Thanks, ==mwh Michael Helm ESnet Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHWgqt009086 for ; Thu, 14 Aug 2003 10:32:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHWggu009085 for ietf-smime-bks; Thu, 14 Aug 2003 10:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHWfqt009078 for ; Thu, 14 Aug 2003 10:32:41 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EHWWil011402; Thu, 14 Aug 2003 10:32:32 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 10:32:32 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113022@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steve Hole'" , "Hallam-Baker, Phillip" Cc: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson , ietf-smime@imc.org, "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 10:32:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Fair enough. Then you better figure out how, exactly, you > are going to > deploy your new protocol for use with S/MIME. Specifically, > you must do > what Blake suggests and write a profile for use. At the moment I am just recovering from getting the XKMS spec itself through last call. I also have to get the WS-Security profiles for X.509 and Kerberos completed. After that I have to stop spam on the Internet completely. That takes us up to the end of September at which point I will be able to get back to the S/MIME issue. Phill Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHU0qt008732 for ; Thu, 14 Aug 2003 10:30:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHU0JS008731 for ietf-smime-bks; Thu, 14 Aug 2003 10:30:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHTxqt008719 for ; Thu, 14 Aug 2003 10:29:59 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EHU0il010814; Thu, 14 Aug 2003 10:30:00 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 10:30:00 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113021@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steve Hole'" , Julien Pierre Cc: ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Thu, 14 Aug 2003 10:30:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well, for the first time in a long time my interest is up on this > list :-). What a wonderful topic! General purpose use of > S/MIME by the masses on the Internet. Why hasn't it > happened and what > can we do about it. Glad you like it... The reason is simple, S/MIME is not transparent to end users. 1) Signature Signature is only possible by changingthe message format. Unfortunately there are still a lot of people out there with broken, non S/MIME capable email clients. Probably more of those than have broken email servers. Of course at this point it is difficult to do anything about this. 2) Encryption Encryption is a big problem for end users, it is simply not transparent. We need to link PKI to the DNS in some way, the SRV service looks the best choice. LDAP is not going to be the answer here, even if you find the right LDAP server the schema issues still have to be solved. Sure LDAP could address the problem - but only to the extent a Turing machine could and only with changes to make LDAP aware of PKI concepts like trust paths. 3) The end to end obsession One of the major reasons the IETF has failled in the security space is that the end to end principle alone does not address security issues. Perimeter security is a major concern for enterprises. As I have been digging into this issue I have discovered that 'end-to-end security' is actually a shiboleth. Go look at the RFCs with security architecture design discussions and you will not find it. Clark never applied it to security either in the naive form that has become the received version. What we need to do is to build specs that address multi-layer security concerns. It should not be necessary for everyone to have a certificate just to be able to do security. It should be possible to sign outgoing messages at either the end user level OR the domain name level - I only care that an email came from Merril Lynch, not that it came from Freddy Bloggs in accounts. 4) Feature support discovery An extension of #2. Clients should be able to advertise their capabilities. Perhaps this is NAPTR, but I doubt it. I see NAPTR as being a server level feature. > The solution is (and always has been) to do a lookup. The > problem is that > there is no directory to look up from. Global X.500/LDAP > directories are > *never* going to happen. Amen brother, Amen. > The reason for the cost is that the mechanism for > establishing root trust > is determined solely by the set of ROOT certificates > distributed by the > client vendor -- of all things!. Again, I designed XKMS to allow enterprises to define their own trust evaluations. One of the main considerations was how to support the Federal Bridge CA, both today and in the future when there are perhaps a thousand significant bridge CAs in operation. > 1. Easy to deploy. The track record for the Internet > stongly indicates > that this means that there are freeware versions of software > that will > support the deployment. This includes both the key management and > publication software and the usage (client) software. Also, obtain buy-in from the principal stakeholders whose help is required to achieve deployment. That is why the answer is XKMS and not SCVP. SCVP does not have the public support of any of the major stakeholders. I spent a lot of time and effort getting buy-in from Microsoft and RSA before we announced XKMS. I worked with Entrust and Baltimore so that we could produce a specification that they could also support. Contrast this to what the IETF mechanism achieves, OK everyone can say what they like. But at the end of the day you do not have the support of a major software vendor, just the individuals in the working group. > 2. Free. Those who "own" the vast majoritiy of the user > population on > the Internet are ISP's. They have almost no margin and > simply cannot > afford to pay for certification. Substitute cheap. Clearly certification becomes a lot cheaper in volume. > Why could we not have organizations issue certificates > distributed via > DNS, with a trust relationship provided by DNS-SEC? Because the working group deliberately sabotaged the spec by refusing changes to make it possible to deploy in .com and .net. > I can then lookup certs based on mail address (duh!), where the mail > domain source is trusted because of DNS-SEC. This trust > relationship > could be either: Not a good choice, very few DNS administrators deal with end users. The TTL constants in DNS are also completely inappropriate to the problem. Phill Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH66qt006614 for ; Thu, 14 Aug 2003 10:06:06 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EH66LA006613 for ietf-smime-bks; Thu, 14 Aug 2003 10:06:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH64qt006603 for ; Thu, 14 Aug 2003 10:06:04 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EH9lV32668; Thu, 14 Aug 2003 11:09:47 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 11:09:47 -0700 To: "Hallam-Baker, Phillip" Subject: RE: PKI and S/MIME Cc: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson , ietf-smime@imc.org, "'Sean P. Turner'" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EH64qt006604 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 14 Aug 2003 05:30:34 -0700 "Hallam-Baker, Phillip" wrote: > We considered certs in the DNS and LDAP before designing XKMS and rejected > them. Both technologies have been available for at least 6 years with > negligible uptake. This is true for LDAP, but is it true for DNS? What specific "deploy certs in DNS" technology are you talking about? > We needed a new protocol because there was no acceptable > existing solution. Sometimes designing a new protocol from scratch is better > than attempting to use an inappropriate one. Fair enough. Then you better figure out how, exactly, you are going to deploy your new protocol for use with S/MIME. Specifically, you must do what Blake suggests and write a profile for use. In particular, if I'm sitting in my Netscape client and I want to send an encrypted message to "Blake Ramsdell " without any prior contact, how am I going to do that? That profile must describe: 1. The collection of services and publication points for accessing the information. 2. The approach that a client must take to do the lookup and resolve the requested certificate. I'm sure that you can do it. I'm also sure that you are going to have to do *something* with DNS because how are you ever going to find your xkms server? If there is an external xkms global hierarchy planned, then pardon me if I'm dubious, but who is going to run the root? (Hint: I'm unlikely to like *any* answer to that last question :-). Chers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGg7qt004889 for ; Thu, 14 Aug 2003 09:42:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGg7wq004888 for ietf-smime-bks; Thu, 14 Aug 2003 09:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGg5qt004880 for ; Thu, 14 Aug 2003 09:42:05 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGjiV32463; Thu, 14 Aug 2003 10:45:45 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:45:45 -0700 To: Simon Josefsson Subject: Re: PKI and S/MIME Cc: Blake Ramsdell , "'Anders Rundgren'" , ietf-smime@imc.org, "'Sean P. Turner'" In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGg5qt004882 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 14 Aug 2003 01:45:51 +0200 Simon Josefsson wrote: > I believe that what is lacking is not a technical solution (DNS CERT > RR, LDAP and SRV, etc) but a guideline document, supported by the > S/MIME community, that you can point at when e-mail application makers > ask question such as the one that started this thread. > > One reason why the DNS CERT solution has been proposed, may be that > the LDAP via SRV idea hasn't been fully documented in a Internet-wide > S/MIME environment, leaving the problem unsolved. I agree. The problem with PKI has always been that it is difficult to experiment. I think that we have enough real world experience now that we should try some alternative things. I think that we do need to experiment with this. It's time to come up with some working solutions and then document them, not the other way around. > One argument for certificates in DNS could be that many ISPs are > familiar with running public DNS, but not as many ISPs run public > LDAP. So instead of upgrading their tools, they would have to learn > new tools with LDAP. [All under the assumption that ISPs will be > required to administer the certificate directory, which I'm not sure > is the best solution.] Yes. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGcEqt004313 for ; Thu, 14 Aug 2003 09:38:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGcEoR004312 for ietf-smime-bks; Thu, 14 Aug 2003 09:38:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGcCqt004300 for ; Thu, 14 Aug 2003 09:38:12 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGg1V32422; Thu, 14 Aug 2003 10:42:01 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:42:02 -0700 To: Blake Ramsdell Subject: RE: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGcCqt004302 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell wrote: > A better question for the DNS distribution of certificates is whether or > not this smells like it would be the most likely thing to get deployed. > My understanding is that you would need DNS servers that supported the > particular record types required for this functionality, as well as > administrative tools to upgrade those records that are different than > typical DNS administration tools. To me, that doesn't smell as good. Actually, I think that there are two barriers: 1. Deployment of DNS-SEC. People have to go out of their way to do it right now. It takes some work both to deploy the right software and to get the relationship set up with the domain registration service. Not all services offer it. 2. Client support. Basically this means that Outlook, Outlook Express, Netscape (and down the list) of clients have to support it. It means a CSP for the Windows twins and a module in the new Netscape/Mozilla security API. Of the two, the second is the hardest. Policy, usage and deployment of S/MIME and PKI is very much shaped by the implementation of the clients. Any changes have to propogate through the clients to be useful. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGV1qt003430 for ; Thu, 14 Aug 2003 09:31:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGV13M003429 for ietf-smime-bks; Thu, 14 Aug 2003 09:31:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGUxqt003418 for ; Thu, 14 Aug 2003 09:30:59 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGYkV32358; Thu, 14 Aug 2003 10:34:46 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:34:47 -0700 To: Anders Rundgren Subject: Re: PKI and S/MIME Cc: ietf-smime@imc.org In-Reply-To: <006901c361be$9f4ba080$0500a8c0@arport> References: <006901c361be$9f4ba080$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGUxqt003419 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 13 Aug 2003 19:16:22 +0200 Anders Rundgren wrote: > > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? Why not? --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGT0qt003175 for ; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGT0Md003174 for ietf-smime-bks; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web40511.mail.yahoo.com (web40511.mail.yahoo.com [66.218.78.128]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7EGT0qt003160 for ; Thu, 14 Aug 2003 09:29:00 -0700 (PDT) (envelope-from deepak_vn@yahoo.com) Message-ID: <20030814162856.26664.qmail@web40511.mail.yahoo.com> Received: from [193.41.16.3] by web40511.mail.yahoo.com via HTTP; Thu, 14 Aug 2003 09:28:56 PDT Date: Thu, 14 Aug 2003 09:28:56 -0700 (PDT) From: Deepak Subject: Query regarding BER/DER encoding of CMS data To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, When i go through the CMS RFC's its saying, all the contenttype(SignedData,EnvelopedData) should be BER encoded. But when i go thorugh the some of the ietf examples, especially in EnvelopedData->RecipientInfo is encoded by DER.(its starting with 31 82 ..). It should be like sequence 30 80 .. ? Could you please explain why was it happend ? Thanks, Deepak __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGQmqt002912 for ; Thu, 14 Aug 2003 09:26:48 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EGQmJ7002911 for ietf-smime-bks; Thu, 14 Aug 2003 09:26:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EGQgqt002891 for ; Thu, 14 Aug 2003 09:26:46 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7EGURV32299; Thu, 14 Aug 2003 10:30:27 -0600 From: Steve Hole Date: Thu, 14 Aug 2003 10:30:28 -0700 To: Julien Pierre Subject: Re: dissemination of public encryption certificates Cc: ietf-smime@imc.org In-Reply-To: <3F3AF421.6060008@netscape.com> References: <3F3AF421.6060008@netscape.com> <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> Message-ID: X-Mailer: Execmail for Win32 6.0.0 alpha Build (1) 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 above.proper.com id h7EGQlqt002905 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, for the first time in a long time my interest is up on this list :-). What a wonderful topic! General purpose use of S/MIME by the masses on the Internet. Why hasn't it happened and what can we do about it. Before you read on, be assured that it is the large scale use of S/MIME that the following diatribe is focused on. On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre wrote: > If you send an email today, you can simply sign it and include your > certificate in the signature. If you just sign all your mail, then all > you always disseminate your certificate. So in what situations does this > new MIME extension certificate lookup help ? I suppose this extension > would be shorter than a digital signature. However it would also be much > less secure. This highlights one of the key issues. It is easy enough to exchange keys simply by sending a signed message, but there are some significant barriers: 1. What if your encryption key is separate from your signing key. This is not only common but considered good security practice. How does one go about exchanging/discovering the encryption key for the new party you want to exchange mail with. 2. Timeliness of the key exchange. The problem with mutual signing exchange is that the other person has to respond to you. What if you just want to send them an encrypted load right off the start. You can't really do it. The solution is (and always has been) to do a lookup. The problem is that there is no directory to look up from. Global X.500/LDAP directories are *never* going to happen. There is only one choice -- DNS. I (and Steve Kille and others) have been flogging LDAP directories and working on LDAP/X.500 interconnects for a decade. Global X.500/LDAP isn't going to happen in our lifetime. > The case I originally asked about is : > neither party has exchanged any e-mail yet, but they know each other's > e-mail address. They want to communicate securely. How do they avoid or > bypass the initial insecure e-mail exchange ? Precisely. They must be able to do a DNS lookup for the information either as a direct data return or a reference to a secondary storage service, which absolutely could and probably should be LDAP. To work in practice I think that it should be possible to get a direct pull from the DNS so that organizations are not required to deploy an LDAP directory and all that goes along with it (much as that pains me). > > In summary I think that a certificate-independent configuration > > of e-mail clients would be more universal than "fishing" in > > domains as the user domain and issuer domain may be entirely > > disjunct. > > "Fishing" in domains as you say would be independent of e-mail client > configuration for the most part (it could just be turned on or off). Actually, I think that "fishing" is an entirely appropriate thing to do. The worst that can happen is that don't find the cert your looking for. Trust issues MUST be dealt with, but certificate trust chains and approaches are both well understood. The best that can happen is that suddenly I can go and find a cert for joe@foobar.com with a simple DNS query. BEAUTIFUL! Why wouldn't I want to do that? This does lead very nicely into my second (and quite separate) issue in this area -- the "trusted ROOT certificate". Julien has provided superp leading commentary here. > You correctly point out that in most cases the user's domain and cert > issuer domain are disjoint. This is especially true of e-mail users > whose ISP isn't a CA (99.9% of them right now). Exactly. Why? Because it costs TOO MUCH. The only acceptable cost for most ISP's is zero because of the volume of users. Cost of certification is, pure and simple, the primary barrier to the general use and deployment of S/MIME on the Internet. The reason for the cost is that the mechanism for establishing root trust is determined solely by the set of ROOT certificates distributed by the client vendor -- of all things!. Thus only those organizations that can afford to pay the client vendor -- of all things! -- to be included in their "special trusted root certificate club" get to have "trust". Which means that you MUST buy certs from one of the club members. Doesn't THAT just suck. Nice business if you can get it. Yes I know about free thawte certs. I know that any root issuer must be secure and provide good protection from having roots keys compromised etc. I agree that anyone who issues certificates should be required to be secure. I understand that there is risk to the client vendor if they report trust in a cert that has been compromised at the root. Regardless, to have this power rest in the hands of the client vendor is ludicrous. Why should I trust that Microsoft can evaluate the security and trustworthiness of "Joe's CA Service" to be a valid issuer. I'm not saying they are unqualified to do so, but I'm a lot more likely to trust a self signed "Bank of America" certificate issued on it's own behalf and obtained from a reliable source, than I am a third party software vendor or CA Verisign (not that there's anything wrong with either Microsoft or Verisign :-). The issue comes down to trust brokering. I just don't think that it is working for the *general* mass consumer Internet. It clearly does work for closed communities within the Internet, but it isn't scaling. Period. If we want generalized S/MIME usage throughout the Internet we need to think of some mechanism that is: 1. Easy to deploy. The track record for the Internet stongly indicates that this means that there are freeware versions of software that will support the deployment. This includes both the key management and publication software and the usage (client) software. 2. Free. Those who "own" the vast majoritiy of the user population on the Internet are ISP's. They have almost no margin and simply cannot afford to pay for certification. Also (and more importantly IMHO) is the desired for businesses to touch their customers. These are HUGE volume relationships in which there are virtually no economically viable ways of establishing bidirectional trust. A cert price of $0.01 a year is too much if your customer population is 25 million people (banks, utilities, etc.) Why could we not have organizations issue certificates distributed via DNS, with a trust relationship provided by DNS-SEC? That is, you can trust that the DNS node your are dealing with is legitimate because they have deployed DNS-SEC (which everyone should do anyway for a host of other security reasons) and the keys that are located within the DNS hierachy are legitimate. I can then lookup certs based on mail address (duh!), where the mail domain source is trusted because of DNS-SEC. This trust relationship could be either: implicit -- the issuer domain location is trusted therefore any keys published there are trusted, explict -- the issuer provides a root signing key which is in turn signed by their DNS-SEC key. There are a number of observations that can be made about this approach: 1. The security provided by the approach is probably not as strong as the full commercial CA approach. I contend "so what". It's better than nothing and Pretty Good (pun intended). The average user doesn't need military grade security. The average bill issued by the local telephone utility doesn't need military grade security. Think of the vast number of paper documents that need only Pretty Good security and trust to be useful (292 Trillion a year in the US -- it's my business and I happen to know). All we need is some security to make that paper go away forever. 2. Some extensions to bind and a new CSP for Windows would get a large number people going in a hurry. Openssl with an HSM card and some reasonable security policy has an organization running pretty quickly. > The only solution for > these users is some sort of universal registration service. Yup. > This implies > the existence of some sort of free worldwide directory service (LDAP) > that would resolve e-mail addresses to certificates ... And clients > would need to be (automatically?) configured to do look ups in it. Well, even though I would love it if it was LDAP, it isn't going to happen. DNS is the only game in town for global directory service. Cheers. --- Steve Hole Chief Technical Officer - Electronic Billing and Payment Systems ACI Worldwide Email: holes@aciworldwide.com Phone: 780 424 4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUkqt084607 for ; Thu, 14 Aug 2003 05:30:46 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ECUk0x084605 for ietf-smime-bks; Thu, 14 Aug 2003 05:30:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUiqt084596 for ; Thu, 14 Aug 2003 05:30:44 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7ECUZil017013; Thu, 14 Aug 2003 05:30:35 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 05:30:35 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Anders Rundgren'" , Blake Ramsdell , Simon Josefsson Cc: ietf-smime@imc.org, "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Thu, 14 Aug 2003 05:30:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are two ways the problem may be solved. The simplest solution is that the domain owner appoints a single CA for the entire zone and simply directs all XKMS requests to the XKMS server run by the CA. The second solution is that the domain owner runs a non-authoritative Locate service locally. XKMS clients that register certificates with the CA of their choice can then in turn register the certificate issued by the CA with their local XKMS locate service. In this second application the XKMS service may choose to impose some form of validation constraint on the certs that it accepts. For example only accepting certs from a limited number of CAs - or it may not. Incidentaly XKMS may also be used to register PGP keys or keys in alternative PKIs. It is a key centric PKI, not a token centric one. Storing end-user certs or keys in the DNS is a lousy idea for several reasons. First the DNS is a machine configuration infrastructure and not a user configuration infrastructure. Storing user information in the DNS requires an administrative interface with a new constituency. Ain't going to happen. Moreover the DNSSEC spec itself is still not in a deployable state, or at least the IETF version of it is not. Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise resource. Enterprises are not going to expose LDAP data in border directories in significant numbers. It is not just the security issue, cost plays a factor. LDAP is not a simple protocol, it is would be completely overspecified for the job of a cert repository if the features LDAP provided were relevant to the task. We considered certs in the DNS and LDAP before designing XKMS and rejected them. Both technologies have been available for at least 6 years with negligible uptake. We needed a new protocol because there was no acceptable existing solution. Sometimes designing a new protocol from scratch is better than attempting to use an inappropriate one. Phill > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, August 13, 2003 1:16 PM > To: Blake Ramsdell; Simon Josefsson > Cc: ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > > > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? > > Anders > > ----- Original Message ----- > From: "Simon Josefsson" > To: "Blake Ramsdell" > Cc: ; "'Sean P. Turner'" > Sent: Wednesday, August 13, 2003 09:32 > Subject: Re: PKI and S/MIME > > > > "Blake Ramsdell" writes: > > > There have been a number of messages recently about the use > of PKI with > > S/MIME, and the concerns about that. I like to think that we're all > > pretty much in agreement that we've established a consistent, > > interoperable practice for the actual syntax and contents of S/MIME > > messages, as well as a reasonable cut of a certificate > syntax profile > > for end-entity certificates. > > > > Should there be a profile for certificate usage > (certificate repository, > > distribution and revocation checking) that is specific for > our problem > > domain? That is, select relevant other work and profile it > for use in > > the S/MIME interpersonal messaging domain? I would imagine > that this > > would be a new draft, start with a summary of the requirements, and > > progress to profiles of relevant standards. > > > > It's also not clear if this is something to discuss in this working > > group, or somewhere else. > > > > Comments? > > Since in practice, addressing this problem would help in getting > "opportunistic S/MIME" to work, I believe it would be useful to > address it. ("Opportunistic S/MIME" means to be able to encrypt > messages to someone you don't have a prior trust relationship with, > simply to provide encryption of data. There is a man in the middle > attack, of course, but in practice the result often isn't worse than > not using S/MIME.) > > A strawman at a requirement: > > * Be able to locate a certificate for a Internet user given only her > email address. > > I should mention that this has been discussed several times before, in > various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so > there is prior work to look at how to design this. To do even more > self-promoting, I'd again like to mention the following draft: > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which do discuss it for S/MIME context as well. I don't have an > opinion on if this WG is the proper place for it. > > Regards, > Simon > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2T1qt032189 for ; Wed, 13 Aug 2003 19:29:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E2T00T032188 for ietf-smime-bks; Wed, 13 Aug 2003 19:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2T0qt032182 for ; Wed, 13 Aug 2003 19:29:00 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7E2SvD09213 for ; Wed, 13 Aug 2003 19:28:57 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJL87P02.S6V; Wed, 13 Aug 2003 19:28:37 -0700 Date: Wed, 13 Aug 2003 19:29:53 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Anders Rundgren" cc: ietf-smime@imc.org, "Hallam-Baker Phillip" In-Reply-To: <001301c360ef$41128990$0500a8c0@arport> Message-ID: <3F3AF421.6060008@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> <001301c360ef$41128990$0500a8c0@arport> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Anders, Anders Rundgren wrote on 08/12/2003, 9:31: > Pierre, > It is good to hear somebody bring up this question which is absolutely > vital for successful deployment of encrypted mail. I'm also glad to see interest in solving this problem. > Personally I don't think that neither the S/MIME WG or XKMS WG > have a solution that at least I would call "acceptable". > > XKMS addresses to some extent the enterprise scenario but only > if the enterprise has their own domain and associated CA. For > truly TTP-based certificates you are out of luck if you are looking > for automated functionality. Are you saying basically that this won't work for Joe User at randomisp.com, who wants to register with randomca.com ? > > I believe that the mail protocol and associated applications > should be augmented with encryption certificate lookup. A > MIME X-extension that you configured in your e-mail client > would do a part of this. I.e. each time you sent a mail, the > lookup would be transmitted as well. Also it would be > nice to have an enhanced "mailto:" URL supporting the same > mechanism. If you send an email today, you can simply sign it and include your certificate in the signature. If you just sign all your mail, then all you always disseminate your certificate. So in what situations does this new MIME extension certificate lookup help ? I suppose this extension would be shorter than a digital signature. However it would also be much less secure. The case I originally asked about is : neither party has exchanged any e-mail yet, but they know each other's e-mail address. They want to communicate securely. How do they avoid or bypass the initial insecure e-mail exchange ? > In summary I think that a certificate-independent configuration > of e-mail clients would be more universal than "fishing" in > domains as the user domain and issuer domain may be entirely > disjunct. "Fishing" in domains as you say would be independent of e-mail client configuration for the most part (it could just be turned on or off). You correctly point out that in most cases the user's domain and cert issuer domain are disjoint. This is especially true of e-mail users whose ISP isn't a CA (99.9% of them right now). The only solution for these users is some sort of universal registration service. This implies the existence of some sort of free worldwide directory service (LDAP) that would resolve e-mail addresses to certificates ... And clients would need to be (automatically?) configured to do look ups in it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTQwMjI5NTNaMCMGCSqGSIb3DQEJBDEWBBSo4N/z 6bdvBgKJjFS12Izb6VR9DDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQB6KYML1UrOipbf75tEtNSTOSsl5BQep5H8Tsnls/yryz+uDpZf1SgAf8y4 UJSHl4t+sVJh4oZ28fEiusRRr9E7CSwGbEpiH9b7u29kXsxxqOXIlGgPtgWStU12Yx1vnen2 MohwfDLzxR3VvY74kiU5wGoZyV9OTWnl3lqzzUXu3NL4HQeZF+r1AYY9u+yLLwDc78RTrxLH lTXVD7pyVHDOhIxFURnXd1k6kXIOBlqUWQ1WmwsqRc/X0bD4tgwUT3LsY60mO91/wAuXAxoR pnWJ8Tksj2rOsVX6b3pt1fKyvZKdPGFMWsq/iroNt2Bb9NnH0E3trmhYETYwmhSeZ2AEAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E05Tqt022386 for ; Wed, 13 Aug 2003 17:05:29 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E05TCo022385 for ietf-smime-bks; Wed, 13 Aug 2003 17:05:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E05Sqt022377 for ; Wed, 13 Aug 2003 17:05:28 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 13 Aug 2003 17:05:25 -0700 From: "Blake Ramsdell" To: "'Simon Josefsson'" Cc: "'Anders Rundgren'" , , "'Sean P. Turner'" Subject: DNS CERT vs. LDAP (was: RE: PKI and S/MIME) Date: Wed, 13 Aug 2003 17:05:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Simon Josefsson [mailto:jas@extundo.com] > Sent: Wednesday, August 13, 2003 4:46 PM > To: Blake Ramsdell > Cc: 'Anders Rundgren'; ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > I believe that what is lacking is not a technical solution (DNS CERT > RR, LDAP and SRV, etc) but a guideline document, supported by the > S/MIME community, that you can point at when e-mail application makers > ask question such as the one that started this thread. Yes, this was the way I indeed started this thread ("PKI and S/MIME"), by saying "select relevant other work and profile it for use in the S/MIME interpersonal messaging domain" ;). I think we're on the same page. My only point about LDAP is that I wanted to illustrate some of the criteria for any potential profile by comparing two certificate repository methods, and pointing out what I believe is a relevant difference. > One reason why the DNS CERT solution has been proposed, may be that > the LDAP via SRV idea hasn't been fully documented in a Internet-wide > S/MIME environment, leaving the problem unsolved. But once again, if someone held a gun to my head and told me to try and guess if CERT records and the infrastructure to maintain them would achieve traction before LDAP and SRV records would, I would say LDAP and SRV records. This may be a matter of personal taste, but I like to think that it is a practical answer based on limited experience with managing my own domains. > > as well as administrative tools to upgrade those records that are > > different than typical DNS administration tools. > > Yes, someone, somewhere will have to do work to make the idea happen. I think the question is whether or not "someone, somewhere" for DNS CERT records is better than "been there, done that" for LDAP or other repositories. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNjuqt021584 for ; Wed, 13 Aug 2003 16:45:56 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNju9W021583 for ietf-smime-bks; Wed, 13 Aug 2003 16:45:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNjsqt021577 for ; Wed, 13 Aug 2003 16:45:55 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7DNjpdk030384 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 14 Aug 2003 01:45:52 +0200 To: "Blake Ramsdell" Cc: "'Anders Rundgren'" , , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:335740bf15304fc1 X-Hashcash: 0:030813:blake@brutesquadlabs.com:335740bf15304fc1 X-Payment: hashcash 1.2 0:030813:anders.rundgren@telia.com:d7a624837cfa94fb X-Hashcash: 0:030813:anders.rundgren@telia.com:d7a624837cfa94fb X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:3d737b7ac6bfa688 X-Hashcash: 0:030813:ietf-smime@imc.org:3d737b7ac6bfa688 X-Payment: hashcash 1.2 0:030813:turners@ieca.com:47a8f772f4360518 X-Hashcash: 0:030813:turners@ieca.com:47a8f772f4360518 Date: Thu, 14 Aug 2003 01:45:51 +0200 In-Reply-To: (Blake Ramsdell's message of "Wed, 13 Aug 2003 15:05:49 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > If I were going to hazard a guess about widely deployed public > certificate repositories, I would say that there would be a better > argument for LDAP than anything else. Notice the careful wording here > ;). As much as the attempts to automatically map from an email address > to an LDAP directory containing a certificate for that email address > might not have progressed as well as we might like, I think that there > is some hope of that being addressed through the SRV record which is (as > far as I can tell) widely supported by DNS implementations. I believe that what is lacking is not a technical solution (DNS CERT RR, LDAP and SRV, etc) but a guideline document, supported by the S/MIME community, that you can point at when e-mail application makers ask question such as the one that started this thread. One reason why the DNS CERT solution has been proposed, may be that the LDAP via SRV idea hasn't been fully documented in a Internet-wide S/MIME environment, leaving the problem unsolved. > A better question for the DNS distribution of certificates is whether or > not this smells like it would be the most likely thing to get deployed. > My understanding is that you would need DNS servers that supported the > particular record types required for this functionality, Support for this was added to major servers before 2000 or thereabouts, so many are already using such DNS servers. > as well as administrative tools to upgrade those records that are > different than typical DNS administration tools. Yes, someone, somewhere will have to do work to make the idea happen. One argument for certificates in DNS could be that many ISPs are familiar with running public DNS, but not as many ISPs run public LDAP. So instead of upgrading their tools, they would have to learn new tools with LDAP. [All under the assumption that ISPs will be required to administer the certificate directory, which I'm not sure is the best solution.] Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMsqt019916 for ; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNMs5U019915 for ietf-smime-bks; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNMsqt019909 for ; Wed, 13 Aug 2003 16:22:54 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNMi315475 for ; Wed, 13 Aug 2003 16:22:44 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZLI02.K7A; Wed, 13 Aug 2003 16:22:30 -0700 Date: Wed, 13 Aug 2003 16:23:47 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: Re: dissemination of public encryption certificates To: "Simon Josefsson" cc: "Alberto Cozer" , ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC883.7000108@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Simon, Simon Josefsson wrote on 08/12/2003, 4:26: > Julien, Alberto, > > There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538. > > Unfortunately it doesn't include useful RR owner name guidelines to > make it work in practice. I have made some clarifications for this in > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which also includes recommended owner names for S/MIME certificates. > Thanks. This is very useful and I will look into it. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzIzNDdaMCMGCSqGSIb3DQEJBDEWBBT5XiEL cNOjSi6ranFoUOBNcUNJPjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQC2ibwYdwLQEIWB7BGWdwMTckFC7SxSvEgbqqvil1I1fEhym9edQxYpwTLe 883NMTwhwmNEOYeRyscA+dy+bCN9UCkdAorK6DICuZDrRojHXHpRqGKg7TsLyCXjq/LxOjqa So7f4HNE9zlFfNwcu7+RsWXWTEa8Gd+0w8N9b42KvBt7c7rDfo7PDlTVIrhvbrpc9j9OhQj/ JjE1jlyqb4r5/7iZ1OeP6CZTQhKcK4OdeuyzQRzO6Vyy8qZ4LdccGsUBuW8KXjrY3Kyro4hO UBBDWwy7yOWzh+4hs2oHrqWEX8JPbJuWmpLe+wAvvmUQ4bBqssQ3E50+LZl3KUL6b0JjAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNIiqt019768 for ; Wed, 13 Aug 2003 16:18:44 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNIiD3019767 for ietf-smime-bks; Wed, 13 Aug 2003 16:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNIhqt019761 for ; Wed, 13 Aug 2003 16:18:43 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNIW315159 for ; Wed, 13 Aug 2003 16:18:33 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZEJ01.Z70; Wed, 13 Aug 2003 16:18:19 -0700 Date: Wed, 13 Aug 2003 16:19:36 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Hallam-Baker Phillip" cc: ietf-smime@imc.org In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> Message-ID: <3F3AC788.7070508@netscape.com> References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Philip, Hallam-Baker, Phillip wrote on 08/11/2003, 16:55: > This issue is one of the main use cases for XKMS. This has > considerable support within the PKI community, VeriSign, Microsoft, RSA, > Entrust and Baltimore have been involved in writing the specification > which is in the final post last call stage in W3C. > > The (almost) final spec is to be found at > http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html > http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html > > There will be two further changes to the spec, one to make a > minor tweak to the schema sometime this week, the second to change the > examples to use exclusive C18N. > > An XKMS locate service may be advertised in the DNS using the > SRV record. So to send mail to alice@example.com you do an XKMS locate > to _xkms_http._tcp.example.com. > That gives you the XKMS service. > > You then do a locate for a certificate to be used with S/MIME. Thanks. This is very interesting and I will need to read more on XKMS. Until I do, you may be able to answer the following question : can the XKMS be easily delegated by the domain owner to a third party in the DNS, just like mail and web services usually are typically delegated today ? It certainly looks like it from the above, but I just want a confirmation. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzE5MzZaMCMGCSqGSIb3DQEJBDEWBBSNzqdq ZBANu8MsXVYSvILvpyaLTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQAOhhg/DNynGt4MXVeCRTy8HDR1pRyzkk6Cp0vJvaIYET+UbQ7s+lUEXcFB Z0Wq5h0JeMh94G1EKkM4V2aiZF+iBfDbp2zRXZX63QJBtIbrxfJrTBANuAdzp4GF6Uv02GVp H1t9yj7gbBRN4A1x+v1fbtIdKLplWZrwIhSLtGIkf0h+FM2s2+bJ71VkidaiXeg8/liH8u7S SAPOz9jgS4qkHDDmF+2/dnkMHUBcEzRX7b1Zgk0ePekuGIkn81lpPR2VG5ISYwRe+R9oZe6e 2Pn6+yJ2/hKdWSUmdbfnFUmsR2jBpTR6ogDbTemylZl8JVK72+pTqmBSz1vpPLZQs29CAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNFtqt019655 for ; Wed, 13 Aug 2003 16:15:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNFtao019654 for ietf-smime-bks; Wed, 13 Aug 2003 16:15:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNFsqt019646 for ; Wed, 13 Aug 2003 16:15:54 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DNFpD25096 for ; Wed, 13 Aug 2003 16:15:51 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKZ9V00.Q6L; Wed, 13 Aug 2003 16:15:31 -0700 Date: Wed, 13 Aug 2003 16:16:47 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: trust domains To: "Alberti Antoine" cc: "'ietf-smime@imc.org'" In-Reply-To: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> Message-ID: <3F3AC6DF.10603@netscape.com> References: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Alberti, Alberti Antoine wrote on 08/11/2003, 1:50: > There was such an issue in TLS, solved, from the server point of view, by > sending a list of trusted authorities when requesting a client > authentication. However, this list was so ennoying to use for both sides > that it is now almost always empty, indicating "Send me whatever you > want, > we'll see then". > I agree that a work could be done on this topic, but it should done > carefully to avoid this conclusion. I'm aware of the change that was made recently to TLS to allow an empty list of trusted certificates to be sent by the SSL server. I don't personally like this change at all and considered very useful in SSL client authentication. This provision means that to login to such servers, I'm now presented with a list of 12 certificates to choose from, with absolutely no hint about which one is correct, instead of having the right one automatically chosen by the application, or at least a list of valid ones if there are several matches. This is what I call shooting oneself in the foot. Some server administrators are probably too lazy to install the valid trusted roots. My opinion is that they probably shouldn't be running PKI servers. Eventually after the client auth login, the code in the SSL server is going to have to check if the client certificate is valid anyway, and that operation will require the trusted root to be installed. If the check does not involve a particular issuing root, there are many spoof attacks I can think of against such SSL servers ... -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzE2NDdaMCMGCSqGSIb3DQEJBDEWBBQ+zlfn 5qf8GXuXhtFWyMb/BuF0oTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQCIkDWQupjr0mnnm50HR+HnC6Jp9p13zTWwzVNMl6lRTADAcIcp3AUqu1Fc YOz2FFj9dBUs/Al3QCqSNTOzizE2vJJlOp7s27d4/bCnXec2eJZhIP2ULcYyQ9aEMlFw/r5D wfioaHsVp5fY+vTcothCkUcrwJypjghZsK+dEQmDQYSDrPjFVDfUqJLRnRxTv9iZFpoHL/gs zDxtSi1Rk4kIe/prPBbE8RVT9Ba3ly4LiPsinmzX46O1FlNkKv+3Imo2b5ZTTQ7B5fowGLsa eFyLOZTUPQsQAOqjN8L9dkfpz5/l1s5iAkr/2gzSi1e9jRR6hU6g03hMLMcuQ5q1GF1eAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN9Pqt019344 for ; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DN9P9r019343 for ietf-smime-bks; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN9Pqt019330 for ; Wed, 13 Aug 2003 16:09:25 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DN9LD24290 for ; Wed, 13 Aug 2003 16:09:21 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKYZ101.55R; Wed, 13 Aug 2003 16:09:01 -0700 Date: Wed, 13 Aug 2003 16:10:17 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: trust domains To: "Blake Ramsdell" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC559.8030403@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Blake Ramsdell wrote on 08/08/2003, 20:44: > > This seems to be a question of certificate policies and mapping those to > the content being protected. That is, if the message being signed is > just casual communication, use one certificate, and if it's a purchase > order, use another one. Right now, I think that most clients pretty > much allow the user to pick. Further, I think that a lot of folks just > have one, so you'd better like it. It is indeed a question of policy, and the example you point out is a good one. Similarly, for internal communications within a company, I shouldn't use my freemail Thawte cert. The internal SSL web servers which require client auth don't accept that certs. Yet mail client accept it just fine. The specific application I'm interested in is e-mail spam filtering based on certificates. You could choose to trust some free CAs (such as Thawte) if you like to receive anonymous email, otherwise restrict to a set of CAs with a more stringent policy (eg. those that require you to pay for the certificate). As far as the number of certificates, I think most folks have zero today, not one. Some will have one, issued by their employer (corporate, or government/military typically). Then there are hobbyists or security professionals like us who may have dozens of certificates. Nowhere does Joe User fit today, because PKI is not widely deployed. Most questions I'm asking are in the context of a very large-scale PKI deployment happening. The problems may not be so obvious unless you get to that point. > Well, I'm not sure that the semantic of multiple SignerInfos is that "if > you verify them, you must verify all of them, and if you don't like any > of them, freak out". I think it's more along the lines of "these are > all equivalent, so go ahead and choose which one you like and run with > it". Where would that be specified ? I would think this would be completely up to the application. If I chose to sign mail with both my personal cert and corporate cert, I know I wouldn't treat each signature in the same way. Eg. if I am an employee, I might not care about the personal cert's signature failing, but care about the corporate cert signature. > This might be interesting to discuss. You could make a capabilities > extension where you could identify your roots (off the top of my head, > I'd say using a hash of the certificate would work) and go from there. > One concern is bloat -- I have over 100 roots on my machine configured > with Outlook 2002 and IE6 that are all marked as suitable roots for > "Secure email" (in the "secure email" trust domain, using your terms). > Sending this stack of hashes with every signed message might make the > world a worse place to address this issue. I think it would be a very bad thing to embed all the root certificates in each S/MIME signature. The signatures are already quite big enough as they are. I know the number of trusted roots can be quite high - it is also high in Netscape products. What I'm getting to is more along the lines of : 1) defining a standard ASN.1 structure to define the user's trusted roots policy WRT email. That structure will most likely be too large to embed in signatures. 2) there may be a set of rules that goes along with the roots. Just having roots trusted may not be right. Eg. my colleagues shouldn't trust email signed with my Thawte cert with jpierre@netscape.com in it, it should be signed with the Netscape CA ... This one I really haven't given much thought to. 3) Some mechanism for transporting that trust structure. I would suggest LDAP, but that requires a standard mechanism to get to it, just like we need a standard means for disseminating certificates > I think the principle is the same, though. It's very similar, with the possible exceptions of the rules (see above). > In the case of S/MIME, it's > "sign with all of your certs". One problem is that you're going to > potentially cart around a large number of certs -- each of your > individual certs as well as the intermediate certs that go with them. > And I'm not sure that there's enough experience with clients handling > multiple signers to tell you what would happen if you used that feature. Definitely not today - multiple signatures is something that would need to be added to most S/MIME software and would hamper deployment. > >From what I can tell, today we solve the problem by having clients > include every root key under the sun, It's worse than that, some SSL intermediate certs are also included with some software (IE) ... Many SSL servers are misconfigured and don't send their intermediate certs. > and most certificates of > significant public value are issued under those roots. Certificates > that aren't issued under those roots are most likely corporate CA > certificates, and typically folks just have to hunt around to find the > right corporate root to install in order to verify the signatures. > Peter Hesse and Sharon Boeyen have recently illustrated this problem on > the PKIX list -- not directly, but by sending signed messages for which > people don't have the root keys. This is a case where the trust domain could be useful. Eg. the mailing list alias could have a defined trust domain, and their software would know not to use that private cert when posting to the list. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMzEwMThaMCMGCSqGSIb3DQEJBDEWBBS46d6u fyuKdkxQ1EnSfebXBrY4NDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQBFI76b+dsTBfdKm/KHUKJxVzXiMCVGyAJsFmewRLpFX5H+tYrk6utIQZWR 6tsbc683LVkK8MmNoxuowv3rpuSbwpjPfy3Lj5at68tDw4iQBBfNjNBcAaZS2GmvscfzgSYz 79WKavLfYc+e2Kjji8ixfl0GdPYCEobmJ2oTERU55OvBXnYKlw9gEHE3scAQXij+OrcyW3eR tFOptc1UZIsvaXzcp/fuFzgxxxqKM0N/9nqrPBgtrH6CALl24MZyZ5+cfe+rhc8jZHM3OkRV 6qwgAi3Oh2hRVoADVMHJ5TriWfypb8u1AAk82jYizdOsPpGDYPyAtqgm7jB+jhi+ClnMAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN65qt019231 for ; Wed, 13 Aug 2003 16:06:05 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DN65eH019230 for ietf-smime-bks; Wed, 13 Aug 2003 16:06:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DN63qt019225 for ; Wed, 13 Aug 2003 16:06:03 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7DN5rdk029769 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 14 Aug 2003 01:05:53 +0200 To: "Anders Rundgren" Cc: "Blake Ramsdell" , , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: <006901c361be$9f4ba080$0500a8c0@arport> From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:anders.rundgren@telia.com:d22d10f4fbc624cb X-Hashcash: 0:030813:anders.rundgren@telia.com:d22d10f4fbc624cb X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:5292953ee89c9b12 X-Hashcash: 0:030813:blake@brutesquadlabs.com:5292953ee89c9b12 X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:c9f896028ba5f801 X-Hashcash: 0:030813:ietf-smime@imc.org:c9f896028ba5f801 X-Payment: hashcash 1.2 0:030813:turners@ieca.com:07e5266f3de80115 X-Hashcash: 0:030813:turners@ieca.com:07e5266f3de80115 Date: Thu, 14 Aug 2003 01:05:53 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, you are right, it doesn't solve all problems. However, in some situations all you have is the email address of the recipient, and in those situations locating the certificate through DNS is simpler than many alternatives. The certificate can be located directly, like RFC 2538, or indirectly using SRV pointers to LDAP or XKMS servers. In either case, your ISP could add those DNS records as yet another step in setting up an email account. One potential advantage of storing certificates directly in DNS a'la RFC 2538 would be that if we ever get DNSSEC, the certificate you receive would be integrity protected. (Whereas a SRV would only provide you with a integrity protected name of the LDAP host.) Regards, Simon "Anders Rundgren" writes: > Simon, > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? > > Anders > > ----- Original Message ----- > From: "Simon Josefsson" > To: "Blake Ramsdell" > Cc: ; "'Sean P. Turner'" > Sent: Wednesday, August 13, 2003 09:32 > Subject: Re: PKI and S/MIME > > > > "Blake Ramsdell" writes: > >> There have been a number of messages recently about the use of PKI with >> S/MIME, and the concerns about that. I like to think that we're all >> pretty much in agreement that we've established a consistent, >> interoperable practice for the actual syntax and contents of S/MIME >> messages, as well as a reasonable cut of a certificate syntax profile >> for end-entity certificates. >> >> Should there be a profile for certificate usage (certificate repository, >> distribution and revocation checking) that is specific for our problem >> domain? That is, select relevant other work and profile it for use in >> the S/MIME interpersonal messaging domain? I would imagine that this >> would be a new draft, start with a summary of the requirements, and >> progress to profiles of relevant standards. >> >> It's also not clear if this is something to discuss in this working >> group, or somewhere else. >> >> Comments? > > Since in practice, addressing this problem would help in getting > "opportunistic S/MIME" to work, I believe it would be useful to > address it. ("Opportunistic S/MIME" means to be able to encrypt > messages to someone you don't have a prior trust relationship with, > simply to provide encryption of data. There is a man in the middle > attack, of course, but in practice the result often isn't worse than > not using S/MIME.) > > A strawman at a requirement: > > * Be able to locate a certificate for a Internet user given only her > email address. > > I should mention that this has been discussed several times before, in > various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so > there is prior work to look at how to design this. To do even more > self-promoting, I'd again like to mention the following draft: > > http://josefsson.org/draft-josefsson-pkix-dns.txt > > which do discuss it for S/MIME context as well. I don't have an > opinion on if this WG is the proper place for it. > > Regards, > Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMovqt018869 for ; Wed, 13 Aug 2003 15:50:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMovKH018868 for ietf-smime-bks; Wed, 13 Aug 2003 15:50:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMouqt018863 for ; Wed, 13 Aug 2003 15:50:56 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7DMomD22772 for ; Wed, 13 Aug 2003 15:50:48 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJKY4300.X5O; Wed, 13 Aug 2003 15:50:27 -0700 Date: Wed, 13 Aug 2003 15:51:44 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: RE: dissemination of public encryption certificates To: "Blake Ramsdell" cc: ietf-smime@imc.org In-Reply-To: Message-ID: <3F3AC100.8080103@netscape.com> References: X-Mailer: AOL Communicator (20030811Trnk.1 Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Blake, Sorry for the long delay in response - workload goes in spikes... Blake Ramsdell wrote on 08/08/2003, 19:41: > > My main question is : has any similar scheme been proposed ? I would > > rather work with something that exists, but if there is nothing that > > fits, I'm open to writing an RFC. > > Check out PKIX. They're not taking new drafts, but there may be > something useful for you there. Any work along these lines would most > likely be handled by that working group. Thanks. I joined the PKIX list and will keep an eye on the related drafts. -- I am the dog in dogfood --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlzCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUxggJ2MIICcgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMKQTIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTMyMjUxNDRaMCMGCSqGSIb3DQEJBDEWBBQRlErZ yGtWAA6ErujbBwOxguAa0jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASCAQAWhgV4CTxNLqCgdRlLD3vi/46cvqxlMgGxZZIvFPdX0okyVgoA8IZ14u2S CCSvzKmqYsX66rsccCHo0q2kzn13qNyqy3nGsfeXsvkgbhmmtOKQUbNe19CTmSz1uXb25VPJ h2jaucbGrgphxSwURuW9cR0AzfFfoBqjPy8eGT81FlL8uiRnX+pUI6yfDF+mJzAvzGSFselO qqmS6Yj39zKlK7sCbDBW8v2VAUMWvz9fBReYuABt3+xu19Mj3fu+k0l5e6Wbb4lu/hH9+9Ws lLN+1rYhrbK2TZohWqDlpxpRP3lABg/CeguJHOIg7wfTvf632qSb5CsEYJb6woC1mjtdAAAA AAAA --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM5tqt015325 for ; Wed, 13 Aug 2003 15:05:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DM5tw5015323 for ietf-smime-bks; Wed, 13 Aug 2003 15:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DM5rqt015304 for ; Wed, 13 Aug 2003 15:05:53 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 13 Aug 2003 15:05:50 -0700 From: "Blake Ramsdell" To: "'Anders Rundgren'" , "'Simon Josefsson'" Cc: , "'Sean P. Turner'" Subject: RE: PKI and S/MIME Date: Wed, 13 Aug 2003 15:05:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <006901c361be$9f4ba080$0500a8c0@arport> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, August 13, 2003 10:16 AM > To: Blake Ramsdell; Simon Josefsson > Cc: ietf-smime@imc.org; 'Sean P. Turner' > Subject: Re: PKI and S/MIME > > I respect your work with DNS for location but is this really > universal? How about my anders.rundgren@telia.com cert > issued by VeriSign? Would it be appropriate to require ISPs > like Telia to maintain a directory pointing to various TTP CAs? > > Or should ever domain-owner become a CA? One thing to keep in mind is that I'm not sure that there is any clear "universality" for *any* protocol that we might consider -- if there existed something universal, we'd have a de facto standard that we'd simply convert to an RFC and be done with it. If I were going to hazard a guess about widely deployed public certificate repositories, I would say that there would be a better argument for LDAP than anything else. Notice the careful wording here ;). As much as the attempts to automatically map from an email address to an LDAP directory containing a certificate for that email address might not have progressed as well as we might like, I think that there is some hope of that being addressed through the SRV record which is (as far as I can tell) widely supported by DNS implementations. A better question for the DNS distribution of certificates is whether or not this smells like it would be the most likely thing to get deployed. My understanding is that you would need DNS servers that supported the particular record types required for this functionality, as well as administrative tools to upgrade those records that are different than typical DNS administration tools. To me, that doesn't smell as good. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHHeqt000448 for ; Wed, 13 Aug 2003 10:17:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DHHe7x000447 for ietf-smime-bks; Wed, 13 Aug 2003 10:17:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHHcqt000431 for ; Wed, 13 Aug 2003 10:17:39 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t8o913p20.telia.com [213.64.26.140]) by smtp1.fre.skanova.net (8.12.9/8.12.9) with SMTP id h7DHHJqJ014039; Wed, 13 Aug 2003 19:17:20 +0200 (CEST) Message-ID: <006901c361be$9f4ba080$0500a8c0@arport> From: "Anders Rundgren" To: "Blake Ramsdell" , "Simon Josefsson" Cc: , "'Sean P. Turner'" References: Subject: Re: PKI and S/MIME Date: Wed, 13 Aug 2003 19:16:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon, I respect your work with DNS for location but is this really universal? How about my anders.rundgren@telia.com cert issued by VeriSign? Would it be appropriate to require ISPs like Telia to maintain a directory pointing to various TTP CAs? Or should ever domain-owner become a CA? Anders ----- Original Message ----- From: "Simon Josefsson" To: "Blake Ramsdell" Cc: ; "'Sean P. Turner'" Sent: Wednesday, August 13, 2003 09:32 Subject: Re: PKI and S/MIME "Blake Ramsdell" writes: > There have been a number of messages recently about the use of PKI with > S/MIME, and the concerns about that. I like to think that we're all > pretty much in agreement that we've established a consistent, > interoperable practice for the actual syntax and contents of S/MIME > messages, as well as a reasonable cut of a certificate syntax profile > for end-entity certificates. > > Should there be a profile for certificate usage (certificate repository, > distribution and revocation checking) that is specific for our problem > domain? That is, select relevant other work and profile it for use in > the S/MIME interpersonal messaging domain? I would imagine that this > would be a new draft, start with a summary of the requirements, and > progress to profiles of relevant standards. > > It's also not clear if this is something to discuss in this working > group, or somewhere else. > > Comments? Since in practice, addressing this problem would help in getting "opportunistic S/MIME" to work, I believe it would be useful to address it. ("Opportunistic S/MIME" means to be able to encrypt messages to someone you don't have a prior trust relationship with, simply to provide encryption of data. There is a man in the middle attack, of course, but in practice the result often isn't worse than not using S/MIME.) A strawman at a requirement: * Be able to locate a certificate for a Internet user given only her email address. I should mention that this has been discussed several times before, in various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so there is prior work to look at how to design this. To do even more self-promoting, I'd again like to mention the following draft: http://josefsson.org/draft-josefsson-pkix-dns.txt which do discuss it for S/MIME context as well. I don't have an opinion on if this WG is the proper place for it. Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D7WPqt047965 for ; Wed, 13 Aug 2003 00:32:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D7WPfH047964 for ietf-smime-bks; Wed, 13 Aug 2003 00:32:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D7WMqt047949 for ; Wed, 13 Aug 2003 00:32:23 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7D7WGdk014631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 13 Aug 2003 09:32:17 +0200 To: "Blake Ramsdell" Cc: , "'Sean P. Turner'" Subject: Re: PKI and S/MIME References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030813:blake@brutesquadlabs.com:2904f722dfddfbf5 X-Hashcash: 0:030813:blake@brutesquadlabs.com:2904f722dfddfbf5 X-Payment: hashcash 1.2 0:030813:ietf-smime@imc.org:0cf67d0c6ed0a93f X-Hashcash: 0:030813:ietf-smime@imc.org:0cf67d0c6ed0a93f X-Payment: hashcash 1.2 0:030813:turners@ieca.com:d13a99f396e04eda X-Hashcash: 0:030813:turners@ieca.com:d13a99f396e04eda Date: Wed, 13 Aug 2003 09:32:16 +0200 In-Reply-To: (Blake Ramsdell's message of "Tue, 12 Aug 2003 19:47:28 -0700") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: > There have been a number of messages recently about the use of PKI with > S/MIME, and the concerns about that. I like to think that we're all > pretty much in agreement that we've established a consistent, > interoperable practice for the actual syntax and contents of S/MIME > messages, as well as a reasonable cut of a certificate syntax profile > for end-entity certificates. > > Should there be a profile for certificate usage (certificate repository, > distribution and revocation checking) that is specific for our problem > domain? That is, select relevant other work and profile it for use in > the S/MIME interpersonal messaging domain? I would imagine that this > would be a new draft, start with a summary of the requirements, and > progress to profiles of relevant standards. > > It's also not clear if this is something to discuss in this working > group, or somewhere else. > > Comments? Since in practice, addressing this problem would help in getting "opportunistic S/MIME" to work, I believe it would be useful to address it. ("Opportunistic S/MIME" means to be able to encrypt messages to someone you don't have a prior trust relationship with, simply to provide encryption of data. There is a man in the middle attack, of course, but in practice the result often isn't worse than not using S/MIME.) A strawman at a requirement: * Be able to locate a certificate for a Internet user given only her email address. I should mention that this has been discussed several times before, in various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so there is prior work to look at how to design this. To do even more self-promoting, I'd again like to mention the following draft: http://josefsson.org/draft-josefsson-pkix-dns.txt which do discuss it for S/MIME context as well. I don't have an opinion on if this WG is the proper place for it. Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2lVqt023796 for ; Tue, 12 Aug 2003 19:47:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D2lVdD023795 for ietf-smime-bks; Tue, 12 Aug 2003 19:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D2lUqt023778 for ; Tue, 12 Aug 2003 19:47:30 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 12 Aug 2003 19:47:27 -0700 From: "Blake Ramsdell" To: Cc: "'Sean P. Turner'" Subject: PKI and S/MIME Date: Tue, 12 Aug 2003 19:47:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There have been a number of messages recently about the use of PKI with S/MIME, and the concerns about that. I like to think that we're all pretty much in agreement that we've established a consistent, interoperable practice for the actual syntax and contents of S/MIME messages, as well as a reasonable cut of a certificate syntax profile for end-entity certificates. Should there be a profile for certificate usage (certificate repository, distribution and revocation checking) that is specific for our problem domain? That is, select relevant other work and profile it for use in the S/MIME interpersonal messaging domain? I would imagine that this would be a new draft, start with a summary of the requirements, and progress to profiles of relevant standards. It's also not clear if this is something to discuss in this working group, or somewhere else. Comments? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGX0qt085744 for ; Tue, 12 Aug 2003 09:33:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CGX0FA085743 for ietf-smime-bks; Tue, 12 Aug 2003 09:33:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CGWxqt085730 for ; Tue, 12 Aug 2003 09:32:59 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t10o913p62.telia.com [213.64.27.182]) by smtp2.fre.skanova.net (8.12.9/8.12.9) with SMTP id h7CGWooe016255; Tue, 12 Aug 2003 18:32:50 +0200 (CEST) Message-ID: <001301c360ef$41128990$0500a8c0@arport> From: "Anders Rundgren" To: "Julien Pierre" , Cc: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> Subject: Re: dissemination of public encryption certificates Date: Tue, 12 Aug 2003 18:31:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pierre, It is good to hear somebody bring up this question which is absolutely vital for successful deployment of encrypted mail. Personally I don't think that neither the S/MIME WG or XKMS WG have a solution that at least I would call "acceptable". XKMS addresses to some extent the enterprise scenario but only if the enterprise has their own domain and associated CA. For truly TTP-based certificates you are out of luck if you are looking for automated functionality. I believe that the mail protocol and associated applications should be augmented with encryption certificate lookup. A MIME X-extension that you configured in your e-mail client would do a part of this. I.e. each time you sent a mail, the lookup would be transmitted as well. Also it would be nice to have an enhanced "mailto:" URL supporting the same mechanism. In summary I think that a certificate-independent configuration of e-mail clients would be more universal than "fishing" in domains as the user domain and issuer domain may be entirely disjunct. Anders ----- Original Message ----- From: "Hallam-Baker, Phillip" To: ; Sent: Tuesday, August 12, 2003 01:55 Subject: RE: dissemination of public encryption certificates Hi, This issue is one of the main use cases for XKMS. This has considerable support within the PKI community, VeriSign, Microsoft, RSA, Entrust and Baltimore have been involved in writing the specification which is in the final post last call stage in W3C. The (almost) final spec is to be found at http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html There will be two further changes to the spec, one to make a minor tweak to the schema sometime this week, the second to change the examples to use exclusive C18N. An XKMS locate service may be advertised in the DNS using the SRV record. So to send mail to alice@example.com you do an XKMS locate to _xkms_http._tcp.example.com. That gives you the XKMS service. You then do a locate for a certificate to be used with S/MIME. Phill > -----Original Message----- > From: jpierre@netscape.com [mailto:jpierre@netscape.com] > Sent: Friday, August 08, 2003 10:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my > responsibilities > for several years has been to maintain the open source > Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The > NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. > > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient > S/MIME e-mail > encryption certificates ? > > Thanks. > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CBQXqt058444 for ; Tue, 12 Aug 2003 04:26:33 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CBQXW5058443 for ietf-smime-bks; Tue, 12 Aug 2003 04:26:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CBQQqt058432 for ; Tue, 12 Aug 2003 04:26:31 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7CBQFdk023178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 12 Aug 2003 13:26:15 +0200 To: "Alberto Cozer" Cc: jpierre@netscape.com (Julien Pierre), ietf-smime@imc.org Subject: Re: dissemination of public encryption certificates References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030812:acozer@fti.com.br:c720615954f0da08 X-Hashcash: 0:030812:acozer@fti.com.br:c720615954f0da08 X-Payment: hashcash 1.2 0:030812:jpierre@netscape.com:3eff6f14a0f2077e X-Hashcash: 0:030812:jpierre@netscape.com:3eff6f14a0f2077e X-Payment: hashcash 1.2 0:030812:ietf-smime@imc.org:79512a673eba340a X-Hashcash: 0:030812:ietf-smime@imc.org:79512a673eba340a Date: Tue, 12 Aug 2003 13:26:15 +0200 In-Reply-To: (Alberto Cozer's message of "Tue, 12 Aug 2003 18:19:00 -0300") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien, Alberto, There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538. Unfortunately it doesn't include useful RR owner name guidelines to make it work in practice. I have made some clarifications for this in http://josefsson.org/draft-josefsson-pkix-dns.txt which also includes recommended owner names for S/MIME certificates. The document has expired on the IETF servers, but if there is interest in picking up this, let me know. (The idea has been implemented in experimental environments. Similar solutions for OpenPGP are freely available. I did my master's thesis on distributing certificate via DNS, to allow for "opportunistic email encryption".) Regards, Simon "Alberto Cozer" writes: > Julien, > > I have seen this idea in the past, but so far no RFC nor any agency > officialy documented it. We should have an hierarchical structure for > public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy > itself could be used for that. We could have a new DNS record type (DRY, > from Directory, for instance). Then, as mail servers and clients consult > MX record to deliver a message they could check for the DRY record to > deliver S/MIME messages. Without this DRY record set in the DNS zone file, > must be possible to deliver a signed message but impossible to deliver an > encrypted one. > > In my oppinion it is really hard to solve the public keys problem without > changing the way people send e-mails. With minor changes in the DNS and > E-MAIL RFC's would be possible to have people sending and receiving > encrypted mail transparently in a couple of years. > > Best regards, > > Alberto Cozer > Security Outsource Director, Future Technologies Digital Security > IBM Certified AIX System Specialist > Checkpoint Certified Security Expert, CCSE NG > acozer@fti.com.br > http://www.fti.com.br > Tel / Fax: 55 (21) 2522-5362 > > > > > > > jpierre@netscape.com (Julien Pierre) > Sent by: owner-ietf-smime@mail.imc.org > 08/08/2003 23:07 > > To: ietf-smime@imc.org > cc: > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my responsibilities > for several years has been to maintain the open source Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to send encrypted > e-mail to somebody knowing his e-mail address, what's a systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to transmit the > public encryption certificate before both parties can exchange encrypted > messages. > > There are also ways to find recipient certificates today using corporate > directory servers, but users must know about them and manually configure > them in their applications, and they are typically not widely available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient S/MIME e-mail > encryption certificates ? > > Thanks. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNtuqt087687 for ; Mon, 11 Aug 2003 16:55:56 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BNtuSu087685 for ietf-smime-bks; Mon, 11 Aug 2003 16:55:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BNttqt087678 for ; Mon, 11 Aug 2003 16:55:55 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7BNtvil028240; Mon, 11 Aug 2003 16:55:57 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 16:55:57 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01112FFC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'jpierre@netscape.com'" , ietf-smime@imc.org Subject: RE: dissemination of public encryption certificates Date: Mon, 11 Aug 2003 16:55:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0034_01C36042.904784A0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C36042.904784A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This issue is one of the main use cases for XKMS. This has considerable support within the PKI community, VeriSign, Microsoft, RSA, Entrust and Baltimore have been involved in writing the specification which is in the final post last call stage in W3C. The (almost) final spec is to be found at http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html There will be two further changes to the spec, one to make a minor tweak to the schema sometime this week, the second to change the examples to use exclusive C18N. An XKMS locate service may be advertised in the DNS using the SRV record. So to send mail to alice@example.com you do an XKMS locate to _xkms_http._tcp.example.com. That gives you the XKMS service. You then do a locate for a certificate to be used with S/MIME. Phill > -----Original Message----- > From: jpierre@netscape.com [mailto:jpierre@netscape.com] > Sent: Friday, August 08, 2003 10:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > > Hi, > > Since this is my first posting to this mailing list, let me introduce > myself : > > I'm a software engineer in AOL / Netscape and one of my > responsibilities > for several years has been to maintain the open source > Netscape Security > Services (NSS) library, which is used in the Mozilla browsers, many > Netscape and Sun servers, and other internal products. The > NSS library > contains an implementation of S/MIME v3. > > I was wondering what thoughts you may have on the following problem : > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? > > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. > > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. > > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. > > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. > > Also, what are the other ways that people locate recipient > S/MIME e-mail > encryption certificates ? > > Thanks. > > > ------=_NextPart_000_0034_01C36042.904784A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILizCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICED71tdHM9i4jiA298PD00EgwDQYJKoZIhvcN AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTAzMDMwNjAwMDAwMFoXDTA0MDMwNTIzNTk1OVowbTERMA8GA1UEChMIVkVS SVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFrZXIg KEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALnb2fFyN844Cl9FoNaBDI8P+O4JliUWbYoS/H5ebiL9BiGWuVAXoo1TAaB/SHU6 Sw12kMz9z7gL+HW09pG9kofKMikS3baa49tG5t/Ap7wOnVNmLgelD5d/JuYi3d5J94N9qh2krJqP auD5FjEbnTQ/Op2NHQzivxnE+g0cdDLJAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRS MFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFu Z2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJha2Vy QHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCi33oiw4urer1XI46PtYSjUD2W43Q+Ez8T9XJo Ewtc3mfUOuEw/PAH7VU3pLjUm6QfGe6W3xRzedAhAWzG1mWKK5vAq4Nnu8tpIV14PdxeXfKWM1Z0 Jw/1MHijGcoqLU9i3a1HYz/pF2A7/mibKe8Le+nJXV5q+XSAaL7K1ZcV3zGCAvgwggL0AgEBMIHB MIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQQIQPvW10cz2LiOIDb3w8PTQSDAJBgUrDgMCGgUAoIIBjDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MTEyMzU1NTBaMCMGCSqGSIb3DQEJBDEWBBQ8kk0t G7LzjA5g2iX4qwOGBhrf/TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYB BAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh c3MgMiBFbXBsb3llZSBDQQIQPvW10cz2LiOIDb3w8PTQSDANBgkqhkiG9w0BAQEFAASBgJ/ZRRua wcpRB9Gj17UEhIJ/w1XYMh7riw2AwvvbEDfYo/gTGDuRHWZGm6LvMmx10qCJNPUGP7+espvl+iyY J3Z/TfwePbeY6B2qfeHhOrVgXUJqYy/wDWjjccRq6+H+vP58TDRRYls7bfvpCtfVb2YK9fJVKts7 Tt9MlPgsudo8AAAAAAAA ------=_NextPart_000_0034_01C36042.904784A0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLOIqt076209 for ; Mon, 11 Aug 2003 14:24:18 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BLOIiI076208 for ietf-smime-bks; Mon, 11 Aug 2003 14:24:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from morpheus.future (mlsrj200152109p016.mls.com.br [200.152.109.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BLNJqt076039 for ; Mon, 11 Aug 2003 14:23:24 -0700 (PDT) (envelope-from acozer@fti.com.br) Received: from aurora.fti.com.br (unverified) by morpheus.future (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Aug 2003 18:20:12 -0300 In-Reply-To: <3F34575C.2090205@netscape.com> To: jpierre@netscape.com (Julien Pierre) Cc: ietf-smime@imc.org, owner-ietf-smime@mail.imc.org Subject: Re: dissemination of public encryption certificates MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1CF2 June 5, 2003 Message-ID: From: "Alberto Cozer" Date: Tue, 12 Aug 2003 18:19:00 -0300 X-MIMETrack: S/MIME Sign by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, Serialize by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, Serialize complete at 11/08/2003 18:17:15, Itemize by Notes Client on Alberto Cozer/Fti(Release 6.0.1CF2|June 5, 2003) at 11/08/2003 18:17:15, S/MIME Sign complete at 11/08/2003 18:17:15, Serialize by Router on aurora/Fti(Release 5.0.9a |January 7, 2002) at 12/08/2003 18:19:01, Serialize complete at 12/08/2003 18:19:01 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z2829_boundary_sign Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z2829_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0074EFA583256D7F_=" This is a multipart message in MIME format. --=_alternative 0074EFA583256D7F_= Content-Type: text/plain; charset="US-ASCII" Julien, I have seen this idea in the past, but so far no RFC nor any agency officialy documented it. We should have an hierarchical structure for public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy itself could be used for that. We could have a new DNS record type (DRY, from Directory, for instance). Then, as mail servers and clients consult MX record to deliver a message they could check for the DRY record to deliver S/MIME messages. Without this DRY record set in the DNS zone file, must be possible to deliver a signed message but impossible to deliver an encrypted one. In my oppinion it is really hard to solve the public keys problem without changing the way people send e-mails. With minor changes in the DNS and E-MAIL RFC's would be possible to have people sending and receiving encrypted mail transparently in a couple of years. Best regards, Alberto Cozer Security Outsource Director, Future Technologies Digital Security IBM Certified AIX System Specialist Checkpoint Certified Security Expert, CCSE NG acozer@fti.com.br http://www.fti.com.br Tel / Fax: 55 (21) 2522-5362 jpierre@netscape.com (Julien Pierre) Sent by: owner-ietf-smime@mail.imc.org 08/08/2003 23:07 To: ietf-smime@imc.org cc: Subject: dissemination of public encryption certificates Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. --=_alternative 0074EFA583256D7F_= Content-Type: text/html; charset="US-ASCII"
Julien,

I have seen this idea in the past, but so far no RFC nor any agency officialy documented it. We should have an hierarchical structure for public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy itself could be used for that. We could have a new DNS record type (DRY, from Directory, for instance). Then, as mail servers and clients consult MX record to deliver a message they could check for the DRY record to deliver S/MIME messages. Without this DRY record set in the DNS zone file, must be possible to deliver a signed message but impossible to deliver an encrypted one.

In my oppinion it is really hard to solve the public keys problem without changing the way people send e-mails. With minor changes in the DNS and E-MAIL RFC's would be possible to have people sending and receiving encrypted mail transparently in a couple of years.

Best regards,

Alberto Cozer
Security Outsource Director, Future Technologies Digital Security
IBM Certified AIX System Specialist
Checkpoint Certified Security Expert, CCSE NG
acozer@fti.com.br
http://www.fti.com.br
Tel / Fax: 55 (21) 2522-5362


jpierre@netscape.com (Julien Pierre)
Sent by: owner-ietf-smime@mail.imc.org

08/08/2003 23:07

       
        To:        ietf-smime@imc.org
        cc:        
        Subject:        dissemination of public encryption certificates



Hi,

Since this is my first posting to this mailing list, let me introduce
myself :

I'm a software engineer in AOL / Netscape and one of my responsibilities
for several years has been to maintain the open source Netscape Security
Services (NSS) library, which is used in the Mozilla browsers, many
Netscape and Sun servers, and other internal products. The NSS library
contains an implementation of S/MIME v3.

I was wondering what thoughts you may have on the following problem :

If I have a keypair and e-mail certificate, and I want to send encrypted
e-mail to somebody knowing his e-mail address, what's a systematic way
to obtain the recipient's encryption certificate ?

Traditionally today, signed e-mail messages typically contain the
signer's public encryption certificate. However that means one party
needs to first send a signed unencrypted, e-mail message to transmit the
public encryption certificate before both parties can exchange encrypted
messages.

There are also ways to find recipient certificates today using corporate
directory servers, but users must know about them and manually configure
them in their applications, and they are typically not widely available
on the Internet.

I'm envisioning some standardized scheme where, by starting with the
recipient's email address, it would be possible to locate a public
directory server, then find the recipient's certificate by looking it up
in that directory server.

My main question is : has any similar scheme been proposed ? I would
rather work with something that exists, but if there is nothing that
fits, I'm open to writing an RFC.

Also, what are the other ways that people locate recipient S/MIME e-mail
encryption certificates ?

Thanks.
--=_alternative 0074EFA583256D7F_=-- ---------z2829_boundary_sign 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 MIAGCSqGSIb3DQEHAqCAMIIc8AIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIbFDCCAqEw ggIKoAMCAQICCwEAAAAAAPEWHPl1MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAyIENBMR4wHAYDVQQDExVHbG9i YWxTaWduIENsYXNzIDIgQ0EwHhcNMDIxMDI0MTExNTE1WhcNMDMxMDI0MTExNTE1WjBHMQswCQYD VQQGEwJCUjEWMBQGA1UEAxMNQWxiZXJ0byBDb3plcjEgMB4GCSqGSIb3DQEJARYRYWNvemVyQGZ0 aS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALSlYvrVUWMEuGmZs1ln5SHtFwbb cs+HfQljbe6VIAkWGz/plRBlr6qytgw1vDnSF83pxsVZOCJHy1qKqkNPoeS3tTdkRCy0ws9xsPYU 1brCB9icDyfh0yZTLvCgST32vDO8wimTheow8M1HyrXN1Cja5gfLUC9s2vtQ6sQd4rRhAgMBAAGj fTB7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBPAwHwYDVR0jBBgwFoAUEW7XkWDL BuRXAFeonIC9djPlWVEwNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5nbG9iYWxzaWduLm5l dC9jbGFzczIuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAK80csAhahcjHH3EycwEOT0SflMqTrni5+OA +P/hjAF9qbsuvkmPUWeaBiN9T1ylu/LurWVNkh8wYAFjDyuiMC1FgxwaoeE/oaDHF9BRjQf7IFlX ruBDMtJultnegNS+b0natY+hhijsoFr7PgHjS8Kk8RGtLKofY0RUQ5J/6FNXMIICoTCCAgqgAwIB AgILAQAAAAAA8RYc+XUwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEds b2JhbFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDIgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24g Q2xhc3MgMiBDQTAeFw0wMjEwMjQxMTE1MTVaFw0wMzEwMjQxMTE1MTVaMEcxCzAJBgNVBAYTAkJS MRYwFAYDVQQDEw1BbGJlcnRvIENvemVyMSAwHgYJKoZIhvcNAQkBFhFhY296ZXJAZnRpLmNvbS5i cjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtKVi+tVRYwS4aZmzWWflIe0XBttyz4d9CWNt 7pUgCRYbP+mVEGWvqrK2DDW8OdIXzenGxVk4IkfLWoqqQ0+h5Le1N2RELLTCz3Gw9hTVusIH2JwP J+HTJlMu8KBJPfa8M7zCKZOF6jDwzUfKtc3UKNrmB8tQL2za+1DqxB3itGECAwEAAaN9MHswEQYJ YIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE8DAfBgNVHSMEGDAWgBQRbteRYMsG5FcAV6ic gL12M+VZUTA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L2NsYXNz Mi5jcmwwDQYJKoZIhvcNAQEFBQADgYEArzRywCFqFyMcfcTJzAQ5PRJ+UypOueLn44D4/+GMAX2p uy6+SY9RZ5oGI31PXKW78u6tZU2SHzBgAWMPK6IwLUWDHBqh4T+hoMcX0FGNB/sgWVeu4EMy0m6W 2d6A1L5vSdq1j6GGKOygWvs+AeNLwqTxEa0sqh9jRFRDkn/oU1cwggN1MIICXaADAgECAgsCAAAA AADWeLeUBTANBgkqhkiG9w0BAQQFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4X DTk4MDkwMTEyMDAwMFoXDTE0MDEyODEyMDAwMFowVzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEds b2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANoO5pmNzqPjT4p++/GLgyVr6kgf 8SqwuZURBL3wY9HiZ2bPHN3PG0gr7o2JjpqvKYBlq+nHLRLLqxxMcAehPQowzRWNT/jd1IxQFRzv UO7ELvf86VLykX3gbdU1MI5eQ3PyQenVauOyiTpWOThvBjyIaVsqTcWnVLhsicyb+TzK5f2J9RI8 kniW1tx0bpNEYdGNx0aydQ6G6BmK1W1s1XgWlaLpyAo46/IkE09zVJMThTobvB40tYsFjLl3i7Hb HyCRqwlTbpDOezd0uXBHkSJRYxZ5rrGuQSYIyBkr0UaqSNZkKteDNP8sKsFsGUNKB4Xn03z2IWjv 6vJSn3+TkM8CAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBRge2YaRQ2XyolQL30E zTSo//z9SzAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4IBAQCuqp/8t9LLH185KSgY njTJbE9vGvBkonBKTxOGm2AonuiBSZh9CrvlsJ09NtuPBVH/CTEqH92Jd54PLmyVBO2Gy7QAP4QC TYBqKi14C65vK6KDRIMfzVCCTCSvvfeltMhaD/TnR15JjjeW/pqIBTrZwNsph+YZlkenOqaMizx3 /kZjp1PaIdGsfkmiS+bDZ1kvs4oOuyy9qapCfDXB2H/VpzE6TmNDOa8IsGE0jNOYqUM09g+HKTud wlZYmHfD9xus9p34PqqnVEXw9fnVMWX+a1iccbMe11LqMhf8QGAdyXkksvZs/ahmDoLdmMvawkRP LqB78vdrLHYRhEaKeKPjMIIDdTCCAl2gAwIBAgILAgAAAAAA1ni3lAUwDQYJKoZIhvcNAQEEBQAw VzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3Qg Q0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0xNDAxMjgx MjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQL EwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDaDuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6N iY6arymAZavpxy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp 1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVt bNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6x rkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIABjAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDwYDVR0TAQH/BAUwAwEB /zANBgkqhkiG9w0BAQQFAAOCAQEArqqf/LfSyx9fOSkoGJ40yWxPbxrwZKJwSk8ThptgKJ7ogUmY fQq75bCdPTbbjwVR/wkxKh/diXeeDy5slQTthsu0AD+EAk2AaioteAuubyuig0SDH81Qgkwkr733 pbTIWg/050deSY43lv6aiAU62cDbKYfmGZZHpzqmjIs8d/5GY6dT2iHRrH5Jokvmw2dZL7OKDrss vamqQnw1wdh/1acxOk5jQzmvCLBhNIzTmKlDNPYPhyk7ncJWWJh3w/cbrPad+D6qp1RF8PX51TFl /mtYnHGzHtdS6jIX/EBgHcl5JLL2bP2oZg6C3ZjL2sJETy6ge/L3ayx2EYRGinij4zCCA4EwggJp oAMCAQICCwQAAAAAAPB2A+jeMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQK ExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMT HUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAyIENBMB4XDTk5MDEyODEyMDAwMVoXDTA0MDEyODEy MDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEzARBgNVBAsT CkNsYXNzIDIgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24gQ2xhc3MgMiBDQTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA2FFbD5PHSWB3URSO4511dR7JhQ5/TAMZGXak7nor/IMGA8ecFpq+jk4R CkB/rDKJ08F5/PlE0YdTz9vTuy1fKbn6uhH7VKLbxtPmtcCIL7VOAofcy5sZefa/3TR63jOFWugy dc9DYUUN48iHO0cQoeXfLWwHBkf5Ttj79oSeDMMCAwEAAaOBtTCBsjAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUEW7XkWDLBuRXAFeonIC9djPlWVEwOQYDVR0f BDIwMDAuoCygKoYoaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QcmltQ2xhc3MyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwHwYDVR0jBBgwFoAUfOeysSzesadr6XYM4aP9TmzHufYwDQYJKoZIhvcN AQEFBQADggEBAI97Kr0tlyP5Q0cC8eNRGd843faTutQNQrKn56iuz1cOmMOAy24QJkXvRptDuJKr W9qGUc4dMPHkeOVpAmiifCNFqkFG8X+quxCeUP8jLENsyE+mn9w/VbHfmNppA2qWW7aCiRGdmlhJ JmjV/nB/6R+daSzL5BDa3P6wifcxvzbgOy+JZlIutHSgi33Y8ndR9LXOLwAr3SN2ryMYSsYMe9vz smgFNFNFSVORDVeu86GGx2EDnpe+ENMdu/WIAdwtI2x7gf3ljWSihDRm6xCkTVlKEtH/d12hnU8v Tx5o1aFwRnQCs7YOI3NBCBp9O7qlrSAHpFMnAaQU/Q0gN6I+Md0wggOBMIICaaADAgECAgsEAAAA AADwdgPo3jANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEbMBkGA1UECxMSUHJpbWFyeSBDbGFzcyAyIENBMSYwJAYDVQQDEx1HbG9iYWxTaWdu IFByaW1hcnkgQ2xhc3MgMiBDQTAeFw05OTAxMjgxMjAwMDFaFw0wNDAxMjgxMjAwMDBaMF0xCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAyIENB MR4wHAYDVQQDExVHbG9iYWxTaWduIENsYXNzIDIgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANhRWw+Tx0lgd1EUjuOddXUeyYUOf0wDGRl2pO56K/yDBgPHnBaavo5OEQpAf6wyidPBefz5 RNGHU8/b07stXym5+roR+1Si28bT5rXAiC+1TgKH3MubGXn2v900et4zhVroMnXPQ2FFDePIhztH EKHl3y1sBwZH+U7Y+/aEngzDAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFBFu15FgywbkVwBXqJyAvXYz5VlRMDkGA1UdHwQyMDAwLqAsoCqG KGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvUHJpbUNsYXNzMi5jcmwwEQYJYIZIAYb4QgEBBAQD AgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2MA0GCSqGSIb3DQEBBQUAA4IBAQCP eyq9LZcj+UNHAvHjURnfON32k7rUDUKyp+eors9XDpjDgMtuECZF70abQ7iSq1vahlHOHTDx5Hjl aQJoonwjRapBRvF/qrsQnlD/IyxDbMhPpp/cP1Wx35jaaQNqllu2gokRnZpYSSZo1f5wf+kfnWks y+QQ2tz+sIn3Mb824DsviWZSLrR0oIt92PJ3UfS1zi8AK90jdq8jGErGDHvb87JoBTRTRUlTkQ1X rvOhhsdhA56XvhDTHbv1iAHcLSNse4H95Y1kooQ0ZusQpE1ZShLR/3ddoZ1PL08eaNWhcEZ0ArO2 DiNzQQgafTu6pa0gB6RTJwGkFP0NIDeiPjHdMIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJ KoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAO BgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAw MDBaFw0wOTAxMjgxMjAwMDBaMG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52 LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJp bWFyeSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdB bvzYvyFvqwadUsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq6 2O7rim+ftrsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/ 7h0MxKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl/3BQ 9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAqMCigJqAkhiJo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAv fQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2ZioidZVbZLmecRI30bfezE8W YEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGBqGQzlPGtnVpbADfipFzkIKpg dJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCWkf7KDCruRY51KismvY6uCN2LuVeN /20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFqFEiluobJ33wmE54tbMhb9Wt8HzhnL47U 16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGdVAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqB MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds b2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBaMG0xCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNz IDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAyIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwadUsEsAJ0/joW4f0qPvaBjKspJ J65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+ftrsoQcAi+05IGgaS17/Xz7nZvThP Ow1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0MxKhrT3VoVujcKBJQ96gknS4kOfsJBd7l o2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbje TVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl/3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZ MIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vp dgzho/1ObMe59jAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jv b3QuY3JsMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IB AQCOSXXBWIDxAxy2ZioidZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx /g3oQt8hUCLucQGBqGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYt vi9PKFx5qeCWkf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziN L3Ur1HFqFEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2m MhGdVAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMYIBtzCCAbMCAQEwbDBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMiBDQTEeMBwGA1UE AxMVR2xvYmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAADxFhz5dTAJBgUrDgMCGgUAoIGiMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxMTIxMTcxNVowIwYJKoZI hvcNAQkEMRYEFL9Z1gw/ncVI9YmdmD5cuYquJ+tsMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0w DgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIGASzySuWFtpSD8ZPlSa4nqulm37TtiZ2qi2c4xx9IgUNk7AeUUTL8+u4gagdUXJAliEU7Jm5ye HSxasmDf6FW2Z2aQY8yTpEdKwQmbbz4szaw63Sv4SNOAu7FLn9La7i0c/xl5inbeQVSH8NiXOkiu 1ypcAcRo+0wpqY+UXzx4on0AAAAA ---------z2829_boundary_sign-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInCqt065660 for ; Mon, 11 Aug 2003 11:49:12 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BInCla065659 for ietf-smime-bks; Mon, 11 Aug 2003 11:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BInAqt065646; Mon, 11 Aug 2003 11:49:10 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id A18056EF75; Mon, 11 Aug 2003 11:49:09 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , , "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" Subject: RE: Draft-11: More complete results Date: Mon, 11 Aug 2003 11:49:34 -0700 Message-ID: <003101c36039$4f5fd9f0$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7BInAqt065647 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, I don't know what I dumped the first time, but I now get the same CEKICV as you do. jim > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Saturday, August 09, 2003 1:17 AM > To: jimsch@exmsft.com; 'Ietf-Smime-Examples'; > ietf-smime@imc.org; 'Paul Hoffman / IMC' > Cc: 'Sean P. Turner' > Subject: RE: Draft-11: More complete results > > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Wednesday, August 06, 2003 2:30 PM > > To: 'Ietf-Smime-Examples'; ietf-smime@imc.org; 'Paul Hoffman / IMC' > > Cc: 'Sean P. Turner'; Blake Ramsdell > > Subject: Draft-11: More complete results > > > > 6.11 FAILED > > test vectors are appended below on this message. I > don't know where > > I am going wrong and this code worked in the past. > > The bad news is, I can't get this example to work either. > The good news is that I have written a new implementation, > and it could very well have some kind of problem. I have > only tested my implementation against the test vectors in RFC 3217. > > These are the results that I got with this example, using the > terminology from RFC 3217 section 3.2 wherever possible: > > > wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, > 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, > 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, > 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD > > TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, > 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, > 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, > 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B > > TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, > 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, > 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, > 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 > > TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, > 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, > 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, > 0x66, 0x10, 0xD7 > > IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5 > > CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, > 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, > 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, > 0x3B, 0x86, 0x2E, 0x3D > > CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, > 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, > 0x0F, 0x38, 0x47, 0x25, 0x2E > > ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D > > computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF > > > Mapping your results onto mine: > > > Wrapped key > > 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac > > t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 > 1f 0b 45 12 > > 4d fb dÌ.®¯Í..¶H..E.M. > > 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ > > > > Mail list key > > 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 > > %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f > > We're on the same page here. I did not dump my Mail list > key, but there are many problems I would have later if these > weren't the same. Specifically, the next item would not match. > > > After decrypt #1 > > 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e > > ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc > 02 d4 81 27 > > db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP > > 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ > > Same as TEMP3 from mine. > > > IV > > 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. > > Same as my IV also. > > > Post Decrypt #2 > > 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f > > PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 > 42 9a ee 66 > > 10 d7 ~N.µÞ.£b..B..f.× > > This should theoretically be the same as my CEKICV (which is > the output of the second decryption), but it's not. This > appears to be the same as my TEMP1 which is the input to the > second decryption, not the output. > > > Computed check sum > > 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ > > Same as my computedICV above. What I can't figure out is how > we both arrived at the same checksum with such different > answers for CEKICV (your "Post Decrypt #2"). My > understanding is that it's the first eight bytes of the sha-1 > digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2". > > > Actual Check sum > > 80 e0 42 9a ee 66 10 d7 > > This does not match my ICV above, but it matches the eight > bytes at the end of your "Post Decrypt #2". > > I would hazard a guess that there is an error in one of our > implementations where the input and the output of the second > decryption step are being mistakenly interchanged. I have > checked mine and run the test vectors from RFC 3217 through > it, and I can't see the problem on my side. Now, I've said > this kind of thing before and been wrong, so take it with a > grain of salt... > > In any case, in my test, this example is broken also, but > unless Jim and I can agree on an answer, it could be the case > that both of our implementations are broken. > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH9bqt059904 for ; Mon, 11 Aug 2003 10:09:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BH9bZm059903 for ietf-smime-bks; Mon, 11 Aug 2003 10:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BH9Yqt059895 for ; Mon, 11 Aug 2003 10:09:36 -0700 (PDT) (envelope-from Francois.Rousseau@CSE-CST.GC.CA) Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:15:49 -0400 Message-ID: <7246F1C4915E1E4B874E62AE51E8F4F8902E5C@broadsword.its.cse.dnd.ca> From: Francois.Rousseau@CSE-CST.GC.CA To: BonattiC@ieca.com Cc: ietf-smime@imc.org Subject: RE: Update of CMS-X.400 Drafts Date: Mon, 11 Aug 2003 13:15:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Chris, I am very sorry to not have noticed this before, but I did not see any mention of optionally supporting Compression (i.e. RFC3274) under WRAP like under MSGbis. Isn't compression something that could also be useful for X.400 content? Was this intentional? Cheers, Francois -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Saturday, August 09, 2003 11:32 AM To: ietf-smime@imc.org Subject: Update of CMS-X.400 Drafts With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTaqt057500 for ; Mon, 11 Aug 2003 09:29:36 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGTavQ057499 for ietf-smime-bks; Mon, 11 Aug 2003 09:29:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTWqt057492 for ; Mon, 11 Aug 2003 09:29:32 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22126; Mon, 11 Aug 2003 12:29:27 -0400 (EDT) Message-Id: <200308111629.MAA22126@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-x400transport-09.txt Date: Mon, 11 Aug 2003 12:29:26 -0400 Sender: owner-ietf-smime@mail.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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-09.txt Pages : 6 Date : 2003-8-8 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400transport-09.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-x400transport-09.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: <2003-8-11124925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11124925.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTVqt057489 for ; Mon, 11 Aug 2003 09:29:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGTVSw057488 for ietf-smime-bks; Mon, 11 Aug 2003 09:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGTRqt057475 for ; Mon, 11 Aug 2003 09:29:28 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22111; Mon, 11 Aug 2003 12:29:22 -0400 (EDT) Message-Id: <200308111629.MAA22111@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-x400wrap-08.txt Date: Mon, 11 Aug 2003 12:29:22 -0400 Sender: owner-ietf-smime@mail.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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-08.txt Pages : 11 Date : 2003-8-8 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-x400wrap-08.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-x400wrap-08.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: <2003-8-11124916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11124916.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8o8qt013352 for ; Mon, 11 Aug 2003 01:50:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B8o8Am013350 for ietf-smime-bks; Mon, 11 Aug 2003 01:50:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7B8o7qt013313 for ; Mon, 11 Aug 2003 01:50:07 -0700 (PDT) (envelope-from aalberti@axway.com) Received: (qmail 3660 invoked from network); 11 Aug 2003 08:50:02 -0000 Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 11 Aug 2003 08:50:02 -0000 Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 10:50:01 +0200 Message-ID: <2B77C2DE2313254A9065D1C3B68A0CFE1A7951@nt1022.pa.sopra> From: Alberti Antoine To: "'Julien Pierre'" , "'ietf-smime@imc.org'" Subject: RE: trust domains Date: Mon, 11 Aug 2003 10:50:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There was such an issue in TLS, solved, from the server point of view, by sending a list of trusted authorities when requesting a client authentication. However, this list was so ennoying to use for both sides that it is now almost always empty, indicating "Send me whatever you want, we'll see then". I agree that a work could be done on this topic, but it should done carefully to avoid this conclusion. Regards. -----Message d'origine----- De : owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]De la part de Julien Pierre Envoye : samedi 9 aout 2003 04:43 A : ietf-smime@imc.org Objet : trust domains Hi, Here is another problem with S/MIME deployment that I'd like to inquire about. Assuming that you have already obtained my public encryption certificate, for example by reading this message, there is no way for you to be certain what type of certificate I will trust if you send me e-mail, in particular what CAs I trust. If you have multiple certificates from different CAs, which one is the most appropriate to use when writing me writing signed and encrypted e-mail ? Nowadays, in Netscape applications (and in the new AOL communicator), each user can make a decision of which CAs he trusts for signing each type of certificate (SSL server, SSL client, email signing, email encryption ...). I call this set of CAs and the trust properties a user's "trust domain". Unlike an email certificate which is typically included in an S/MIME message's digital signature, my trust domain is not exposed to you. The only clue that you have when writing to me is that I probably trust the same Thawte freemail CA that issued my own public encryption certificate. However, if I had signed this message with my corporate certificate (and if my smartcard was working right now:)), you would not be able to get a certificate from the same CA, unless you were employed by the same company. One theoretical answer to the problem would be for you to sign your message with all the certificates you have, including multiple signatures, in the hope I would trust one. Today our mail clients only support a single signature, so that wouldn't work. But even if they did tomorrow, the software trust policy might be to not trust the message unless all its signatures are valid, so having one good signature and n bad signatures wouldn't help. You might send your message n times, each signed with a different certificate, but I would probably get annoyed. What I'm getting at is that there is a need to make the user's trust domain information available, so that senders get a hint of the proper certificate to use. This is similar to what happens in the SSL protocol when an SSL server requests client authentication. The SSL server provides a list of trusted CA certificates. The SSL client is then free to choose one to use if he has one that chains to a CA the server accepts. Of course the problem was easier to solve for SSL, since it is an online protocol, and S/MIME is not. My question is : is there any work going within the IETF to solve this problem for the S/MIME protocol ? And how have you been solving this problem today ? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7B8Zpqt009884 for ; Mon, 11 Aug 2003 01:35:51 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7B8ZpaK009883 for ietf-smime-bks; Mon, 11 Aug 2003 01:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7B8Zmqt009860 for ; Mon, 11 Aug 2003 01:35:50 -0700 (PDT) (envelope-from aalberti@axway.com) Received: (qmail 26940 invoked from network); 11 Aug 2003 08:35:41 -0000 Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 11 Aug 2003 08:35:41 -0000 Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 10:35:40 +0200 Message-ID: <2B77C2DE2313254A9065D1C3B68A0CFE1A7950@nt1022.pa.sopra> From: Alberti Antoine To: "'Julien Pierre'" , "'ietf-smime@imc.org'" Subject: RE: dissemination of public encryption certificates Date: Mon, 11 Aug 2003 10:35:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe some work is being done about this issue and DNS in the PKIX working group. Regards. -----Message d'origine----- De : owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]De la part de Julien Pierre Envoye : samedi 9 aout 2003 04:07 A : ietf-smime@imc.org Objet : dissemination of public encryption certificates Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h79FWiqt032426 for ; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h79FWiiM032425 for ietf-smime-bks; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h79FWhqt032417 for ; Sat, 9 Aug 2003 08:32:44 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from 1cust124.tnt7.bos2.da.uu.net (HELO OMNI) (bonattic@ieca.com@67.241.230.124 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 9 Aug 2003 15:32:44 -0000 Reply-To: From: "Bonatti, Chris" To: Subject: Update of CMS-X.400 Drafts Date: Sat, 9 Aug 2003 11:31:33 -0400 Organization: IECA, Inc. Message-ID: <001501c35e8b$7a715a60$7ce6f143@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h79FWiqt032419 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: With Paul and Anders help, I have addressed some outstanding IESG (or AD) comments that I did not hear of until after the Vienna meeting. The comments and their resolution are included below. I also updated WRAP so that it includes a specification of AES key sizes in alignment with the -05 issue of MSGbis. This latter issue was mentioned in my status report in Vienna. So you should look for an -08 issue of WRAP and an -09 issue of TRANSPORT in the Internet-Drafts directory in short order (posted Friday AM). Cheers! Chris ______WRAP COMMENTS________ 3.2----->"whatever gateway system that is bridging" seems grammatically wrong. Replaced with "any gateway system that might bridge the gap". 3.2.1---->"since it is out" should be "since it is outside"? Done. 3.3----->"If other binary transport" should "If another binary"? Replaced with "If other transport (e.g., X.400) that is optimized for binary content". I think that's clearer. 3.3.1------> "it is out" again, outside? Done. 3.4.1---> "7-bit transport, is optional" spurious comma. Done. 3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun. Replaced with "certs-only, which applies only to signed-only messages)". ______TRANSPORT COMMENTS________ 2.6.1--->"because those type do not" has subject/verb agreeement problem. Changed "type" to "types". 2.6.2-----> "A RecipeintInfo" should be "RecipientInfo". Done. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h798HNqt094089 for ; Sat, 9 Aug 2003 01:17:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h798HNwY094088 for ietf-smime-bks; Sat, 9 Aug 2003 01:17:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h798HMqt094070; Sat, 9 Aug 2003 01:17:22 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Sat, 9 Aug 2003 01:17:16 -0700 From: "Blake Ramsdell" To: , "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" Subject: RE: Draft-11: More complete results Date: Sat, 9 Aug 2003 01:17:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <005e01c35c61$dd8b8fc0$1400a8c0@augustcellars.local> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h798HMqu094081 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, August 06, 2003 2:30 PM > To: 'Ietf-Smime-Examples'; ietf-smime@imc.org; 'Paul Hoffman / IMC' > Cc: 'Sean P. Turner'; Blake Ramsdell > Subject: Draft-11: More complete results > > 6.11 FAILED > test vectors are appended below on this message. I don't know > where I am going wrong and this code worked in the past. The bad news is, I can't get this example to work either. The good news is that I have written a new implementation, and it could very well have some kind of problem. I have only tested my implementation against the test vectors in RFC 3217. These are the results that I got with this example, using the terminology from RFC 3217 section 3.2 wherever possible: wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7 IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5 CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF Mapping your results onto mine: > Wrapped key > 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac > t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 > 4d fb dÌ.®¯Í..¶H..E.M. > 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ > > Mail list key > 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 > %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f We're on the same page here. I did not dump my Mail list key, but there are many problems I would have later if these weren't the same. Specifically, the next item would not match. > After decrypt #1 > 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e > ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 > db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP > 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ Same as TEMP3 from mine. > IV > 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. Same as my IV also. > Post Decrypt #2 > 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f > PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 > 10 d7 ~N.µÞ.£b..B..f.× This should theoretically be the same as my CEKICV (which is the output of the second decryption), but it's not. This appears to be the same as my TEMP1 which is the input to the second decryption, not the output. > Computed check sum > 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ Same as my computedICV above. What I can't figure out is how we both arrived at the same checksum with such different answers for CEKICV (your "Post Decrypt #2"). My understanding is that it's the first eight bytes of the sha-1 digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2". > Actual Check sum > 80 e0 42 9a ee 66 10 d7 This does not match my ICV above, but it matches the eight bytes at the end of your "Post Decrypt #2". I would hazard a guess that there is an error in one of our implementations where the input and the output of the second decryption step are being mistakenly interchanged. I have checked mine and run the test vectors from RFC 3217 through it, and I can't see the problem on my side. Now, I've said this kind of thing before and been wrong, so take it with a grain of salt... In any case, in my test, this example is broken also, but unless Jim and I can agree on an answer, it could be the case that both of our implementations are broken. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h793idqt072427 for ; Fri, 8 Aug 2003 20:44:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h793idqK072426 for ietf-smime-bks; Fri, 8 Aug 2003 20:44:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h793icqt072418 for ; Fri, 8 Aug 2003 20:44:38 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 8 Aug 2003 20:44:36 -0700 From: "Blake Ramsdell" To: "'Julien Pierre'" , Subject: RE: trust domains Date: Fri, 8 Aug 2003 20:44:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F345FB7.1020008@netscape.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Julien Pierre > Sent: Friday, August 08, 2003 7:43 PM > To: ietf-smime@imc.org > Subject: trust domains > > Assuming that you have already obtained my public encryption > certificate, for example by reading this message, there is no way for > you to be certain what type of certificate I will trust if > you send me > e-mail, in particular what CAs I trust. Yup. > If you have multiple certificates from different CAs, which > one is the > most appropriate to use when writing me writing signed and encrypted > e-mail ? This seems to be a question of certificate policies and mapping those to the content being protected. That is, if the message being signed is just casual communication, use one certificate, and if it's a purchase order, use another one. Right now, I think that most clients pretty much allow the user to pick. Further, I think that a lot of folks just have one, so you'd better like it. > One theoretical answer to the problem would be for you to sign your > message with all the certificates you have, including multiple > signatures, in the hope I would trust one. Today our mail > clients only > support a single signature, so that wouldn't work. But even > if they did > tomorrow, the software trust policy might be to not trust the message > unless all its signatures are valid, so having one good > signature and n > bad signatures wouldn't help. You might send your message n > times, each > signed with a different certificate, but I would probably get annoyed. Well, I'm not sure that the semantic of multiple SignerInfos is that "if you verify them, you must verify all of them, and if you don't like any of them, freak out". I think it's more along the lines of "these are all equivalent, so go ahead and choose which one you like and run with it". > What I'm getting at is that there is a need to make the user's trust > domain information available, so that senders get a hint of > the proper > certificate to use. This might be interesting to discuss. You could make a capabilities extension where you could identify your roots (off the top of my head, I'd say using a hash of the certificate would work) and go from there. One concern is bloat -- I have over 100 roots on my machine configured with Outlook 2002 and IE6 that are all marked as suitable roots for "Secure email" (in the "secure email" trust domain, using your terms). Sending this stack of hashes with every signed message might make the world a worse place to address this issue. > This is similar to what happens in the SSL protocol when an > SSL server > requests client authentication. The SSL server provides a list of > trusted CA certificates. The SSL client is then free to choose one to > use if he has one that chains to a CA the server accepts. Of > course the > problem was easier to solve for SSL, since it is an online > protocol, and > S/MIME is not. I think the principle is the same, though. In the case of S/MIME, it's "sign with all of your certs". One problem is that you're going to potentially cart around a large number of certs -- each of your individual certs as well as the intermediate certs that go with them. And I'm not sure that there's enough experience with clients handling multiple signers to tell you what would happen if you used that feature. > My question is : is there any work going within the IETF to > solve this > problem for the S/MIME protocol ? And how have you been solving this > problem today ? >From what I can tell, today we solve the problem by having clients include every root key under the sun, and most certificates of significant public value are issued under those roots. Certificates that aren't issued under those roots are most likely corporate CA certificates, and typically folks just have to hunt around to find the right corporate root to install in order to verify the signatures. Peter Hesse and Sharon Boeyen have recently illustrated this problem on the PKIX list -- not directly, but by sending signed messages for which people don't have the root keys. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792gFqt070768 for ; Fri, 8 Aug 2003 19:42:15 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h792gFgF070767 for ietf-smime-bks; Fri, 8 Aug 2003 19:42:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792gEqt070761 for ; Fri, 8 Aug 2003 19:42:14 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h792g4i07409 for ; Fri, 8 Aug 2003 19:42:05 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJBZHT00.H31; Fri, 8 Aug 2003 19:41:53 -0700 Date: Fri, 8 Aug 2003 19:43:03 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: trust domains To: ietf-smime@imc.org Message-ID: <3F345FB7.1020008@netscape.com> X-Mailer: AOL Communicator (20030718.2230-ddrinan Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hi, Here is another problem with S/MIME deployment that I'd like to inquire about. Assuming that you have already obtained my public encryption certificate, for example by reading this message, there is no way for you to be certain what type of certificate I will trust if you send me e-mail, in particular what CAs I trust. If you have multiple certificates from different CAs, which one is the most appropriate to use when writing me writing signed and encrypted e-mail ? Nowadays, in Netscape applications (and in the new AOL communicator), each user can make a decision of which CAs he trusts for signing each type of certificate (SSL server, SSL client, email signing, email encryption ...). I call this set of CAs and the trust properties a user's "trust domain". Unlike an email certificate which is typically included in an S/MIME message's digital signature, my trust domain is not exposed to you. The only clue that you have when writing to me is that I probably trust the same Thawte freemail CA that issued my own public encryption certificate. However, if I had signed this message with my corporate certificate (and if my smartcard was working right now:)), you would not be able to get a certificate from the same CA, unless you were employed by the same company. One theoretical answer to the problem would be for you to sign your message with all the certificates you have, including multiple signatures, in the hope I would trust one. Today our mail clients only support a single signature, so that wouldn't work. But even if they did tomorrow, the software trust policy might be to not trust the message unless all its signatures are valid, so having one good signature and n bad signatures wouldn't help. You might send your message n times, each signed with a different certificate, but I would probably get annoyed. What I'm getting at is that there is a need to make the user's trust domain information available, so that senders get a hint of the proper certificate to use. This is similar to what happens in the SSL protocol when an SSL server requests client authentication. The SSL server provides a list of trusted CA certificates. The SSL client is then free to choose one to use if he has one that chains to a CA the server accepts. Of course the problem was easier to solve for SSL, since it is an online protocol, and S/MIME is not. My question is : is there any work going within the IETF to solve this problem for the S/MIME protocol ? And how have you been solving this problem today ? --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUwggNXMIICwKADAgECAgMKQTIwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA2MzAyMTI0MDBaFw0wNDA2 MjkyMTI0MDBaMIGCMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UE AxMNSnVsaWVuIFBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20x ITAfBgkqhkiG9w0BCQEWEm1hZGJyYWluQHJhd2J3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMonynDCpU2BidOpbQxkFHMKp1r9CPhnoKT1ZbsUdjL0U7p1qIO5OGZZ g6BUSKWRzpZsQtyvaiXWvO+pVJKJzTXQ4EvO6hsliMcpa8yzRX4mQSs3Mdor0oi5M/Rl4oT0 C7b+c/7JUhBmDT2n4R2lnJtNaC68sDW4WOM2/agIK7t78PuGRUQqjRNcIGaGQBsYBjYjuI1l EjdxzapPWRk8gvgHaU85prPE1zAOvT1GYMiulsDMM7Fhz58dNPIZlaQMx8mHF9GRygqBf4eT 0jh6bQijM2dCDs/YARd54DWcVxKBLJXtGJ57uyOfwnGDtzZgaB+31rBcH5dXG5fL9aCF9pUC AwEAAaNFMEMwMwYDVR0RBCwwKoEUanBpZXJyZUBuZXRzY2FwZS5jb22BEm1hZGJyYWluQHJh d2J3LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALk1TPB0P4XC6zc67Qpv +LbkV18cX+h0FuKcbtD6I6+PWpaCuzF92VUxxqZ0ZTLsSjch4I4e2gBTOuhoGkbYnI7mBEDg Dws9FQEduZ5FfOzjSg/AlaP//3C+18uU/AfXdDUFaNM3SuBoz0WmyIt8KDRdX2782V1MITUQ yYeTGkqFMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCkEyMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTAyNDMwNVowIwYJKoZIhvcNAQkEMRYEFKl33TvG7xJn v23e4aO5jx9MCoqqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEy MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEggEAj3WrMO/BlW/S/6f+kTbuysQvie1S 34QTFRcPaJ2y7MDRE4o6M0p4ThKf67sYL2GO8bNwvDxgPZXjbqyqbNYSOgel9DDVLddDSsIF VRlJ2ZwS9t9EuCmA7svfjdrXETSRUhQQDNIrVSIcfNM2uit9F0JizhlaPw2YCKF8i6lyyOsc cVVarQwBuox7k4kz3sZ/Lv+oAykhZZ7Iub+UaMv7vwBYQAeb2D6XRPK0QybaCJiUStUfwUWx j5QL9TG+oJu4/UMaViaygvw/rSIqEq1YwK+ukW2QmvQEiocEtJqhb0ulYJa2COxAyPljWCme ZZ4kkLYmNHUNpNS45rcClNJCZgAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792fFqt070720 for ; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h792fF2i070719 for ietf-smime-bks; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h792fFqt070714 for ; Fri, 8 Aug 2003 19:41:15 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 8 Aug 2003 19:41:12 -0700 From: "Blake Ramsdell" To: "'Julien Pierre'" , Subject: RE: dissemination of public encryption certificates Date: Fri, 8 Aug 2003 19:41:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F34575C.2090205@netscape.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Julien Pierre > Sent: Friday, August 08, 2003 7:07 PM > To: ietf-smime@imc.org > Subject: dissemination of public encryption certificates > > If I have a keypair and e-mail certificate, and I want to > send encrypted > e-mail to somebody knowing his e-mail address, what's a > systematic way > to obtain the recipient's encryption certificate ? Systematic is an interesting choice of words ;). I have seen LDAP work (if properly configured). For the most part, the most reliable way I've seen is for an intended recipient to send a signed message containing their encrypting certificate (which you are about to point out ;)). > Traditionally today, signed e-mail messages typically contain the > signer's public encryption certificate. However that means one party > needs to first send a signed unencrypted, e-mail message to > transmit the > public encryption certificate before both parties can > exchange encrypted > messages. Yup. > There are also ways to find recipient certificates today > using corporate > directory servers, but users must know about them and > manually configure > them in their applications, and they are typically not widely > available > on the Internet. Yup. > I'm envisioning some standardized scheme where, by starting with the > recipient's email address, it would be possible to locate a public > directory server, then find the recipient's certificate by > looking it up > in that directory server. I believe that at least one proposal exists for this in the PKIX working group -- look at the operational protocols for certificate store access. > My main question is : has any similar scheme been proposed ? I would > rather work with something that exists, but if there is nothing that > fits, I'm open to writing an RFC. Check out PKIX. They're not taking new drafts, but there may be something useful for you there. Any work along these lines would most likely be handled by that working group. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7926Zqt069811 for ; Fri, 8 Aug 2003 19:06:35 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7926ZhW069810 for ietf-smime-bks; Fri, 8 Aug 2003 19:06:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7926Yqt069803 for ; Fri, 8 Aug 2003 19:06:34 -0700 (PDT) (envelope-from jpierre@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h7926Ni05172 for ; Fri, 8 Aug 2003 19:06:23 -0700 (PDT) Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HJBXUC01.N1W; Fri, 8 Aug 2003 19:06:12 -0700 Date: Fri, 8 Aug 2003 19:07:24 -0700 From: jpierre@netscape.com (Julien Pierre) Subject: dissemination of public encryption certificates To: ietf-smime@imc.org Message-ID: <3F34575C.2090205@netscape.com> X-Mailer: AOL Communicator (20030718.2230-ddrinan Win) Organization: Netscape MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010704000904080802040505 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hi, Since this is my first posting to this mailing list, let me introduce myself : I'm a software engineer in AOL / Netscape and one of my responsibilities for several years has been to maintain the open source Netscape Security Services (NSS) library, which is used in the Mozilla browsers, many Netscape and Sun servers, and other internal products. The NSS library contains an implementation of S/MIME v3. I was wondering what thoughts you may have on the following problem : If I have a keypair and e-mail certificate, and I want to send encrypted e-mail to somebody knowing his e-mail address, what's a systematic way to obtain the recipient's encryption certificate ? Traditionally today, signed e-mail messages typically contain the signer's public encryption certificate. However that means one party needs to first send a signed unencrypted, e-mail message to transmit the public encryption certificate before both parties can exchange encrypted messages. There are also ways to find recipient certificates today using corporate directory servers, but users must know about them and manually configure them in their applications, and they are typically not widely available on the Internet. I'm envisioning some standardized scheme where, by starting with the recipient's email address, it would be possible to locate a public directory server, then find the recipient's certificate by looking it up in that directory server. My main question is : has any similar scheme been proposed ? I would rather work with something that exists, but if there is nothing that fits, I'm open to writing an RFC. Also, what are the other ways that people locate recipient S/MIME e-mail encryption certificates ? Thanks. --------------ms010704000904080802040505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoX DTA0MDYyOTIxMjQwMFowgYIxDzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYw FAYDVQQDEw1KdWxpZW4gUGllcnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBl LmNvbTEhMB8GCSqGSIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWo g7k4ZlmDoFRIpZHOlmxC3K9qJda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz 9GXihPQLtv5z/slSEGYNPafhHaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgG NiO4jWUSN3HNqk9ZGTyC+AdpTzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHK CoF/h5PSOHptCKMzZ0IOz9gBF3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1 oIX2lQIDAQABo0UwQzAzBgNVHREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJh aW5AcmF3YncuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLr NzrtCm/4tuRXXxxf6HQW4pxu0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRtic juYEQOAPCz0VAR25nkV87ONKD8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZ XUwhNRDJh5MaSoUwggNXMIICwKADAgECAgMKQTIwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA2MzAyMTI0MDBaFw0wNDA2 MjkyMTI0MDBaMIGCMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UE AxMNSnVsaWVuIFBpZXJyZTEjMCEGCSqGSIb3DQEJARYUanBpZXJyZUBuZXRzY2FwZS5jb20x ITAfBgkqhkiG9w0BCQEWEm1hZGJyYWluQHJhd2J3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMonynDCpU2BidOpbQxkFHMKp1r9CPhnoKT1ZbsUdjL0U7p1qIO5OGZZ g6BUSKWRzpZsQtyvaiXWvO+pVJKJzTXQ4EvO6hsliMcpa8yzRX4mQSs3Mdor0oi5M/Rl4oT0 C7b+c/7JUhBmDT2n4R2lnJtNaC68sDW4WOM2/agIK7t78PuGRUQqjRNcIGaGQBsYBjYjuI1l EjdxzapPWRk8gvgHaU85prPE1zAOvT1GYMiulsDMM7Fhz58dNPIZlaQMx8mHF9GRygqBf4eT 0jh6bQijM2dCDs/YARd54DWcVxKBLJXtGJ57uyOfwnGDtzZgaB+31rBcH5dXG5fL9aCF9pUC AwEAAaNFMEMwMwYDVR0RBCwwKoEUanBpZXJyZUBuZXRzY2FwZS5jb22BEm1hZGJyYWluQHJh d2J3LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALk1TPB0P4XC6zc67Qpv +LbkV18cX+h0FuKcbtD6I6+PWpaCuzF92VUxxqZ0ZTLsSjch4I4e2gBTOuhoGkbYnI7mBEDg Dws9FQEduZ5FfOzjSg/AlaP//3C+18uU/AfXdDUFaNM3SuBoz0WmyIt8KDRdX2782V1MITUQ yYeTGkqFMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCkEyMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgwOTAyMDcyNFowIwYJKoZIhvcNAQkEMRYEFGlDhKI0AAhL lB7h4JDRZdtmWoltMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEy MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKQTIwDQYJKoZIhvcNAQEBBQAEggEAhZuv8zcGhq1z4pdP8/oY2uuKvrvc SvZkQvAznHv/T7W79Hunk3Wwggz5IK5VVJPaHLY3NmYW39MhekjR7QndahCBjFC85JAeEjah eco7rwlBFMr9SXGLmwqtbWHSaT3q79TYcYVV0u5Ht4zm0NLu5LhXalS+Z4fUgl+YsSxEsBlH OUYoKTJLShgj9ugI4Ai6QezojwJ3l3W8XANOGFtxsear7FSFS5DsdyCfABhqfTnc3CmgAeD8 /ERSoSaAf+eYBrm0/MJH/O1vtsLB6BdUwX7dXpPnrOwed1S9V9hc/8I4b3PAfm31B3NkX19H R4S3uP+SucF1dKmac4sZ9xngBQAAAAAAAA== --------------ms010704000904080802040505-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76LTQqt047802 for ; Wed, 6 Aug 2003 14:29:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76LTQej047801 for ietf-smime-bks; Wed, 6 Aug 2003 14:29:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76LTNqt047788; Wed, 6 Aug 2003 14:29:23 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 251DD6F5BC; Wed, 6 Aug 2003 14:29:23 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Ietf-Smime-Examples'" , , "'Paul Hoffman / IMC'" Cc: "'Sean P. Turner'" , "Blake Ramsdell" Subject: Draft-11: More complete results Date: Wed, 6 Aug 2003 14:29:47 -0700 Message-ID: <005e01c35c61$dd8b8fc0$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h76LTOqt047789 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: People, I now have only a couple of examples that I have not checked. There are a couple of failures in this set of messages from my perspective. jim 4.1 pass 4.2 pass 5.1 pass 5.2 pass 5.3 -- not checked --- 5.4 pass with comments 1. certificates are Alice DSS, Carl DSS (root), Alice RSA 5.5 pass 5.6 --- not checked -- - structurally fine - - First Sig checks Diane signature unchecked 5.7 pass 5.8 -- not checked -- 1. I have an assumption that the wrong signature OID is used in the message. 5.9 FAILED 1. id-dsa is the signature algorithm not id-dsa-with-sha1 2. Commentary text states that the body part is the same as 5.1 - this is not correct as the signature values and exContent are different (content is actually "\0xd\0xaThis is some sample content." 5.10 pass with comments 1. List of attributes is 1. content type 2. message digest 3. 1.2.5555 (unknown) 4. content hint 5. smime capabilities 6. security label 7. content reference 8. encrypt key preference 9. ML expansion history 10. Equivalent label 5.11 pass with comments 1. Text should be Alice's and Carl's DSS certificates. 6.1 passed with comments 1. New commentary to add to replace that at the end of the message is appended to this message. 6.2 passed 6.3 passed with comments 1. RC2/128 for the content encryption algorithm. 6.4 passed 6.5 passed 6.6 -- not checked -- 6.7 passed 6.8 -- not checked -- 6.9 FAILED Recip #1 pass Recip #2 pass Recip #3 FAIL Content hints says the content is 1.2.6.5.4 not id-data 6.10 pass 6.11 FAILED test vectors are appended below on this message. I don't know where I am going wrong and this code worked in the past. 7.0 pass 8.1 passed 8.2 passed with comment Need to specify that this uses the same key value as does 8.1 9 -- checked-- 10.1 -- not checked -- 10.2 checked 11.1 FAILED 1. Text states signed with RSA, message signed with DSA 2. DSA signature OID incorrect 3. I retract the comments about the receipt request and AliceRSA. This is fine. The only odditity is the the receipt is going to a non-example address (robert.colestock@wang.com) 11.2 FAILED 1. I do not get the same value for the msgSigDigest attribute as this message has. I am investigating further. 11.3 passed 11.4 passed 11.5 -- not checked -- 11.6 -- not checked -- ***************************** 6.1 intermediate data for document ********************** Z ae c3 35 7f 90 75 b5 e4 c5 f8 92 6b 9e c5 96 a3 24 52 9d 85 32 60 7b 8b bd c2 a7 39 63 e9 d6 93 ad d5 1f 56 8d 91 97 72 a9 c2 f4 83 27 fa 37 3d 13 12 f3 3b 5c 8d ec ce 6b 2d 4f f1 9b 4c 91 e4 6d c0 68 1a 2e e0 c4 07 46 c3 f2 90 f4 ae fe c8 d8 ef dc ca 84 d5 fd 3a 36 ee ba 67 16 18 7f a3 de f3 df 3b 66 e1 6a 0b 79 bb 6a 50 c2 63 9f 24 ed 9b 17 d8 c1 b4 4e 8a a1 6a 35 02 d0 81 9c a3 X9.42 Other Info encoding for first hash 30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 04 04 00 00 00 01 a0 42 04 40 a9 74 c4 e9 aa 79 d3 ce 5c 74 a4 ed a5 db 65 f5 c0 37 d6 81 f1 0a 93 5f 24 a1 db 97 96 ee 87 8b 79 db e9 07 11 23 ce 70 24 84 30 72 02 83 d5 7d 60 d3 d4 f6 a7 4d 4c c2 e0 89 fa cd 59 20 a2 93 a2 06 04 04 00 00 00 c0 Hash Result #1 5d fa dc ad 89 87 33 7c ec cf af 8a fc e8 fd 56 38 d8 89 0c Hash Result #2 74 f2 fb f8 2c d7 bd 7a 92 1b 3c 10 df 16 0b a9 64 08 f2 a5 3DES Key Encryption Key 5d fb dc ad 89 86 32 7c ec ce ae 8a fd e9 fd 57 38 d9 89 0d 75 f2 fb f8 3DES Content Encryption Key 92 40 51 b6 43 16 13 52 f7 ad 92 cb f2 57 3e 7f a8 ce 02 ba b6 2a cd c2 ***************************** 6.11 intermediate data from my test **************** But it fails.... Wrapped key 0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 4d fb dÌ.®¯Í..¶H..E.M. 0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki­ Mail list key 0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 %^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f After decrypt #1 0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e ×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP 0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{ IV 0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø. Post Decrypt #2 0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 10 d7 ~N.µÞ.£b..B..f.× Computed check sum 0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯ Actual Check sum 80 e0 42 9a ee 66 10 d7 --- they don't match!!!!! Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71DwYqt096319 for ; Fri, 1 Aug 2003 06:58:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71DwY8D096318 for ietf-smime-bks; Fri, 1 Aug 2003 06:58:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h71DwXqt096310 for ; Fri, 1 Aug 2003 06:58:33 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25130 invoked by uid 0); 1 Aug 2003 13:57:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.141.10) by woodstock.binhost.com with SMTP; 1 Aug 2003 13:57:15 -0000 Message-Id: <5.2.0.9.2.20030731215303.040c27e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 21:54:02 -0400 To: capel@comgate.com, ietf-smime@imc.org From: Russ Housley Subject: RE: RFC2632bis and subjectAltName In-Reply-To: <000f01c35773$270aa350$01b5a8c0@tony> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony: Nice suggestion. I think we should do it. Russ >Blake: > >The absence of an rfc2822 e-mail address in the certificate should not be >considered a "failure" since its absence must have been permitted by the >certificate issuer - and we assume (!) that certificates are issued >according to issuer policy. > >The current text (which you quoted) could be incomplete. My interpretation* >of the middle sentence of this paragraph is that the check is only mandatory >if the address is present (so a comparison to an absent/"blank" field is not >mandatory). The following sentence then suggests what action to take if the >check/comparison fails. Since if the comparison is not done, it will not >fail, one could interpret that no indication is required if the address is >absent from the cert. > >The paragraph following the quoted one addresses the display of the signer's >identity: > >A receiving agent SHOULD display a subject name or other certificate >details when displaying an indication of successful or unsuccessful >signature verification. > >Should this be stronger in cases where the certificate has an absent rfc2822 >field (and no check against the From: header field was done)? > >Maybe adding the sentence between these two paragraphs: > >"Receiving agents which do not perform the foregoing check due to the >absence of an address in the certificate MUST display the subject name >from the certificate when displaying an indication of successful or >unsuccessful signature verification." > >-leaving the following paragraph as a SHOULD, strongly encouraging >additional information to be displayed in this and all other cases. > >Tony > >* I interpret the phrase: "if mail addresses are present in the >Certificate" to be a qualifier for the "MUST" in this sentence. > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell >| Sent: July 31, 2003 12:53 AM >| To: 'Russ Housley'; jimsch@exmsft.com; ietf-smime@imc.org >| Subject: RE: RFC2632bis and subjectAltName >| >| >| >| > -----Original Message----- >| > From: Russ Housley [mailto:housley@vigilsec.com] >| > Sent: Tuesday, July 29, 2003 4:36 PM >| > To: jimsch@exmsft.com; 'Blake Ramsdell'; ietf-smime@imc.org >| > Subject: RE: RFC2632bis and subjectAltName >| > >| > I understand that non-email applications of CMS and the >| > associated MIME >| > types need other address forms. But, RFC2632bis does not tell an >| > implementor what to do fir S/MIME (which is an email >| > application) if the >| > certificate does not contain an email address. >| >| I'm still not clear whether S/MIME means "secure MIME used >| anywhere MIME can be used, such as XMPP or BEEP" or S/MIME >| means "secure MIME used for interpersonal email messaging". >| Depending on the answer, you will get different answers if >| it's necessary to clarify any language about the absence of >| email addresses in the certificate. >| >| The relevant text about current processing rules seems to be: >| >| >| Sending agents SHOULD make the address in the From or Sender >| header in a mail message match an Internet mail address in >| the signer's certificate. Receiving agents MUST check that >| the address in the From or Sender header of a mail message >| matches an Internet mail address, if present, in the signer's >| certificate, if mail addresses are present in the >| certificate. A receiving agent SHOULD provide some explicit >| alternate processing of the message if this comparison fails, >| which may be to display a message that shows the recipient >| the addresses in the certificate or other certificate details. >| >| >| So if there are not any email addresses found in the >| certificate, this is a mismatch (blank from the certificate >| doesn't match nonblank from the From or Sender), and you >| should go crazy insane and show a hex dump of the certificate. >| >| We could clarify that "failure" includes the case where there >| are zero email addresses in the certificate... >| >| Blake >|