From owner-ietf-openpgp@mail.imc.org Sun Apr 1 07:50:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18297 for ; Sun, 1 Apr 2001 07:50:11 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA17061 for ietf-openpgp-bks; Sun, 1 Apr 2001 04:35:24 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [64.40.111.31]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA17055 for ; Sun, 1 Apr 2001 04:35:19 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp1.hushmail.com (Postfix) with ESMTP id 88DD31372E; Sun, 1 Apr 2001 04:34:24 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id EAA03480; Sun, 1 Apr 2001 04:34:24 -0700 Message-Id: <200104011134.EAA03480@user4.hushmail.com> Date: Sun, 1 Apr 2001 12:30:04 +0000 (GMT+01:00) To: ietf-openpgp@imc.org, exelrud@usa.net Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD" Subject: Java Implementation Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD Content-type: text/plain Jacques Exelrud was recently inquiring about the availability of a complete Java implementation of OpenPGP. We have one in our SDK, which will be powering the soon-to-be-released HushMail Version 2. It's intended for use with our keyserver network and OpenPGP CA. The source will be published with the release of HushMail V2. If interested, let me know. Regards, Brian Smith * * * * * * * * * * * * * * * * * * * * * S. Brian Smith Director of Research and Development Hush Communications Email: sbs@hushmail.com Mobile: +353 86 809 2163 Tel: +353 1 241 0325 Fax: +353 1 241 0370 Website: www.hush.com Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD-- From owner-ietf-openpgp@mail.imc.org Sun Apr 1 13:41:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03356 for ; Sun, 1 Apr 2001 13:41:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA29868 for ietf-openpgp-bks; Sun, 1 Apr 2001 10:22:33 -0700 (PDT) Received: from webmail.vento.com.br ([200.214.174.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29864 for ; Sun, 1 Apr 2001 10:22:31 -0700 (PDT) Received: from pterodactilo (200.251.188.19) by webmail.vento.com.br (5.1.056) id 3ABFF8C70006392B for ietf-openpgp@imc.org; Sun, 1 Apr 2001 14:22:32 -0300 Message-ID: <015701c0bacf$d2e3b970$0140a8c0@pterodactilo> From: "Jacques Exelrud" To: References: <200104011134.EAA03480@user4.hushmail.com> Subject: Re: Java Implementation Date: Sun, 1 Apr 2001 14:18:26 -0300 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Under what kind of licensing will it be released ? Will this SDK comply fully with OpenPGP ? Thanks in advance, Jacques ----- Original Message ----- From: To: ; Sent: Sunday, April 01, 2001 9:30 AM Subject: Java Implementation > Jacques Exelrud was recently inquiring about the availability of a complete > Java implementation of OpenPGP. We have one in our SDK, which will be powering > the soon-to-be-released HushMail Version 2. It's intended for use with > our keyserver network and OpenPGP CA. The source will be published with > the release of HushMail V2. If interested, let me know. > > Regards, > Brian Smith > > > * * * * * * * * * * * * * * * * * * * * * > S. Brian Smith > Director of Research and Development > Hush Communications > Email: sbs@hushmail.com > Mobile: +353 86 809 2163 > Tel: +353 1 241 0325 > Fax: +353 1 241 0370 > Website: www.hush.com > > > > > Free, encrypted, secure Web-based email at www.hushmail.com From owner-ietf-openpgp@mail.imc.org Sun Apr 1 14:18:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09943 for ; Sun, 1 Apr 2001 14:18:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA00572 for ietf-openpgp-bks; Sun, 1 Apr 2001 11:08:56 -0700 (PDT) Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00568 for ; Sun, 1 Apr 2001 11:08:55 -0700 (PDT) Received: from mwyoung ([24.48.51.230]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GB4L1S00.NVA for ; Sun, 1 Apr 2001 14:08:16 -0400 Message-ID: <00c501c0bad6$9cc99c40$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <003501c0ba04$55313e60$0140a8c0@pterodactilo> Subject: Re: Date fields Date: Sun, 1 Apr 2001 14:07:26 -0400 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- > For split-keys (hope that's a OpenPGP feature and not just a PGP > feature, have not checked the rfc) it may happen that parts of this It's an NAI feature, not part of the OpenPGP spec. The format of share files does not resemble a "packet" (but the encrypted data deep inside does). While I'd like OpenPGP to include a "split key" packet, I certainly wouldn't suggest the NAI format. [Note that the split key is really a split symmetric key, not a split of the whole secret key.] I don't think the split material has any timestamp itself. > For non split-keys the problem may not be as serious. What may > happen is that the user may receive an encrypted message with the There should never be a problem *decrypting* using an expired key. > security/legal problem. At most the lack of certain on the date the > message was generated because there is a one day lag the the key have Moreover, timestamps are only as trustworthy as the party generating them. You can always forge an old timestamp by setting your clock (or adjusting your software :-). I guess I don't understand the problem you're considering. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOsduNmNDnIII+QUHAQGutAf9FJy0Rbyvbo3GwoSvBOWGVvsxNGESmkuB ieXDF/SaKCst7oHs5dYgB0xNaTLmGWRe6M0zSTvGL+5NTK+Kd1PV6GVbaPAHP2Nb uf4yhjpB7VuVp8XFBvax8tKjk0yT4gwg00OZsYkKFBuiPxVfV2PKJoRK0eSD7zgF pZEy1f8U0ZOPurpRm8VDkEx5r/DKqyMmugXId8Dz2rQA23BFD733xxIYo2j/Z/vr gW2c590nBebQrg50cOoib4APTF0sTBjkm7cs8P2cYMPrDwkgmuWNxkIA/nlv4vZO d6SkAsZ0hto27wCGyhYynG8840oWYW372mkGVAsoOEU02v/qNFuAHg== =+bmT -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Apr 3 03:30:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24648 for ; Tue, 3 Apr 2001 03:30:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id AAA24626 for ietf-openpgp-bks; Tue, 3 Apr 2001 00:14:04 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA24618 for ; Tue, 3 Apr 2001 00:14:02 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f337Dns27520 for ietf-openpgp@imc.org; Tue, 3 Apr 2001 09:13:49 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Interesting attack to DSA Date: 3 Apr 2001 07:13:49 GMT Organization: IKS GmbH Jena Lines: 3 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a serious attack to DSA keys which seems to be indefeatable by the currently recommented secret key data. From owner-ietf-openpgp@mail.imc.org Tue Apr 3 06:26:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25673 for ; Tue, 3 Apr 2001 06:26:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA14975 for ietf-openpgp-bks; Tue, 3 Apr 2001 03:12:29 -0700 (PDT) Received: from ns.decros.cz (ns.decros.cz [193.85.26.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14969 for ; Tue, 3 Apr 2001 03:12:21 -0700 (PDT) Received: from dcrfs.decros.cz (exchange [10.1.1.3]) by ns.decros.cz (8.11.2/8.11.2) with ESMTP id f33AC7J26810; Tue, 3 Apr 2001 12:12:07 +0200 (CEST) Received: by dcrfs.decros.cz with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 12:12:06 +0200 Message-ID: <9E85DC6CA1D5D311BB460006293960FE089558@dcrfs.decros.cz> From: Klima Vlastimil To: "'ietf-openpgp@imc.org'" Cc: "'mailto:lutz@iks-jena.de'" Subject: RE: Interesting attack to DSA Date: Tue, 3 Apr 2001 12:12:04 +0200 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You can find our answer in the thread sci.crypt. Tomas Rosa and Vlastimil Klima Best regards Dr.Vlastimil Klima, Cryptologist DECROS Ltd. - ICZ a.s., V Olsinach 75, 100 97 Prague 10, Czech Republic v.klima@decros.cz, http://www.decros.cz, http://www.i.cz -----Original Message----- From: lutz@iks-jena.de [mailto:lutz@iks-jena.de] Sent: Tuesday, April 03, 2001 9:14 AM To: ietf-openpgp@imc.org Subject: Interesting attack to DSA The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a serious attack to DSA keys which seems to be indefeatable by the currently recommented secret key data. From owner-ietf-openpgp@mail.imc.org Wed Apr 4 14:36:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28501 for ; Wed, 4 Apr 2001 14:36:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA18184 for ietf-openpgp-bks; Wed, 4 Apr 2001 11:19:25 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA18179 for ; Wed, 4 Apr 2001 11:19:23 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA16569 for ietf-openpgp@imc.org; Wed, 4 Apr 2001 11:16:03 -0700 Date: Wed, 4 Apr 2001 11:16:03 -0700 Message-Id: <200104041816.LAA16569@finney.org> To: ietf-openpgp@imc.org Subject: RE: Interesting attack to DSA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The answer referred to below has not yet appeared on my news reader. Can someone who has seen it forward it to this list? On first analysis, the attack in the thread forwarded by Lutz is not really worth worrying about. You have to assume a combination of an incredibly clueless user and an extremely powerful attacker who can control the user's file accesses to a high degree. Hal > From: Klima Vlastimil > To: "'ietf-openpgp@imc.org'" > > You can find our answer in the thread sci.crypt. > > Tomas Rosa and Vlastimil Klima > > Best regards > Dr.Vlastimil Klima, Cryptologist > DECROS Ltd. - ICZ a.s., V Olsinach 75, 100 97 Prague 10, Czech Republic > v.klima@decros.cz, http://www.decros.cz, http://www.i.cz > > -----Original Message----- > From: lutz@iks-jena.de [mailto:lutz@iks-jena.de] > Sent: Tuesday, April 03, 2001 9:14 AM > To: ietf-openpgp@imc.org > Subject: Interesting attack to DSA > > > The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a > serious attack to DSA keys which seems to be indefeatable by the currently > recommented secret key data. From owner-ietf-openpgp@mail.imc.org Wed Apr 4 15:53:56 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00050 for ; Wed, 4 Apr 2001 15:53:54 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA23882 for ietf-openpgp-bks; Wed, 4 Apr 2001 12:33:35 -0700 (PDT) Received: from hotmail.com (oe66.law3.hotmail.com [209.185.240.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23876 for ; Wed, 4 Apr 2001 12:33:34 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Apr 2001 12:33:07 -0700 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: purpose of the checksum? Date: Wed, 4 Apr 2001 15:30:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BF_01C0BD1C.3C0EA2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 04 Apr 2001 19:33:07.0341 (UTC) FILETIME=[132863D0:01C0BD3E] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- The checksum of a pgp message block, can be deleted together with the footer, from any pgp signed/encrypted/signed & encrypted message without affecting decryptability or verifiability. {as long as the pgp footer is deleted together with it. if only the checksum is deleted without the footer, there will be a message of = } As this is so, what is the purpose of the checksum? vedaal nistar - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/01 -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt: build 4 < http://www.ipgpp.com/> Comment: { Acts of Kindness better the World, and protect the Soul } Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBOsty4moFoLeFMG0lAQHpiAf+OqLfs7jdQ3/LyE8JxqKSLD7RBlPOSr2G CMpNtYIuLHzumbOuai/mzuSIlahJMhuRjgelqSkBXNb1s+GqkfJZ3cNdPkkrr9VC gFixgE1zI0ODMCcTGt4k1wIqdn2MiBrNH12pUXAebzqXQ5TgtRKJ09+hV23VLNyd K07vbZw4qUtj8RGdYwRXocr1CiCmqnaqtLLKKryqSfAxX4+Og3D5pPC08XNWm4vy /dIKspyjpe2dcz//19I1nUn+j8AwZ1nO0j4TVtMXhpFfuAywZujTxAch8hrK1tXs uaskaKe1C8pTnTBKL1ISavQKddXdADQs686lteyYKpDwQzVwGwRLZA=3D=3D =3DAsoF -----END PGP SIGNATURE----- ------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED = MESSAGE-----
 
The checksum of a pgp message block, = can be deleted=20 together with the
footer, from any pgp signed/encrypted/signed &=20 encrypted message without
affecting decryptability or = verifiability.
{as=20 long as the pgp footer is deleted together with it.  if only=20 the
checksum is deleted without the footer, there will be a message = of=20 <ascii
armor incomplete>}
 
As this is so, what is the purpose of = the=20 checksum?
 

vedaal nistar
 

- ---
Outgoing mail is certified Virus Free.
Checked by = AVG=20 anti-virus system (http://www.grisoft.com).
Version: = 6.0.237 /=20 Virus Database: 115 - Release Date: 3/7/01
 
-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt: build = 4  =20 < http://www.ipgpp.com/>
Comment: = {=20 Acts of Kindness better the World, and protect the Soul }
Comment: = KeyID:=20 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  = D9AE 02FD=20 A711 97BA
 
iQEVAwUBOsty4moFoLeFMG0lAQHpiAf+OqLfs7jdQ3/LyE8JxqKSLD7RBlPOSr2G
= CMpNtYIuLHzumbOuai/mzuSIlahJMhuRjgelqSkBXNb1s+GqkfJZ3cNdPkkrr9VC
gFixg= E1zI0ODMCcTGt4k1wIqdn2MiBrNH12pUXAebzqXQ5TgtRKJ09+hV23VLNyd
K07vbZw4qU= tj8RGdYwRXocr1CiCmqnaqtLLKKryqSfAxX4+Og3D5pPC08XNWm4vy
/dIKspyjpe2dcz/= /19I1nUn+j8AwZ1nO0j4TVtMXhpFfuAywZujTxAch8hrK1tXs
uaskaKe1C8pTnTBKL1IS= avQKddXdADQs686lteyYKpDwQzVwGwRLZA=3D=3D
=3DAsoF
-----END=20 PGP SIGNATURE-----
------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0-- From owner-ietf-openpgp@mail.imc.org Wed Apr 4 16:02:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00226 for ; Wed, 4 Apr 2001 16:02:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA25414 for ietf-openpgp-bks; Wed, 4 Apr 2001 12:52:25 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25407 for ; Wed, 4 Apr 2001 12:52:23 -0700 (PDT) Received: from [199.106.106.131] (vpnap-g1-012043.qualcomm.com [10.13.12.43]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f34JqIV21466 for ; Wed, 4 Apr 2001 12:52:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1-0404010834] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 4 Apr 2001 12:51:54 -0700 To: ietf-openpgp@imc.org From: John W Noerenberg II Subject: WG Last Call - draft-ietf-openpgp-mime - Done! Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:55 PM -0600 3/20/01, John W Noerenberg II wrote: >This the Last Call for WG comments on draft-ietf-openpgp-mime. WG LAST CALL IS NOW OVER. Thomas Roessler has a -06 draft ready, which I will submit to the ADs. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Wed Apr 4 16:20:38 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00804 for ; Wed, 4 Apr 2001 16:20:37 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA26648 for ietf-openpgp-bks; Wed, 4 Apr 2001 13:07:30 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA26642 for ; Wed, 4 Apr 2001 13:07:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA17064; Wed, 4 Apr 2001 13:04:05 -0700 Date: Wed, 4 Apr 2001 13:04:05 -0700 Message-Id: <200104042004.NAA17064@finney.org> To: ietf-openpgp@imc.org, vedaal@hotmail.com Subject: Re: purpose of the checksum? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: vedaal nistar writes: > As this is so, what is the purpose of the checksum? It's to detect line noise from your 2400 baud modem. Hal From owner-ietf-openpgp@mail.imc.org Thu Apr 5 07:02:20 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27157 for ; Thu, 5 Apr 2001 07:02:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA02881 for ietf-openpgp-bks; Thu, 5 Apr 2001 03:40:56 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02869 for ; Thu, 5 Apr 2001 03:40:54 -0700 (PDT) Message-Id: <200104051040.DAA02869@above.proper.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:19 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:59:50 +0200 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-ietf-openpgp@mail.imc.org Thu Apr 5 12:39:29 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07481 for ; Thu, 5 Apr 2001 12:39:29 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA29374 for ietf-openpgp-bks; Thu, 5 Apr 2001 09:21:47 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA29370 for ; Thu, 5 Apr 2001 09:21:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA03840 for ietf-openpgp@imc.org; Thu, 5 Apr 2001 09:16:35 -0700 Date: Thu, 5 Apr 2001 09:16:35 -0700 Message-Id: <200104051616.JAA03840@finney.org> To: ietf-openpgp@imc.org Subject: RE: Interesting attack to DSA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The newsgroup posting by Vlastimil Klima, one of the Czech researchers who identified the problems associated with potential modifications to the secret key file, has now appeared on my local news server. (He also sent me a copy personally.) It also includes the text of the attack posted to sci.crypt which could work even with mathematical checks of the consistency of the DSS key. This attack is far less powerful than the original Czech attack, which was itself of highly limited impact IMO. But here are the messages, for future reference: > From: "Vlastimil Klima" > Newsgroups: sci.crypt > References: <99jdj9$1n9$1@news.ox.ac.uk> <3abe252a$1@news.cvut.cz> <20010402192001.22654.qmail@nym.alias.net> > Subject: Re: Is this a solution to the PGP flaw > Date: Tue, 3 Apr 2001 12:00:10 +0200 > Lines: 68 > Organization: Decros Ltd., ICZ Group, Prague, Czech Republic > X-Priority: 3 > X-MSMail-Priority: Normal > X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > NNTP-Posting-Host: brana.i.cz > X-Original-NNTP-Posting-Host: brana.i.cz > Message-ID: <3ac99fb1$1@news.cvut.cz> > X-Trace: 3 Apr 2001 11:02:25 +0100, brana.i.cz > Path: news.cvut.cz!brana.i.cz > Xref: news.cvut.cz sci.crypt:151235 > > Great observation! > > In the article "Breaking Public Key Cryptosystems on Tamper Resistance > Devices in the Presence of Transient Faults" by Bao, Deng, Han, > Jeng,Narasimhalu and Ngair (Security Protocols, 1997, Springer-Verlag, LNCS > vol. 1361, pp.115-124) is a very similar idea. > > Your attack needs more iterations, but it is very interesting. > > In our paper ( http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf), section > 7, we proposed "temporary tests (say for a patch) " and "future > countermeasures". On the temporary tests we said > "....We stress out that the aforesaid test is not to be a substitute for the > missing check of integrity of the file with the private key but it is to > serve as a temporary measure which prevents the herein specified attack..." > and at section 7.2 we said: > "...Let us also note that whereas such type of tests as we already mentioned > is trusted a lot, for instance in RSA, in case of DSA we have to be careful. > Unlike RSA there is only one value here (private key x), unknown by the > attacker. Other parameters are known by the attacker and it may change them > at its own discretion. This is a reason, why this test is considered only a > temporary solution, which must be replaced as soon as possible with another > type of check of integrity of the discussed records, as hereafter specified. > " > > Our recommendations are expressed in section 7.4 of the paper. > > Vlastimil Klima and Tomas Rosa > > "lcs Mixmaster Remailer" wrote in message > news:20010402192001.22654.qmail@nym.alias.net... > > Here is another variant on the attack which will still work even if > > the recommended mathematical checks are done. However it leaks only a > > small amount of information about the secret key. > > > > We have g^q = 1 mod p; g^x = y mod p; q | (p-1), etc. Now suppose an > > attacker wants to learn if x is even or odd. > > > > He can toggle the low order bit of x by xoring into the ciphertext. > > As is well known, in CFB mode, such an xor goes through to the > > plaintext at the cost of disturbing the following block of plaintext. > > (CBC has similar properties, but with the roles of the two plaintext > > blocks reversed.) > > > > Toggling the low order bit of x will either increment it or decrement > > it, depending on whether x is even or odd. This will cause y to be > > either multiplied by g, or divided by g. > > > > The attacker makes a guess about x being even or odd, toggles the bit > > and adjusts y accordingly. (He also has to adjust the checksum, which > > he can do with 50% success.) The resulting key is perfectly > > consistent mathematically, if his guess was correct. > > > > Then he sees if the user is able to use the key, or if he gets an > > error. If there is no error, the attacker knows he guessed right > > about the low bit of x. > > > > In some circumstances it may be possible for the attack to be mounted > > repeatedly and gradually learn more bits. For example, if the attack > > is possible because the key is stored on a network file system, as Dr. > > Klima proposes, the user may re-run PGP repeatedly when he gets an > > error, thinking he is typing his passphrase wrong. In some > > configurations this will re-fetch the secret key ring each time, and > > the attacker can modify a different bit of x each time. He can learn > > almost 128 bits of x in the best case. With this advantage, brute > > forcing the remaining bits of x may be possible. From owner-ietf-openpgp@mail.imc.org Fri Apr 6 11:45:34 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12590 for ; Fri, 6 Apr 2001 11:45:33 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA04375 for ietf-openpgp-bks; Fri, 6 Apr 2001 08:25:02 -0700 (PDT) Received: from NABOO.glueckkanja.com (mail.glueckkanja.de [195.4.63.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04368 for ; Fri, 6 Apr 2001 08:24:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Elliptic Curves Date: Fri, 6 Apr 2001 17:24:30 +0200 Message-ID: Thread-Topic: Elliptic Curves Thread-Index: AcC+raypFlHA//snRyCEca9/qviCWg== From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA04370 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Now that we are done with mime, is anybody interessted in adding ECC/ECDSA to the open-pgp standard? I think it would be time to do so and it won't be hard to specify (for those who had implemented elliptic curves in some context it is very clear what algorithm-specific values are needed). -- Dominikus Scherkl From owner-ietf-openpgp@mail.imc.org Sat Apr 7 05:36:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12367 for ; Sat, 7 Apr 2001 05:36:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA21689 for ietf-openpgp-bks; Sat, 7 Apr 2001 02:20:36 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [64.40.111.31]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA21685 for ; Sat, 7 Apr 2001 02:20:35 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp1.hushmail.com (Postfix) with ESMTP id 88B2013756 for ; Sat, 7 Apr 2001 02:19:43 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id CAA16613; Sat, 7 Apr 2001 02:19:43 -0700 Message-Id: <200104070919.CAA16613@user4.hushmail.com> Date: Sat, 7 Apr 2001 10:12:37 +0000 (GMT+01:00) To: ietf-openpgp@imc.org Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK" Subject: Re: Java Implementation Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK Content-type: text/plain Since the toolkit is intended for use with the same key servers that are used for HushMail.com, our standard licensing is on a per-key-registered basis. I'm sure we could work something out for use outside that context. It is fully compliant with 2440, but some of the "SHOULD" algorithms aren't packaged with it at this point. Our approach to MIME is initially not standard, because, among other things, we wanted interoperability with the Network Associates PGP users, and Network Associates PGP doesn't seem to implement PGP/MIME, even though there's a checkbox for it?!? Get in touch with me off the list, let me know what your specific requirements are, and we'll see what we can work out. Thanks, Brian At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: > > Under what kind of licensing will it be released ? > Will this SDK comply fully with OpenPGP ? > > Thanks in advance, > Jacques > >----- Original Message ----- >From: >To: ; >Sent: Sunday, April 01, 2001 9:30 AM >Subject: Java Implementation > > >> Jacques Exelrud was recently inquiring about the availability of a >complete >> Java implementation of OpenPGP. We have one in our SDK, which will >be >powering >> the soon-to-be-released HushMail Version 2. It's intended for use >with >> our keyserver network and OpenPGP CA. The source will be published >with >> the release of HushMail V2. If interested, let me know. >> >> Regards, >> Brian Smith >> >> >> * * * * * * * * * * * * * * * * * * * * * >> S. Brian Smith >> Director of Research and Development >> Hush Communications >> Email: sbs@hushmail.com >> Mobile: +353 86 809 2163 >> Tel: +353 1 241 0325 >> Fax: +353 1 241 0370 >> Website: www.hush.com >> >> >> >> >> Free, encrypted, secure Web-based email at www.hushmail.com > > > >Free, encrypted, secure Web-based email at www.hushmail.com > Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK-- From owner-ietf-openpgp@mail.imc.org Sat Apr 7 08:13:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13655 for ; Sat, 7 Apr 2001 08:13:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA06584 for ietf-openpgp-bks; Sat, 7 Apr 2001 05:00:35 -0700 (PDT) Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA06580 for ; Sat, 7 Apr 2001 05:00:33 -0700 (PDT) Received: from alsutton.demon.co.uk ([194.222.50.252] helo=cola) by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1) id 14lrOL-000Ah5-0B for ietf-openpgp@imc.org; Sat, 7 Apr 2001 12:00:33 +0000 Message-ID: <004901c0bf5a$4be16b40$fc32dec2@internal.jacobsrimell.com> From: "Al Sutton" To: Subject: Key sharing Date: Sat, 7 Apr 2001 13:00:09 +0100 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit All, Would this be the right group to look at OpenPGP key servers and the protocols used to obtain keys from them, and the protocols they use to share information between them. The reason I ask is that there seem to be some de facto standards with little or no documentation. Regards, Al. From owner-ietf-openpgp@mail.imc.org Sat Apr 7 11:02:25 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15007 for ; Sat, 7 Apr 2001 11:02:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA18075 for ietf-openpgp-bks; Sat, 7 Apr 2001 07:46:17 -0700 (PDT) Received: from mail.citicom.com (citicom.com [64.58.200.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18070 for ; Sat, 7 Apr 2001 07:46:15 -0700 (PDT) Received: from dgal-ws1 (dgal-ws1.cust.citicom.com [64.58.197.42]) by mail.citicom.com (MX-CITI/4b) with SMTP id f37EkEP13555; Sat, 7 Apr 2001 10:46:14 -0400 Reply-To: From: "Damon Gallaty" To: Cc: Subject: RE: Java Implementation Date: Sat, 7 Apr 2001 10:46:05 -0400 Message-ID: <000401c0bf71$7933ee30$2ac53a40@dgal-ws1.cust.citicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200104070919.CAA16613@user4.hushmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Actually, we do implement PGP/MIME where we can. Naturally, it requires access to the mail headers, and not all mail apps give plug-ins that kind of control. Unfortunately, out of all the plug-ins we currently have, only the Eudora plug-in is able to both create and interpret PGP/MIME. - Damon Gallaty > -----Original Message----- > From: owner-ietf-openpgp@mail.imc.org > [mailto:owner-ietf-openpgp@mail.imc.org]On Behalf Of sbs@hushmail.com > Sent: Saturday, April 07, 2001 6:13 AM > To: ietf-openpgp@imc.org > Subject: Re: Java Implementation > > > Since the toolkit is intended for use with the same key servers that are > used for HushMail.com, our standard licensing is on a per-key-registered > basis. I'm sure we could work something out for use outside that context. > > It is fully compliant with 2440, but some of the "SHOULD" > algorithms aren't > packaged with it at this point. Our approach to MIME is > initially not standard, > because, among other things, we wanted interoperability with the Network > Associates PGP users, and Network Associates PGP doesn't seem to > implement > PGP/MIME, even though there's a checkbox for it?!? > > Get in touch with me off the list, let me know what your specific > requirements > are, and we'll see what we can work out. > > Thanks, > Brian > > At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: > > > > > Under what kind of licensing will it be released ? > > Will this SDK comply fully with OpenPGP ? > > > > Thanks in advance, > > Jacques > > > >----- Original Message ----- > >From: > >To: ; > >Sent: Sunday, April 01, 2001 9:30 AM > >Subject: Java Implementation > > > > > >> Jacques Exelrud was recently inquiring about the availability of a > >complete > >> Java implementation of OpenPGP. We have one in our SDK, which will > >be > >powering > >> the soon-to-be-released HushMail Version 2. It's intended for use > >with > >> our keyserver network and OpenPGP CA. The source will be published > >with > >> the release of HushMail V2. If interested, let me know. > >> > >> Regards, > >> Brian Smith > >> > >> > >> * * * * * * * * * * * * * * * * * * * * * > >> S. Brian Smith > >> Director of Research and Development > >> Hush Communications > >> Email: sbs@hushmail.com > >> Mobile: +353 86 809 2163 > >> Tel: +353 1 241 0325 > >> Fax: +353 1 241 0370 > >> Website: www.hush.com > >> > >> > >> > >> > >> Free, encrypted, secure Web-based email at www.hushmail.com > > > > > > > >Free, encrypted, secure Web-based email at www.hushmail.com > > > Free, encrypted, secure Web-based email at www.hushmail.com From owner-ietf-openpgp@mail.imc.org Sun Apr 8 08:22:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08506 for ; Sun, 8 Apr 2001 08:22:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA26662 for ietf-openpgp-bks; Sun, 8 Apr 2001 05:05:08 -0700 (PDT) Received: from smtp4.hushmail.com (smtp4.hushmail.com [64.40.111.32]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA26655 for ; Sun, 8 Apr 2001 05:05:06 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp4.hushmail.com (Postfix) with ESMTP id 9DF112F2D; Sun, 8 Apr 2001 05:03:53 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id FAA16182; Sun, 8 Apr 2001 05:03:51 -0700 Message-Id: <200104081203.FAA16182@user4.hushmail.com> Date: Sun, 8 Apr 2001 13:03:31 +0000 (GMT+01:00) Cc: To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO" Subject: Plug-ins and PGP/MIME (was RE: Java Implementation) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO Content-type: text/plain That makes sense, since we were testing against the Outlook plug-in. It seems that this issue is a real barrier against adoption of PGP/MIME, though. Outlook is so far and away the dominant email client that it doesn't seem likely that PGP/MIME will get far if it can't be used in a plug-in. (I don't really see Microsoft building in an OpenPGP implementation anytime in the near future.) Brian Smith At Sat, 7 Apr 2001 10:46:05 -0400, "Damon Gallaty" wrote: > >Actually, we do implement PGP/MIME where we can. Naturally, it requires >access to the mail headers, and not all mail apps give plug-ins that >kind of >control. Unfortunately, out of all the plug-ins we currently have, only >the >Eudora plug-in is able to both create and interpret PGP/MIME. > >- Damon Gallaty > >> -----Original Message----- >> From: owner-ietf-openpgp@mail.imc.org >> [mailto:owner-ietf-openpgp@mail.imc.org]On Behalf Of sbs@hushmail.com >> Sent: Saturday, April 07, 2001 6:13 AM >> To: ietf-openpgp@imc.org >> Subject: Re: Java Implementation >> >> >> Since the toolkit is intended for use with the same key servers that >are >> used for HushMail.com, our standard licensing is on a per-key-registered >> basis. I'm sure we could work something out for use outside that >context. >> >> It is fully compliant with 2440, but some of the "SHOULD" >> algorithms aren't >> packaged with it at this point. Our approach to MIME is >> initially not standard, >> because, among other things, we wanted interoperability with the >Network >> Associates PGP users, and Network Associates PGP doesn't seem to >> implement >> PGP/MIME, even though there's a checkbox for it?!? >> >> Get in touch with me off the list, let me know what your specific >> requirements >> are, and we'll see what we can work out. >> >> Thanks, >> Brian >> >> At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: >> >> > >> > Under what kind of licensing will it be released ? >> > Will this SDK comply fully with OpenPGP ? >> > >> > Thanks in advance, >> > Jacques >> > >> >----- Original Message ----- >> >From: >> >To: ; >> >Sent: Sunday, April 01, 2001 9:30 AM >> >Subject: Java Implementation >> > >> > >> >> Jacques Exelrud was recently inquiring about the availability of >a >> >complete >> >> Java implementation of OpenPGP. We have one in our SDK, which >will >> >be >> >powering >> >> the soon-to-be-released HushMail Version 2. It's intended for >use >> >with >> >> our keyserver network and OpenPGP CA. The source will be published >> >with >> >> the release of HushMail V2. If interested, let me know. >> >> >> >> Regards, >> >> Brian Smith >> >> >> >> >> >> * * * * * * * * * * * * * * * * * * * * * >> >> S. Brian Smith >> >> Director of Research and Development >> >> Hush Communications >> >> Email: sbs@hushmail.com >> >> Mobile: +353 86 809 2163 >> >> Tel: +353 1 241 0325 >> >> Fax: +353 1 241 0370 >> >> Website: www.hush.com >> >> >> >> Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO-- From owner-ietf-openpgp@mail.imc.org Sun Apr 8 15:09:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11917 for ; Sun, 8 Apr 2001 15:09:30 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA22581 for ietf-openpgp-bks; Sun, 8 Apr 2001 11:51:38 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22577 for ; Sun, 8 Apr 2001 11:51:37 -0700 (PDT) Received: from mwyoung (sdn-ar-006florlaP094.dialsprint.net [158.252.72.182]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA29702 for ; Sun, 8 Apr 2001 11:51:18 -0700 (PDT) Message-ID: <011e01c0c05c$cb9c0d60$b648fc9e@transarc.ibm.com> From: "Michael Young" To: References: Subject: Re: purpose of the checksum? Date: Sat, 7 Apr 2001 19:31:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01C0BF99.53605EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0113_01C0BF99.53605EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- >As this is so, what is the purpose of the checksum? >=20 - From context, I gather you're talking about the ASCII armor checksum, not the encrypted checksums inside key or session key packets? The purpose is simply to reduce transmission accidents, which is the point to armoring in general. As you observed, the (dearmored) PGP packets are complete without it, and can be properly interpreted. An OpenPGP implementation certainly *could* insist on it being complete. Note that the armor checksum is done on the entire *encoded* message, not the plaintext, so it does not deter malicious alterations. The OpenPGP draft now includes a modification detection code to address malicious alteration or truncation. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOs+jOmNDnIII+QUHAQGRiQf+MojoFO08xGr57VDGLXXCxHELqOMzfhGy PTmXfIT4JjVdd5q7ifEihXzcpzP+YNhyraDTqCvyBKH0jUZU9Tqjnb09IoMaOXd6 YOTM5HKXW6+C+MURcbQb3v5jzolnEKI4kc5whk9Zq331oFNSDbQlGcTRrD/LS4p0 NbqkxEVEsyAeDczUMv4BZuj5GjaIRX5BRY1zm3ycjoDeQgbdVOHAvfZPxx8XxDqZ VrNRaBjISjTfDMvX11O3VO7W84ozdZYA6X0Je1aVdBhHDDL3Oa0XhSZESgKJWgA1 V7mGncQzwqJ29unLZTSvrpsE1+6r68Jjb9SVb9YCwlr71Iy0Y4Fr0Q=3D=3D =3DRO9X -----END PGP SIGNATURE----- ------=_NextPart_000_0113_01C0BF99.53605EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE-----
 
>As this is so, what is the purpose of the checksum?
> =
- From=20 context, I gather you're talking about the ASCII armor checksum,
not = the=20 encrypted checksums inside key or session key packets?
 
The purpose is simply to reduce transmission accidents, which is=20 the
point to armoring in general.  As you observed, the = (dearmored)=20 PGP
packets are complete without it, and can be properly = interpreted. =20 An
OpenPGP implementation certainly *could* insist on it being=20 complete.
 
Note that the armor checksum is done on the entire *encoded*=20 message,
not the plaintext, so it does not deter malicious = alterations. =20 The
OpenPGP draft now includes a modification detection code to=20 address
malicious alteration or truncation.
 
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy = 6.5.3
 
iQEVAwUBOs+jOmNDnIII+QUHAQGRiQf+MojoFO08xGr57VDGLXXCxHELqOMzfhGy
= PTmXfIT4JjVdd5q7ifEihXzcpzP+YNhyraDTqCvyBKH0jUZU9Tqjnb09IoMaOXd6
YOTM5= HKXW6+C+MURcbQb3v5jzolnEKI4kc5whk9Zq331oFNSDbQlGcTRrD/LS4p0
NbqkxEVEsy= AeDczUMv4BZuj5GjaIRX5BRY1zm3ycjoDeQgbdVOHAvfZPxx8XxDqZ
VrNRaBjISjTfDMv= X11O3VO7W84ozdZYA6X0Je1aVdBhHDDL3Oa0XhSZESgKJWgA1
V7mGncQzwqJ29unLZTSv= rpsE1+6r68Jjb9SVb9YCwlr71Iy0Y4Fr0Q=3D=3D
=3DRO9X
-----END=20 PGP SIGNATURE-----
------=_NextPart_000_0113_01C0BF99.53605EA0-- From owner-ietf-openpgp@mail.imc.org Mon Apr 9 13:24:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12328 for ; Mon, 9 Apr 2001 13:24:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA15136 for ietf-openpgp-bks; Mon, 9 Apr 2001 10:07:32 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15125 for ; Mon, 9 Apr 2001 10:07:30 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin158.pg6-nt.dusseldorf.nikoma.de [213.54.101.158]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id TAA77826; Mon, 9 Apr 2001 19:07:15 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id AFAC22ED15; Mon, 9 Apr 2001 19:06:07 +0200 (CEST) Date: Mon, 9 Apr 2001 19:06:07 +0200 From: Thomas Roessler To: John W Noerenberg II , "ietf-openpgp@imc.org" Subject: PGP/MIME: Last-minute editorial nits. Message-ID: <20010409190607.A1948@sobolev.does-not-exist.org> Mail-Followup-To: John W Noerenberg II , "ietf-openpgp@imc.org" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'll put the following last-minute changes which have not yet been discussed or announced here into draft-ietf-openpgp-mime-06.txt: - Replace OpenPGP Working Group by Network Working Group (Since that's what's on RFCs). - Fix the copyright notes to say Copyright (C) ISOC 2001 (instead of 2000). - In section 5 (OpenPGP signed data), paragraph 2, I'd like to change the wording like this: The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format -"pgp-", where identifies the Message +"pgp-", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Hash-symbols are constructed from the text names registered in [1] or according to the mechanism defined in that document by converting This is to avoid any confusion which may be caused by the fact that, in the old wording, hash-symbol refers to pgp-md5 as well as to md5. John: I hope the last change is within the limits of due process for things which can be done after Last Call. Please send me a short confirmation of that; I'll then finally submit draft-06. ;-) Thanks, -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Tue Apr 10 05:33:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10083 for ; Tue, 10 Apr 2001 05:33:53 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA01993 for ietf-openpgp-bks; Tue, 10 Apr 2001 02:19:31 -0700 (PDT) Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA01986 for ; Tue, 10 Apr 2001 02:19:28 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14muha-000392-00; Tue, 10 Apr 2001 11:44:46 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14muL6-0005RZ-00; Tue, 10 Apr 2001 11:21:32 +0200 Date: Tue, 10 Apr 2001 11:21:32 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: PGP/MIME aware MUAs Message-ID: <20010410112132.A20911@alberti.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i X-PGP-KeyID: 621CC013 X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D CD75 5DE2 4996 5B03 58A2 X-Request-PGP: finger:wk@porta.u64.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, is there a list of PGP/MIME aware clients available or could we gather some newer info to enhance the table available under http://cryptorights.org/pgp-users/pgp-mail-clients.html ? Here is a first update: Sylpheed support PGP/MIME natively (with gpg installed), signed and encrypted mail is created using the canoncial PGP/MIME method. The combined method can however be handled on recieving mails. ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Tue Apr 10 12:38:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20155 for ; Tue, 10 Apr 2001 12:38:13 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA10627 for ietf-openpgp-bks; Tue, 10 Apr 2001 09:23:18 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10621 for ; Tue, 10 Apr 2001 09:23:17 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14n0uW-0005Hh-00 for ietf-openpgp@imc.org; Tue, 10 Apr 2001 18:22:32 +0200 To: ietf-openpgp@imc.org Subject: Re: Plug-ins and PGP/MIME (was RE: Java Implementation) References: <200104081203.FAA16182@user4.hushmail.com> From: Florian Weimer Date: 10 Apr 2001 18:22:32 +0200 In-Reply-To: <200104081203.FAA16182@user4.hushmail.com> (sbs@hushmail.com's message of "Sun, 8 Apr 2001 13:03:31 +0000 (GMT+01:00)") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sbs@hushmail.com writes: > That makes sense, since we were testing against the Outlook plug-in. > It seems that this issue is a real barrier against adoption of > PGP/MIME, though. Is it possible to write a plug-in for Exchange which removes or adds some additional transport armor before a message distributed using proprietary technology over the LAN is injected into the Net? This way, access to message headers would not be strictly necessary at the client system. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Wed Apr 11 07:16:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20424 for ; Wed, 11 Apr 2001 07:16:14 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA01627 for ietf-openpgp-bks; Wed, 11 Apr 2001 04:01:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01621 for ; Wed, 11 Apr 2001 04:01:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20025; Wed, 11 Apr 2001 07:01:16 -0400 (EDT) Message-Id: <200104111101.HAA20025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-mime-06.txt Date: Wed, 11 Apr 2001 07:01:16 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : MIME Security with OpenPGP Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler Filename : draft-ietf-openpgp-mime-06.txt Pages : 13 Date : 10-Apr-01 This document describes how the OpenPGP Message Format [1] can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 [2]. This draft is being discussed on the 'ietf-openpgp' mailing list. To join the list, send a message to with the single word 'subscribe' in the subject. An archive of the working group's list is located at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-mime-06.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-openpgp-mime-06.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: <20010410134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-mime-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-mime-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010410134952.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Wed Apr 11 10:07:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24417 for ; Wed, 11 Apr 2001 10:07:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA13598 for ietf-openpgp-bks; Wed, 11 Apr 2001 06:55:21 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA13590 for ; Wed, 11 Apr 2001 06:55:18 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 11 Apr 2001 14:49:21 +0200 Message-ID: <3AD460E1.CFC1D64F@saiknes.lv> Date: Wed, 11 Apr 2001 15:49:21 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: SHA256 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 isn't it time to define new algorithm numbers for SHA2 ? 8 for SHA256 (and maybe 9,10 for SHA384,512?) the bigger problem however is with OIDs... none of SHA2 have OIDs defined, just like HAVAL and TIGER :( == == Disastry http://i.am/disastry/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOtREaDBaTVEuJQxkEQIrxwCfd6V3ar8SsymtClQUQlgPxtzJgSMAni8/ wc88/0sPxRvSsKXmWnW7POOg =qYO4 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 11 12:19:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27480 for ; Wed, 11 Apr 2001 12:19:14 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA26358 for ietf-openpgp-bks; Wed, 11 Apr 2001 09:07:07 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA26327 for ; Wed, 11 Apr 2001 09:06:57 -0700 (PDT) Received: from [63.73.97.180] (64.166.153.162) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Wed, 11 Apr 2001 09:06:20 -0700 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <3AD460E1.CFC1D64F@saiknes.lv> References: <3AD460E1.CFC1D64F@saiknes.lv> Date: Wed, 11 Apr 2001 08:53:35 -0700 To: disastry@saiknes.lv, ietf-openpgp@imc.org From: Jon Callas Subject: Re: SHA256 ? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:49 PM +0200 4/11/01, disastry@saiknes.lv wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >isn't it time to define new algorithm numbers for SHA2 ? >8 for SHA256 (and maybe 9,10 for SHA384,512?) > >the bigger problem however is with OIDs... >none of SHA2 have OIDs defined, just like HAVAL and TIGER :( > That is, in fact, the bigger problem. We can either finesse it -- we agree on an OID to use for them -- or we wait for some other OID space to assign them. Jon -- From owner-ietf-openpgp@mail.imc.org Wed Apr 11 13:12:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29105 for ; Wed, 11 Apr 2001 13:12:10 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA29165 for ietf-openpgp-bks; Wed, 11 Apr 2001 10:00:09 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29161 for ; Wed, 11 Apr 2001 10:00:08 -0700 (PDT) Received: from [129.46.76.217] (dhcp231.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3BGxuT28148; Wed, 11 Apr 2001 09:59:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <20010409190607.A1948@sobolev.does-not-exist.org> References: <20010409190607.A1948@sobolev.does-not-exist.org> X-Mailer: Eudora [Macintosh version 5.1-0411010852] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 11 Apr 2001 09:55:37 -0700 To: Thomas Roessler From: John W Noerenberg II Subject: Re: PGP/MIME: Last-minute editorial nits. Cc: "ietf-openpgp@imc.org" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:06 PM +0200 4/9/01, Thomas Roessler wrote: >John: I hope the last change is within the limits of due process for >things which can be done after Last Call. Please send me a short >confirmation of that; I'll then finally submit draft-06. ;-) This was just dandy. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Wed Apr 11 13:46:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29709 for ; Wed, 11 Apr 2001 13:46:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA00952 for ietf-openpgp-bks; Wed, 11 Apr 2001 10:29:51 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00947 for ; Wed, 11 Apr 2001 10:29:49 -0700 (PDT) Received: from [129.46.76.217] (dhcp231.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3BHToT09469 for ; Wed, 11 Apr 2001 10:29:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200104111101.HAA20025@ietf.org> References: <200104111101.HAA20025@ietf.org> X-Mailer: Eudora [Macintosh version 5.1-0411010852] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 11 Apr 2001 10:22:23 -0700 To: ietf-openpgp@imc.org From: John W Noerenberg II Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:01 AM -0400 4/11/01, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the An Open Specification for Pretty >Good Privacy Working Group of the IETF. > > Title : MIME Security with OpenPGP > Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler > Filename : draft-ietf-openpgp-mime-06.txt > Pages : 13 > Date : 10-Apr-01 I have requested Jeff and Marcus review -06, and submit it to the IESG for promotion to Proposed Standard as soon as possible. Thanks to everyone for your contributions to this! Thanks especially to the editors who have worked diligently to get it to this point. We'll have congratulations all around when the draft gets its RFC number. Forgive my US-centric quote, but all the time I spend on PGP I think about what PGP means to everyone on the net, in the US and elsewhere. Dr. Lessig's observations about privacy and freedom of speech are never far from my mind. best, -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- Two hundred years after the framers ratified the Constitution, the Net has taught us what the First Amendment really means. -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Fri Apr 13 19:50:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20750 for ; Fri, 13 Apr 2001 19:50:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA00565 for ietf-openpgp-bks; Fri, 13 Apr 2001 16:34:45 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA00561 for ; Fri, 13 Apr 2001 16:34:44 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14oD4b-00064O-00 for ietf-openpgp@imc.org; Sat, 14 Apr 2001 01:33:53 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt References: <200104111101.HAA20025@ietf.org> From: Florian Weimer Date: 14 Apr 2001 01:33:53 +0200 In-Reply-To: <200104111101.HAA20025@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 11 Apr 2001 07:01:16 -0400") Message-ID: Lines: 31 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Internet-Drafts@ietf.org writes: > Title : MIME Security with OpenPGP > Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler > Filename : draft-ietf-openpgp-mime-06.txt > Pages : 13 > Date : 10-Apr-01 I know it's too late know, but while reviewing the current USEFOR draft, I discovered that the explanation | Multipart/signed and multipart/encrypted are to be treated by agents | as opaque, meaning that the data is not to be altered in any way [2], | [7]. However, many existing mail gateways will detect if the next hop | does not support MIME or 8-bit data and perform conversion to either | Quoted-Printable or Base64. This presents serious problems for | multipart/signed, in particular, where the signature is invalidated | when such an operation occurs. For this reason all data signed | according to this protocol MUST be constrained to 7 bits (8-bit data | MUST be encoded using either Quoted-Printable or Base64). of the 7 bit constraint fails to mention the binary/text mode signature interoperability problem which can only be addressed if there aren't any 8-bit characters. (USEFOR currently overrides the analogous requirement in RFC 2015.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Sat Apr 14 04:13:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09982 for ; Sat, 14 Apr 2001 04:13:57 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA04139 for ietf-openpgp-bks; Sat, 14 Apr 2001 01:02:48 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA04131 for ; Sat, 14 Apr 2001 01:02:46 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin189.pg5-nt.dusseldorf.nikoma.de [213.54.100.189]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id KAA94556; Sat, 14 Apr 2001 10:02:31 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 329152ED15; Sat, 14 Apr 2001 09:55:29 +0200 (CEST) Date: Sat, 14 Apr 2001 09:55:29 +0200 From: Thomas Roessler To: Florian Weimer Cc: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt Message-ID: <20010414095529.A12141@sobolev.does-not-exist.org> Mail-Followup-To: Florian Weimer , ietf-openpgp@imc.org References: <200104111101.HAA20025@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Sat, Apr 14, 2001 at 01:33:53AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-04-14 01:33:53 +0200, Florian Weimer wrote: >> Multipart/signed and multipart/encrypted are to be treated by >> agents as opaque, meaning that the data is not to be altered >> in any way [2], [7]. However, many existing mail gateways >> will detect if the next hop does not support MIME or 8-bit >> data and perform conversion to either Quoted-Printable or >> Base64. This presents serious problems for multipart/signed, >> in particular, where the signature is invalidated when such >> an operation occurs. For this reason all data signed >> according to this protocol MUST be constrained to 7 bits >> (8-bit data MUST be encoded using either Quoted-Printable or >> Base64). > of the 7 bit constraint fails to mention the binary/text mode > signature interoperability problem which can only be addressed if > there aren't any 8-bit characters. Eh? It may be because I didn't have any coffee so far, but somehow, I don't understand what you are trying to say here. The text/binary mode interop problem is related to trailing whitespace. It is not related to the presence or absence 8bit characters. The next section basically says that, and makes suggestions on how to fix things: Additionally, implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied. Note: In most cases, trailing whitespace can either be removed, or protected by applying an appropriate content-transfer-encoding. However, special care must be taken when any header lines - either in MIME entity headers, or in embedded RFC 822 headers - are present which only consist of whitespace: Such lines must be removed entirely, since replacing them by empty lines would turn them into header delimiters, and change the semantics of the message. The restrictions on whitespace are necessary in order to make the hash calculated invariant under the text and binary mode signature mechanisms provided by OpenPGP [1]. Also, they help to avoid compatibility problems with PGP implementations which predate the OpenPGP specification. Note: If any line begins with the string "From ", it is strongly suggested that either the Quoted-Printable or Base64 MIME encoding be applied. If Quoted-Printable is used, at least one of the characters in the string should be encoded using the hexadecimal coding rule. This is because many mail transfer and delivery agents treat "From " (the word "from" followed immediately by a space character) as the start of a new message and thus insert a right angle-bracket (>) in front of any line beginning with "From " to distinguish this case, invalidating the signature. Of course, implementations are free to find other standards-compliant ways of protecting whitespace - however, I doubt they'll find such ways. > (USEFOR currently overrides the analogous requirement in RFC 2015.) I hope you're joking. Could you please send the relevant sections from the latest usefor draft to this list? -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Sat Apr 14 05:35:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10409 for ; Sat, 14 Apr 2001 05:35:47 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA13655 for ietf-openpgp-bks; Sat, 14 Apr 2001 02:24:06 -0700 (PDT) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13650 for ; Sat, 14 Apr 2001 02:24:04 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin134.pg4-nt.dusseldorf.nikoma.de [213.54.99.134]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id LAA27459; Sat, 14 Apr 2001 11:24:01 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 411312ED15; Sat, 14 Apr 2001 11:23:12 +0200 (CEST) Date: Sat, 14 Apr 2001 11:23:12 +0200 From: Thomas Roessler To: usenet-format@landfield.com Cc: ietf-openpgp@imc.org Subject: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010414112312.B12141@sobolev.does-not-exist.org> Mail-Followup-To: usenet-format@landfield.com, ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm writing as one of the co-authors of draft-ietf-openpgp-mime-06, which is hoped to become the successor of RFC 2015 (PGP/MIME) soon. In section 6.21.3 of draft-*-article-04, you write the following: In the same way, Content-Types requiring special processing for their display, such as "application", "image", "audio", "video" and "multipart/related" are discouraged except in groups specifically intended (by policy or custom) to include them. Exceptionally, those application types defined in [RFC 1847] and [RFC 2015] for use within "multipart/signed" articles, and the type "application/pgp-keys" (or other similar types containing digital certificates) may be used freely but, contrary to [RFC 2015] and unless the article is intended to be sent by mail also, the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" as appropriate). I consider this section harmful for various reasons. First, it should be noted that problems with transmitting 8bit content are not the only reason for which an agent implementing PGP/MIME may elect to use quoted-printable or base64 as a body part's encoding. In particular, draft-ietf-openpgp-mime-06 specifies that the signed material in a PGP/MIME multipart/signed entity MUST NOT include any trailing whitespace. This may either be achieved by cutting off trailing whitespace, or by protecting it with an appropriate transfer encoding. The reason for this lies in the definition of a text-mode signature in RFC 2440 [OpenPGP], which is incompatible with the definition used by traditional implementations (aka pgp version 2). More precisely, a text-mode signature traditionally meant that any line feed has to be canonicalized to CR LF before hashing. With OpenPGP, trailing whitespace is additionally snipped. (That's the kind of processing which has traditionally been applied to clearsigned messages.) Now, the processing rules for multipart/signed make sure that line feeds are canonical before they hit the signing engine. With traditional PGP, that meant that text-mode and binary-mode hashes of the material would be identical. This is no longer valid with OpenPGP, which has two consequences: (1) In order to determine what hash is to be computed, a receiving agent would have to look at the signature. This would break the possibility to process multipart/signed in one pass. (2) In the presence of trailing whitespace, text-mode signatures wouldn't be interoperable between implementations using PGP 2 and OpenPGP implementations. The best way to fix both problems is to make sure that no trailing whitespace is present, by applying appropriate encodings. (With text/plain; format=flowed, this will be something which is encountered quite frequently.) For this reason alone, mandating transparent encodings may not be the best idea at this point. It should also be noted it's impossible to convert a multipart/signed entity which contains 8bit body parts to any 7bit format without breaking the signature. (Remember that MIME explicitly forbids nested MIME encodings: Recoding has to happen on the leaf level of a nested MIME structure.) This implies, that a multipart/signed entity wihich contains 8bit body parts cannot be legally transported via Internet e-mail without ruining the signature - be it as part of message/rfc822 encapsulation, be it as a direct attachment. Finally, I'd like to warn you that signature generation and verification interoperability may seriously be endangered by allowing 8bit body parts in a multipart/signed. More precisely, a multipart/signed body part may generally contain textual data in various character sets - it may even contain a nested multipart/mixed with text/plain subparts which bear different character sets. However, PGP signature generators and verifiers have traditionally been expecting that they are presented with data in a local character set when preparing text-mode signatures. For this reason, signature generators and verifiers may attempt to recode data they are presented with to whatever character set is considered to be canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2). When applying such (unnecessary) transformations to 8bit messages in on-the-wire-format (which would inevitably happen when a multipart/signed is verified or generated), interoperability will, of course, be ruined. Restricting the signed material to 7bit data also helps to make signature generation and verification more robust against such problems, and implementations considerably simpler. For all these reasons, I urge the Usenet format working group to remove the reference to multipart/signed from section 6.21.3. -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Sat Apr 14 11:07:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13042 for ; Sat, 14 Apr 2001 11:07:36 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA08083 for ietf-openpgp-bks; Sat, 14 Apr 2001 07:39:22 -0700 (PDT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08076 for ; Sat, 14 Apr 2001 07:39:20 -0700 (PDT) Received: from LOCALHOST ([64.228.185.149]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010414143850.QTRY17644.tomts5-srv.bellnexxia.net@LOCALHOST>; Sat, 14 Apr 2001 10:38:50 -0400 From: Ulf =?iso-8859-1?Q?M=F6ller?= To: hal@finney.org Date: Sat, 14 Apr 2001 10:37:37 -0400 Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Message-ID: <20010414103737.A982@localhost.localdomain> References: <200102132359.PAA03769@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200102132359.PAA03769@finney.org>; from hal@finney.org on Tue, Feb 13, 2001 at 03:59:37PM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 13, 2001 at 03:59:37PM -0800, hal@finney.org wrote: > I can tell you that on message receipt, the commercial versions of PGP > from Network Associates DO hash trailing whitespace on PGP/MIME messages. > That is, they are sensitive to the presence of trailing whitespace and > it is included in the hash. This is true regardless of whether the > signature type byte is text or binary mode. That may or may not be > compatible with the spec but that is how these versions work. Then why did you guys refuse to change the OpenPGP specification when the inconsistency was pointed out well before RFC 2440 was published? From owner-ietf-openpgp@mail.imc.org Sat Apr 14 14:23:39 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14085 for ; Sat, 14 Apr 2001 14:23:38 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA24113 for ietf-openpgp-bks; Sat, 14 Apr 2001 11:11:41 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA24108 for ; Sat, 14 Apr 2001 11:11:40 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA04356 for ietf-openpgp@imc.org; Sat, 14 Apr 2001 11:06:18 -0700 Date: Sat, 14 Apr 2001 11:06:18 -0700 Message-Id: <200104141806.LAA04356@finney.org> To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ulf =?iso-8859-1?Q?M=F6ller?= > On Tue, Feb 13, 2001 at 03:59:37PM -0800, hal@finney.org wrote: > > > I can tell you that on message receipt, the commercial versions of PGP > > from Network Associates DO hash trailing whitespace on PGP/MIME messages. > > That is, they are sensitive to the presence of trailing whitespace and > > it is included in the hash. This is true regardless of whether the > > signature type byte is text or binary mode. That may or may not be > > compatible with the spec but that is how these versions work. > > Then why did you guys refuse to change the OpenPGP specification when > the inconsistency was pointed out well before RFC 2440 was published? First, my description above referred to the behavior of NAI's commercial implementation of PGP on PGP/MIME messages. RFC 2440 does not discuss PGP/MIME messages, so it would not be appropriate to put such information into RFC 2440. Second, RFC 2440 is not perfect and does have errors. These are not the result of stubborn refusal to make changes and insistence on putting out an imperfect draft. Rather, mistakes are made in both the drafting and editing process, and sometimes comments are overlooked. Hal From owner-ietf-openpgp@mail.imc.org Sun Apr 15 02:49:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02686 for ; Sun, 15 Apr 2001 02:49:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA12061 for ietf-openpgp-bks; Sat, 14 Apr 2001 23:36:14 -0700 (PDT) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA12050 for ; Sat, 14 Apr 2001 23:36:12 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin82.pg2-nt.dusseldorf.nikoma.de [213.54.97.82]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id IAA70315 for ; Sun, 15 Apr 2001 08:36:07 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id C32AC2ED15; Sat, 14 Apr 2001 20:30:14 +0200 (CEST) Date: Sat, 14 Apr 2001 20:30:14 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Message-ID: <20010414203014.A26840@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <200104141806.LAA04356@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <200104141806.LAA04356@finney.org>; from hal@finney.org on Sat, Apr 14, 2001 at 11:06:18AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-04-14 11:06:18 -0700, hal@finney.org wrote: > First, my description above referred to the behavior of NAI's > commercial implementation of PGP on PGP/MIME messages. RFC 2440 > does not discuss PGP/MIME messages, so it would not be > appropriate to put such information into RFC 2440. PGP/MIME makes use of the OpenPGP format. It says very clearly what's the signed material, and that an OpenPGP signatur is generated. This means, of course, that no changes should be done to the signed material beyond what the OpenPGP spec mandates. In particular, PGP/MIME does NOT define any new hash methods, or new canonification methods to be performed by the back-end. It just refers the reader to the OpenPGP (or PGP) specification for all these points. Thus, Ulf's question remains valid: If you follow the old behaviour in one of the more important fields of application anyway, why on earth didn't you make sure RFC 2440 and your applications followed this kind of behaviour in general? After all, he had indeed warned of the inconsistency introduced by RFC 2440. But, anyway, the new spec resolves this by prohibiting trailing whitespace, which brings other problems, but seems to be the only compatible way out of this mess. -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Sun Apr 15 03:39:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04828 for ; Sun, 15 Apr 2001 03:39:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id AAA20522 for ietf-openpgp-bks; Sun, 15 Apr 2001 00:26:10 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA20511 for ; Sun, 15 Apr 2001 00:26:08 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id AAA06210 for ietf-openpgp@imc.org; Sun, 15 Apr 2001 00:20:44 -0700 Date: Sun, 15 Apr 2001 00:20:44 -0700 Message-Id: <200104150720.AAA06210@finney.org> To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > Thus, Ulf's question remains valid: If you follow the old behaviour > in one of the more important fields of application anyway, why on > earth didn't you make sure RFC 2440 and your applications followed > this kind of behaviour in general? After all, he had indeed warned > of the inconsistency introduced by RFC 2440. It is true, Ulf posted on this twice, on 16 Sep 98: | 0x01: Signature of a canonical text document. | Typically, this means the signer owns it, created it, or | certifies that it has not been modified. The signature is | calculated over the text data with its line endings converted to | and trailing blanks removed. Trailing blanks are removed _only_ for cleartext signatures, in the transformation described in section 7.1. Otherwise (for signatures contained in a PGP message, and for detached signatures) they are part of the signature. BTW, there's no proper definition of detached signatures in the draft. They probably should be mentioned in section 10 because they are used for PGP/MIME. and again on 13 Oct 98: Looks good, but the definition for the canonical text signature is still wrong. (Also I note you didn't include the note about PGP 2.6.x being unable to hande signature and pubkey packets of length type 0.) | 0x01: Signature of a canonical text document. | Typically, this means the signer owns it, created it, or | certifies that it has not been modified. The signature is | calculated over the text data with its line endings converted to | and trailing blanks removed. Trailing blanks are removed _only_ for cleartext signatures, in the transformation described in section 7.1. Otherwise (for signatures contained in a PGP message, and for detached signatures) they are part of the signature. The RFC issued on 11 Nov 98 without this change. I can't account for our overlooking these two comments. It was an error on my part and that of the other authors. No process is perfect. I note that the current RFC2440bis draft still has the incorrect language. Should we change the new draft to document the way the commercial versions of PGP, and versions 2.X, have always worked? Hal From owner-ietf-openpgp@mail.imc.org Sun Apr 15 13:26:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10872 for ; Sun, 15 Apr 2001 13:26:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA10000 for ietf-openpgp-bks; Sun, 15 Apr 2001 10:13:20 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA09994 for ; Sun, 15 Apr 2001 10:13:18 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14oq4U-0003a8-00 for ietf-openpgp@imc.org; Sun, 15 Apr 2001 19:12:22 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt References: <200104111101.HAA20025@ietf.org> <20010414095529.A12141@sobolev.does-not-exist.org> From: Florian Weimer Date: 15 Apr 2001 19:12:22 +0200 Message-ID: Lines: 45 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > The text/binary mode interop problem is related to trailing > whitespace. It is not related to the presence or absence 8bit > characters. OpenPGP textmode signatures are not very well-defined. First of all, OpenPGP requires text to be encoded in UTF-8, a requirement which is hardly followed in practice. In addition, there are at least four Unicode characters relating to line endings: U+000A, U+000D, U+0085 (NEXT LINE or NEL, somehow related to ISO 6429), U+2028 (LINE SEPARATOR, native to the Unicode standard). Especially U+0085 could be considered as a line terminator by some implementations which are closely related to an EBCDIC environment (AFAIK, this control character is used to represent a line-terminating EBCDIC control character when using one of the bijective EBCDIC <-> ISO 8859 maps). So 8-bit data signed by a text-mode signature should not include the following octets: 0x0a, 0x0d, 0x85 (ISO 8859 represenation of NEL), the octet sequence 0xc2 0x85 (UTF-8 representation of NEL), and the octet sequence 0xe2 0x80 0xa8, which is the UTF-8 representation of the LINE SEPERATOR character. This does not include any legacy ;-) East-Asia encodings (which might be used instead of UTF-8 for encoding the signed text), and overlong UTF-8 sequences (which are not permitted in theory, but implementations might disagree). Given these problems, I think it's not wise to assume that text-mode signatures are binary-transparent in any way. > > (USEFOR currently overrides the analogous requirement in RFC 2015.) > > I hope you're joking. No, I'm afraid. :-/ > Could you please send the relevant sections from the latest usefor > draft to this list? I think you've already found them. I've raised this issue as well on the list, hopefully it is addressed properly. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Mon Apr 16 09:09:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03168 for ; Mon, 16 Apr 2001 09:08:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA26962 for ietf-openpgp-bks; Mon, 16 Apr 2001 05:52:05 -0700 (PDT) Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.51]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA26956 for ; Mon, 16 Apr 2001 05:52:02 -0700 (PDT) Received: (qmail 16293 invoked from network); 16 Apr 2001 14:51:52 +0200 Received: from delenn.tninet.se (HELO algonet.se) (195.100.94.104) by hromeo.algonet.se with SMTP; 16 Apr 2001 14:51:52 +0200 Received: from kairos.algonet.se (kairos.algonet.se [194.213.74.201]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 850192.425511.987delenn-s1 for ; Mon, 16 Apr 2001 14:51:51 +0200 Received: (qmail 28846 invoked by uid 8884); 16 Apr 2001 12:51:51 -0000 Date: 16 Apr 2001 12:51:51 -0000 Message-ID: <20010416125151.28845.qmail@kairos.algonet.se> To: usenet-format@rkive.landfield.com Cc: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. From: sommar@algonet.se (Erland Sommarskog) In-Reply-To: <20010414112312.B12141@sobolev.does-not-exist.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > It should also be noted it's impossible to convert a > multipart/signed entity which contains 8bit body parts to any 7bit > format without breaking the signature. (Remember that MIME > explicitly forbids nested MIME encodings: Recoding has to happen on > the leaf level of a nested MIME structure.) Since I know very little about this signing business, I'll have to ask some really stupid questions. What is in multipart/signed? Is it just the signature? Or is it any part of the message that a human is supposed to read? If it's only the signature, I don't have any issue with it. If it is text intended to be read by humans, is the problem both trailing white-space and octets >= 128? If only trailing white-space is the problem, wouldn't be better to define an encoding that took care of those and nothing else? What I care about in the end is that text which is supposed to be read by humans are not mutilated. -- Erland Sommarskog, Stockholm, sommar@algonet.se From owner-ietf-openpgp@mail.imc.org Mon Apr 16 14:16:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10430 for ; Mon, 16 Apr 2001 14:16:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA19263 for ietf-openpgp-bks; Mon, 16 Apr 2001 11:02:04 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19259 for ; Mon, 16 Apr 2001 11:02:02 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14pDJA-0005YK-00 for ietf-openpgp@imc.org; Mon, 16 Apr 2001 20:01:04 +0200 To: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010416125151.28845.qmail@kairos.algonet.se> From: Florian Weimer Date: 16 Apr 2001 20:01:04 +0200 In-Reply-To: <20010416125151.28845.qmail@kairos.algonet.se> (sommar@algonet.se's message of "16 Apr 2001 12:51:51 -0000") Message-ID: Lines: 12 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sommar@algonet.se (Erland Sommarskog) writes: > Since I know very little about this signing business, I'll have to > ask some really stupid questions. I'm sorry but I've already replied on the USEFOR list only. The discussion will be continued over there. :-/ -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Mon Apr 16 16:06:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12932 for ; Mon, 16 Apr 2001 16:06:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA25194 for ietf-openpgp-bks; Mon, 16 Apr 2001 12:52:13 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25189 for ; Mon, 16 Apr 2001 12:52:12 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id MAA23709; Mon, 16 Apr 2001 12:51:55 -0700 Date: Mon, 16 Apr 2001 12:51:55 -0700 From: Brad Templeton To: Erland Sommarskog Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416125155.F16467@main.templetons.com> Mail-Followup-To: Erland Sommarskog , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20010416125151.28845.qmail@kairos.algonet.se> Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 12:51:51PM -0000, Erland Sommarskog wrote: > Thomas Roessler writes: > > It should also be noted it's impossible to convert a > > multipart/signed entity which contains 8bit body parts to any 7bit > > format without breaking the signature. (Remember that MIME > > explicitly forbids nested MIME encodings: Recoding has to happen on > > the leaf level of a nested MIME structure.) > > Since I know very little about this signing business, I'll have to > ask some really stupid questions. > > What is in multipart/signed? Is it just the signature? Or is it any part > of the message that a human is supposed to read? Mulitpart/signed, while probably the best of the singature forms, is not suitable to USENET. It only signs the body. Signing the body is not just the least interesting thing we can do in USENET (99.9% of all problems come from forged headers, not modification of bodies) it can actually have negative value, if it leads people to think the article is "signed" and thus can be trusted in ways that it actually can't. From owner-ietf-openpgp@mail.imc.org Mon Apr 16 17:20:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14035 for ; Mon, 16 Apr 2001 17:20:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA01088 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:07:12 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA01082 for ; Mon, 16 Apr 2001 14:07:11 -0700 (PDT) Received: (qmail 4705 invoked by uid 50); 16 Apr 2001 21:07:07 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 12:51:55 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 14:07:07 -0700 Message-ID: Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > Mulitpart/signed, while probably the best of the singature forms, is not > suitable to USENET. It only signs the body. Signing the body is not > just the least interesting thing we can do in USENET (99.9% of all > problems come from forged headers, not modification of bodies) it can > actually have negative value, if it leads people to think the article is > "signed" and thus can be trusted in ways that it actually can't. This depends rather heavily on the context. What you say is true for some applications (like control messages) and not true for others (like official announcements from some entity or another that are posted to Usenet). At the worst, what it means that one has to include the important information that should be authenticated by the signature, such as the date and the author, in the body of the message. Quite frequently for things like announcements this is done as a matter of course anyway. -- Russ Allbery (rra@stanford.edu) From owner-ietf-openpgp@mail.imc.org Mon Apr 16 17:39:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14278 for ; Mon, 16 Apr 2001 17:39:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA02288 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:24:05 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02283 for ; Mon, 16 Apr 2001 14:24:02 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id OAA24864; Mon, 16 Apr 2001 14:23:57 -0700 Date: Mon, 16 Apr 2001 14:23:57 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416142357.H16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote: > Brad Templeton writes: > > > Mulitpart/signed, while probably the best of the singature forms, is not > > suitable to USENET. It only signs the body. Signing the body is not > > just the least interesting thing we can do in USENET (99.9% of all > > problems come from forged headers, not modification of bodies) it can > > actually have negative value, if it leads people to think the article is > > "signed" and thus can be trusted in ways that it actually can't. > > This depends rather heavily on the context. What you say is true for some > applications (like control messages) and not true for others (like > official announcements from some entity or another that are posted to > Usenet). At the worst, what it means that one has to include the > important information that should be authenticated by the signature, such > as the date and the author, in the body of the message. Quite frequently > for things like announcements this is done as a matter of course anyway. Yes, but manual verification of signatures is of dubious value. For digital signature authentication to work properly, it is unfortunately necessary that all messages in a class be signed, and that the presence of an unsigned or improperly signed message be a major anomaly which gets a fair bit of attention, or which is in fact forbidden. If newsgroups allow both signed and unsigned messages, then it is trivial to cause trouble by simply not signing your unsigned messages. If a given user signs all his messages, it is not even sufficient for the software to be able to warn that a user who normally signs all his messages has not signed one, because the forger can play any number of tricks, including simply posting a message "From: rrra@stanford.edu" which looks like you to the non-careful eye, or worse "From: rra@windlord.stanford.edu" which *is* you but the software is unlikley to trap the warning that all messages from this address should be signed. Or rra%stanford.edu@leland.stanford.edu or many other forms which point to you. Of course you're even assuming something outside the multipart/signed spec, that the software is checking the From line at all, based on parsing it somehow out of the body. People have been able to sign article bodies for some time. It's not widely used and it's really not very useful. It would be a poor intermediate step because it's the wrong problem, and can lead to problems as well as limited benefit. All signing bodies does, without other checks, is allow me to prove after the fact that I really sent a message. It doesn't prove that I _didn't_ send it, for I am free to post unsigned messages which I can later disclaim. It also allows those who know my key to verify I sent a message, if they check. I've never been called upon to prove I sent a message. I don't recall ever seeing this for anybody else either. I have seen cases where people wonder if a person really sent a message, of course, but I've also seen a lot of forgeries that were so blatantly obvious that nobody of the sort who would check signatures would ever be fooled, and yet people are fooled. What you need is a system that shows that messages are from who they say they are from, and makes a big deal when they aren't. If 90% of messages start having a "The sender of this message could not be authenticated" then people simply start ignoring the warning, and it becomes of limited value. From owner-ietf-openpgp@mail.imc.org Mon Apr 16 17:55:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14496 for ; Mon, 16 Apr 2001 17:55:39 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA03192 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:42:55 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA03188 for ; Mon, 16 Apr 2001 14:42:54 -0700 (PDT) Received: (qmail 4861 invoked by uid 50); 16 Apr 2001 21:42:51 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 14:23:57 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 14:42:51 -0700 Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote: >> This depends rather heavily on the context. What you say is true for >> some applications (like control messages) and not true for others (like >> official announcements from some entity or another that are posted to >> Usenet). At the worst, what it means that one has to include the >> important information that should be authenticated by the signature, >> such as the date and the author, in the body of the message. Quite >> frequently for things like announcements this is done as a matter of >> course anyway. > Yes, but manual verification of signatures is of dubious value. That seems to be a non-sequitur. It's certainly possible to automatically verify a multipart/signed message. Some news readers and many mail readers already do this. > For digital signature authentication to work properly, it is > unfortunately necessary that all messages in a class be signed, and that > the presence of an unsigned or improperly signed message be a major > anomaly which gets a fair bit of attention, or which is in fact > forbidden. You're solving a different problem than I'm talking about. For occasional use for important announcements, the multipart/signed protocol works just fine. I understand that you're trying to solve the problem of fully authenticated message streams, which I agree is an interesting theoretical problem. I don't expect to see such a thing show up on Usenet soon, however, since most people currently using Usenet don't really have much use for it. *shrug* I know you care more about it than I do, and I may be underestimating the demand. > People have been able to sign article bodies for some time. It's not > widely used and it's really not very useful. It does, however, have the advantage of actually being deployed, working, and standardized. The sort of signature system that you're describing would be more useful for some applications than multipart/signed, I agree, should someone eventually write it and standardize it. Making it work well within MIME would be quite difficult, as we've already established in some of the previous rounds of discussion on that topic. -- Russ Allbery (rra@stanford.edu) From owner-ietf-openpgp@mail.imc.org Mon Apr 16 19:35:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15242 for ; Mon, 16 Apr 2001 19:35:58 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA09605 for ietf-openpgp-bks; Mon, 16 Apr 2001 16:20:40 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA09598 for ; Mon, 16 Apr 2001 16:20:38 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id QAA26264; Mon, 16 Apr 2001 16:20:37 -0700 Date: Mon, 16 Apr 2001 16:20:37 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416162037.I16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote: > Brad Templeton writes: > > Yes, but manual verification of signatures is of dubious value. > > That seems to be a non-sequitur. It's certainly possible to automatically > verify a multipart/signed message. Some news readers and many mail > readers already do this. If all the software does is include a string about the verification, that is then manually checked, it's manual verification. Humans ignore warnings which happen frequently. Thus if most (or even just a lot, like a few percent) of otherwise valid messages have the warning, people learn to ignore the warning. > > For digital signature authentication to work properly, it is > > unfortunately necessary that all messages in a class be signed, and that > > the presence of an unsigned or improperly signed message be a major > > anomaly which gets a fair bit of attention, or which is in fact > > forbidden. > > You're solving a different problem than I'm talking about. For occasional > use for important announcements, the multipart/signed protocol works just > fine. I understand that you're trying to solve the problem of fully > authenticated message streams, which I agree is an interesting theoretical What are these "important announcements" though? As I indicated, I mean that all the messages in a "class" have to be signed, so that it becomes worthy of note when a message in a class is not signed, and this can cause a warning that will be paid attention to. So what is this class called "important annoucements" and how is it defined, and how does the software detect it, and know when an important annoucement comes that is not validly signed, so that it can warn me about it? If you just mean that "before you say something important" be sure to sign it, again the value of that is limited, though not zero. It means that people who are in the know, after reading something of some importance (whatever that is) would then look to see if it is signed, or have their brain pay attention to the "this is not signed" warning which appears on almost all messages. I would rather solve the real problems the net faces with security, which are unauthorized control messages (and the resulting lack of trust in authorized control messages), most of all cancel, and large scale spam. Don't get me wrong, I think bodies should be authenticated, but the value from it, at least in today's net, is minimal, and the backlash over it, namely a lot of mime stuff most readers don't know how to handle tacked on the end of messages, far worse than the benefit. We will eventually need to put all that mime stuff in, and it will annoy a lot of users (we've all seen this) but we should do it for something really useful, not mostly ignored signature of bodies. From owner-ietf-openpgp@mail.imc.org Mon Apr 16 20:01:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15467 for ; Mon, 16 Apr 2001 20:01:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA11555 for ietf-openpgp-bks; Mon, 16 Apr 2001 16:50:51 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA11550 for ; Mon, 16 Apr 2001 16:50:50 -0700 (PDT) Received: (qmail 5341 invoked by uid 50); 16 Apr 2001 23:50:48 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 16:20:37 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 16:50:48 -0700 Message-ID: Lines: 77 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote: >> That seems to be a non-sequitur. It's certainly possible to >> automatically verify a multipart/signed message. Some news readers and >> many mail readers already do this. > If all the software does is include a string about the verification, > that is then manually checked, it's manual verification. Humans ignore > warnings which happen frequently. Thus if most (or even just a lot, > like a few percent) of otherwise valid messages have the warning, people > learn to ignore the warning. It seems reasonably easy to warn if the identity associated with the signature doesn't match the displayed identity derived from the From header, but I haven't thought a great deal about the user interface portion of this. > What are these "important announcements" though? As I indicated, I mean > that all the messages in a "class" have to be signed, so that it becomes > worthy of note when a message in a class is not signed, and this can > cause a warning that will be paid attention to. There are some announce groups where all the content is signed. comp.os.linux.announce, for example. There are some people who always sign all of their posts. > I would rather solve the real problems the net faces with security, > which are unauthorized control messages (and the resulting lack of trust > in authorized control messages), most of all cancel, and large scale > spam. Yes, I agree. However, no one is asking you to solve any of these other problems. This thread started with the OpenPGP folks asking us to please not arbitrarily mangle their existing standard. That seems rather reasonable to me. We don't have to do any work at all beyond not interfering with their (existing!) standard. > We will eventually need to put all that mime stuff in, and it will annoy > a lot of users (we've all seen this) but we should do it for something > really useful, not mostly ignored signature of bodies. So it's your position that this standard should *not* adopt MIME? To repeat myself (again), I feel very strongly that adopting MIME is a binary switch. Either we adopt MIME or we don't. The time to try to fiddle with MIME was when MIME was being developed, and should have been done as part of a different working group than this one; at this point, it's just Not Invented Here syndrome. Either netnews should continue to track the mail standards (which I would argue should be the *default* since that's been the policy behind netnews from the beginning), or we should explicitly say that we're not adopting MIME, but trying to grab bits and pieces creates exactly the kinds of internal inconsistencies that are being pointed out in this thread. If we want multipart messages, well-labelled character sets, the ability to transfer non-text messages without unlabelled structural content like uuencode, and the ability to take advantage of all of the work that the (quite a bit larger, quite a bit better-funded, and quite a bit better at developing and deploying new technology) mail community is doing, then I think we should simply say that the MIME standard also applies to netnews messages and then pick up the pieces, if any, within the framework already laid out for extending MIME. The current draft leans more in that direction than in the direction of not adopting MIME, but currently in some places is still trying to balance on the top of non-existent fences. And lest people worry too much about some portions of that, let me point out that (a) Usenet is not the only thing that netnews is used for and the standard should be usable for things other than Usenet, and (b) it's still perfectly reasonable for individual hierarchies to have their own policies about acceptable message body formats above and beyond what the standard *allows* for. If they want to try to figure out how to get message/signed working without QP, that's their lookout; it's a heck of a lot easier to change hierarchy policies than it is to change an RFC. -- Russ Allbery (rra@stanford.edu) From owner-ietf-openpgp@mail.imc.org Mon Apr 16 20:25:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15563 for ; Mon, 16 Apr 2001 20:25:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA12424 for ietf-openpgp-bks; Mon, 16 Apr 2001 17:16:02 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA12420 for ; Mon, 16 Apr 2001 17:16:00 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id RAA27144; Mon, 16 Apr 2001 17:16:00 -0700 Date: Mon, 16 Apr 2001 17:16:00 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416171600.N16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 04:50:48PM -0700, Russ Allbery wrote: > Brad Templeton writes: > It seems reasonably easy to warn if the identity associated with the > signature doesn't match the displayed identity derived from the From > header, but I haven't thought a great deal about the user interface > portion of this. Indeed that's good. That's header verification, which is what I'm pushing for, though you should verify more than just the From header. There are a variety of ways to do this. The right "mime" way is ugly, namely to embed another multipart in the 1st half of the mult/signed, which in turn has the body and a representation of the header. I have advocated (and the multipart/signed people I have talked to have agreed, saying they should have done this in the first place) that the multipart/signed form allow more than 2 parts, with semantics in the final signature part controlling just how the signature is checked on parts 1...N-1. USENET could be the first to include this extension. If there were a body issuing certificates for email addresses, that could be used to verify just the from line or other email lines, but again, why stop there. Somehow, somewhere in the body, a hash of the valid header needs to be provided. Putting it in the text is ugly, but is the only way the existing multipart/signed spec would verify it. The best option is probably to extend the spec. > > There are some announce groups where all the content is signed. > comp.os.linux.announce, for example. There are some people who always > sign all of their posts. A group where everything is signed can be secured, if the software is then programmed to reject or give warnings on the rare unsigned messages. (ideally relays should just not carry them in such a group, just as they in theory reject unauthorized postings in moderated groups.) However, support for "people who signs all their posts" is the hard issue. You need to spec a lot of extra stuff to make this work, somehow building databases of people who are in this state, and getting software to use those databases. You must have a certificate system, because you can't just put this flag on a user once they sign their first post, as the first one might be forged, thus locking the user out from posting under his own email. But even then, as I have indicated, it's easy for me to post as "rra@leland3.stanford.edu" even if you are the only one who can post as "rra@stanford.edu". It would be tough for you to figure out every form of your name and reserve it. > So it's your position that this standard should *not* adopt MIME? It should absolutely adopt MIME, and should make it a SHOULD, possibly even a MUST. At the same time, non-conformant readers will exist for quite some time, so we must for some years be aware of the older readers, and decide how we will _use_ MIME, comparing the tradeoff for those users with the benefit of it. Securing headers is well worth the ugly display to users of old newsreaders. Signing bodies is less convincing a sell. > To repeat myself (again), I feel very strongly that adopting MIME is a > binary switch. Either we adopt MIME or we don't. The time to try to > fiddle with MIME was when MIME was being developed, and should have been MIME is meant to be extended, and major users of it are free to develop extensions and try to get them adopted outside their space. I fully agree we should throw that binary switch, but I also face reality. I've seen newsgroups where people post with wasteful stuff, for no benefit to most of the readers, and it gets a lot of antipathy. Mime multipart/alternative was created so MIME systems could go through evolutions, but it's a very bulky system, more suited to mail than news, and so when it first started being used by Netscape, people were screamed at to go away. It's a little more accepted now but it took a lot. That was, in part, why I pushed the concept of out of band markup, which is a better migration to rich text than multipart/alternative. Note that at this time, the vast majority of USENET users have a reader that handles not just MIME, but even HTML. Still, some things are worth it and some are not. Non-english character sets, hyperlinks, structure, and securing headers are all worth it. Signing bodies is something we've seen for a while, but I have yet to see it actually be useful to anybody. From owner-ietf-openpgp@mail.imc.org Mon Apr 16 21:41:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17011 for ; Mon, 16 Apr 2001 21:41:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA16492 for ietf-openpgp-bks; Mon, 16 Apr 2001 18:30:12 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA16488 for ; Mon, 16 Apr 2001 18:30:10 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id VAA05096; Mon, 16 Apr 2001 21:29:56 -0400 To: Brad Templeton Cc: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> <20010416171600.N16467@main.templetons.com> From: Derek Atkins Date: 16 Apr 2001 21:29:55 -0400 In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 17:16:00 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You might want to take a look at draft-ietf-impp-msgfmt-??.txt (please forgive me for not knowing the current revision number). This draft tries to describe a MIME format for encapsulating a MIME message with it's associated meta-content (header information). The purpose of this draft was to allow a sender to sign a message and associated message headers, and then allow a transport system to send the message from the sender to the recipient(s). Using MSGFMT does imply some duplication of headers if your transport system requires them (e.g. IMPP, SMTP, etc). But if you don't need the transport-layer headers, you can stuff them into the MSGFMT part and sign them. Unfortunately this would be an incompatible change with the current netnews protocols. But I figured I'd point out that there are efforts to try to unify the message/message-meta-data dichotomy. Enjoy! -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Mon Apr 16 22:53:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18348 for ; Mon, 16 Apr 2001 22:53:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id TAA18657 for ietf-openpgp-bks; Mon, 16 Apr 2001 19:43:48 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA18648 for ; Mon, 16 Apr 2001 19:43:45 -0700 (PDT) Received: from PROXY.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A2472E8F01B4; Tue, 17 Apr 2001 10:49:59 0800 Message-Id: <5.0.0.25.1.20010417102958.00a93758@mail.comasp.com> X-Sender: ejc@mail.comasp.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 17 Apr 2001 10:30:16 +0800 To: usenet-format@landfield.com, ietf-openpgp@imc.org From: Erron Criddle Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thought I'd clarify: At 11:23 AM 14/04/2001 +0200, Thomas Roessler wrote: >In section 6.21.3 of draft-*-article-04, you write the following: > > In the same way, Content-Types requiring special processing for > their display, such as "application", "image", "audio", "video" > and "multipart/related" are discouraged except in groups > specifically intended (by policy or custom) to include them. > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). > >I consider this section harmful for various reasons. >In particular, draft-ietf-openpgp-mime-06 specifies that the signed >material in a PGP/MIME multipart/signed entity MUST NOT include any >trailing whitespace. >The reason for this lies in the definition of a text-mode signature >in RFC 2440 [OpenPGP] >Now, the processing rules for multipart/signed make sure that line >feeds are canonical before they hit the signing engine. ie, trailing white space is included. >The best way to fix both problems is to make sure that no trailing >whitespace is present, by applying appropriate encodings. (With >text/plain; format=flowed, this will be something which is >encountered quite frequently.) > >For this reason alone, mandating transparent encodings may not be >the best idea at this point. >It should also be noted it's impossible to convert a >multipart/signed entity which contains 8bit body parts to any 7bit >format without breaking the signature. This is important for 7-bit relays... >This implies, that a multipart/signed entity wihich contains 8bit >body parts cannot be legally transported via Internet e-mail without >ruining the signature - be it as part of message/rfc822 >encapsulation, be it as a direct attachment. True, if the raley server can only handle 7-bit ASCII >When applying such (unnecessary) transformations to 8bit messages in >on-the-wire-format (which would inevitably happen when a >multipart/signed is verified or generated), interoperability will, >of course, be ruined. This comment regards various character sets... >Restricting the signed material to 7bit data also helps to make >signature generation and verification more robust against such >problems, and implementations considerably simpler. True. >For all these reasons, I urge the Usenet format working group to >remove the reference to multipart/signed from section 6.21.3. Ditto. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Apr 19 05:31:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09248 for ; Thu, 19 Apr 2001 05:31:36 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA08100 for ietf-openpgp-bks; Thu, 19 Apr 2001 02:17:35 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA08092 for ; Thu, 19 Apr 2001 02:17:33 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 10:16:25 +0200 Message-ID: <3ADEACE9.94E464EA@saiknes.lv> Date: Thu, 19 Apr 2001 11:16:25 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: SHA256 ? References: <3AD460E1.CFC1D64F@saiknes.lv> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Callas wrote: > At 3:49 PM +0200 4/11/01, disastry@saiknes.lv wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >isn't it time to define new algorithm numbers for SHA2 ? > >8 for SHA256 (and maybe 9,10 for SHA384,512?) > > > >the bigger problem however is with OIDs... > >none of SHA2 have OIDs defined, just like HAVAL and TIGER :( > > > > That is, in fact, the bigger problem. We can either finesse it -- we agree > on an OID to use for them -- or we wait for some other OID space to assign > them. there is OIDs for SHA256, SHA384, SHA512 ! The ASN.1 OIDs are: - SHA256: 2.16.840.1.101.3.4.2.1 - SHA384: 2.16.840.1.101.3.4.2.2 - SHA512: 2.16.840.1.101.3.4.2.3 The hexadecimal representations are: - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 so The full hash prefixes for these are: SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 so how about assigning algorithm numbers for SHA2: ID Algorithm Text Name -- --------- ---- ---- 8 - SHA256 "SHA256" 9 - SHA384 "SHA384" 10 - SHA512 "SHA512" ? == == Disastry http://i.am/disastry/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOt6QwzBaTVEuJQxkEQI+WACgz9uOr++iIuUD8HN2coNGv5XGgNsAn29A WGhf3roDQImhNiMX5W11za4H =wvub -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Apr 19 10:19:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11453 for ; Thu, 19 Apr 2001 10:19:29 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA29418 for ietf-openpgp-bks; Thu, 19 Apr 2001 07:03:12 -0700 (PDT) Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29413 for ; Thu, 19 Apr 2001 07:03:10 -0700 (PDT) Received: from ssv2.dina.kvl.dk (ssv2.dina.kvl.dk [130.225.40.226]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA17316; Thu, 19 Apr 2001 16:02:05 +0200 Received: from abraham by ssv2.dina.kvl.dk with local (Exim 3.12 #1 (Debian)) id 14qF0X-00004y-00; Thu, 19 Apr 2001 16:02:05 +0200 To: usenet-format@landfield.com Cc: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 19 Apr 2001 16:02:04 +0200 In-Reply-To: <20010414112312.B12141@sobolev.does-not-exist.org> (Thomas Roessler's message of "Sat, 14 Apr 2001 11:23:12 +0200") Message-ID: Lines: 110 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This discussion seem to have degenerated into Thomas Roessler writes: > I'm writing as one of the co-authors of > draft-ietf-openpgp-mime-06, which is hoped to become the > successor of RFC 2015 (PGP/MIME) soon. > > In section 6.21.3 of draft-*-article-04, you write the following: > > In the same way, Content-Types requiring special processing for > their display, such as "application", "image", "audio", "video" > and "multipart/related" are discouraged except in groups > specifically intended (by policy or custom) to include them. > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). > > I consider this section harmful for various reasons. > > > > First, it should be noted that problems with transmitting 8bit > content are not the only reason for which an agent implementing > PGP/MIME may elect to use quoted-printable or base64 as a body > part's encoding. > > In particular, draft-ietf-openpgp-mime-06 specifies that the signed > material in a PGP/MIME multipart/signed entity MUST NOT include any > trailing whitespace. This may either be achieved by cutting off > trailing whitespace, or by protecting it with an appropriate > transfer encoding. > > The reason for this lies in the definition of a text-mode signature > in RFC 2440 [OpenPGP], which is incompatible with the definition > used by traditional implementations (aka pgp version 2). > > More precisely, a text-mode signature traditionally meant that any > line feed has to be canonicalized to CR LF before hashing. With > OpenPGP, trailing whitespace is additionally snipped. (That's the > kind of processing which has traditionally been applied to > clearsigned messages.) > > Now, the processing rules for multipart/signed make sure that line > feeds are canonical before they hit the signing engine. With > traditional PGP, that meant that text-mode and binary-mode hashes of > the material would be identical. This is no longer valid with > OpenPGP, which has two consequences: (1) In order to determine what > hash is to be computed, a receiving agent would have to look at the > signature. This would break the possibility to process > multipart/signed in one pass. (2) In the presence of trailing > whitespace, text-mode signatures wouldn't be interoperable between > implementations using PGP 2 and OpenPGP implementations. > > The best way to fix both problems is to make sure that no trailing > whitespace is present, by applying appropriate encodings. (With > text/plain; format=flowed, this will be something which is > encountered quite frequently.) > > For this reason alone, mandating transparent encodings may not be > the best idea at this point. > > > It should also be noted it's impossible to convert a > multipart/signed entity which contains 8bit body parts to any 7bit > format without breaking the signature. (Remember that MIME > explicitly forbids nested MIME encodings: Recoding has to happen on > the leaf level of a nested MIME structure.) > > This implies, that a multipart/signed entity wihich contains 8bit > body parts cannot be legally transported via Internet e-mail without > ruining the signature - be it as part of message/rfc822 > encapsulation, be it as a direct attachment. > > > Finally, I'd like to warn you that signature generation and > verification interoperability may seriously be endangered by > allowing 8bit body parts in a multipart/signed. > > More precisely, a multipart/signed body part may generally contain > textual data in various character sets - it may even contain a > nested multipart/mixed with text/plain subparts which bear different > character sets. > > However, PGP signature generators and verifiers have traditionally > been expecting that they are presented with data in a local > character set when preparing text-mode signatures. For this reason, > signature generators and verifiers may attempt to recode data they > are presented with to whatever character set is considered to be > canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2). > When applying such (unnecessary) transformations to 8bit messages in > on-the-wire-format (which would inevitably happen when a > of course, be ruined. > > Restricting the signed material to 7bit data also helps to make > signature generation and verification more robust against such > problems, and implementations considerably simpler. > > > For all these reasons, I urge the Usenet format working group to > remove the reference to multipart/signed from section 6.21.3. > > -- > Thomas Roessler From owner-ietf-openpgp@mail.imc.org Thu Apr 19 10:27:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11608 for ; Thu, 19 Apr 2001 10:27:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA00139 for ietf-openpgp-bks; Thu, 19 Apr 2001 07:13:32 -0700 (PDT) Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00134 for ; Thu, 19 Apr 2001 07:13:30 -0700 (PDT) Received: from ssv2.dina.kvl.dk (ssv2.dina.kvl.dk [130.225.40.226]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA17399; Thu, 19 Apr 2001 16:12:50 +0200 Received: from abraham by ssv2.dina.kvl.dk with local (Exim 3.12 #1 (Debian)) id 14qFAw-0000Ag-00; Thu, 19 Apr 2001 16:12:50 +0200 To: usenet-format@clari.net, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 19 Apr 2001 16:12:50 +0200 In-Reply-To: (Per Abrahamsen's message of "19 Apr 2001 16:02:04 +0200") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Per Abrahamsen writes: > This discussion seem to have degenerated into Oops, I hit the send key too soon. Basically, I agree USEFOR should not attempt to overrule RFC 2015. Just removing this section should do the trick: > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). From owner-ietf-openpgp@mail.imc.org Thu Apr 19 12:01:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13472 for ; Thu, 19 Apr 2001 12:01:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA08625 for ietf-openpgp-bks; Thu, 19 Apr 2001 08:49:33 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA08621 for ; Thu, 19 Apr 2001 08:49:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA09677; Thu, 19 Apr 2001 08:43:51 -0700 Date: Thu, 19 Apr 2001 08:43:51 -0700 Message-Id: <200104191543.IAA09677@finney.org> To: disastry@saiknes.lv, ietf-openpgp@imc.org, jon@callas.org Subject: Re: SHA256 ? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: disastry@saiknes.lv writes: > there is OIDs for SHA256, SHA384, SHA512 ! > > The ASN.1 OIDs are: > - SHA256: 2.16.840.1.101.3.4.2.1 > - SHA384: 2.16.840.1.101.3.4.2.2 > - SHA512: 2.16.840.1.101.3.4.2.3 This sounds plausible, although I haven't found an exact reference for it. 2.16.840.1.101 is the U.S. Government 2.16.840.1.101.3 is CSOR, the Computer Security Objects Register. Its home is http://csrc.nist.gov/csor/. nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm. However while that page defines the .0 and .1 subtrees under nistAlgorithms (.1 being AES), it does not define the .2 values used above. But that is about where we would expect to see the new SHA OIDs, so probably these pages have just not been updated yet. Hal From owner-ietf-openpgp@mail.imc.org Thu Apr 19 12:30:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14008 for ; Thu, 19 Apr 2001 12:30:07 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA10053 for ietf-openpgp-bks; Thu, 19 Apr 2001 09:11:30 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10048 for ; Thu, 19 Apr 2001 09:11:26 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 17:10:30 +0200 Message-ID: <3ADF0DF6.96A1E08B@saiknes.lv> Date: Thu, 19 Apr 2001 18:10:30 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org, hal@finney.org, jon@callas.org Subject: Re: SHA256 ? References: <200104191543.IAA09677@finney.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hal@finney.org wrote: > disastry@saiknes.lv writes: > > there is OIDs for SHA256, SHA384, SHA512 ! > > > > The ASN.1 OIDs are: > > - SHA256: 2.16.840.1.101.3.4.2.1 > > - SHA384: 2.16.840.1.101.3.4.2.2 > > - SHA512: 2.16.840.1.101.3.4.2.3 > > This sounds plausible, although I haven't found an exact reference > for it. > > 2.16.840.1.101 is the U.S. Government > 2.16.840.1.101.3 is CSOR, the Computer Security Objects Register. Its > home is http://csrc.nist.gov/csor/. > > nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm. > However while that page defines the .0 and .1 subtrees under > nistAlgorithms (.1 being AES), it does not define the .2 values used > above. But that is about where we would expect to see the new SHA OIDs, > so probably these pages have just not been updated yet. > Hal they realy are not listed there yet... I found these OIDs in IEEE P1363a Draft D7.9: http://grouper.ieee.org/groups/1363/P1363a/draft.html == == Disastry http://i.am/disastry/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOt7xeTBaTVEuJQxkEQKZuQCdGANX2tP8qbzxzBvuRXb61wVg2NkAoMxs JEXyY8rEhsHxnQ5/3ygQKQhD =EEDP -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Apr 19 13:48:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15189 for ; Thu, 19 Apr 2001 13:48:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA16991 for ietf-openpgp-bks; Thu, 19 Apr 2001 10:35:08 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16986 for ; Thu, 19 Apr 2001 10:35:07 -0700 (PDT) Received: from [129.46.76.217] (dhcp21.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3JHZ7T02555 for ; Thu, 19 Apr 2001 10:35:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 5.1fc3] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 19 Apr 2001 10:31:50 -0700 To: OpenPGP mailing list From: John W Noerenberg II Subject: Shamelessly self-serving message from the Chair Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For those interested in writing extensions for Eudora, I have updated documentation on the horribly-named-but-nevertheless-I-am-forced-to-live-with Extended Messaging Services API (emsapi) for Eudora. The documentation and kit hasn't been posted to our website, yet. But I will make it available to anyone requesting it. I'm sorry for the inconvenience, and we'll get it out to the site, but I figured that some of you would both like to know and not want to wait for that. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Sat Apr 21 12:42:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11202 for ; Sat, 21 Apr 2001 12:42:10 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA02270 for ietf-openpgp-bks; Sat, 21 Apr 2001 09:23:15 -0700 (PDT) Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA02264 for ; Sat, 21 Apr 2001 09:23:14 -0700 (PDT) Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GC5HHP03.UK7 for ; Sat, 21 Apr 2001 12:22:37 -0400 Message-ID: <008c01c0ca7f$38ea2420$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <3AD460E1.CFC1D64F@saiknes.lv> Subject: Re: SHA256 ? Date: Sat, 21 Apr 2001 12:22:11 -0400 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > isn't it time to define new algorithm numbers for SHA2 ? I really don't understand the rush. Last I checked, the new variants were not even *draft* FIPS. At the same time, I note that ECDSA is FIPS-approved, and has a reserved algorithm number, but no details. Note that I don't think NIST approval should always dictate inclusion in OpenPGP, but at least in the SHA-256+ cases, they were the originator and they may tweak them if something comes up during evaluation (as happened with SHA-1). From owner-ietf-openpgp@mail.imc.org Mon Apr 23 05:39:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02907 for ; Mon, 23 Apr 2001 05:39:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA24412 for ietf-openpgp-bks; Mon, 23 Apr 2001 02:22:57 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA24406 for ; Mon, 23 Apr 2001 02:22:55 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id KAA05667; Mon, 23 Apr 2001 10:23:10 +0100 (BST) Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.22 #1) id 14rcUI-000JUU-00; Mon, 23 Apr 2001 10:18:30 +0100 Date: Mon, 23 Apr 2001 10:18:30 +0100 From: "Clive D.W. Feather" To: Per Abrahamsen Cc: usenet-format@clari.net, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010423101830.E67157@demon.net> References: <20010414112312.B12141@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from abraham@dina.kvl.dk on Thu, Apr 19, 2001 at 04:12:50PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Per Abrahamsen said: > Basically, I agree USEFOR should not attempt to overrule RFC 2015. Having thought about this, I agree. We should not be modifying MIME in any shape, size, or form. Just using it. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646 From owner-ietf-openpgp@mail.imc.org Fri Apr 27 17:41:15 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16985 for ; Fri, 27 Apr 2001 17:41:14 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA23643 for ietf-openpgp-bks; Fri, 27 Apr 2001 14:22:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA23625 for ; Fri, 27 Apr 2001 14:22:39 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16560; Fri, 27 Apr 2001 17:22:39 -0400 (EDT) Message-Id: <200104272122.RAA16560@ietf.org> To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: The IESG SUBJECT: Last Call: MIME Security with OpenPGP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 27 Apr 2001 17:22:38 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the An Open Specification for Pretty Good Privacy Working Group to consider MIME Security with OpenPGP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 11, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt Received: by above.proper.com (8.9.3/8.9.3) id OAA23643 for ietf-openpgp-bks; Fri, 27 Apr 2001 14:22:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA23625 for ; Fri, 27 Apr 2001 14:22:39 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16560; Fri, 27 Apr 2001 17:22:39 -0400 (EDT) Message-Id: <200104272122.RAA16560@ietf.org> To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: The IESG SUBJECT: Last Call: MIME Security with OpenPGP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 27 Apr 2001 17:22:38 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the An Open Specification for Pretty Good Privacy Working Group to consider MIME Security with OpenPGP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 11, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt Received: by above.proper.com (8.9.3/8.9.3) id CAA24412 for ietf-openpgp-bks; Mon, 23 Apr 2001 02:22:57 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA24406 for ; Mon, 23 Apr 2001 02:22:55 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id KAA05667; Mon, 23 Apr 2001 10:23:10 +0100 (BST) Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.22 #1) id 14rcUI-000JUU-00; Mon, 23 Apr 2001 10:18:30 +0100 Date: Mon, 23 Apr 2001 10:18:30 +0100 From: "Clive D.W. Feather" To: Per Abrahamsen Cc: usenet-format@clari.net, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010423101830.E67157@demon.net> References: <20010414112312.B12141@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from abraham@dina.kvl.dk on Thu, Apr 19, 2001 at 04:12:50PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Per Abrahamsen said: > Basically, I agree USEFOR should not attempt to overrule RFC 2015. Having thought about this, I agree. We should not be modifying MIME in any shape, size, or form. Just using it. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646 Received: by above.proper.com (8.9.3/8.9.3) id JAA02270 for ietf-openpgp-bks; Sat, 21 Apr 2001 09:23:15 -0700 (PDT) Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA02264 for ; Sat, 21 Apr 2001 09:23:14 -0700 (PDT) Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GC5HHP03.UK7 for ; Sat, 21 Apr 2001 12:22:37 -0400 Message-ID: <008c01c0ca7f$38ea2420$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <3AD460E1.CFC1D64F@saiknes.lv> Subject: Re: SHA256 ? Date: Sat, 21 Apr 2001 12:22:11 -0400 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > isn't it time to define new algorithm numbers for SHA2 ? I really don't understand the rush. Last I checked, the new variants were not even *draft* FIPS. At the same time, I note that ECDSA is FIPS-approved, and has a reserved algorithm number, but no details. Note that I don't think NIST approval should always dictate inclusion in OpenPGP, but at least in the SHA-256+ cases, they were the originator and they may tweak them if something comes up during evaluation (as happened with SHA-1). Received: by above.proper.com (8.9.3/8.9.3) id KAA16991 for ietf-openpgp-bks; Thu, 19 Apr 2001 10:35:08 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16986 for ; Thu, 19 Apr 2001 10:35:07 -0700 (PDT) Received: from [129.46.76.217] (dhcp21.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3JHZ7T02555 for ; Thu, 19 Apr 2001 10:35:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 5.1fc3] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 19 Apr 2001 10:31:50 -0700 To: OpenPGP mailing list From: John W Noerenberg II Subject: Shamelessly self-serving message from the Chair Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For those interested in writing extensions for Eudora, I have updated documentation on the horribly-named-but-nevertheless-I-am-forced-to-live-with Extended Messaging Services API (emsapi) for Eudora. The documentation and kit hasn't been posted to our website, yet. But I will make it available to anyone requesting it. I'm sorry for the inconvenience, and we'll get it out to the site, but I figured that some of you would both like to know and not want to wait for that. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- Received: by above.proper.com (8.9.3/8.9.3) id JAA10053 for ietf-openpgp-bks; Thu, 19 Apr 2001 09:11:30 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10048 for ; Thu, 19 Apr 2001 09:11:26 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 17:10:30 +0200 Message-ID: <3ADF0DF6.96A1E08B@saiknes.lv> Date: Thu, 19 Apr 2001 18:10:30 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org, hal@finney.org, jon@callas.org Subject: Re: SHA256 ? References: <200104191543.IAA09677@finney.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hal@finney.org wrote: > disastry@saiknes.lv writes: > > there is OIDs for SHA256, SHA384, SHA512 ! > > > > The ASN.1 OIDs are: > > - SHA256: 2.16.840.1.101.3.4.2.1 > > - SHA384: 2.16.840.1.101.3.4.2.2 > > - SHA512: 2.16.840.1.101.3.4.2.3 > > This sounds plausible, although I haven't found an exact reference > for it. > > 2.16.840.1.101 is the U.S. Government > 2.16.840.1.101.3 is CSOR, the Computer Security Objects Register. Its > home is http://csrc.nist.gov/csor/. > > nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm. > However while that page defines the .0 and .1 subtrees under > nistAlgorithms (.1 being AES), it does not define the .2 values used > above. But that is about where we would expect to see the new SHA OIDs, > so probably these pages have just not been updated yet. > Hal they realy are not listed there yet... I found these OIDs in IEEE P1363a Draft D7.9: http://grouper.ieee.org/groups/1363/P1363a/draft.html == == Disastry http://i.am/disastry/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOt7xeTBaTVEuJQxkEQKZuQCdGANX2tP8qbzxzBvuRXb61wVg2NkAoMxs JEXyY8rEhsHxnQ5/3ygQKQhD =EEDP -----END PGP SIGNATURE----- Received: by above.proper.com (8.9.3/8.9.3) id IAA08625 for ietf-openpgp-bks; Thu, 19 Apr 2001 08:49:33 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA08621 for ; Thu, 19 Apr 2001 08:49:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA09677; Thu, 19 Apr 2001 08:43:51 -0700 Date: Thu, 19 Apr 2001 08:43:51 -0700 Message-Id: <200104191543.IAA09677@finney.org> To: disastry@saiknes.lv, ietf-openpgp@imc.org, jon@callas.org Subject: Re: SHA256 ? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: disastry@saiknes.lv writes: > there is OIDs for SHA256, SHA384, SHA512 ! > > The ASN.1 OIDs are: > - SHA256: 2.16.840.1.101.3.4.2.1 > - SHA384: 2.16.840.1.101.3.4.2.2 > - SHA512: 2.16.840.1.101.3.4.2.3 This sounds plausible, although I haven't found an exact reference for it. 2.16.840.1.101 is the U.S. Government 2.16.840.1.101.3 is CSOR, the Computer Security Objects Register. Its home is http://csrc.nist.gov/csor/. nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm. However while that page defines the .0 and .1 subtrees under nistAlgorithms (.1 being AES), it does not define the .2 values used above. But that is about where we would expect to see the new SHA OIDs, so probably these pages have just not been updated yet. Hal Received: by above.proper.com (8.9.3/8.9.3) id HAA00139 for ietf-openpgp-bks; Thu, 19 Apr 2001 07:13:32 -0700 (PDT) Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00134 for ; Thu, 19 Apr 2001 07:13:30 -0700 (PDT) Received: from ssv2.dina.kvl.dk (ssv2.dina.kvl.dk [130.225.40.226]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA17399; Thu, 19 Apr 2001 16:12:50 +0200 Received: from abraham by ssv2.dina.kvl.dk with local (Exim 3.12 #1 (Debian)) id 14qFAw-0000Ag-00; Thu, 19 Apr 2001 16:12:50 +0200 To: usenet-format@clari.net, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 19 Apr 2001 16:12:50 +0200 In-Reply-To: (Per Abrahamsen's message of "19 Apr 2001 16:02:04 +0200") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Per Abrahamsen writes: > This discussion seem to have degenerated into Oops, I hit the send key too soon. Basically, I agree USEFOR should not attempt to overrule RFC 2015. Just removing this section should do the trick: > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA29418 for ietf-openpgp-bks; Thu, 19 Apr 2001 07:03:12 -0700 (PDT) Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29413 for ; Thu, 19 Apr 2001 07:03:10 -0700 (PDT) Received: from ssv2.dina.kvl.dk (ssv2.dina.kvl.dk [130.225.40.226]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA17316; Thu, 19 Apr 2001 16:02:05 +0200 Received: from abraham by ssv2.dina.kvl.dk with local (Exim 3.12 #1 (Debian)) id 14qF0X-00004y-00; Thu, 19 Apr 2001 16:02:05 +0200 To: usenet-format@landfield.com Cc: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 19 Apr 2001 16:02:04 +0200 In-Reply-To: <20010414112312.B12141@sobolev.does-not-exist.org> (Thomas Roessler's message of "Sat, 14 Apr 2001 11:23:12 +0200") Message-ID: Lines: 110 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This discussion seem to have degenerated into Thomas Roessler writes: > I'm writing as one of the co-authors of > draft-ietf-openpgp-mime-06, which is hoped to become the > successor of RFC 2015 (PGP/MIME) soon. > > In section 6.21.3 of draft-*-article-04, you write the following: > > In the same way, Content-Types requiring special processing for > their display, such as "application", "image", "audio", "video" > and "multipart/related" are discouraged except in groups > specifically intended (by policy or custom) to include them. > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). > > I consider this section harmful for various reasons. > > > > First, it should be noted that problems with transmitting 8bit > content are not the only reason for which an agent implementing > PGP/MIME may elect to use quoted-printable or base64 as a body > part's encoding. > > In particular, draft-ietf-openpgp-mime-06 specifies that the signed > material in a PGP/MIME multipart/signed entity MUST NOT include any > trailing whitespace. This may either be achieved by cutting off > trailing whitespace, or by protecting it with an appropriate > transfer encoding. > > The reason for this lies in the definition of a text-mode signature > in RFC 2440 [OpenPGP], which is incompatible with the definition > used by traditional implementations (aka pgp version 2). > > More precisely, a text-mode signature traditionally meant that any > line feed has to be canonicalized to CR LF before hashing. With > OpenPGP, trailing whitespace is additionally snipped. (That's the > kind of processing which has traditionally been applied to > clearsigned messages.) > > Now, the processing rules for multipart/signed make sure that line > feeds are canonical before they hit the signing engine. With > traditional PGP, that meant that text-mode and binary-mode hashes of > the material would be identical. This is no longer valid with > OpenPGP, which has two consequences: (1) In order to determine what > hash is to be computed, a receiving agent would have to look at the > signature. This would break the possibility to process > multipart/signed in one pass. (2) In the presence of trailing > whitespace, text-mode signatures wouldn't be interoperable between > implementations using PGP 2 and OpenPGP implementations. > > The best way to fix both problems is to make sure that no trailing > whitespace is present, by applying appropriate encodings. (With > text/plain; format=flowed, this will be something which is > encountered quite frequently.) > > For this reason alone, mandating transparent encodings may not be > the best idea at this point. > > > It should also be noted it's impossible to convert a > multipart/signed entity which contains 8bit body parts to any 7bit > format without breaking the signature. (Remember that MIME > explicitly forbids nested MIME encodings: Recoding has to happen on > the leaf level of a nested MIME structure.) > > This implies, that a multipart/signed entity wihich contains 8bit > body parts cannot be legally transported via Internet e-mail without > ruining the signature - be it as part of message/rfc822 > encapsulation, be it as a direct attachment. > > > Finally, I'd like to warn you that signature generation and > verification interoperability may seriously be endangered by > allowing 8bit body parts in a multipart/signed. > > More precisely, a multipart/signed body part may generally contain > textual data in various character sets - it may even contain a > nested multipart/mixed with text/plain subparts which bear different > character sets. > > However, PGP signature generators and verifiers have traditionally > been expecting that they are presented with data in a local > character set when preparing text-mode signatures. For this reason, > signature generators and verifiers may attempt to recode data they > are presented with to whatever character set is considered to be > canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2). > When applying such (unnecessary) transformations to 8bit messages in > on-the-wire-format (which would inevitably happen when a > of course, be ruined. > > Restricting the signed material to 7bit data also helps to make > signature generation and verification more robust against such > problems, and implementations considerably simpler. > > > For all these reasons, I urge the Usenet format working group to > remove the reference to multipart/signed from section 6.21.3. > > -- > Thomas Roessler Received: by above.proper.com (8.9.3/8.9.3) id CAA08100 for ietf-openpgp-bks; Thu, 19 Apr 2001 02:17:35 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA08092 for ; Thu, 19 Apr 2001 02:17:33 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 10:16:25 +0200 Message-ID: <3ADEACE9.94E464EA@saiknes.lv> Date: Thu, 19 Apr 2001 11:16:25 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: SHA256 ? References: <3AD460E1.CFC1D64F@saiknes.lv> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Callas wrote: > At 3:49 PM +0200 4/11/01, disastry@saiknes.lv wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >isn't it time to define new algorithm numbers for SHA2 ? > >8 for SHA256 (and maybe 9,10 for SHA384,512?) > > > >the bigger problem however is with OIDs... > >none of SHA2 have OIDs defined, just like HAVAL and TIGER :( > > > > That is, in fact, the bigger problem. We can either finesse it -- we agree > on an OID to use for them -- or we wait for some other OID space to assign > them. there is OIDs for SHA256, SHA384, SHA512 ! The ASN.1 OIDs are: - SHA256: 2.16.840.1.101.3.4.2.1 - SHA384: 2.16.840.1.101.3.4.2.2 - SHA512: 2.16.840.1.101.3.4.2.3 The hexadecimal representations are: - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 so The full hash prefixes for these are: SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 so how about assigning algorithm numbers for SHA2: ID Algorithm Text Name -- --------- ---- ---- 8 - SHA256 "SHA256" 9 - SHA384 "SHA384" 10 - SHA512 "SHA512" ? == == Disastry http://i.am/disastry/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOt6QwzBaTVEuJQxkEQI+WACgz9uOr++iIuUD8HN2coNGv5XGgNsAn29A WGhf3roDQImhNiMX5W11za4H =wvub -----END PGP SIGNATURE----- Received: by above.proper.com (8.9.3/8.9.3) id TAA18657 for ietf-openpgp-bks; Mon, 16 Apr 2001 19:43:48 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA18648 for ; Mon, 16 Apr 2001 19:43:45 -0700 (PDT) Received: from PROXY.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A2472E8F01B4; Tue, 17 Apr 2001 10:49:59 0800 Message-Id: <5.0.0.25.1.20010417102958.00a93758@mail.comasp.com> X-Sender: ejc@mail.comasp.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 17 Apr 2001 10:30:16 +0800 To: usenet-format@landfield.com, ietf-openpgp@imc.org From: Erron Criddle Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thought I'd clarify: At 11:23 AM 14/04/2001 +0200, Thomas Roessler wrote: >In section 6.21.3 of draft-*-article-04, you write the following: > > In the same way, Content-Types requiring special processing for > their display, such as "application", "image", "audio", "video" > and "multipart/related" are discouraged except in groups > specifically intended (by policy or custom) to include them. > Exceptionally, those application types defined in [RFC 1847] and > [RFC 2015] for use within "multipart/signed" articles, and the > type "application/pgp-keys" (or other similar types containing > digital certificates) may be used freely but, contrary to [RFC > 2015] and unless the article is intended to be sent by mail also, > the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" > as appropriate). > >I consider this section harmful for various reasons. >In particular, draft-ietf-openpgp-mime-06 specifies that the signed >material in a PGP/MIME multipart/signed entity MUST NOT include any >trailing whitespace. >The reason for this lies in the definition of a text-mode signature >in RFC 2440 [OpenPGP] >Now, the processing rules for multipart/signed make sure that line >feeds are canonical before they hit the signing engine. ie, trailing white space is included. >The best way to fix both problems is to make sure that no trailing >whitespace is present, by applying appropriate encodings. (With >text/plain; format=flowed, this will be something which is >encountered quite frequently.) > >For this reason alone, mandating transparent encodings may not be >the best idea at this point. >It should also be noted it's impossible to convert a >multipart/signed entity which contains 8bit body parts to any 7bit >format without breaking the signature. This is important for 7-bit relays... >This implies, that a multipart/signed entity wihich contains 8bit >body parts cannot be legally transported via Internet e-mail without >ruining the signature - be it as part of message/rfc822 >encapsulation, be it as a direct attachment. True, if the raley server can only handle 7-bit ASCII >When applying such (unnecessary) transformations to 8bit messages in >on-the-wire-format (which would inevitably happen when a >multipart/signed is verified or generated), interoperability will, >of course, be ruined. This comment regards various character sets... >Restricting the signed material to 7bit data also helps to make >signature generation and verification more robust against such >problems, and implementations considerably simpler. True. >For all these reasons, I urge the Usenet format working group to >remove the reference to multipart/signed from section 6.21.3. Ditto. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by above.proper.com (8.9.3/8.9.3) id SAA16492 for ietf-openpgp-bks; Mon, 16 Apr 2001 18:30:12 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA16488 for ; Mon, 16 Apr 2001 18:30:10 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id VAA05096; Mon, 16 Apr 2001 21:29:56 -0400 To: Brad Templeton Cc: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> <20010416171600.N16467@main.templetons.com> From: Derek Atkins Date: 16 Apr 2001 21:29:55 -0400 In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 17:16:00 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You might want to take a look at draft-ietf-impp-msgfmt-??.txt (please forgive me for not knowing the current revision number). This draft tries to describe a MIME format for encapsulating a MIME message with it's associated meta-content (header information). The purpose of this draft was to allow a sender to sign a message and associated message headers, and then allow a transport system to send the message from the sender to the recipient(s). Using MSGFMT does imply some duplication of headers if your transport system requires them (e.g. IMPP, SMTP, etc). But if you don't need the transport-layer headers, you can stuff them into the MSGFMT part and sign them. Unfortunately this would be an incompatible change with the current netnews protocols. But I figured I'd point out that there are efforts to try to unify the message/message-meta-data dichotomy. Enjoy! -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA12424 for ietf-openpgp-bks; Mon, 16 Apr 2001 17:16:02 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA12420 for ; Mon, 16 Apr 2001 17:16:00 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id RAA27144; Mon, 16 Apr 2001 17:16:00 -0700 Date: Mon, 16 Apr 2001 17:16:00 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416171600.N16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 04:50:48PM -0700, Russ Allbery wrote: > Brad Templeton writes: > It seems reasonably easy to warn if the identity associated with the > signature doesn't match the displayed identity derived from the From > header, but I haven't thought a great deal about the user interface > portion of this. Indeed that's good. That's header verification, which is what I'm pushing for, though you should verify more than just the From header. There are a variety of ways to do this. The right "mime" way is ugly, namely to embed another multipart in the 1st half of the mult/signed, which in turn has the body and a representation of the header. I have advocated (and the multipart/signed people I have talked to have agreed, saying they should have done this in the first place) that the multipart/signed form allow more than 2 parts, with semantics in the final signature part controlling just how the signature is checked on parts 1...N-1. USENET could be the first to include this extension. If there were a body issuing certificates for email addresses, that could be used to verify just the from line or other email lines, but again, why stop there. Somehow, somewhere in the body, a hash of the valid header needs to be provided. Putting it in the text is ugly, but is the only way the existing multipart/signed spec would verify it. The best option is probably to extend the spec. > > There are some announce groups where all the content is signed. > comp.os.linux.announce, for example. There are some people who always > sign all of their posts. A group where everything is signed can be secured, if the software is then programmed to reject or give warnings on the rare unsigned messages. (ideally relays should just not carry them in such a group, just as they in theory reject unauthorized postings in moderated groups.) However, support for "people who signs all their posts" is the hard issue. You need to spec a lot of extra stuff to make this work, somehow building databases of people who are in this state, and getting software to use those databases. You must have a certificate system, because you can't just put this flag on a user once they sign their first post, as the first one might be forged, thus locking the user out from posting under his own email. But even then, as I have indicated, it's easy for me to post as "rra@leland3.stanford.edu" even if you are the only one who can post as "rra@stanford.edu". It would be tough for you to figure out every form of your name and reserve it. > So it's your position that this standard should *not* adopt MIME? It should absolutely adopt MIME, and should make it a SHOULD, possibly even a MUST. At the same time, non-conformant readers will exist for quite some time, so we must for some years be aware of the older readers, and decide how we will _use_ MIME, comparing the tradeoff for those users with the benefit of it. Securing headers is well worth the ugly display to users of old newsreaders. Signing bodies is less convincing a sell. > To repeat myself (again), I feel very strongly that adopting MIME is a > binary switch. Either we adopt MIME or we don't. The time to try to > fiddle with MIME was when MIME was being developed, and should have been MIME is meant to be extended, and major users of it are free to develop extensions and try to get them adopted outside their space. I fully agree we should throw that binary switch, but I also face reality. I've seen newsgroups where people post with wasteful stuff, for no benefit to most of the readers, and it gets a lot of antipathy. Mime multipart/alternative was created so MIME systems could go through evolutions, but it's a very bulky system, more suited to mail than news, and so when it first started being used by Netscape, people were screamed at to go away. It's a little more accepted now but it took a lot. That was, in part, why I pushed the concept of out of band markup, which is a better migration to rich text than multipart/alternative. Note that at this time, the vast majority of USENET users have a reader that handles not just MIME, but even HTML. Still, some things are worth it and some are not. Non-english character sets, hyperlinks, structure, and securing headers are all worth it. Signing bodies is something we've seen for a while, but I have yet to see it actually be useful to anybody. Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA11555 for ietf-openpgp-bks; Mon, 16 Apr 2001 16:50:51 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA11550 for ; Mon, 16 Apr 2001 16:50:50 -0700 (PDT) Received: (qmail 5341 invoked by uid 50); 16 Apr 2001 23:50:48 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> <20010416162037.I16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 16:20:37 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 16:50:48 -0700 Message-ID: Lines: 77 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote: >> That seems to be a non-sequitur. It's certainly possible to >> automatically verify a multipart/signed message. Some news readers and >> many mail readers already do this. > If all the software does is include a string about the verification, > that is then manually checked, it's manual verification. Humans ignore > warnings which happen frequently. Thus if most (or even just a lot, > like a few percent) of otherwise valid messages have the warning, people > learn to ignore the warning. It seems reasonably easy to warn if the identity associated with the signature doesn't match the displayed identity derived from the From header, but I haven't thought a great deal about the user interface portion of this. > What are these "important announcements" though? As I indicated, I mean > that all the messages in a "class" have to be signed, so that it becomes > worthy of note when a message in a class is not signed, and this can > cause a warning that will be paid attention to. There are some announce groups where all the content is signed. comp.os.linux.announce, for example. There are some people who always sign all of their posts. > I would rather solve the real problems the net faces with security, > which are unauthorized control messages (and the resulting lack of trust > in authorized control messages), most of all cancel, and large scale > spam. Yes, I agree. However, no one is asking you to solve any of these other problems. This thread started with the OpenPGP folks asking us to please not arbitrarily mangle their existing standard. That seems rather reasonable to me. We don't have to do any work at all beyond not interfering with their (existing!) standard. > We will eventually need to put all that mime stuff in, and it will annoy > a lot of users (we've all seen this) but we should do it for something > really useful, not mostly ignored signature of bodies. So it's your position that this standard should *not* adopt MIME? To repeat myself (again), I feel very strongly that adopting MIME is a binary switch. Either we adopt MIME or we don't. The time to try to fiddle with MIME was when MIME was being developed, and should have been done as part of a different working group than this one; at this point, it's just Not Invented Here syndrome. Either netnews should continue to track the mail standards (which I would argue should be the *default* since that's been the policy behind netnews from the beginning), or we should explicitly say that we're not adopting MIME, but trying to grab bits and pieces creates exactly the kinds of internal inconsistencies that are being pointed out in this thread. If we want multipart messages, well-labelled character sets, the ability to transfer non-text messages without unlabelled structural content like uuencode, and the ability to take advantage of all of the work that the (quite a bit larger, quite a bit better-funded, and quite a bit better at developing and deploying new technology) mail community is doing, then I think we should simply say that the MIME standard also applies to netnews messages and then pick up the pieces, if any, within the framework already laid out for extending MIME. The current draft leans more in that direction than in the direction of not adopting MIME, but currently in some places is still trying to balance on the top of non-existent fences. And lest people worry too much about some portions of that, let me point out that (a) Usenet is not the only thing that netnews is used for and the standard should be usable for things other than Usenet, and (b) it's still perfectly reasonable for individual hierarchies to have their own policies about acceptable message body formats above and beyond what the standard *allows* for. If they want to try to figure out how to get message/signed working without QP, that's their lookout; it's a heck of a lot easier to change hierarchy policies than it is to change an RFC. -- Russ Allbery (rra@stanford.edu) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA09605 for ietf-openpgp-bks; Mon, 16 Apr 2001 16:20:40 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA09598 for ; Mon, 16 Apr 2001 16:20:38 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id QAA26264; Mon, 16 Apr 2001 16:20:37 -0700 Date: Mon, 16 Apr 2001 16:20:37 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416162037.I16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote: > Brad Templeton writes: > > Yes, but manual verification of signatures is of dubious value. > > That seems to be a non-sequitur. It's certainly possible to automatically > verify a multipart/signed message. Some news readers and many mail > readers already do this. If all the software does is include a string about the verification, that is then manually checked, it's manual verification. Humans ignore warnings which happen frequently. Thus if most (or even just a lot, like a few percent) of otherwise valid messages have the warning, people learn to ignore the warning. > > For digital signature authentication to work properly, it is > > unfortunately necessary that all messages in a class be signed, and that > > the presence of an unsigned or improperly signed message be a major > > anomaly which gets a fair bit of attention, or which is in fact > > forbidden. > > You're solving a different problem than I'm talking about. For occasional > use for important announcements, the multipart/signed protocol works just > fine. I understand that you're trying to solve the problem of fully > authenticated message streams, which I agree is an interesting theoretical What are these "important announcements" though? As I indicated, I mean that all the messages in a "class" have to be signed, so that it becomes worthy of note when a message in a class is not signed, and this can cause a warning that will be paid attention to. So what is this class called "important annoucements" and how is it defined, and how does the software detect it, and know when an important annoucement comes that is not validly signed, so that it can warn me about it? If you just mean that "before you say something important" be sure to sign it, again the value of that is limited, though not zero. It means that people who are in the know, after reading something of some importance (whatever that is) would then look to see if it is signed, or have their brain pay attention to the "this is not signed" warning which appears on almost all messages. I would rather solve the real problems the net faces with security, which are unauthorized control messages (and the resulting lack of trust in authorized control messages), most of all cancel, and large scale spam. Don't get me wrong, I think bodies should be authenticated, but the value from it, at least in today's net, is minimal, and the backlash over it, namely a lot of mime stuff most readers don't know how to handle tacked on the end of messages, far worse than the benefit. We will eventually need to put all that mime stuff in, and it will annoy a lot of users (we've all seen this) but we should do it for something really useful, not mostly ignored signature of bodies. Received: by above.proper.com (8.9.3/8.9.3) id OAA03192 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:42:55 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA03188 for ; Mon, 16 Apr 2001 14:42:54 -0700 (PDT) Received: (qmail 4861 invoked by uid 50); 16 Apr 2001 21:42:51 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> <20010416142357.H16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 14:23:57 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 14:42:51 -0700 Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote: >> This depends rather heavily on the context. What you say is true for >> some applications (like control messages) and not true for others (like >> official announcements from some entity or another that are posted to >> Usenet). At the worst, what it means that one has to include the >> important information that should be authenticated by the signature, >> such as the date and the author, in the body of the message. Quite >> frequently for things like announcements this is done as a matter of >> course anyway. > Yes, but manual verification of signatures is of dubious value. That seems to be a non-sequitur. It's certainly possible to automatically verify a multipart/signed message. Some news readers and many mail readers already do this. > For digital signature authentication to work properly, it is > unfortunately necessary that all messages in a class be signed, and that > the presence of an unsigned or improperly signed message be a major > anomaly which gets a fair bit of attention, or which is in fact > forbidden. You're solving a different problem than I'm talking about. For occasional use for important announcements, the multipart/signed protocol works just fine. I understand that you're trying to solve the problem of fully authenticated message streams, which I agree is an interesting theoretical problem. I don't expect to see such a thing show up on Usenet soon, however, since most people currently using Usenet don't really have much use for it. *shrug* I know you care more about it than I do, and I may be underestimating the demand. > People have been able to sign article bodies for some time. It's not > widely used and it's really not very useful. It does, however, have the advantage of actually being deployed, working, and standardized. The sort of signature system that you're describing would be more useful for some applications than multipart/signed, I agree, should someone eventually write it and standardize it. Making it work well within MIME would be quite difficult, as we've already established in some of the previous rounds of discussion on that topic. -- Russ Allbery (rra@stanford.edu) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA02288 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:24:05 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02283 for ; Mon, 16 Apr 2001 14:24:02 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id OAA24864; Mon, 16 Apr 2001 14:23:57 -0700 Date: Mon, 16 Apr 2001 14:23:57 -0700 From: Brad Templeton To: Russ Allbery Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416142357.H16467@main.templetons.com> Mail-Followup-To: Russ Allbery , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote: > Brad Templeton writes: > > > Mulitpart/signed, while probably the best of the singature forms, is not > > suitable to USENET. It only signs the body. Signing the body is not > > just the least interesting thing we can do in USENET (99.9% of all > > problems come from forged headers, not modification of bodies) it can > > actually have negative value, if it leads people to think the article is > > "signed" and thus can be trusted in ways that it actually can't. > > This depends rather heavily on the context. What you say is true for some > applications (like control messages) and not true for others (like > official announcements from some entity or another that are posted to > Usenet). At the worst, what it means that one has to include the > important information that should be authenticated by the signature, such > as the date and the author, in the body of the message. Quite frequently > for things like announcements this is done as a matter of course anyway. Yes, but manual verification of signatures is of dubious value. For digital signature authentication to work properly, it is unfortunately necessary that all messages in a class be signed, and that the presence of an unsigned or improperly signed message be a major anomaly which gets a fair bit of attention, or which is in fact forbidden. If newsgroups allow both signed and unsigned messages, then it is trivial to cause trouble by simply not signing your unsigned messages. If a given user signs all his messages, it is not even sufficient for the software to be able to warn that a user who normally signs all his messages has not signed one, because the forger can play any number of tricks, including simply posting a message "From: rrra@stanford.edu" which looks like you to the non-careful eye, or worse "From: rra@windlord.stanford.edu" which *is* you but the software is unlikley to trap the warning that all messages from this address should be signed. Or rra%stanford.edu@leland.stanford.edu or many other forms which point to you. Of course you're even assuming something outside the multipart/signed spec, that the software is checking the From line at all, based on parsing it somehow out of the body. People have been able to sign article bodies for some time. It's not widely used and it's really not very useful. It would be a poor intermediate step because it's the wrong problem, and can lead to problems as well as limited benefit. All signing bodies does, without other checks, is allow me to prove after the fact that I really sent a message. It doesn't prove that I _didn't_ send it, for I am free to post unsigned messages which I can later disclaim. It also allows those who know my key to verify I sent a message, if they check. I've never been called upon to prove I sent a message. I don't recall ever seeing this for anybody else either. I have seen cases where people wonder if a person really sent a message, of course, but I've also seen a lot of forgeries that were so blatantly obvious that nobody of the sort who would check signatures would ever be fooled, and yet people are fooled. What you need is a system that shows that messages are from who they say they are from, and makes a big deal when they aren't. If 90% of messages start having a "The sender of this message could not be authenticated" then people simply start ignoring the warning, and it becomes of limited value. Received: by above.proper.com (8.9.3/8.9.3) id OAA01088 for ietf-openpgp-bks; Mon, 16 Apr 2001 14:07:12 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.13.23]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA01082 for ; Mon, 16 Apr 2001 14:07:11 -0700 (PDT) Received: (qmail 4705 invoked by uid 50); 16 Apr 2001 21:07:07 -0000 To: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> <20010416125155.F16467@main.templetons.com> In-Reply-To: Brad Templeton's message of "Mon, 16 Apr 2001 12:51:55 -0700" From: Russ Allbery Organization: The Eyrie Date: 16 Apr 2001 14:07:07 -0700 Message-ID: Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brad Templeton writes: > Mulitpart/signed, while probably the best of the singature forms, is not > suitable to USENET. It only signs the body. Signing the body is not > just the least interesting thing we can do in USENET (99.9% of all > problems come from forged headers, not modification of bodies) it can > actually have negative value, if it leads people to think the article is > "signed" and thus can be trusted in ways that it actually can't. This depends rather heavily on the context. What you say is true for some applications (like control messages) and not true for others (like official announcements from some entity or another that are posted to Usenet). At the worst, what it means that one has to include the important information that should be authenticated by the signature, such as the date and the author, in the body of the message. Quite frequently for things like announcements this is done as a matter of course anyway. -- Russ Allbery (rra@stanford.edu) Received: by above.proper.com (8.9.3/8.9.3) id MAA25194 for ietf-openpgp-bks; Mon, 16 Apr 2001 12:52:13 -0700 (PDT) Received: from main.templetons.com (IDENT:root@main.templetons.com [209.31.224.60]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25189 for ; Mon, 16 Apr 2001 12:52:12 -0700 (PDT) Received: (from brad@localhost) by main.templetons.com (8.9.3/8.9.3) id MAA23709; Mon, 16 Apr 2001 12:51:55 -0700 Date: Mon, 16 Apr 2001 12:51:55 -0700 From: Brad Templeton To: Erland Sommarskog Cc: usenet-format@rkive.landfield.com, ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010416125155.F16467@main.templetons.com> Mail-Followup-To: Erland Sommarskog , usenet-format@rkive.landfield.com, ietf-openpgp@imc.org References: <20010414112312.B12141@sobolev.does-not-exist.org> <20010416125151.28845.qmail@kairos.algonet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20010416125151.28845.qmail@kairos.algonet.se> Organization: http://www.templetons.com/brad Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 16, 2001 at 12:51:51PM -0000, Erland Sommarskog wrote: > Thomas Roessler writes: > > It should also be noted it's impossible to convert a > > multipart/signed entity which contains 8bit body parts to any 7bit > > format without breaking the signature. (Remember that MIME > > explicitly forbids nested MIME encodings: Recoding has to happen on > > the leaf level of a nested MIME structure.) > > Since I know very little about this signing business, I'll have to > ask some really stupid questions. > > What is in multipart/signed? Is it just the signature? Or is it any part > of the message that a human is supposed to read? Mulitpart/signed, while probably the best of the singature forms, is not suitable to USENET. It only signs the body. Signing the body is not just the least interesting thing we can do in USENET (99.9% of all problems come from forged headers, not modification of bodies) it can actually have negative value, if it leads people to think the article is "signed" and thus can be trusted in ways that it actually can't. Received: by above.proper.com (8.9.3/8.9.3) id LAA19263 for ietf-openpgp-bks; Mon, 16 Apr 2001 11:02:04 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19259 for ; Mon, 16 Apr 2001 11:02:02 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14pDJA-0005YK-00 for ietf-openpgp@imc.org; Mon, 16 Apr 2001 20:01:04 +0200 To: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. References: <20010416125151.28845.qmail@kairos.algonet.se> From: Florian Weimer Date: 16 Apr 2001 20:01:04 +0200 In-Reply-To: <20010416125151.28845.qmail@kairos.algonet.se> (sommar@algonet.se's message of "16 Apr 2001 12:51:51 -0000") Message-ID: Lines: 12 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sommar@algonet.se (Erland Sommarskog) writes: > Since I know very little about this signing business, I'll have to > ask some really stupid questions. I'm sorry but I've already replied on the USEFOR list only. The discussion will be continued over there. :-/ -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: by above.proper.com (8.9.3/8.9.3) id FAA26962 for ietf-openpgp-bks; Mon, 16 Apr 2001 05:52:05 -0700 (PDT) Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.51]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA26956 for ; Mon, 16 Apr 2001 05:52:02 -0700 (PDT) Received: (qmail 16293 invoked from network); 16 Apr 2001 14:51:52 +0200 Received: from delenn.tninet.se (HELO algonet.se) (195.100.94.104) by hromeo.algonet.se with SMTP; 16 Apr 2001 14:51:52 +0200 Received: from kairos.algonet.se (kairos.algonet.se [194.213.74.201]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 850192.425511.987delenn-s1 for ; Mon, 16 Apr 2001 14:51:51 +0200 Received: (qmail 28846 invoked by uid 8884); 16 Apr 2001 12:51:51 -0000 Date: 16 Apr 2001 12:51:51 -0000 Message-ID: <20010416125151.28845.qmail@kairos.algonet.se> To: usenet-format@rkive.landfield.com Cc: ietf-openpgp@imc.org Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. From: sommar@algonet.se (Erland Sommarskog) In-Reply-To: <20010414112312.B12141@sobolev.does-not-exist.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > It should also be noted it's impossible to convert a > multipart/signed entity which contains 8bit body parts to any 7bit > format without breaking the signature. (Remember that MIME > explicitly forbids nested MIME encodings: Recoding has to happen on > the leaf level of a nested MIME structure.) Since I know very little about this signing business, I'll have to ask some really stupid questions. What is in multipart/signed? Is it just the signature? Or is it any part of the message that a human is supposed to read? If it's only the signature, I don't have any issue with it. If it is text intended to be read by humans, is the problem both trailing white-space and octets >= 128? If only trailing white-space is the problem, wouldn't be better to define an encoding that took care of those and nothing else? What I care about in the end is that text which is supposed to be read by humans are not mutilated. -- Erland Sommarskog, Stockholm, sommar@algonet.se Received: by above.proper.com (8.9.3/8.9.3) id KAA10000 for ietf-openpgp-bks; Sun, 15 Apr 2001 10:13:20 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA09994 for ; Sun, 15 Apr 2001 10:13:18 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14oq4U-0003a8-00 for ietf-openpgp@imc.org; Sun, 15 Apr 2001 19:12:22 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt References: <200104111101.HAA20025@ietf.org> <20010414095529.A12141@sobolev.does-not-exist.org> From: Florian Weimer Date: 15 Apr 2001 19:12:22 +0200 Message-ID: Lines: 45 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > The text/binary mode interop problem is related to trailing > whitespace. It is not related to the presence or absence 8bit > characters. OpenPGP textmode signatures are not very well-defined. First of all, OpenPGP requires text to be encoded in UTF-8, a requirement which is hardly followed in practice. In addition, there are at least four Unicode characters relating to line endings: U+000A, U+000D, U+0085 (NEXT LINE or NEL, somehow related to ISO 6429), U+2028 (LINE SEPARATOR, native to the Unicode standard). Especially U+0085 could be considered as a line terminator by some implementations which are closely related to an EBCDIC environment (AFAIK, this control character is used to represent a line-terminating EBCDIC control character when using one of the bijective EBCDIC <-> ISO 8859 maps). So 8-bit data signed by a text-mode signature should not include the following octets: 0x0a, 0x0d, 0x85 (ISO 8859 represenation of NEL), the octet sequence 0xc2 0x85 (UTF-8 representation of NEL), and the octet sequence 0xe2 0x80 0xa8, which is the UTF-8 representation of the LINE SEPERATOR character. This does not include any legacy ;-) East-Asia encodings (which might be used instead of UTF-8 for encoding the signed text), and overlong UTF-8 sequences (which are not permitted in theory, but implementations might disagree). Given these problems, I think it's not wise to assume that text-mode signatures are binary-transparent in any way. > > (USEFOR currently overrides the analogous requirement in RFC 2015.) > > I hope you're joking. No, I'm afraid. :-/ > Could you please send the relevant sections from the latest usefor > draft to this list? I think you've already found them. I've raised this issue as well on the list, hopefully it is addressed properly. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: by above.proper.com (8.9.3/8.9.3) id AAA20522 for ietf-openpgp-bks; Sun, 15 Apr 2001 00:26:10 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA20511 for ; Sun, 15 Apr 2001 00:26:08 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id AAA06210 for ietf-openpgp@imc.org; Sun, 15 Apr 2001 00:20:44 -0700 Date: Sun, 15 Apr 2001 00:20:44 -0700 Message-Id: <200104150720.AAA06210@finney.org> To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Roessler writes: > Thus, Ulf's question remains valid: If you follow the old behaviour > in one of the more important fields of application anyway, why on > earth didn't you make sure RFC 2440 and your applications followed > this kind of behaviour in general? After all, he had indeed warned > of the inconsistency introduced by RFC 2440. It is true, Ulf posted on this twice, on 16 Sep 98: | 0x01: Signature of a canonical text document. | Typically, this means the signer owns it, created it, or | certifies that it has not been modified. The signature is | calculated over the text data with its line endings converted to | and trailing blanks removed. Trailing blanks are removed _only_ for cleartext signatures, in the transformation described in section 7.1. Otherwise (for signatures contained in a PGP message, and for detached signatures) they are part of the signature. BTW, there's no proper definition of detached signatures in the draft. They probably should be mentioned in section 10 because they are used for PGP/MIME. and again on 13 Oct 98: Looks good, but the definition for the canonical text signature is still wrong. (Also I note you didn't include the note about PGP 2.6.x being unable to hande signature and pubkey packets of length type 0.) | 0x01: Signature of a canonical text document. | Typically, this means the signer owns it, created it, or | certifies that it has not been modified. The signature is | calculated over the text data with its line endings converted to | and trailing blanks removed. Trailing blanks are removed _only_ for cleartext signatures, in the transformation described in section 7.1. Otherwise (for signatures contained in a PGP message, and for detached signatures) they are part of the signature. The RFC issued on 11 Nov 98 without this change. I can't account for our overlooking these two comments. It was an error on my part and that of the other authors. No process is perfect. I note that the current RFC2440bis draft still has the incorrect language. Should we change the new draft to document the way the commercial versions of PGP, and versions 2.X, have always worked? Hal Received: by above.proper.com (8.9.3/8.9.3) id XAA12061 for ietf-openpgp-bks; Sat, 14 Apr 2001 23:36:14 -0700 (PDT) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA12050 for ; Sat, 14 Apr 2001 23:36:12 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin82.pg2-nt.dusseldorf.nikoma.de [213.54.97.82]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id IAA70315 for ; Sun, 15 Apr 2001 08:36:07 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id C32AC2ED15; Sat, 14 Apr 2001 20:30:14 +0200 (CEST) Date: Sat, 14 Apr 2001 20:30:14 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Message-ID: <20010414203014.A26840@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <200104141806.LAA04356@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <200104141806.LAA04356@finney.org>; from hal@finney.org on Sat, Apr 14, 2001 at 11:06:18AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-04-14 11:06:18 -0700, hal@finney.org wrote: > First, my description above referred to the behavior of NAI's > commercial implementation of PGP on PGP/MIME messages. RFC 2440 > does not discuss PGP/MIME messages, so it would not be > appropriate to put such information into RFC 2440. PGP/MIME makes use of the OpenPGP format. It says very clearly what's the signed material, and that an OpenPGP signatur is generated. This means, of course, that no changes should be done to the signed material beyond what the OpenPGP spec mandates. In particular, PGP/MIME does NOT define any new hash methods, or new canonification methods to be performed by the back-end. It just refers the reader to the OpenPGP (or PGP) specification for all these points. Thus, Ulf's question remains valid: If you follow the old behaviour in one of the more important fields of application anyway, why on earth didn't you make sure RFC 2440 and your applications followed this kind of behaviour in general? After all, he had indeed warned of the inconsistency introduced by RFC 2440. But, anyway, the new spec resolves this by prohibiting trailing whitespace, which brings other problems, but seems to be the only compatible way out of this mess. -- Thomas Roessler Received: by above.proper.com (8.9.3/8.9.3) id LAA24113 for ietf-openpgp-bks; Sat, 14 Apr 2001 11:11:41 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA24108 for ; Sat, 14 Apr 2001 11:11:40 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA04356 for ietf-openpgp@imc.org; Sat, 14 Apr 2001 11:06:18 -0700 Date: Sat, 14 Apr 2001 11:06:18 -0700 Message-Id: <200104141806.LAA04356@finney.org> To: ietf-openpgp@imc.org Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ulf =?iso-8859-1?Q?M=F6ller?= > On Tue, Feb 13, 2001 at 03:59:37PM -0800, hal@finney.org wrote: > > > I can tell you that on message receipt, the commercial versions of PGP > > from Network Associates DO hash trailing whitespace on PGP/MIME messages. > > That is, they are sensitive to the presence of trailing whitespace and > > it is included in the hash. This is true regardless of whether the > > signature type byte is text or binary mode. That may or may not be > > compatible with the spec but that is how these versions work. > > Then why did you guys refuse to change the OpenPGP specification when > the inconsistency was pointed out well before RFC 2440 was published? First, my description above referred to the behavior of NAI's commercial implementation of PGP on PGP/MIME messages. RFC 2440 does not discuss PGP/MIME messages, so it would not be appropriate to put such information into RFC 2440. Second, RFC 2440 is not perfect and does have errors. These are not the result of stubborn refusal to make changes and insistence on putting out an imperfect draft. Rather, mistakes are made in both the drafting and editing process, and sometimes comments are overlooked. Hal Received: by above.proper.com (8.9.3/8.9.3) id HAA08083 for ietf-openpgp-bks; Sat, 14 Apr 2001 07:39:22 -0700 (PDT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08076 for ; Sat, 14 Apr 2001 07:39:20 -0700 (PDT) Received: from LOCALHOST ([64.228.185.149]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010414143850.QTRY17644.tomts5-srv.bellnexxia.net@LOCALHOST>; Sat, 14 Apr 2001 10:38:50 -0400 From: Ulf =?iso-8859-1?Q?M=F6ller?= To: hal@finney.org Date: Sat, 14 Apr 2001 10:37:37 -0400 Subject: Re: PGP/MIME implementors: text mode vs. binary mode? Message-ID: <20010414103737.A982@localhost.localdomain> References: <200102132359.PAA03769@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200102132359.PAA03769@finney.org>; from hal@finney.org on Tue, Feb 13, 2001 at 03:59:37PM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 13, 2001 at 03:59:37PM -0800, hal@finney.org wrote: > I can tell you that on message receipt, the commercial versions of PGP > from Network Associates DO hash trailing whitespace on PGP/MIME messages. > That is, they are sensitive to the presence of trailing whitespace and > it is included in the hash. This is true regardless of whether the > signature type byte is text or binary mode. That may or may not be > compatible with the spec but that is how these versions work. Then why did you guys refuse to change the OpenPGP specification when the inconsistency was pointed out well before RFC 2440 was published? Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA13655 for ietf-openpgp-bks; Sat, 14 Apr 2001 02:24:06 -0700 (PDT) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13650 for ; Sat, 14 Apr 2001 02:24:04 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin134.pg4-nt.dusseldorf.nikoma.de [213.54.99.134]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id LAA27459; Sat, 14 Apr 2001 11:24:01 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 411312ED15; Sat, 14 Apr 2001 11:23:12 +0200 (CEST) Date: Sat, 14 Apr 2001 11:23:12 +0200 From: Thomas Roessler To: usenet-format@landfield.com Cc: ietf-openpgp@imc.org Subject: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful. Message-ID: <20010414112312.B12141@sobolev.does-not-exist.org> Mail-Followup-To: usenet-format@landfield.com, ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm writing as one of the co-authors of draft-ietf-openpgp-mime-06, which is hoped to become the successor of RFC 2015 (PGP/MIME) soon. In section 6.21.3 of draft-*-article-04, you write the following: In the same way, Content-Types requiring special processing for their display, such as "application", "image", "audio", "video" and "multipart/related" are discouraged except in groups specifically intended (by policy or custom) to include them. Exceptionally, those application types defined in [RFC 1847] and [RFC 2015] for use within "multipart/signed" articles, and the type "application/pgp-keys" (or other similar types containing digital certificates) may be used freely but, contrary to [RFC 2015] and unless the article is intended to be sent by mail also, the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit" as appropriate). I consider this section harmful for various reasons. First, it should be noted that problems with transmitting 8bit content are not the only reason for which an agent implementing PGP/MIME may elect to use quoted-printable or base64 as a body part's encoding. In particular, draft-ietf-openpgp-mime-06 specifies that the signed material in a PGP/MIME multipart/signed entity MUST NOT include any trailing whitespace. This may either be achieved by cutting off trailing whitespace, or by protecting it with an appropriate transfer encoding. The reason for this lies in the definition of a text-mode signature in RFC 2440 [OpenPGP], which is incompatible with the definition used by traditional implementations (aka pgp version 2). More precisely, a text-mode signature traditionally meant that any line feed has to be canonicalized to CR LF before hashing. With OpenPGP, trailing whitespace is additionally snipped. (That's the kind of processing which has traditionally been applied to clearsigned messages.) Now, the processing rules for multipart/signed make sure that line feeds are canonical before they hit the signing engine. With traditional PGP, that meant that text-mode and binary-mode hashes of the material would be identical. This is no longer valid with OpenPGP, which has two consequences: (1) In order to determine what hash is to be computed, a receiving agent would have to look at the signature. This would break the possibility to process multipart/signed in one pass. (2) In the presence of trailing whitespace, text-mode signatures wouldn't be interoperable between implementations using PGP 2 and OpenPGP implementations. The best way to fix both problems is to make sure that no trailing whitespace is present, by applying appropriate encodings. (With text/plain; format=flowed, this will be something which is encountered quite frequently.) For this reason alone, mandating transparent encodings may not be the best idea at this point. It should also be noted it's impossible to convert a multipart/signed entity which contains 8bit body parts to any 7bit format without breaking the signature. (Remember that MIME explicitly forbids nested MIME encodings: Recoding has to happen on the leaf level of a nested MIME structure.) This implies, that a multipart/signed entity wihich contains 8bit body parts cannot be legally transported via Internet e-mail without ruining the signature - be it as part of message/rfc822 encapsulation, be it as a direct attachment. Finally, I'd like to warn you that signature generation and verification interoperability may seriously be endangered by allowing 8bit body parts in a multipart/signed. More precisely, a multipart/signed body part may generally contain textual data in various character sets - it may even contain a nested multipart/mixed with text/plain subparts which bear different character sets. However, PGP signature generators and verifiers have traditionally been expecting that they are presented with data in a local character set when preparing text-mode signatures. For this reason, signature generators and verifiers may attempt to recode data they are presented with to whatever character set is considered to be canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2). When applying such (unnecessary) transformations to 8bit messages in on-the-wire-format (which would inevitably happen when a multipart/signed is verified or generated), interoperability will, of course, be ruined. Restricting the signed material to 7bit data also helps to make signature generation and verification more robust against such problems, and implementations considerably simpler. For all these reasons, I urge the Usenet format working group to remove the reference to multipart/signed from section 6.21.3. -- Thomas Roessler Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA04139 for ietf-openpgp-bks; Sat, 14 Apr 2001 01:02:48 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA04131 for ; Sat, 14 Apr 2001 01:02:46 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin189.pg5-nt.dusseldorf.nikoma.de [213.54.100.189]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id KAA94556; Sat, 14 Apr 2001 10:02:31 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 329152ED15; Sat, 14 Apr 2001 09:55:29 +0200 (CEST) Date: Sat, 14 Apr 2001 09:55:29 +0200 From: Thomas Roessler To: Florian Weimer Cc: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt Message-ID: <20010414095529.A12141@sobolev.does-not-exist.org> Mail-Followup-To: Florian Weimer , ietf-openpgp@imc.org References: <200104111101.HAA20025@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Sat, Apr 14, 2001 at 01:33:53AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-04-14 01:33:53 +0200, Florian Weimer wrote: >> Multipart/signed and multipart/encrypted are to be treated by >> agents as opaque, meaning that the data is not to be altered >> in any way [2], [7]. However, many existing mail gateways >> will detect if the next hop does not support MIME or 8-bit >> data and perform conversion to either Quoted-Printable or >> Base64. This presents serious problems for multipart/signed, >> in particular, where the signature is invalidated when such >> an operation occurs. For this reason all data signed >> according to this protocol MUST be constrained to 7 bits >> (8-bit data MUST be encoded using either Quoted-Printable or >> Base64). > of the 7 bit constraint fails to mention the binary/text mode > signature interoperability problem which can only be addressed if > there aren't any 8-bit characters. Eh? It may be because I didn't have any coffee so far, but somehow, I don't understand what you are trying to say here. The text/binary mode interop problem is related to trailing whitespace. It is not related to the presence or absence 8bit characters. The next section basically says that, and makes suggestions on how to fix things: Additionally, implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied. Note: In most cases, trailing whitespace can either be removed, or protected by applying an appropriate content-transfer-encoding. However, special care must be taken when any header lines - either in MIME entity headers, or in embedded RFC 822 headers - are present which only consist of whitespace: Such lines must be removed entirely, since replacing them by empty lines would turn them into header delimiters, and change the semantics of the message. The restrictions on whitespace are necessary in order to make the hash calculated invariant under the text and binary mode signature mechanisms provided by OpenPGP [1]. Also, they help to avoid compatibility problems with PGP implementations which predate the OpenPGP specification. Note: If any line begins with the string "From ", it is strongly suggested that either the Quoted-Printable or Base64 MIME encoding be applied. If Quoted-Printable is used, at least one of the characters in the string should be encoded using the hexadecimal coding rule. This is because many mail transfer and delivery agents treat "From " (the word "from" followed immediately by a space character) as the start of a new message and thus insert a right angle-bracket (>) in front of any line beginning with "From " to distinguish this case, invalidating the signature. Of course, implementations are free to find other standards-compliant ways of protecting whitespace - however, I doubt they'll find such ways. > (USEFOR currently overrides the analogous requirement in RFC 2015.) I hope you're joking. Could you please send the relevant sections from the latest usefor draft to this list? -- Thomas Roessler Received: by above.proper.com (8.9.3/8.9.3) id QAA00565 for ietf-openpgp-bks; Fri, 13 Apr 2001 16:34:45 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA00561 for ; Fri, 13 Apr 2001 16:34:44 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14oD4b-00064O-00 for ietf-openpgp@imc.org; Sat, 14 Apr 2001 01:33:53 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt References: <200104111101.HAA20025@ietf.org> From: Florian Weimer Date: 14 Apr 2001 01:33:53 +0200 In-Reply-To: <200104111101.HAA20025@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 11 Apr 2001 07:01:16 -0400") Message-ID: Lines: 31 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Internet-Drafts@ietf.org writes: > Title : MIME Security with OpenPGP > Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler > Filename : draft-ietf-openpgp-mime-06.txt > Pages : 13 > Date : 10-Apr-01 I know it's too late know, but while reviewing the current USEFOR draft, I discovered that the explanation | Multipart/signed and multipart/encrypted are to be treated by agents | as opaque, meaning that the data is not to be altered in any way [2], | [7]. However, many existing mail gateways will detect if the next hop | does not support MIME or 8-bit data and perform conversion to either | Quoted-Printable or Base64. This presents serious problems for | multipart/signed, in particular, where the signature is invalidated | when such an operation occurs. For this reason all data signed | according to this protocol MUST be constrained to 7 bits (8-bit data | MUST be encoded using either Quoted-Printable or Base64). of the 7 bit constraint fails to mention the binary/text mode signature interoperability problem which can only be addressed if there aren't any 8-bit characters. (USEFOR currently overrides the analogous requirement in RFC 2015.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: by above.proper.com (8.9.3/8.9.3) id KAA00952 for ietf-openpgp-bks; Wed, 11 Apr 2001 10:29:51 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00947 for ; Wed, 11 Apr 2001 10:29:49 -0700 (PDT) Received: from [129.46.76.217] (dhcp231.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3BHToT09469 for ; Wed, 11 Apr 2001 10:29:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200104111101.HAA20025@ietf.org> References: <200104111101.HAA20025@ietf.org> X-Mailer: Eudora [Macintosh version 5.1-0411010852] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 11 Apr 2001 10:22:23 -0700 To: ietf-openpgp@imc.org From: John W Noerenberg II Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:01 AM -0400 4/11/01, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the An Open Specification for Pretty >Good Privacy Working Group of the IETF. > > Title : MIME Security with OpenPGP > Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler > Filename : draft-ietf-openpgp-mime-06.txt > Pages : 13 > Date : 10-Apr-01 I have requested Jeff and Marcus review -06, and submit it to the IESG for promotion to Proposed Standard as soon as possible. Thanks to everyone for your contributions to this! Thanks especially to the editors who have worked diligently to get it to this point. We'll have congratulations all around when the draft gets its RFC number. Forgive my US-centric quote, but all the time I spend on PGP I think about what PGP means to everyone on the net, in the US and elsewhere. Dr. Lessig's observations about privacy and freedom of speech are never far from my mind. best, -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- Two hundred years after the framers ratified the Constitution, the Net has taught us what the First Amendment really means. -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999 ---------------------------------------------------------------------- Received: by above.proper.com (8.9.3/8.9.3) id KAA29165 for ietf-openpgp-bks; Wed, 11 Apr 2001 10:00:09 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29161 for ; Wed, 11 Apr 2001 10:00:08 -0700 (PDT) Received: from [129.46.76.217] (dhcp231.qualcomm.com [129.46.76.217]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f3BGxuT28148; Wed, 11 Apr 2001 09:59:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <20010409190607.A1948@sobolev.does-not-exist.org> References: <20010409190607.A1948@sobolev.does-not-exist.org> X-Mailer: Eudora [Macintosh version 5.1-0411010852] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 11 Apr 2001 09:55:37 -0700 To: Thomas Roessler From: John W Noerenberg II Subject: Re: PGP/MIME: Last-minute editorial nits. Cc: "ietf-openpgp@imc.org" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:06 PM +0200 4/9/01, Thomas Roessler wrote: >John: I hope the last change is within the limits of due process for >things which can be done after Last Call. Please send me a short >confirmation of that; I'll then finally submit draft-06. ;-) This was just dandy. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- Received: by above.proper.com (8.9.3/8.9.3) id JAA26358 for ietf-openpgp-bks; Wed, 11 Apr 2001 09:07:07 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA26327 for ; Wed, 11 Apr 2001 09:06:57 -0700 (PDT) Received: from [63.73.97.180] (64.166.153.162) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Wed, 11 Apr 2001 09:06:20 -0700 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <3AD460E1.CFC1D64F@saiknes.lv> References: <3AD460E1.CFC1D64F@saiknes.lv> Date: Wed, 11 Apr 2001 08:53:35 -0700 To: disastry@saiknes.lv, ietf-openpgp@imc.org From: Jon Callas Subject: Re: SHA256 ? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:49 PM +0200 4/11/01, disastry@saiknes.lv wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >isn't it time to define new algorithm numbers for SHA2 ? >8 for SHA256 (and maybe 9,10 for SHA384,512?) > >the bigger problem however is with OIDs... >none of SHA2 have OIDs defined, just like HAVAL and TIGER :( > That is, in fact, the bigger problem. We can either finesse it -- we agree on an OID to use for them -- or we wait for some other OID space to assign them. Jon -- Received: by above.proper.com (8.9.3/8.9.3) id GAA13598 for ietf-openpgp-bks; Wed, 11 Apr 2001 06:55:21 -0700 (PDT) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA13590 for ; Wed, 11 Apr 2001 06:55:18 -0700 (PDT) From: disastry@saiknes.lv Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 11 Apr 2001 14:49:21 +0200 Message-ID: <3AD460E1.CFC1D64F@saiknes.lv> Date: Wed, 11 Apr 2001 15:49:21 +0200 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: SHA256 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 isn't it time to define new algorithm numbers for SHA2 ? 8 for SHA256 (and maybe 9,10 for SHA384,512?) the bigger problem however is with OIDs... none of SHA2 have OIDs defined, just like HAVAL and TIGER :( == == Disastry http://i.am/disastry/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBOtREaDBaTVEuJQxkEQIrxwCfd6V3ar8SsymtClQUQlgPxtzJgSMAni8/ wc88/0sPxRvSsKXmWnW7POOg =qYO4 -----END PGP SIGNATURE----- Received: by above.proper.com (8.9.3/8.9.3) id EAA01627 for ietf-openpgp-bks; Wed, 11 Apr 2001 04:01:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01621 for ; Wed, 11 Apr 2001 04:01:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20025; Wed, 11 Apr 2001 07:01:16 -0400 (EDT) Message-Id: <200104111101.HAA20025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-mime-06.txt Date: Wed, 11 Apr 2001 07:01:16 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : MIME Security with OpenPGP Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler Filename : draft-ietf-openpgp-mime-06.txt Pages : 13 Date : 10-Apr-01 This document describes how the OpenPGP Message Format [1] can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 [2]. This draft is being discussed on the 'ietf-openpgp' mailing list. To join the list, send a message to with the single word 'subscribe' in the subject. An archive of the working group's list is located at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-mime-06.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-openpgp-mime-06.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: <20010410134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-mime-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-mime-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010410134952.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.9.3/8.9.3) id JAA10627 for ietf-openpgp-bks; Tue, 10 Apr 2001 09:23:18 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10621 for ; Tue, 10 Apr 2001 09:23:17 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14n0uW-0005Hh-00 for ietf-openpgp@imc.org; Tue, 10 Apr 2001 18:22:32 +0200 To: ietf-openpgp@imc.org Subject: Re: Plug-ins and PGP/MIME (was RE: Java Implementation) References: <200104081203.FAA16182@user4.hushmail.com> From: Florian Weimer Date: 10 Apr 2001 18:22:32 +0200 In-Reply-To: <200104081203.FAA16182@user4.hushmail.com> (sbs@hushmail.com's message of "Sun, 8 Apr 2001 13:03:31 +0000 (GMT+01:00)") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sbs@hushmail.com writes: > That makes sense, since we were testing against the Outlook plug-in. > It seems that this issue is a real barrier against adoption of > PGP/MIME, though. Is it possible to write a plug-in for Exchange which removes or adds some additional transport armor before a message distributed using proprietary technology over the LAN is injected into the Net? This way, access to message headers would not be strictly necessary at the client system. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: by above.proper.com (8.9.3/8.9.3) id CAA01993 for ietf-openpgp-bks; Tue, 10 Apr 2001 02:19:31 -0700 (PDT) Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA01986 for ; Tue, 10 Apr 2001 02:19:28 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14muha-000392-00; Tue, 10 Apr 2001 11:44:46 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14muL6-0005RZ-00; Tue, 10 Apr 2001 11:21:32 +0200 Date: Tue, 10 Apr 2001 11:21:32 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: PGP/MIME aware MUAs Message-ID: <20010410112132.A20911@alberti.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i X-PGP-KeyID: 621CC013 X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D CD75 5DE2 4996 5B03 58A2 X-Request-PGP: finger:wk@porta.u64.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, is there a list of PGP/MIME aware clients available or could we gather some newer info to enhance the table available under http://cryptorights.org/pgp-users/pgp-mail-clients.html ? Here is a first update: Sylpheed support PGP/MIME natively (with gpg installed), signed and encrypted mail is created using the canoncial PGP/MIME method. The combined method can however be handled on recieving mails. ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.9.3/8.9.3) id KAA15136 for ietf-openpgp-bks; Mon, 9 Apr 2001 10:07:32 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15125 for ; Mon, 9 Apr 2001 10:07:30 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin158.pg6-nt.dusseldorf.nikoma.de [213.54.101.158]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id TAA77826; Mon, 9 Apr 2001 19:07:15 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id AFAC22ED15; Mon, 9 Apr 2001 19:06:07 +0200 (CEST) Date: Mon, 9 Apr 2001 19:06:07 +0200 From: Thomas Roessler To: John W Noerenberg II , "ietf-openpgp@imc.org" Subject: PGP/MIME: Last-minute editorial nits. Message-ID: <20010409190607.A1948@sobolev.does-not-exist.org> Mail-Followup-To: John W Noerenberg II , "ietf-openpgp@imc.org" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'll put the following last-minute changes which have not yet been discussed or announced here into draft-ietf-openpgp-mime-06.txt: - Replace OpenPGP Working Group by Network Working Group (Since that's what's on RFCs). - Fix the copyright notes to say Copyright (C) ISOC 2001 (instead of 2000). - In section 5 (OpenPGP signed data), paragraph 2, I'd like to change the wording like this: The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format -"pgp-", where identifies the Message +"pgp-", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Hash-symbols are constructed from the text names registered in [1] or according to the mechanism defined in that document by converting This is to avoid any confusion which may be caused by the fact that, in the old wording, hash-symbol refers to pgp-md5 as well as to md5. John: I hope the last change is within the limits of due process for things which can be done after Last Call. Please send me a short confirmation of that; I'll then finally submit draft-06. ;-) Thanks, -- Thomas Roessler Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA22581 for ietf-openpgp-bks; Sun, 8 Apr 2001 11:51:38 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22577 for ; Sun, 8 Apr 2001 11:51:37 -0700 (PDT) Received: from mwyoung (sdn-ar-006florlaP094.dialsprint.net [158.252.72.182]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA29702 for ; Sun, 8 Apr 2001 11:51:18 -0700 (PDT) Message-ID: <011e01c0c05c$cb9c0d60$b648fc9e@transarc.ibm.com> From: "Michael Young" To: References: Subject: Re: purpose of the checksum? Date: Sat, 7 Apr 2001 19:31:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01C0BF99.53605EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0113_01C0BF99.53605EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- >As this is so, what is the purpose of the checksum? >=20 - From context, I gather you're talking about the ASCII armor checksum, not the encrypted checksums inside key or session key packets? The purpose is simply to reduce transmission accidents, which is the point to armoring in general. As you observed, the (dearmored) PGP packets are complete without it, and can be properly interpreted. An OpenPGP implementation certainly *could* insist on it being complete. Note that the armor checksum is done on the entire *encoded* message, not the plaintext, so it does not deter malicious alterations. The OpenPGP draft now includes a modification detection code to address malicious alteration or truncation. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOs+jOmNDnIII+QUHAQGRiQf+MojoFO08xGr57VDGLXXCxHELqOMzfhGy PTmXfIT4JjVdd5q7ifEihXzcpzP+YNhyraDTqCvyBKH0jUZU9Tqjnb09IoMaOXd6 YOTM5HKXW6+C+MURcbQb3v5jzolnEKI4kc5whk9Zq331oFNSDbQlGcTRrD/LS4p0 NbqkxEVEsyAeDczUMv4BZuj5GjaIRX5BRY1zm3ycjoDeQgbdVOHAvfZPxx8XxDqZ VrNRaBjISjTfDMvX11O3VO7W84ozdZYA6X0Je1aVdBhHDDL3Oa0XhSZESgKJWgA1 V7mGncQzwqJ29unLZTSvrpsE1+6r68Jjb9SVb9YCwlr71Iy0Y4Fr0Q=3D=3D =3DRO9X -----END PGP SIGNATURE----- ------=_NextPart_000_0113_01C0BF99.53605EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE-----
 
>As this is so, what is the purpose of the checksum?
> =
- From=20 context, I gather you're talking about the ASCII armor checksum,
not = the=20 encrypted checksums inside key or session key packets?
 
The purpose is simply to reduce transmission accidents, which is=20 the
point to armoring in general.  As you observed, the = (dearmored)=20 PGP
packets are complete without it, and can be properly = interpreted. =20 An
OpenPGP implementation certainly *could* insist on it being=20 complete.
 
Note that the armor checksum is done on the entire *encoded*=20 message,
not the plaintext, so it does not deter malicious = alterations. =20 The
OpenPGP draft now includes a modification detection code to=20 address
malicious alteration or truncation.
 
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy = 6.5.3
 
iQEVAwUBOs+jOmNDnIII+QUHAQGRiQf+MojoFO08xGr57VDGLXXCxHELqOMzfhGy
= PTmXfIT4JjVdd5q7ifEihXzcpzP+YNhyraDTqCvyBKH0jUZU9Tqjnb09IoMaOXd6
YOTM5= HKXW6+C+MURcbQb3v5jzolnEKI4kc5whk9Zq331oFNSDbQlGcTRrD/LS4p0
NbqkxEVEsy= AeDczUMv4BZuj5GjaIRX5BRY1zm3ycjoDeQgbdVOHAvfZPxx8XxDqZ
VrNRaBjISjTfDMv= X11O3VO7W84ozdZYA6X0Je1aVdBhHDDL3Oa0XhSZESgKJWgA1
V7mGncQzwqJ29unLZTSv= rpsE1+6r68Jjb9SVb9YCwlr71Iy0Y4Fr0Q=3D=3D
=3DRO9X
-----END=20 PGP SIGNATURE-----
------=_NextPart_000_0113_01C0BF99.53605EA0-- Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA26662 for ietf-openpgp-bks; Sun, 8 Apr 2001 05:05:08 -0700 (PDT) Received: from smtp4.hushmail.com (smtp4.hushmail.com [64.40.111.32]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA26655 for ; Sun, 8 Apr 2001 05:05:06 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp4.hushmail.com (Postfix) with ESMTP id 9DF112F2D; Sun, 8 Apr 2001 05:03:53 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id FAA16182; Sun, 8 Apr 2001 05:03:51 -0700 Message-Id: <200104081203.FAA16182@user4.hushmail.com> Date: Sun, 8 Apr 2001 13:03:31 +0000 (GMT+01:00) Cc: To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO" Subject: Plug-ins and PGP/MIME (was RE: Java Implementation) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO Content-type: text/plain That makes sense, since we were testing against the Outlook plug-in. It seems that this issue is a real barrier against adoption of PGP/MIME, though. Outlook is so far and away the dominant email client that it doesn't seem likely that PGP/MIME will get far if it can't be used in a plug-in. (I don't really see Microsoft building in an OpenPGP implementation anytime in the near future.) Brian Smith At Sat, 7 Apr 2001 10:46:05 -0400, "Damon Gallaty" wrote: > >Actually, we do implement PGP/MIME where we can. Naturally, it requires >access to the mail headers, and not all mail apps give plug-ins that >kind of >control. Unfortunately, out of all the plug-ins we currently have, only >the >Eudora plug-in is able to both create and interpret PGP/MIME. > >- Damon Gallaty > >> -----Original Message----- >> From: owner-ietf-openpgp@mail.imc.org >> [mailto:owner-ietf-openpgp@mail.imc.org]On Behalf Of sbs@hushmail.com >> Sent: Saturday, April 07, 2001 6:13 AM >> To: ietf-openpgp@imc.org >> Subject: Re: Java Implementation >> >> >> Since the toolkit is intended for use with the same key servers that >are >> used for HushMail.com, our standard licensing is on a per-key-registered >> basis. I'm sure we could work something out for use outside that >context. >> >> It is fully compliant with 2440, but some of the "SHOULD" >> algorithms aren't >> packaged with it at this point. Our approach to MIME is >> initially not standard, >> because, among other things, we wanted interoperability with the >Network >> Associates PGP users, and Network Associates PGP doesn't seem to >> implement >> PGP/MIME, even though there's a checkbox for it?!? >> >> Get in touch with me off the list, let me know what your specific >> requirements >> are, and we'll see what we can work out. >> >> Thanks, >> Brian >> >> At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: >> >> > >> > Under what kind of licensing will it be released ? >> > Will this SDK comply fully with OpenPGP ? >> > >> > Thanks in advance, >> > Jacques >> > >> >----- Original Message ----- >> >From: >> >To: ; >> >Sent: Sunday, April 01, 2001 9:30 AM >> >Subject: Java Implementation >> > >> > >> >> Jacques Exelrud was recently inquiring about the availability of >a >> >complete >> >> Java implementation of OpenPGP. We have one in our SDK, which >will >> >be >> >powering >> >> the soon-to-be-released HushMail Version 2. It's intended for >use >> >with >> >> our keyserver network and OpenPGP CA. The source will be published >> >with >> >> the release of HushMail V2. If interested, let me know. >> >> >> >> Regards, >> >> Brian Smith >> >> >> >> >> >> * * * * * * * * * * * * * * * * * * * * * >> >> S. Brian Smith >> >> Director of Research and Development >> >> Hush Communications >> >> Email: sbs@hushmail.com >> >> Mobile: +353 86 809 2163 >> >> Tel: +353 1 241 0325 >> >> Fax: +353 1 241 0370 >> >> Website: www.hush.com >> >> >> >> Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO-- Received: by above.proper.com (8.9.3/8.9.3) id HAA18075 for ietf-openpgp-bks; Sat, 7 Apr 2001 07:46:17 -0700 (PDT) Received: from mail.citicom.com (citicom.com [64.58.200.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18070 for ; Sat, 7 Apr 2001 07:46:15 -0700 (PDT) Received: from dgal-ws1 (dgal-ws1.cust.citicom.com [64.58.197.42]) by mail.citicom.com (MX-CITI/4b) with SMTP id f37EkEP13555; Sat, 7 Apr 2001 10:46:14 -0400 Reply-To: From: "Damon Gallaty" To: Cc: Subject: RE: Java Implementation Date: Sat, 7 Apr 2001 10:46:05 -0400 Message-ID: <000401c0bf71$7933ee30$2ac53a40@dgal-ws1.cust.citicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200104070919.CAA16613@user4.hushmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Actually, we do implement PGP/MIME where we can. Naturally, it requires access to the mail headers, and not all mail apps give plug-ins that kind of control. Unfortunately, out of all the plug-ins we currently have, only the Eudora plug-in is able to both create and interpret PGP/MIME. - Damon Gallaty > -----Original Message----- > From: owner-ietf-openpgp@mail.imc.org > [mailto:owner-ietf-openpgp@mail.imc.org]On Behalf Of sbs@hushmail.com > Sent: Saturday, April 07, 2001 6:13 AM > To: ietf-openpgp@imc.org > Subject: Re: Java Implementation > > > Since the toolkit is intended for use with the same key servers that are > used for HushMail.com, our standard licensing is on a per-key-registered > basis. I'm sure we could work something out for use outside that context. > > It is fully compliant with 2440, but some of the "SHOULD" > algorithms aren't > packaged with it at this point. Our approach to MIME is > initially not standard, > because, among other things, we wanted interoperability with the Network > Associates PGP users, and Network Associates PGP doesn't seem to > implement > PGP/MIME, even though there's a checkbox for it?!? > > Get in touch with me off the list, let me know what your specific > requirements > are, and we'll see what we can work out. > > Thanks, > Brian > > At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: > > > > > Under what kind of licensing will it be released ? > > Will this SDK comply fully with OpenPGP ? > > > > Thanks in advance, > > Jacques > > > >----- Original Message ----- > >From: > >To: ; > >Sent: Sunday, April 01, 2001 9:30 AM > >Subject: Java Implementation > > > > > >> Jacques Exelrud was recently inquiring about the availability of a > >complete > >> Java implementation of OpenPGP. We have one in our SDK, which will > >be > >powering > >> the soon-to-be-released HushMail Version 2. It's intended for use > >with > >> our keyserver network and OpenPGP CA. The source will be published > >with > >> the release of HushMail V2. If interested, let me know. > >> > >> Regards, > >> Brian Smith > >> > >> > >> * * * * * * * * * * * * * * * * * * * * * > >> S. Brian Smith > >> Director of Research and Development > >> Hush Communications > >> Email: sbs@hushmail.com > >> Mobile: +353 86 809 2163 > >> Tel: +353 1 241 0325 > >> Fax: +353 1 241 0370 > >> Website: www.hush.com > >> > >> > >> > >> > >> Free, encrypted, secure Web-based email at www.hushmail.com > > > > > > > >Free, encrypted, secure Web-based email at www.hushmail.com > > > Free, encrypted, secure Web-based email at www.hushmail.com Received: by above.proper.com (8.9.3/8.9.3) id FAA06584 for ietf-openpgp-bks; Sat, 7 Apr 2001 05:00:35 -0700 (PDT) Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA06580 for ; Sat, 7 Apr 2001 05:00:33 -0700 (PDT) Received: from alsutton.demon.co.uk ([194.222.50.252] helo=cola) by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1) id 14lrOL-000Ah5-0B for ietf-openpgp@imc.org; Sat, 7 Apr 2001 12:00:33 +0000 Message-ID: <004901c0bf5a$4be16b40$fc32dec2@internal.jacobsrimell.com> From: "Al Sutton" To: Subject: Key sharing Date: Sat, 7 Apr 2001 13:00:09 +0100 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Would this be the right group to look at OpenPGP key servers and the protocols used to obtain keys from them, and the protocols they use to share information between them. The reason I ask is that there seem to be some de facto standards with little or no documentation. Regards, Al. Received: by above.proper.com (8.9.3/8.9.3) id CAA21689 for ietf-openpgp-bks; Sat, 7 Apr 2001 02:20:36 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [64.40.111.31]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA21685 for ; Sat, 7 Apr 2001 02:20:35 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp1.hushmail.com (Postfix) with ESMTP id 88B2013756 for ; Sat, 7 Apr 2001 02:19:43 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id CAA16613; Sat, 7 Apr 2001 02:19:43 -0700 Message-Id: <200104070919.CAA16613@user4.hushmail.com> Date: Sat, 7 Apr 2001 10:12:37 +0000 (GMT+01:00) To: ietf-openpgp@imc.org Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK" Subject: Re: Java Implementation Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK Content-type: text/plain Since the toolkit is intended for use with the same key servers that are used for HushMail.com, our standard licensing is on a per-key-registered basis. I'm sure we could work something out for use outside that context. It is fully compliant with 2440, but some of the "SHOULD" algorithms aren't packaged with it at this point. Our approach to MIME is initially not standard, because, among other things, we wanted interoperability with the Network Associates PGP users, and Network Associates PGP doesn't seem to implement PGP/MIME, even though there's a checkbox for it?!? Get in touch with me off the list, let me know what your specific requirements are, and we'll see what we can work out. Thanks, Brian At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), sbs@hushmail.com wrote: > > Under what kind of licensing will it be released ? > Will this SDK comply fully with OpenPGP ? > > Thanks in advance, > Jacques > >----- Original Message ----- >From: >To: ; >Sent: Sunday, April 01, 2001 9:30 AM >Subject: Java Implementation > > >> Jacques Exelrud was recently inquiring about the availability of a >complete >> Java implementation of OpenPGP. We have one in our SDK, which will >be >powering >> the soon-to-be-released HushMail Version 2. It's intended for use >with >> our keyserver network and OpenPGP CA. The source will be published >with >> the release of HushMail V2. If interested, let me know. >> >> Regards, >> Brian Smith >> >> >> * * * * * * * * * * * * * * * * * * * * * >> S. Brian Smith >> Director of Research and Development >> Hush Communications >> Email: sbs@hushmail.com >> Mobile: +353 86 809 2163 >> Tel: +353 1 241 0325 >> Fax: +353 1 241 0370 >> Website: www.hush.com >> >> >> >> >> Free, encrypted, secure Web-based email at www.hushmail.com > > > >Free, encrypted, secure Web-based email at www.hushmail.com > Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK-- Received: by above.proper.com (8.9.3/8.9.3) id IAA04375 for ietf-openpgp-bks; Fri, 6 Apr 2001 08:25:02 -0700 (PDT) Received: from NABOO.glueckkanja.com (mail.glueckkanja.de [195.4.63.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04368 for ; Fri, 6 Apr 2001 08:24:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Elliptic Curves Date: Fri, 6 Apr 2001 17:24:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Elliptic Curves Thread-Index: AcC+raypFlHA//snRyCEca9/qviCWg== From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA04370 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Now that we are done with mime, is anybody interessted in adding ECC/ECDSA to the open-pgp standard? I think it would be time to do so and it won't be hard to specify (for those who had implemented elliptic curves in some context it is very clear what algorithm-specific values are needed). -- Dominikus Scherkl Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA29374 for ietf-openpgp-bks; Thu, 5 Apr 2001 09:21:47 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA29370 for ; Thu, 5 Apr 2001 09:21:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA03840 for ietf-openpgp@imc.org; Thu, 5 Apr 2001 09:16:35 -0700 Date: Thu, 5 Apr 2001 09:16:35 -0700 Message-Id: <200104051616.JAA03840@finney.org> To: ietf-openpgp@imc.org Subject: RE: Interesting attack to DSA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The newsgroup posting by Vlastimil Klima, one of the Czech researchers who identified the problems associated with potential modifications to the secret key file, has now appeared on my local news server. (He also sent me a copy personally.) It also includes the text of the attack posted to sci.crypt which could work even with mathematical checks of the consistency of the DSS key. This attack is far less powerful than the original Czech attack, which was itself of highly limited impact IMO. But here are the messages, for future reference: > From: "Vlastimil Klima" > Newsgroups: sci.crypt > References: <99jdj9$1n9$1@news.ox.ac.uk> <3abe252a$1@news.cvut.cz> <20010402192001.22654.qmail@nym.alias.net> > Subject: Re: Is this a solution to the PGP flaw > Date: Tue, 3 Apr 2001 12:00:10 +0200 > Lines: 68 > Organization: Decros Ltd., ICZ Group, Prague, Czech Republic > X-Priority: 3 > X-MSMail-Priority: Normal > X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > NNTP-Posting-Host: brana.i.cz > X-Original-NNTP-Posting-Host: brana.i.cz > Message-ID: <3ac99fb1$1@news.cvut.cz> > X-Trace: 3 Apr 2001 11:02:25 +0100, brana.i.cz > Path: news.cvut.cz!brana.i.cz > Xref: news.cvut.cz sci.crypt:151235 > > Great observation! > > In the article "Breaking Public Key Cryptosystems on Tamper Resistance > Devices in the Presence of Transient Faults" by Bao, Deng, Han, > Jeng,Narasimhalu and Ngair (Security Protocols, 1997, Springer-Verlag, LNCS > vol. 1361, pp.115-124) is a very similar idea. > > Your attack needs more iterations, but it is very interesting. > > In our paper ( http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf), section > 7, we proposed "temporary tests (say for a patch) " and "future > countermeasures". On the temporary tests we said > "....We stress out that the aforesaid test is not to be a substitute for the > missing check of integrity of the file with the private key but it is to > serve as a temporary measure which prevents the herein specified attack..." > and at section 7.2 we said: > "...Let us also note that whereas such type of tests as we already mentioned > is trusted a lot, for instance in RSA, in case of DSA we have to be careful. > Unlike RSA there is only one value here (private key x), unknown by the > attacker. Other parameters are known by the attacker and it may change them > at its own discretion. This is a reason, why this test is considered only a > temporary solution, which must be replaced as soon as possible with another > type of check of integrity of the discussed records, as hereafter specified. > " > > Our recommendations are expressed in section 7.4 of the paper. > > Vlastimil Klima and Tomas Rosa > > "lcs Mixmaster Remailer" wrote in message > news:20010402192001.22654.qmail@nym.alias.net... > > Here is another variant on the attack which will still work even if > > the recommended mathematical checks are done. However it leaks only a > > small amount of information about the secret key. > > > > We have g^q = 1 mod p; g^x = y mod p; q | (p-1), etc. Now suppose an > > attacker wants to learn if x is even or odd. > > > > He can toggle the low order bit of x by xoring into the ciphertext. > > As is well known, in CFB mode, such an xor goes through to the > > plaintext at the cost of disturbing the following block of plaintext. > > (CBC has similar properties, but with the roles of the two plaintext > > blocks reversed.) > > > > Toggling the low order bit of x will either increment it or decrement > > it, depending on whether x is even or odd. This will cause y to be > > either multiplied by g, or divided by g. > > > > The attacker makes a guess about x being even or odd, toggles the bit > > and adjusts y accordingly. (He also has to adjust the checksum, which > > he can do with 50% success.) The resulting key is perfectly > > consistent mathematically, if his guess was correct. > > > > Then he sees if the user is able to use the key, or if he gets an > > error. If there is no error, the attacker knows he guessed right > > about the low bit of x. > > > > In some circumstances it may be possible for the attack to be mounted > > repeatedly and gradually learn more bits. For example, if the attack > > is possible because the key is stored on a network file system, as Dr. > > Klima proposes, the user may re-run PGP repeatedly when he gets an > > error, thinking he is typing his passphrase wrong. In some > > configurations this will re-fetch the secret key ring each time, and > > the attacker can modify a different bit of x each time. He can learn > > almost 128 bits of x in the best case. With this advantage, brute > > forcing the remaining bits of x may be possible. Received: by above.proper.com (8.9.3/8.9.3) id DAA02881 for ietf-openpgp-bks; Thu, 5 Apr 2001 03:40:56 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02869 for ; Thu, 5 Apr 2001 03:40:54 -0700 (PDT) Message-Id: <200104051040.DAA02869@above.proper.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:19 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:59:50 +0200 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm Received: by above.proper.com (8.9.3/8.9.3) id NAA26648 for ietf-openpgp-bks; Wed, 4 Apr 2001 13:07:30 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA26642 for ; Wed, 4 Apr 2001 13:07:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA17064; Wed, 4 Apr 2001 13:04:05 -0700 Date: Wed, 4 Apr 2001 13:04:05 -0700 Message-Id: <200104042004.NAA17064@finney.org> To: ietf-openpgp@imc.org, vedaal@hotmail.com Subject: Re: purpose of the checksum? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: vedaal nistar writes: > As this is so, what is the purpose of the checksum? It's to detect line noise from your 2400 baud modem. Hal Received: by above.proper.com (8.9.3/8.9.3) id MAA25414 for ietf-openpgp-bks; Wed, 4 Apr 2001 12:52:25 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25407 for ; Wed, 4 Apr 2001 12:52:23 -0700 (PDT) Received: from [199.106.106.131] (vpnap-g1-012043.qualcomm.com [10.13.12.43]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f34JqIV21466 for ; Wed, 4 Apr 2001 12:52:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1-0404010834] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 4 Apr 2001 12:51:54 -0700 To: ietf-openpgp@imc.org From: John W Noerenberg II Subject: WG Last Call - draft-ietf-openpgp-mime - Done! Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:55 PM -0600 3/20/01, John W Noerenberg II wrote: >This the Last Call for WG comments on draft-ietf-openpgp-mime. WG LAST CALL IS NOW OVER. Thomas Roessler has a -06 draft ready, which I will submit to the ADs. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- Peace of mind isn't at all superficial, really. It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA23882 for ietf-openpgp-bks; Wed, 4 Apr 2001 12:33:35 -0700 (PDT) Received: from hotmail.com (oe66.law3.hotmail.com [209.185.240.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23876 for ; Wed, 4 Apr 2001 12:33:34 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Apr 2001 12:33:07 -0700 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: purpose of the checksum? Date: Wed, 4 Apr 2001 15:30:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BF_01C0BD1C.3C0EA2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 04 Apr 2001 19:33:07.0341 (UTC) FILETIME=[132863D0:01C0BD3E] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- The checksum of a pgp message block, can be deleted together with the footer, from any pgp signed/encrypted/signed & encrypted message without affecting decryptability or verifiability. {as long as the pgp footer is deleted together with it. if only the checksum is deleted without the footer, there will be a message of = } As this is so, what is the purpose of the checksum? vedaal nistar - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/01 -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt: build 4 < http://www.ipgpp.com/> Comment: { Acts of Kindness better the World, and protect the Soul } Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBOsty4moFoLeFMG0lAQHpiAf+OqLfs7jdQ3/LyE8JxqKSLD7RBlPOSr2G CMpNtYIuLHzumbOuai/mzuSIlahJMhuRjgelqSkBXNb1s+GqkfJZ3cNdPkkrr9VC gFixgE1zI0ODMCcTGt4k1wIqdn2MiBrNH12pUXAebzqXQ5TgtRKJ09+hV23VLNyd K07vbZw4qUtj8RGdYwRXocr1CiCmqnaqtLLKKryqSfAxX4+Og3D5pPC08XNWm4vy /dIKspyjpe2dcz//19I1nUn+j8AwZ1nO0j4TVtMXhpFfuAywZujTxAch8hrK1tXs uaskaKe1C8pTnTBKL1ISavQKddXdADQs686lteyYKpDwQzVwGwRLZA=3D=3D =3DAsoF -----END PGP SIGNATURE----- ------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED = MESSAGE-----
 
The checksum of a pgp message block, = can be deleted=20 together with the
footer, from any pgp signed/encrypted/signed &=20 encrypted message without
affecting decryptability or = verifiability.
{as=20 long as the pgp footer is deleted together with it.  if only=20 the
checksum is deleted without the footer, there will be a message = of=20 <ascii
armor incomplete>}
 
As this is so, what is the purpose of = the=20 checksum?
 

vedaal nistar
 

- ---
Outgoing mail is certified Virus Free.
Checked by = AVG=20 anti-virus system (http://www.grisoft.com).
Version: = 6.0.237 /=20 Virus Database: 115 - Release Date: 3/7/01
 
-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt: build = 4  =20 < http://www.ipgpp.com/>
Comment: = {=20 Acts of Kindness better the World, and protect the Soul }
Comment: = KeyID:=20 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  = D9AE 02FD=20 A711 97BA
 
iQEVAwUBOsty4moFoLeFMG0lAQHpiAf+OqLfs7jdQ3/LyE8JxqKSLD7RBlPOSr2G
= CMpNtYIuLHzumbOuai/mzuSIlahJMhuRjgelqSkBXNb1s+GqkfJZ3cNdPkkrr9VC
gFixg= E1zI0ODMCcTGt4k1wIqdn2MiBrNH12pUXAebzqXQ5TgtRKJ09+hV23VLNyd
K07vbZw4qU= tj8RGdYwRXocr1CiCmqnaqtLLKKryqSfAxX4+Og3D5pPC08XNWm4vy
/dIKspyjpe2dcz/= /19I1nUn+j8AwZ1nO0j4TVtMXhpFfuAywZujTxAch8hrK1tXs
uaskaKe1C8pTnTBKL1IS= avQKddXdADQs686lteyYKpDwQzVwGwRLZA=3D=3D
=3DAsoF
-----END=20 PGP SIGNATURE-----
------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0-- Received: by above.proper.com (8.9.3/8.9.3) id LAA18184 for ietf-openpgp-bks; Wed, 4 Apr 2001 11:19:25 -0700 (PDT) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA18179 for ; Wed, 4 Apr 2001 11:19:23 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA16569 for ietf-openpgp@imc.org; Wed, 4 Apr 2001 11:16:03 -0700 Date: Wed, 4 Apr 2001 11:16:03 -0700 Message-Id: <200104041816.LAA16569@finney.org> To: ietf-openpgp@imc.org Subject: RE: Interesting attack to DSA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The answer referred to below has not yet appeared on my news reader. Can someone who has seen it forward it to this list? On first analysis, the attack in the thread forwarded by Lutz is not really worth worrying about. You have to assume a combination of an incredibly clueless user and an extremely powerful attacker who can control the user's file accesses to a high degree. Hal > From: Klima Vlastimil > To: "'ietf-openpgp@imc.org'" > > You can find our answer in the thread sci.crypt. > > Tomas Rosa and Vlastimil Klima > > Best regards > Dr.Vlastimil Klima, Cryptologist > DECROS Ltd. - ICZ a.s., V Olsinach 75, 100 97 Prague 10, Czech Republic > v.klima@decros.cz, http://www.decros.cz, http://www.i.cz > > -----Original Message----- > From: lutz@iks-jena.de [mailto:lutz@iks-jena.de] > Sent: Tuesday, April 03, 2001 9:14 AM > To: ietf-openpgp@imc.org > Subject: Interesting attack to DSA > > > The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a > serious attack to DSA keys which seems to be indefeatable by the currently > recommented secret key data. Received: by above.proper.com (8.9.3/8.9.3) id DAA14975 for ietf-openpgp-bks; Tue, 3 Apr 2001 03:12:29 -0700 (PDT) Received: from ns.decros.cz (ns.decros.cz [193.85.26.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14969 for ; Tue, 3 Apr 2001 03:12:21 -0700 (PDT) Received: from dcrfs.decros.cz (exchange [10.1.1.3]) by ns.decros.cz (8.11.2/8.11.2) with ESMTP id f33AC7J26810; Tue, 3 Apr 2001 12:12:07 +0200 (CEST) Received: by dcrfs.decros.cz with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 12:12:06 +0200 Message-ID: <9E85DC6CA1D5D311BB460006293960FE089558@dcrfs.decros.cz> From: Klima Vlastimil To: "'ietf-openpgp@imc.org'" Cc: "'mailto:lutz@iks-jena.de'" Subject: RE: Interesting attack to DSA Date: Tue, 3 Apr 2001 12:12:04 +0200 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You can find our answer in the thread sci.crypt. Tomas Rosa and Vlastimil Klima Best regards Dr.Vlastimil Klima, Cryptologist DECROS Ltd. - ICZ a.s., V Olsinach 75, 100 97 Prague 10, Czech Republic v.klima@decros.cz, http://www.decros.cz, http://www.i.cz -----Original Message----- From: lutz@iks-jena.de [mailto:lutz@iks-jena.de] Sent: Tuesday, April 03, 2001 9:14 AM To: ietf-openpgp@imc.org Subject: Interesting attack to DSA The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a serious attack to DSA keys which seems to be indefeatable by the currently recommented secret key data. Received: by above.proper.com (8.9.3/8.9.3) id AAA24626 for ietf-openpgp-bks; Tue, 3 Apr 2001 00:14:04 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA24618 for ; Tue, 3 Apr 2001 00:14:02 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f337Dns27520 for ietf-openpgp@imc.org; Tue, 3 Apr 2001 09:13:49 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Interesting attack to DSA Date: 3 Apr 2001 07:13:49 GMT Organization: IKS GmbH Jena Lines: 3 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The thread news:20010402224016.3984.qmail@nym.alias.net and above contains a serious attack to DSA keys which seems to be indefeatable by the currently recommented secret key data. Received: by above.proper.com (8.9.3/8.9.3) id LAA00572 for ietf-openpgp-bks; Sun, 1 Apr 2001 11:08:56 -0700 (PDT) Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00568 for ; Sun, 1 Apr 2001 11:08:55 -0700 (PDT) Received: from mwyoung ([24.48.51.230]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GB4L1S00.NVA for ; Sun, 1 Apr 2001 14:08:16 -0400 Message-ID: <00c501c0bad6$9cc99c40$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <003501c0ba04$55313e60$0140a8c0@pterodactilo> Subject: Re: Date fields Date: Sun, 1 Apr 2001 14:07:26 -0400 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- > For split-keys (hope that's a OpenPGP feature and not just a PGP > feature, have not checked the rfc) it may happen that parts of this It's an NAI feature, not part of the OpenPGP spec. The format of share files does not resemble a "packet" (but the encrypted data deep inside does). While I'd like OpenPGP to include a "split key" packet, I certainly wouldn't suggest the NAI format. [Note that the split key is really a split symmetric key, not a split of the whole secret key.] I don't think the split material has any timestamp itself. > For non split-keys the problem may not be as serious. What may > happen is that the user may receive an encrypted message with the There should never be a problem *decrypting* using an expired key. > security/legal problem. At most the lack of certain on the date the > message was generated because there is a one day lag the the key have Moreover, timestamps are only as trustworthy as the party generating them. You can always forge an old timestamp by setting your clock (or adjusting your software :-). I guess I don't understand the problem you're considering. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOsduNmNDnIII+QUHAQGutAf9FJy0Rbyvbo3GwoSvBOWGVvsxNGESmkuB ieXDF/SaKCst7oHs5dYgB0xNaTLmGWRe6M0zSTvGL+5NTK+Kd1PV6GVbaPAHP2Nb uf4yhjpB7VuVp8XFBvax8tKjk0yT4gwg00OZsYkKFBuiPxVfV2PKJoRK0eSD7zgF pZEy1f8U0ZOPurpRm8VDkEx5r/DKqyMmugXId8Dz2rQA23BFD733xxIYo2j/Z/vr gW2c590nBebQrg50cOoib4APTF0sTBjkm7cs8P2cYMPrDwkgmuWNxkIA/nlv4vZO d6SkAsZ0hto27wCGyhYynG8840oWYW372mkGVAsoOEU02v/qNFuAHg== =+bmT -----END PGP SIGNATURE----- Received: by above.proper.com (8.9.3/8.9.3) id KAA29868 for ietf-openpgp-bks; Sun, 1 Apr 2001 10:22:33 -0700 (PDT) Received: from webmail.vento.com.br ([200.214.174.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29864 for ; Sun, 1 Apr 2001 10:22:31 -0700 (PDT) Received: from pterodactilo (200.251.188.19) by webmail.vento.com.br (5.1.056) id 3ABFF8C70006392B for ietf-openpgp@imc.org; Sun, 1 Apr 2001 14:22:32 -0300 Message-ID: <015701c0bacf$d2e3b970$0140a8c0@pterodactilo> From: "Jacques Exelrud" To: References: <200104011134.EAA03480@user4.hushmail.com> Subject: Re: Java Implementation Date: Sun, 1 Apr 2001 14:18:26 -0300 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Under what kind of licensing will it be released ? Will this SDK comply fully with OpenPGP ? Thanks in advance, Jacques ----- Original Message ----- From: To: ; Sent: Sunday, April 01, 2001 9:30 AM Subject: Java Implementation > Jacques Exelrud was recently inquiring about the availability of a complete > Java implementation of OpenPGP. We have one in our SDK, which will be powering > the soon-to-be-released HushMail Version 2. It's intended for use with > our keyserver network and OpenPGP CA. The source will be published with > the release of HushMail V2. If interested, let me know. > > Regards, > Brian Smith > > > * * * * * * * * * * * * * * * * * * * * * > S. Brian Smith > Director of Research and Development > Hush Communications > Email: sbs@hushmail.com > Mobile: +353 86 809 2163 > Tel: +353 1 241 0325 > Fax: +353 1 241 0370 > Website: www.hush.com > > > > > Free, encrypted, secure Web-based email at www.hushmail.com Received: by above.proper.com (8.9.3/8.9.3) id EAA17061 for ietf-openpgp-bks; Sun, 1 Apr 2001 04:35:24 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [64.40.111.31]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA17055 for ; Sun, 1 Apr 2001 04:35:19 -0700 (PDT) From: sbs@hushmail.com Received: from user4.hushmail.com (user4.hushmail.com [64.40.111.44]) by smtp1.hushmail.com (Postfix) with ESMTP id 88DD31372E; Sun, 1 Apr 2001 04:34:24 -0700 (PDT) Received: (from root@localhost) by user4.hushmail.com (8.9.3/8.9.3) id EAA03480; Sun, 1 Apr 2001 04:34:24 -0700 Message-Id: <200104011134.EAA03480@user4.hushmail.com> Date: Sun, 1 Apr 2001 12:30:04 +0000 (GMT+01:00) To: ietf-openpgp@imc.org, exelrud@usa.net Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD" Subject: Java Implementation Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD Content-type: text/plain Jacques Exelrud was recently inquiring about the availability of a complete Java implementation of OpenPGP. We have one in our SDK, which will be powering the soon-to-be-released HushMail Version 2. It's intended for use with our keyserver network and OpenPGP CA. The source will be published with the release of HushMail V2. If interested, let me know. Regards, Brian Smith * * * * * * * * * * * * * * * * * * * * * S. Brian Smith Director of Research and Development Hush Communications Email: sbs@hushmail.com Mobile: +353 86 809 2163 Tel: +353 1 241 0325 Fax: +353 1 241 0370 Website: www.hush.com Free, encrypted, secure Web-based email at www.hushmail.com --Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD--