From owner-ietf-openpgp@mail.imc.org Thu Nov 03 11:51:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXiIz-0006KY-3d for openpgp-archive@megatron.ietf.org; Thu, 03 Nov 2005 11:51:15 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12438 for ; Thu, 3 Nov 2005 11:50:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GMCSV095590; Thu, 3 Nov 2005 08:22:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3GMC1N095589; Thu, 3 Nov 2005 08:22:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GM9dd095571 for ; Thu, 3 Nov 2005 08:22:09 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110316214901300g0hkce>; Thu, 3 Nov 2005 16:21:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3GLmX6021881; Thu, 3 Nov 2005 11:21:48 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3GLljG001489; Thu, 3 Nov 2005 11:21:47 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3GLiLx001488; Thu, 3 Nov 2005 11:21:44 -0500 Date: Thu, 3 Nov 2005 11:21:44 -0500 From: David Shaw To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051103162144.GC1303@jabberwocky.com> Mail-Followup-To: Simon Josefsson , ietf-openpgp@imc.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote: > > Hi everyone! FYI: > > I submitted an updated version of this document a few weeks ago. The > changes since -01 are small: A new "preference" field has been added, > to signal whether the sender wish that e-mail should be signed, > encrypted or both. I have some concerns with this preference field. There is already a way to specify this preference on the key itself ("preferred-email-encoding@pgp.com"). Once a user finds the key, they have an authoritative and tamperproof statement about email preference. The OpenPGP header is not tamperproof, and having the preference in there raises the question what to do if the header preference doesn't match the preference on the key. I see the OpenPGP header as a useful key finding aid. Once the key is found, though, the header has served its purpose. David From owner-ietf-openpgp@mail.imc.org Thu Nov 03 15:03:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlIs-00035L-EY for openpgp-archive@megatron.ietf.org; Thu, 03 Nov 2005 15:03:18 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23452 for ; Thu, 3 Nov 2005 15:02:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JVA9B018600; Thu, 3 Nov 2005 11:31:10 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JVAmU018599; Thu, 3 Nov 2005 11:31:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JV4vA018583 for ; Thu, 3 Nov 2005 11:31:04 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110319305401300g34ase>; Thu, 3 Nov 2005 19:30:56 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3JUsX6022478; Thu, 3 Nov 2005 14:30:54 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3JUqd5001689; Thu, 3 Nov 2005 14:30:52 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3JUpF1001688; Thu, 3 Nov 2005 14:30:51 -0500 Date: Thu, 3 Nov 2005 14:30:51 -0500 From: David Shaw To: Anand Kumria Cc: atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Message-ID: <20051103193051.GA1671@jabberwocky.com> Mail-Followup-To: Anand Kumria , atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org References: <20051031072532.GC29693@progsoc.uts.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051031072532.GC29693@progsoc.uts.edu.au> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 31, 2005 at 06:25:32PM +1100, Anand Kumria wrote: > Hi there, > > The openpgp-mailnews-header defines a mechanism for senders to notify > recipients of both their preferences (w.r.t OpenPGP keys) and the keying > material to be used (e.g. keyid). > > dnsext-rfc2538bis defines a mechanism where keying material is stored > within the DNS (e.g. OpenPGP). The overlap here is that users may wish > to store their key in the DNS (via dnsext-rfc2538bis) and refer to them > using openpgp-mailnews-header. > > Since openpgp-mailnews-header specifies using a URI to refer to the > location, it would seem -- to me at least -- that there needs to be some > kind of URI specification to allow you to refer to DNS resource records. > > Is there one already, or work underway to produce a DNS URI spec.? There is this, by the same author as rfc2538bis: http://josefsson.org/dns-url/draft-josefsson-dns-url-13.txt David From owner-ietf-openpgp@mail.imc.org Thu Nov 03 15:22:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlbu-0000OU-Bc for openpgp-archive@megatron.ietf.org; Thu, 03 Nov 2005 15:22:58 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24474 for ; Thu, 3 Nov 2005 15:22:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmdYY020109; Thu, 3 Nov 2005 11:48:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JmdEr020108; Thu, 3 Nov 2005 11:48:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmbV8020101 for ; Thu, 3 Nov 2005 11:48:38 -0800 (PST) (envelope-from brian@braverock.com) Received: from [10.23.3.106] (terminus [66.92.135.15]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id jA3JmR14023971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Nov 2005 13:48:28 -0600 From: "Brian G. Peterson" Organization: Braverock Ventures To: Simon Josefsson , ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Date: Thu, 3 Nov 2005 13:48:25 -0600 User-Agent: KMail/1.8.3 References: <20051103162144.GC1303@jabberwocky.com> In-Reply-To: <20051103162144.GC1303@jabberwocky.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511031348.26342.brian@braverock.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 03 November 2005 10:21 am, David Shaw wrote: > I have some concerns with this preference field. There is already a > way to specify this preference on the key itself > ("preferred-email-encoding@pgp.com"). I'd like to see the preferred-email-encoding issue covered in an RFC or draft. I think that the issues around user preference and interoperability really need to be in an official RFC. Hopefully we can take this up as 2440bis winds up and moves on into the next stages. Regards, - Brian From owner-ietf-openpgp@mail.imc.org Fri Nov 04 10:16:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3It-0007ME-M7 for openpgp-archive@megatron.ietf.org; Fri, 04 Nov 2005 10:16:32 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25158 for ; Fri, 4 Nov 2005 10:16:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpjcP064017; Fri, 4 Nov 2005 06:51:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4EpjA6064016; Fri, 4 Nov 2005 06:51:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpfpJ064004 for ; Fri, 4 Nov 2005 06:51:44 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA4EpbGs000401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2005 15:51:38 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 References: <20051103162144.GC1303@jabberwocky.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051104:ietf-openpgp@imc.org::cPU0iZLr2Tu4Io8A:1v8d Date: Fri, 04 Nov 2005 15:51:35 +0100 In-Reply-To: <20051103162144.GC1303@jabberwocky.com> (David Shaw's message of "Thu, 3 Nov 2005 11:21:44 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote: >> >> Hi everyone! FYI: >> >> I submitted an updated version of this document a few weeks ago. The >> changes since -01 are small: A new "preference" field has been added, >> to signal whether the sender wish that e-mail should be signed, >> encrypted or both. > > I have some concerns with this preference field. There is already a > way to specify this preference on the key itself > ("preferred-email-encoding@pgp.com"). That is not standardized though. I agree with Brian that I'd like to see it standardized. > Once a user finds the key, they have an authoritative and > tamperproof statement about email preference. The OpenPGP header is > not tamperproof, and having the preference in there raises the > question what to do if the header preference doesn't match the > preference on the key. I hope the OpenPGP document doesn't leave any questions as to what should happen. The document says in several places that it is for informational purposes, and that the information should not be considered trust-worthy. > I see the OpenPGP header as a useful key finding aid. Once the key is > found, though, the header has served its purpose. I recall some situations where this preference field might be useful. I think it was another way to bootstrap OpenPGP communication. Yes, how about this use-case: An announcement-only mailing list might prefer OpenPGP signed messages. It could then add a 'OpenPGP: preference=sign' message to all list posts. The sender could be the mailing list address, which may not have a OpenPGP key at all. So you couldn't fetch an OpenPGP key for the mailing list address. Arguable, the mailing list managers could create a dummy OpenPGP key for the mailing list address, and set the e-mail preference and upload the key. However, so could anyone, since the key isn't used nor trusted by anyone. The announcement-only mailing list could be some abstract mail addresses too. Like submit@bugs.debian.org or similar. I haven't thought this idea through, so it may be silly. However, I recall convincing myself that the OpenPGP field may be useful in some situations where a OpenPGP key preference field is less useful. These two ideas doesn't have to be mutually exclusive. It is clear that the tamper-proof preference should be preferred, if you trust that key, but otherwise it doesn't matter. Thanks, Simon From owner-ietf-openpgp@mail.imc.org Fri Nov 04 10:30:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3Wl-0002Bp-By for openpgp-archive@megatron.ietf.org; Fri, 04 Nov 2005 10:30:51 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25983 for ; Fri, 4 Nov 2005 10:30:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJLXq067361; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4FJLoN067360; Fri, 4 Nov 2005 07:19:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net ([63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJKv2067307 for ; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005110415184501400sua2ve>; Fri, 4 Nov 2005 15:18:45 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA4FIjX6026720 for ; Fri, 4 Nov 2005 10:18:45 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA4FIi2q005063 for ; Fri, 4 Nov 2005 10:18:44 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA4FIijF005062 for ietf-openpgp@imc.org; Fri, 4 Nov 2005 10:18:44 -0500 Date: Fri, 4 Nov 2005 10:18:44 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051104151844.GA4972@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051103162144.GC1303@jabberwocky.com> <200511031348.26342.brian@braverock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511031348.26342.brian@braverock.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Nov 03, 2005 at 01:48:25PM -0600, Brian G. Peterson wrote: > > On Thursday 03 November 2005 10:21 am, David Shaw wrote: > > I have some concerns with this preference field. There is already a > > way to specify this preference on the key itself > > ("preferred-email-encoding@pgp.com"). > > I'd like to see the preferred-email-encoding issue covered in an RFC or draft. > I think that the issues around user preference and interoperability really > need to be in an official RFC. Hopefully we can take this up as 2440bis > winds up and moves on into the next stages. I agree. I think the current design is just fine, but documenting it in an RFC is a good thing to do. David From CarolynChase@fruitfull.biz Fri Nov 04 10:39:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3eg-0003lV-IN for openpgp-archive@megatron.ietf.org; Fri, 04 Nov 2005 10:39:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26315 for ; Fri, 4 Nov 2005 10:38:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3tf-0001u2-Ce for openpgp-archive@ietf.org; Fri, 04 Nov 2005 10:54:33 -0500 Received: from pool-71-98-180-237.tampfl.dsl-w.verizon.net ([71.98.180.237]) by mx2.foretec.com with smtp (Exim 4.24) id 1EY3ec-0003zQ-Bs for openpgp-archive@ietf.org; Fri, 04 Nov 2005 10:38:58 -0500 Received: from wQJ@localhost by BonJ.int (8.11.6/8.11.6); Fri, 04 Nov 2005 18:12:25 +0200 Message-ID: From: "Helen Colon" Reply-To: "Helen Colon" To: openpgp-archive@ietf.org Subject: Finally, you can afford software by Office XP Macromedia & Win XP Date: Fri, 04 Nov 2005 12:17:25 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: CarolynChase@fruitfull.biz Content-Type: multipart/mixed; boundary="--A8dE4IiFAHuZRiml" X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 7kzh ----A8dE4IiFAHuZRiml Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

----A8dE4IiFAHuZRiml-- From MAILER-DAEMON@ietf.org Fri Nov 04 12:46:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5de-0003ar-3E for openpgp-archive@megatron.ietf.org; Fri, 04 Nov 2005 12:46:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03853 for ; Fri, 4 Nov 2005 12:45:43 -0500 (EST) Message-Id: <200511041745.MAA03853@ietf.org> Received: from adsl-157-61-17.bna.bellsouth.net ([70.157.61.17] helo=ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5sf-0005c7-7A for openpgp-archive@ietf.org; Fri, 04 Nov 2005 13:01:38 -0500 From: "Mail Delivery Subsystem" To: openpgp-archive@ietf.org Subject: Message could not be delivered Date: Fri, 4 Nov 2005 09:50:48 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_D1EB37BA.D0FBC27A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 8897a8f96c648179e32cc9ffbb0aaffd This is a multi-part message in MIME format. ------=_NextPart_000_0007_D1EB37BA.D0FBC27A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id MAA03853 wYiCr1RIjvmnlZybkngtb2xmRWsnn1FcI162sc9L773L927Tcoz8TeAs4DhlKF+r19ZTkGpY uD+2/My3/i+ypbj2icWeiS0okz7clYTrDQoljNVtUdENCkqWKPOG5k797dyZICFYXkY+xVd2 975Lyq4pmOE8MSy0dHhCqKJojbXuYbxbUKrRirNtM69wO55QMUg3M7bej869m5hhNs0nmsBf 8g0KbCMwi9H04f6Vmo6O0SN26ILHe71P2Hn+5pY7lkVN6/dhj5/kXFCV1oeeQYisiuUNCg0K ------=_NextPart_000_0007_D1EB37BA.D0FBC27A Content-Type: application/octet-stream; name="document.zip" Content-Disposition: attachment; filename="document.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAFiOZDNEUWcFJWUAACVlAAAMAAAAZG9jdW1lbnQuemlwU EsDBAoAAAAAAFiOZDOW ogEpq2QAAKtkAAAMAAAAZG9jdW1lbnQuc2NyTVoAAAAAAAAAAAAAUEUAAEw BAgAAAAAAAAAAAAAA AADgAA8BCwEAAAACAAAAAAAAAAAAAJJCAQAAEAAADAAAAAAAUAAAEAAAAAIAAAQAAAAAAAAABAAA AAAAAAAAMAIAAAIAAAA AAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAACXQgEA FAAAAJVBAQDUAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA AABNRVcARhLSwwDQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAADAAtJ124oW69QAUAEAAOAA AKtiAAAAAgAAAAAAAAAAAAAAAAAA4AAAwL4c4FAAi96trVCtl7KApLaA/xNz+TP J/xNzFjPA/ xNz IbaAQbAQ/xMSwHP6dT6q6+Dodt4AAAL2g9kBdQ7/U/zrJqzR6HQvE8nrGpFIweAIrP9T /D0AfQAA cwq A/AVzBoP4f3cCQUGVi8W2AFaL9yvw86Re65uthcB1kOg6QwEArZatl1asPAB1+/9T8JVWrQ/I QFl07HkHrDwAdfuRQFBV/1P0q4XAdeXDAAAzyUH/ExPJ/xNy+MN0QgEAgUIBAAAAAAAA4FAALAFQ AADGUAAAxlAA6wBxVmowWWSLAeRAdQwYcBytDgheP8NgnGwkfx9FPEFUBXgB6vRKGPhaeCAP6+M0 SXzwUu4x/+TAHfyshAF0B8HPDfzH6wH0O3wkKHXhu0hAZuwMZEsSHB+YBFToiT1EJIBhw1+B77j/ 3wKZkwuJ+OsF888BE2iOTg7sU+2SgBcxyWa5b24BUWh1cmxtVP3Q4DYaBS9wUOh4ThpRIY13M1bQ F1LzgzOY/ooOImZff0FhViDpwGuckXRHcDovFncCHi5hb5xyw2plY3SbZKtu99+BZy9zaboYvW1/ O3Vs+/phfXL+Y9ATEd67PGcOLnBuuAAs21AAHDgQUAdLRVJOMEwzMi51RO3AgEYAaW5kQ2xvc2XO FkeNdBzvy1Ojeu0jGE7ieKYSQR4PTWFwVl/Fd09mGBAeVW5WbRGQL2IIcnOzMAyZRW52Im/fUvx7 PFZh++ZirBlnRBp 2 sVR5cEwPU/W/bI5tVGl5j1e0NhgjUkPflWEmDPnjmL5nXUxv9mTp7GJyz555 1SKMUMhj8HPjREwHx2JhTz2yDmOnWUzYDUVyPs6wK011zAh4U2zGMHJjIPVL83r5tiKuPYBHQ28r cHnGnUR2DiqGDaYmKEhh6I+eMjVTlUagZMombmRFVAbgcFBgUmg OJFcsg293c0S+iH1j89V5SpJo 7pLATW 9kdVRsXE4oYW1gPkV4ZoZo5VVkIAjyQffztVD2MLRkmiaODPpwpaIjNyBDriqMkqlvWiGd / UnNZkeCvVL/UhjFaHYZOn2TlEgWUUyogGCMD6xjghI7Dn4SSGs+JHXwKsn2ZHtlSGioamp1GGy8 QnnptkfaDElynj5rN2QWapkkG0wsUq qhsvO4SFBv/UYpIGNINHBGe06l9qK+ghQSGrrpuTtuIkaP bZQKomlMnawF0ILlSV8qeU 4/Q3V/1PxW5I07o9mmyQgAplq6xpyWbv8DFl5Pj0 RWvZFJUX7Gkc1n Myg8Syp5DTZPcHwZoX9BVA9MjVbQdfNYEFHSFhAAEvTHNsZtY4QNrMSGQIFx+BBNU1YUQ 1JUb5CJ ctHYnkhHZ up3looRrA0QaTlzZLpn6jUJSOUgEdrMtw8JT3ByG0pXtJlBtEUHRF8gEQVVU8Qg Kc5I wlWwfcOyQnVmikGWEIYMof93Vwxmdqj7JbUHJMoLUsQVk+ 01GxnWzE0kwWFJZz3MQNtXEVMyX9kD A5EJEiIKRDMWiRESDyQCSA6RCCITRHI4YIAAq0JRAIM4YQh0AEkE/1ZXagWJDhFaiwFBcQjB5swP tgM4C/dASolzGgEBdepfXsNWg zAEM8BXsHkIhQfSfi1TVfHa0e7I4DsO/nIEK4MMAYHHDQLYcxAM ixHB53kqw4UL/UIDoEt12V1bvmjKkAREtlyEAcYPtznB6AvYr8 f+egAIO/hzP4lCBGxm8CzwcL+j jIaeAMH/BQP4Zok5ZYswPU9XGU0KdBiWOYFB5eC3oB42CnGAkus/OSvwN/ggv9uab40G3YHB7gUr xr6AQrxqKgFYmIDN7FFQU5naxxyF27D5WH4aD1aJXf zhVQiNNMOYDD7oMUX/AgPG1E38GHXrXkaL ywBaX9PiWyvCyeQE4UY6d3iJB/gz/zl9XD3ZfVrw/Bl+IFZ4EkBCDB7obwZ/b89PFADT4AlF/DBH O0584l5iixRfW7BCU1ahmXVAoO4H0HZlkB+BifmUoPylAwmNjDgCjQPA6MX+D4PYg8ugO/B1K4FR +9GKKH09MmzI/MJrjUYBo9UDww3eR+iXXejbCwrY69G+KgM73n0RbUskOOzoe4tx NQ pfisNefplW 2vrI8ehgYzGFwHUW+kQaJAxXlIAXA1qNTHcwMOjjMes7i33XPk4CKj8kGVd1G0sQtkJNSEGMjMfo vDeDBcAI6xFqBYqOBEKzWuippBMQhF1n475AQFOtiUVz2D515Ltdc9QM uQM5Bg+EskFZF54J6BhG OtQDUPAiVfCAOG X/DLmbGzy44bmAEov7A Fnzq18z9hK NTcAMXuwG8IHcmFL4 BuDoMzz90jnY2Har kFJz+ADOg+ADjVXAwTvhBLLIpvSB80voiKBBt3MPTYEKUTREy4F6BI3JQCReg2D+EowYbA7BLolN 9H3zGbrrDSYK5QXU7gP1yz4KBvtw4Ch0IlYBVegrx4oEEJ+ziIfQ/3U/ 6kjdRmU+1B4eJiRDs2CL dIZowEN3BszoFOlkCxA9i IB8bORNjOgzik1YZmNF6HOADS/HReANQTvp/BL4YP2Fv9AdH4iYjOjR MYWgUnU/kN1BDwTRIM9D6LmoGHVroasHh+j4D52zSCTXzqILK89i+AllhoqI0IGx+NKPtz8GAu lB l8ilsER/MXUFhU7s6yciasgRZ1wY8DbrCaiPo1u3PBLs1Qxnd v+KmHX0LzyZaApdy1XbVFq/RYES fv0s+OlVpr+2hVk8 bdzHDPKtJHUGJ3wgZA bbWqMgYAp26NCR+DEEl3wDME1Yktl3U VAG5weaVBEY YAMVaPwhBXxNi8gHg 9H5secBSfzPAnfTwygOfRoLrVKL0QNVK8gIXkteBZFzWDUH6yGNUZ2Z/E77 1B41j/ivRaRQatSqhLVGgOvYlhNHhf8KeHt+MvYCSioH6ehkwojgCHOILApC5RL0VK/7duFk0346 BTuJ2HLbrwMc/A0PgptrRlILDFutycMAAAAAAO9HUQBooQAAABBQAERV AAAAAABv/fo1H9gwFJND 3WPaJyUI6iJxUzqZ/fiuvOpkqfEujZqe2f2zJm1Ldh3IlHV11U Lidwu91CHhvHg7gK7eRlICqX/K bfS/sCOXYh2/oc5qUyQCVs+eGBv5kg0oOr0v5SZB448IMCRDKFfa720D30y3u1rv5Ly/XVtSan0v u4PXK8G mT6Lc5xL5 TvC6aNJXdxVUt4dVnyD9BcQLP/5jXP hRzmQelEZc7oS/c6oXcaEPlo1V17Ji K9F4C+j/ThL0hXNPgiF+yr4VHBJaAQu3qbHXCytbNaoaUEZyCl8A7Y4H/FQu9PtxA8flgPSrWsMZ gojeLuABG5e9h4m p9NC7S9DMpBK3GyqiX74jPjf5XaU6ml9rHMAlL3I/r0wL7QVA6aPUSrh0tyuF TtjtJB16D+3iHbqy5zw1W0f1++vExi14OLLKSg2XqveBp8rswPDJtaz3M6vhH6Dyss9BCz3Imclt Nu1h6 cXdKZpQU5vh+M15IUjocPhbk0M7C1353fVwSGnEmI2Wxev654fnVYGMq/+I1mfTkzIchwwm JjGAPp+tq8MMdIpJOrF2WnH5VfDHkuIfkfPYBjT43TFPjtBIfphQ1yexr9Qk84hxgHCEoeMsoKBe tsC390oCAl8YmrHPyq ZNAdY8KwP9Vjgjk4sS4SD4Nfp7zzMGdrXaSZJnLLFmo7KZaLxYfChxGeIs ozDWoZ+ZHDxhi yJTU/V3ud139jNSDQ6V/iA4npq4FZrdCwUDKwltqf7qRHpJwC7OVsWysXjQppzF y1AvTAWdFrsHFn1whTe3Cs41jdJ1JqY2HQ214e+CcccRLVoeR800Cn1jMAUD2RyLfl05F/6nPguY 9WD0OuspRgrpg/Wzkt0sD+j5xtYy5BfIUBT5gQO6eOXrRAU5Q+ejofy9 wxwn0acuBbapWzpo67/4 BFsA74Wsvr7bK60kbh7XK3w+RE6oTyCpi1V/lnoCXp/4SrsKo+fEFpNXT6KH+p5hJUnaWftCGImX w1jJ9ag8eDzfxQ4XFqvKy/9e GuGCZUXFfstufX+Ho4TGhcE23MoiFaNs NEASvp78XU6I4DTdf/q4 4fBl8IVQB7wXbaJ7d6Xbgd+tRKMdoPaINXxk8 t1FpO+GODUk+QSxelMK9ay1fdljSsT9blMEzWWy jtF4k7Pj12AFeDyi8vBs45ZTgb+gFZidjI832cQmem0m/jZxAOq5FQKICEWDOgfdbNxotSG Vv6Hq /QjVD6MjIdydynXJew0guMCn0z3bPnvzS tcECNwTT9nOzg9Ls5zwq+zQGHwlspRi/ti0nmdUbydr vCILygcko27m1fjCChAn NY06xrnP2tYCOy4eIhi1JkVo/LRNs48 iBW7xRU7R2yBYI/uS9B6vNlLm Y0NnCsowxb+bu+xomi8jwHX5nBZM5idwgQ8WTOrQj5KELnz0BnfiJs0cPftIJvXL3f/Rmb6oHAiT a6Wk/H53POunV4h0sYYQUDYJ54HXEzn7VEcKNnU5erR8lkLQza5nWBoTsV5pD9hMqVSVIjiCbxIz OZ+L3tcSnRWXimxpCDxOoK+rs6BOVhhLraYe77xaqM/N1e8dQehjjxKQffoK5CrknYfCAqZqy5tt O7I83WzmvcdYzUXm5gC0khWRyKAxpJtPkY5mXI/AFoj6zVkSLniMp+HDVNumrFs5e ZylwZMut llm 6ShLL9eE2mi/9cmnqffKU0e uCoa+I3FTXyBjZBYN9D5LqZ9BhSyDjsoxcL0Bl9J5Ye8ItXvV1Q5t jYFjsS4f8/fU+txKCWOpEVASWZ1qq4ycjFuoSyJKNOe8sZ1EkIX9JBaUrta9BjTvFaSc65AS+Ubx QiCEQYCPueNJcUZIYsBroY1345mRw5nfwTuY87OJmWI1LIwLqyT8hPf6b17I1ykrl7nrWeBzD U3o XxaRk/A9gVIgh4lbI6eGKpahIBgji8d bsx2RLjfeG uKIaV/WXktCDIbp/eau331SjliKiWDpfw3m Em nIhgOEHc3fRNRZW99jimgZ0NnK8SPzLwIuO1zNwERyg0BKJEenHBcRiVDp0Rktx7ozXTt0P38U 9jDm/a7bdQuvUiCT3HJSXBEnBwy2/EDFlG/KEE0d3OZI92Bg6JehYEc1loTRfoTpQ+ClIx6fzB2x o34uf4uwBiu3TNLv8ro7vZr/cEd58w2pUZeconztOD5p2inPRUeD7U81by6HLYvm+vbpt2vFH1Of Gt6/NQU87RyhPc4zmLe6uas8wK0eOnOiW/0S3bSviHDw+YvgtA7escHuLfe6Fk65QDz305qvMY/g xrwYRLhJt9gT3jGCdtSCkGnUBRflrnMjISbV+b5/Yifzbl1reWIQUg5UDUh56gXQ++ZGy3DUnaUS p 5fnNHCa5OJMFbziEs7txWJgwF+n7UyPgnb1A/Yc30fSwrzDvY ZYaswl+L+Zo+RNa4ObJED2RTnE Ss8Lz7IPizMT6yoEF3pPoICeIa2RBfhwIj4e8f7hThB IvLmWbcfhqZX8fx+iuIQDU+pu8Oi 0ENJT GcQLedZScAMNEClUoKP/pI6QhfH2+nf5CDgNLoe9wb1E/0YV5rXO4dkrTrPptn8WC/WF8hQ9P45F M1/8 NRc1qqEvG2GGnQYs31KOLuaSod66xKvh12BNRDRvOannW5+O1KQ8oJuh08T4bLTWi3NCMxLB ICXtLTSxc4hNjQBx1H4du5uWZX/nsEo0Y/JG KVGWEhmDqSrjMk1f86A5iWeJbQVvXccLqxMIWB7j 6zbGXcNUW2Wl9bRr0MBrPd+kZhv8ftqcwEsSJ7Mnki2pzhGYiUWvZsJc 3DYi4KUEM2YdIyarMiZi 7UpOyk9MTNHdUrRFopuZ/GtpGXNnFMLVsRKNB04+iyq6OkuhabDPVqtd3U954GQ5MqT5yI5M5JDX kFWZo4JTGjCPIFt6GYRkG0Q71LiRapwECvmwk0XECdkYE7+7TeFtxdPdKrbBrXjZjti3LCo2UqaE V1/L+w2Vd4gsPg6oIesybRz+LHRinE0fR0uzcWw7iyGWl3NDhYAEE8qHmfH0dQay5hmbJMzB+bnb PZ240BJZUCSZ02YqoMPAxDe1g7/povPP4anDwc6EafIEJd1sh3h/jD2xW43MzOsKLepknWtMgl /3 oBMgUkm9JSDolRQSYANtNdX0Qj7ENzvfaXN6Z47cw2JyKEiJhxtU/y3F3jOT+S2kbIrL 8SeUlGvr /jBDjtToheTrNX K 70g1fqLNDl9GsV4qVNC8QvxX2RYMYRU25yHrWzVTmwju YqjL0OId+uBSf8Xgy QfGk4FFqxgj inAGkGVY/K0F2QHynU406IoGZxFhbp2SU/7OvZEoeE1eCypbvmiVWORzpmIh9hfXX zWmKSXwLRL30A4+kQbWpAnlvTh2WGvSOzO6k75juCoQtmcz5 ZTe+Lm+zjPo2L6mXz00OFxdv/GLv S/0/M7NF 6Is+f+Xp51qm7VOTJppeedHLqaVr7/zfIf2pBX5NHdH3G5IHMnPoIxwm6Kq33WY4zOtX cRpyrQMzClYKQY2kb/OpO1cwaPoxEOG2lfpKfcx88MmP4bm1zsWFnxIgcsvYonzFU3hceQ5K5MbG C+oiqVXuOKg4Eb70pYXa9JEmLk/FqYgBL3auUjt3aRL3gRGaT7Ql6NCGoQzLL OB837n1fxX2YvPj M8DpgNI3Ga3osh6hPbrvLcz6vfWt1x5C4eZCNxbuI9KMSGYr+4NSkFNMwOpPK1COFQbDiZQOOYIp LmxzxIPIJxBZG7VDduVKi8b5wqrO3BYbjBFjKQN/WS+j5QlmsUAQKXAG+V/S/C4uJ3Fdpm79KIYN rr3Sm4HFzvTRvWYHCQk98NlC6AJCWxp+xvnaBlpC r3Z/ZYTYPMJy8qaWrgvX7 sQj9MY9u2ooi381 P0A4pGIaMzWvWSCfGPXoGRUCFScZmmR4hY1Kj89t 3zo0L Er0O1Fp5AOlV9o0x7ewwbNJJjdB2Toa V371dfK2zHsnhyCSc31BU4j/hDXgYzzHiJoqI3Mk4ZJvNjCCWWiLXFRcbvp8tb/J7a3PzMrswzNp dBoa9gPclx+hekVeaT9mutLg5XIrsDcExCyI20IhVN3rxiH4An5DV5JqO0a81+byW3Y+ZuGxHk3q tWAJf72fPQE7VN3JKvtPUldAbx+pMhSshiRcmmuk2aYnfTW42CHrsbQ9m04xzlb3SXxgjJSJDe+X RWxkMN/vcr6P67PXkEeUTR7hLw8dWl6Vll7BjyKobfFCV8VWLmg oHtbvvc+xlLbZAAMmeKaPetPE u9aqTgBrmcKUM4q18do2X4g+2OqDqUkRdds2QDATTZ1vGUYzBVSUc4nf/G Srs2zdUggpGSfGWR78 cYjTVbzBF6i4Y6e3F1eBDEDiGHDK0J+LPINUyrFMNo7fSVKgRLVHQwKAhrwvIbmWz6buv3FXGMpQ YBnONPTQgmVadAH+mUaYuHZA+4MHskvOW/IUs5SH/DdHGGgdFm0iXbOg22MOeHJ6PmpcAitgY5bs egfCjpeDG hfqSpzVZBxvGgG381v2LRKFhHp5je+w/XCKy7tm5x2qAdUKo53uf9C37qECEwU+8xPt dd67x2JJ mWlQu3en5T29VYCyPpKh1RODfj+c1nfziug1I6JanumZkJz2zwkz5TpXJdCXv/PA9Snf x4Zi/jZqAIytJIelnn85rbqr8/bHyJMOGG/El2xpYBin4FS+06ffdtuTXKv2M8GGLxSEdxVKpYbO +NPY+LyR3noR+NVAkInXDN+rMwyBH9YlugE3NGK1mfp+HOjhmEvIGZEwxOyLcmkTK TodnJHSpbH6 TYDwWcY6BKIRj1XM26aBqN32iPa202ej06TarRBbcLQyo 3NU0dZZs8QgiATEQACQ8SA2BNGKCn6d zuXAodUkbU2h16HcQyYX9s3dbGzAAXz4L76DzVZfMQ4aYp0XU85yEfFd2R/1Rbqjo4glLemtt65m B+vugv3rCaNtDdBQ2sO6TsZDhsOOrtPYso8E3E3Mc2xNybxQt36JSkNxE0P6VHYbvexv/V9TM+Hk tveW91VAy+Tre5u8hec7mGEYc+97VB6a2uStmE0 Wud4OzTeQ+bU74Ruu5pky5Y9cEb2XepjAnfzM uT/1XkUsFmGcYbPcStHANX/JV IsLzjrf9CAQ6lKtNojcS/6UL0a/LoDbpCxgJY+vLrYms34oY9zx e99YLeWEnDZ0KvIghormijTPB58tkKLI82luzcr BPLHNgYl+inVBEKFisd9Mf3Gt4+tgSufKiVSF EBifrZmpFNTZuGBhL1Uio1b3lw9aKsU7yEwY4JT25CoIKUmLQegVKXUMPCNss5zm7NuDLOrVZwxg v yqmzuXoJGzenoxhIg0ww1XKuoAU+QvGRxuKBHT4 WnCbChQP9pB3FDUDaKAZSWvA39FMYqcZGh/G gW9ajrIz15R2DgF8O1UjGDKgcY6DMcYGRh6tcnQ0AtXFWUGjKbB5l77HfsTjLRWcnqP/yfJlpnxx aq2UFOjYEytZIgmt9JrrzYP7Z0XG/NdRXZH9FbVF5ABeh+9Ae7yb3aUzBKj3uiFUg5+WOmk/ReV+ CrfutgTf92V5wkgInR2Hv+NnmlYrhJV+DRUj9muNV4KQ0z57k+MoNEVT6TRwV6vRJ68U5aNvguFz CHNWftERNtihFcfwp+G3Y1Afoeed6pTqQB6+KknJwAiHU33Xkfh1R1h3Bz/YDSWeP4GTkqJookQX Nr7JdEusbqqlboeEvrDN mgYw4/qL3zJFa8OEw91qlj/5w1JyjdgsxI2PjoYIMMuKqZGqjDhF40Tw oZS3dJe9So8SU82wUxVxDdM+OBG8ZjsNSauYQKM3P86IXALego53PsSM/spv6USB7v5dZhmuTllB 2s0kQr5Si0ZEVjVCo5cq5WcQwgMAxpY3xN7acqug6o6Ci9L6CXhdItAhqjloJxxwDkQqaoOgB/26 MYtKKoUATFxThl9G/MBiLLmq0RlGjC68hiW5AqW0LaTwHHA05GbfRZ 1Tzyjw+Ls+lMXtFTqoJwcb VNBxFQDk8PWYbHFonBkCDerZxywzpzH6S2EkRQ7XkQ+250ArtG4bWyhNo0GAu4iaGK1pMT2wJrew ffk646ve4WTkREOgZKGfIIZa1xbSTtEKMwWbe1rwZrIgaI1T0Oh5s3kfwReF+b3KJpLNZGEDUhVP 51Y7WQ7heHHpq4hSaDneQh2krThIYRKN7htwsSpCpNIHdVnNsZO5LSY6HjUmCinPxO1iF1VA31rZ 9ZaJ23KixsEgfqziK9H/HWwRVSmf3dcR418XoyO1mZQd0WaL SLWHX9Ugzh Eu Ux2LhAC7zk96rfWg /AVSILrBBgpNB65FVJmjz4GFVMwxpPu5z1cXZEUGJ+tR46vp9Z6iBKA9T3GTDVv6pkDlCaLjXVRs Gn7uPxL25ajIYyY3UemfKBhklc/mT5ctu2R1rmElHYIxerQDKM0wdh3Crv1CGbbHeBIkN5kryAYJ F1BcQ ndwnHvUNzLjELaj/k9+TbbPbq9/aBdzJkB6ZNOrvAMbp6e/KpUTLwLKxsq8I/DWk+SDrEN6 wJAdTxX7vu/0qGUsQ1irmgAaxd6AGGcEXn9pPhtuIj9c8GtWtZZZMugfytd4zENoCiAbMqw+USvL bRnAhRtB18MzG9mjhMd/MRsGkr6ajZy5svaYs1qSL7j+s B2Fzl1A45ce/GGY nmZsYuXuR9tKxco6 s6JL739ISUTD2+Jde1aOsnEs8RHBOz4uccgoLjGWxhDCJtcrnj2dauQuTSUycxPqk+LJjsxWVJq6 GPzbtHHSGwcYlafmDOcmZP885sPDkLnZunlSjLSBWBtt77nktiS6HHCAuz6SH5M/l0IuA2kck8kJ kTP945E0fiSJ28iYThNDRUcrNgeYoOQz9v0x/Xv1gmw/Q+Yn8lBORKfcO/EtdZohnSs1gsMLIh/Q xs3DwFdD3G9gcu+d11Bt4Ay5Xh3/iDQyuhjfruf0cqAvl14hCy6uDQ7q2rMOoBtAf3PguVL5VH4d isHw16QNUYaFKObgkMO7mLP448H8LNVt80XbpBcS/XjNO+x7pETi9GmiZzi8LSNqobuqo60QpzCF 2jckDc4sGDT+Dm+pZLVxJaqhx5zYBv5Wp7uSDAKg+IJ ruVtO8qW/0dsK3OcN0MoQE8dF2fIzJtQX EGuokcfrHZo6LUzJNEke9k5OjMF0nPmXyY85N8C/na9XTJWRcyvwujjTc/t4EZRKYsutb5fwK2Vr uK6CWk54OYWBLPMRYamGd5yVxcIkVeVJ1HVEt69qxmTolUWbggErxIpw2vGHqVLBbYLUfFgA4M4g 7O2ePxS5+/GMPWDsa4WgY/VpG4G/lC4gT+0xv4+ljeycx0WtxbmJzi9kJ1Dpy9nfOrkhdwznokqe aGX1wlGrduzvyKS0aT/0v71pIusnixbOkGfQe+U1qsCCi2uEEr8fkDpM/ldLsgp22QGyMjMvyiYu +FC0BWfQ2ZPEaSKhFzXkg8T6cP+7W7MJP90EFxv6qezr1/fhW7RsrcgPFLc8JFssKogScyXLsuwk 1K2LYb87vaPfYBQS4RulkW4e7Qbst/JO1ln9cM9mMsZTLH3eRruk0heBu8h8G6nHVFJmeF+QAI5M 8EMEHReMEn4TgcZpine9L4WOohvpUH2IZGTt5hI1kV5IPJY41iIexFNPHuwp0vCvY13oAnT/7P5i hWPoctljW0mVAx1K7o1dc/qoyNzqgYPp2GDXJN8QucIVve/hN72gSI6IhdxMRNitH83LOZrf7zb9 cZf/kdbLBQK36FTJGxY+dw1w944UfyFqu5iUvr4wOQf8vZWfM 8vfyZyuoP5YKyCtFo8k1qwaL/O3 ROTlxFkgGE4akcM+L59HFKWzi72ox8QYuStl+XIjlClmoi5GfIxh5ERuddgmlSC5YDO/UW51HMS8 bRXcH5N/xhAmVvo+wppC88CvTZCyiLMcTu32XJmcLfUMMr8VgDd5GC8ZQEj/iB GYiYQ1lY9hJfeW bjPFyiB1kxaaae5l7cTbGPxZ6+dZbFa2lw7eqOmBvXbQSECchNPpIkOj4267uPUxypJH/HE9MmqM foAQJaW74wJUMs/DvNAOspbhr+oUxU2EZd1N74OOHtJ0Gk0TQ+14FsfnSWqBc2C0e9BkvyCWiM0d dPP4tAV+zweuW8ekpG+sYGJdKokOl58uyEeZn m9zXodJcgjNd2ZGc9L4z74Xfy1y2IiZStvWT4BK GYTT9Y+7X2UjAvD1RjgQpnK uxwFvRTn+79Yn3okPINP /CWYHaiQSEuXO8JEFK0lHLpW8lcJh0rM0 RbK+TCgSTvYO5wE9ohMoSZ2LXlly4fpwq Z5xpNVP6Z+tXjIvwFMgq83xAniBWvdTIh93DMof7miA /MW5IAmDF4QQkMys6DpUuSIDBidfajxJ7JWArqfB2oL1HiBletvaAqNub04T4lptoUyf/5I5ilre F3hHpdvIVIUtdBC320C8M/9VfeWSeGI VbgtDlbphp/XDHXpOYVRtobfYZNTvtl+M+ngQuSUS 8en3 Vraoa4zGvIs6Nh+Trq1EknC4xrk59vxSpBpbEqmczjMHHBA1k4wPXF9K7xwLaS+Z01ddL mM1gmSF ZGsBBE/Mv+pgVTzku+oDYY9zfb2kOMjWLkUTOZ YbLk9W8OixucZ0oyb564xG8TtRc9a8Hw ilYl3j OEzKVIhNXm6wlcP/Fu75+ZRfkDap9h1KfrayuMCUp87v A+NNf87vo/dDRJqTGWw83A7tIX2xdEZ3 MKgG5I6JuqSBwEv1ukQNVj/07HUS4sUiS6vn/ERuo+BejnDG3Hs6nKH9 Jnq6lFkzYp4FBXHryzCR nSCzYfXMaPjK6fkhCxaEroX9C2 07/x8IRMgKsG6LqslyB1t67L5cBuLYTYwXFYpBz3KNBZpfM/S5 xFeR2fFCkFgdPQBwBV85dRSrqhVPLIDjEFwD3g1MJcaeU1hMEIbMgG/lbpNBjf0mgzVlJlnOdnDN qhC Z2o2+Z+gR6c3AVd8n3hqTBywu/j5aREza7Hy1ZAXWHnXkSbOwTA3x89Q8DrMOlI9cEXumoJ UH 1gFYk5IuA/qnLjuY/s4noIdsMfTrdpBC6gIzs5hvG+BBW8WM3Y523yuvJcWljkxI+BrDbcY5Rf s2 9Kme11k6J5M8UR8XaQtY0zh7FxVAaBEVElpX/tauTvGTWPfVS2Z1KCR4Ad4KODcwYF0VmacJ+v9Q edlpWPn9xt3vr8+h7z2GAetclRL6cYEDmIG/+ufMzGd7qUvc/qnOk89Xm3n4Wq Y8gQs4lGURyIrE 4415nJyF3uZSJ4yiMmNywfhv80ji3yqYS1RtoUbFOnoqREmciO17XGZaumAIiXynotRVx3/czPJM vcbAG5RRpJaFNCLoGgOYOgT3GYAGmAVehqlGTrIwHVkMc+6FXNmsETTTsVBQdcLhOsaTafzuwso+ ke/9HsNMiP20bltSlD9pbZdBRhxmxi8XU7njFscI1ZjHdVpXDoIOBuvWAep0KogvPL8DVF3yDUNi ihWFHMWulEu75cEk3cd0QAYDnZTQGDl7nGIw4kwuXvH84f9SnF5qMQB1VRwi82nfBCXkBgGD1Bt9 mHth7HEBhIXmlJMAPeq bVRYsc+W0HdZp70ykHk7Xw8VFB3k5g9B4e27/97npcpbJ6Tdnzs4L+i9 z Dwvb uF+n5vk5xiT6RNNyU26t0b0+oYnXwHZ9eItnJv3rmposl9HEMcypYeye2nNeVGnTiWPkPtFQ /fqdaFLunNy92eMMlwU4CToJNlOneFVaEzy6NQbNaDew2mIsAVjNHNZUyB0PNU97x3BhHl9gqrH4 XeVmQ+k0t2VjCPw1nbNFozbpDauMrrZ9hOKn EDfhViG99apaYNANbqWxACgbioXft6jxwIFfd0p6 l9SMibPWgE3jM+PuWDG+mPt/cIalnPdkG0E74CrYBo/F16ZFHpjS/D3ifyNUiQuczJ2Q17dh3/wS aqiLres1VqEJjcD8ApsZV7z/bpydS0l/Rsb2d bsknIbwAgf7fPnwkqZJ+LoW6eKvIuJitrS1qJ6H cDYaB7FOeUk6GZqaSM/KoBT3DBWrEXusKV9qSFbCOhDE+ jgtlrSQUvz KwvemPyre4RUa/XaMSFpj 3nsfO5CvfSlXXfdhQp7LMSzkNykwAc1k3kwWUQXGSOp0QINFozT9sfC2zEuLl2iByng5O5/0cp 9h 5WjjDzWIdpNR45enZ0RX kT/D1A3RQpvsC8euITKMJOIuLjFgOQIyKCzJpBahsArlDTKMB8e9+B53 H/aVFJFweUxHfdzgP55lwbgzr6lkMpsAuYxDbRpvo0qHb2HH2XrLS9t6Ci+ICCkgERG YG/ynezDn jY3lT2yHZXNLX22EKljcJxfXtv3gtvVVcIDLjQkruVXzePAgP8mle16YdeV8rEBMD+jyAeOH5o2l tf8a4f8U36WAHI8Ft3mC1H8Y4q+R2LHj2GCQaQ6Dk9Ufca5ME/MQnGXcHeCQm/LVD2WtwUqSHX /9 dClfcsWra/sMN0H1AFQ5EKfKGt0visk5qfBUZvjcePTiMq6bjfBXZ0WGkfA4lb85ztT1rtjl2EU7 aJEk3qrQonVTnBdOPNwQesDwaQ13KL4eaQja3 XFAeMMMYlXrUR6yDihcnAf1lx6jP9ySibaqZrlm 8fEAK9aJSY3xp2cBPzuiDDDGEThJTYuOs3lxtRl3C7dabK/mVX1ecJvPgf5G8tu9HZgMUex0QYUQ k9FU7K6l27f1DXlWtIcjYtCdQFZzzFIPuCsMmJ190N3qwMCHfiYqDuJMMvI89ES PtxZ08aHfX cbd ABRlnJZg7F94eGIgQFt+o26wqjbhCSWdzHb5Jv5ax9ErC6LtC4OTQqavAZwSJCMZVr64uSH3Dfpo j+EjJCtEYLs+nV9iP1mmPgkpOj/uAWlOKcubiNuwYGOWUgjDL5B Z0 2G19iG tFrj/SmpmXaGj62u7 jR3mGZqRTAVzte5Lz/BgWiIt3pCsh+PHsxh8lDrawfdt93Grmt/Yn2SaJhrypahbMCOl8u+vTtBI M2coTIMvuwgsRYh62bVLJWOAn4h sOLbmAbJijNbSpWKhPeE2NYJH5lMG1UGAn/IkLNUAu2N5S ZGO Cb16ifivCd48 1JGHtTw+uNTWZIgsGCGWJkNZN6sPbI/k5MHWkWnQiG41LjUOK+y47aM8pyytciZg aBRz6KEhnitDhodL1XOJg 1yDjxcfRe2YpBtEopti3g5xxuc4ETmyhZK+0PZlrw0IAQTI3+pyjH7O stVMgqQ2DLCkB+LtLiR9zuRTGexDnS6 qjQzRTLbd1Stbd0x44VH0usdKUCTL3eRRpT4QwVZZ KxJs gJZCJunX CeUNNHFLqWoha/8UudIHD7CinNn1ShJYGGOYP9Nozf/QPi zJCWbydI cl4wmhVJ68hFcT QgTiVnhmRgOPBNbnG0YvHUaid1nDD08mlcXxdOjcC9Tp3mcnDo9ueL5yrIJzVpmayA5g49t7PKvr QIb+nH7KhHQX14ThxgsLYEKaHaIVwIkfwWAkY4HxODM5ctNsUB7aWRNRdP2 Q8aeskluSXz7h3vUP lClyvMK9zg6IJKDu0jMwSOgtUy6p/MgZQQlhti1tIcuJHjQaj54y0X9vxqMXE0R2BYzPl1cmyxzy hlXRCC9eqg52DWBJlMd+US0dQXoQmWjneg+sadFIvghZELdu98mDviNCZlqRJngkBodoDz6Yl32E 7mat/RCYDKh0fNJl5z+Li6SRCy6rGoikli0oKvM1VoQzHOH5cdWS3X7jMVljKfH1PJXmashM6 MXJ utRNv34vLrDSq2NvBM3gLMZ1dtdY/jaBMSI4UXlJJnlKKqfXOPnpRAOhCK83ttUfR57zyQe2UCxl +3vYpL8V79rU3Ag8JMAxk7A5rFpGz3TmBKEsEv7Q6LQc2hUi7+63gJsEpWSdpfX0TeN5LmV0C/le L4CSJ+6IXJFpG4iC+CycBZjJ6yVKsUFYgxcFWBExsaWV9XmwKLbDQdm+KNAWVpBItI6JVM2JbADw FP6egXadIPksyKVJanT1YnnYNUAcOYisVRmM/WARwcK3rbGl77hXcl3Q5Hkna4hHIPMPkhK6f27+ XIHueCExwpGqtG4knnXqmDdXnhwY0coOTc g9kbGZjWgpV2pd+7+tNeawVmrBqmrpNK637JzsdAW/ iHt XGCVaza5BK1RTXpa17J+P/zof7al5JypE+E3T3A5IKewajCCyckJRagTLZAhz8TiEXdI0zjXm eIef+jW5Cm2C5Oq2xqjci3ZYrTDoYM8EkGRFTZ3OjipFYFKwy7SOaMjs8dOyZeMgOx/f+zukfyI7 lU9rqbCuKE8jZEopaj9XUicGFzTAIre2wA9FquDuIoNibiskgC22S7NMMG2HL rS3QDyIU/pz16s+ LDxbR8JnWLum2Y59SM/L2Di/wtZJPZa3dsMKpCHxhQoFQgYYYmG9c0dbL+2jBgFqhmw8VY1ATfcz mj22rVCDjC3nA0H3/+JqQz66S+w1WvR/cY kGxsFT/dUDuYBceVFuMoRtpj+nu9DiwgrmheQ4wZQR VooniCnbck0zg1WhC3f7L1XY43CulU0KNUkPppA3UEdZg3H3WxC ARFgPsTdhUeTd3AKAewAtioK/ PT7+e4hQ0MwQUeUnjOnr0NzwW+HihKTFU4LSfXwmAIeJQvAtLx9y1iZXw/oW+ks1E35vD/vP82nO KflSHoms0Lef5wSq9/royFNzkrSRMCl3dE3mZNfeeXwaS1Oz3G3S6sxsxfl4cqPe1Hno EuMGJeXP ktKS1GWhwq+e/SwDZHPl2/c5eP7wVshLWlWdmqNDFZb2V9DG5B0P3 fydHiKsxQQZqoAZWUM/QWmw gQQP5BBBsT0c4NoI IufyEdC0kr89DmABcXpf2Riz8XCVX866iXu/3AgvIYvtdvHkjQAOce 16uf+S RgAwh3zZnkmQ0idbgngDLUEHPZLgRpASXxsJMMONw/1I2VHAefMnllHjsfL4fJ2JMBJ+zKeosxK7 pLMsG jF2m6PkqgYIresj28bl0ehmvcOZH/SLjN+lUgpwx+8/BUreduYQn1/uU1TuvIms1Yvk7Aw9 Ow8rfcbUTCZ+LM24UGFzDBmWu8Hbk2iVh9k41Y5JW1Z7rYBgLzr9nEt+hshsrEaRVopnpSP30/VR 2IZ/ y/LeAaP8M1pUmjeV T5QoXyWkIaNo2M8UdzZuzmFhjCjV Ue2ltrLgsAs1 peKWBXSFAOspZWYm bTGNFqY8v2uR/eB/STS4UaivnLs7ezF+PSwzxRwUCNq/GpkfF16p3KnOoy68yQP+DDU5XNXMaUoF zjNiiQUCR7+3h7sw7h5p4Y4yDYH6gyHgOMNc9Klt/kPozzCghVYGbcKX8 23RxlQoxVOyhbyxfKR v CNiXKOgvsjl78TERHnLGNxbpMx/Xi01u+i+91wlKBpc5+8CIQcqS/mMujnqY8TeH29OOOFN7a0GL C7gpQG3OFWy8/ka4Y0C9EzHTjSV1Ywo+6t+/Cua98HocrKYN5BS8c1Vt65RgJ2Y9MnORopV uUyDq JatyVGEtBOIEE32Gxb1nswtyoFKAYVspTFCO7fc8z6rsSSkSfh68jkt9BFf S1lHnZtX929qWyjLa yBQIgNX k4+KTlB0+kPnoqo5uQNb0A QOdbZ0W7o4AaMFIDYP LhgWhHVuREgDoLxxLO4sHFrsduf59 GneU2FatCn9n9bckaG0VL7L+IwD0WpsB8OREIU IJpoBeq4un+MYvxi us/t82fy9ArVgXCVQOzhn8 Mf6wQg/LM8StGBHPbdsintygqGso99W3FlsUlI2ubcKbdKzgJRI4HSMqlAm7wEPCaBUrTb6RFac+ OX6CvS53zmevw8O11YgRFcG43Ho12NhEUAAO33S2BPOD2rwzDuHgL2eFUuAHTcj0TwoMumCP+eRJ QvkumZs+DEAeshnG4ctMxbM8QzkEus5RJPgxZ2hGnUVrkyjBZLcWnls8bwexgbnppn0x18HuYYB6 6PZKzIPysyYh4 ckoN1u8wvMOiXcXDZhQoPvOGU Y1VDNtg8zOBNj9+kgCmqP9UeN5axIKcyUG3Lsr ft3ndS/Ln/u/w2V6TEMywtj8hr/TZ/0gkxU0kSUzyc ZBSwMTil2Wei3e8y4WPRy5IFBtP255Eu54 /pJcN6It8+2SiZNQlRsOjw9LfB32OjMVrAgUTXaRzbOpY/8Lc7YVsy9sn5am5gIAg+IR/PQHt401 x66Q6fCEnjt4aSwY7AewBQtc7C9yxK4uqkwXKkyhWrrK4DTsnRKNzDj0ZTxQLbM0IwCrG+e57e2l Z4E701al4mt1PvyGkz2xx0XvCtsGO5zhgfp70gAlqWMbW+djs4WL0xOhqpAc6oy/zBwxutpoy+/g jMR5p/z/gLHOCC0ZNjvGqwiu0rzNKwn 61Co K ebR8xDavNXG1byZS+r/CJCk0sjnlOOYXPthjnHHN Wt 70EwKABbNxgW+eu+bzDP1M/P/LY7tkes6QlNj652J92XDMwe6bN ssqla92QUahZD8xj6IAhAbx rB3txCnL4gwzEmoZZL/Os88S3xT481WXSvQ4qVY8xAX9LsCkOPgzlhxIFUGdQTUeajDFtGUal1Kk hBuktAfI9pMEEHv YCMV41yYR2XwtfZefMirFl4DB1Z/ttnKECg1H18XqJHK8mCpDnVN/MEkmNSTx j /rvKVXn+07KXs4eQOVKqaWY7FLgx0aittqAwEaFhu4DvEGdZnvJHejI9VL1DT39YJHVEH4wCg9u C4knDRIfg44gJsxF3wdwYr1oFqarbjIz0B42icZoqbfaQFWltd1dJAsuaFGDpFgTt6bh5ZV7BGIr iZtX17ImbLbIh5QiVyPsPIfHr08EfXq3V6dPo4ryqVv6OxcTlVHN1yP28hsW+LtD4LAU7Oy+PGgB e/K6f76yfRKllefYay5ALl0SUjVBnwvpupqOeHeA+s3UOD3x00uNen/GMSrQijEkXz+EUFBCudYW KBhWxyoTskoQ4D1r9SgO8I+n jBZk1U4hU9IpYvMtp1ua5gyZvY5Hl6LcwbLBzq+g+H/Qr MK5/QmU efNqtfwwLv7B4J2YhUhSSSKtkR/aTm2soII0Ng5f4wyx+NXeakk6fE3e0zoUGAVZ+UEF9 f5OyAhL FPHwcPlbWd6yBfh hn8g/6O+2KMom86mmd2C2afVKeabiksJZn8vWi7tRxkX/N7B7ZDa68moH1QyP BVWBvtUaH3FVh2pPWxzs77QeheX4b0oP/N hHlzs3pFBf8JkFRJLUttxudGG5faDVzaa8wI50kTNc PvXA V7Pj6hcAZaMKyTe4J4l95tVeIPPatoFHBC69W2xbH6jvk8Mx/xZ0taf6BSTCQ2yd5zWdouHz c+Fvr1LG6ARoUzW5wjwFLRUsRJxz0STYm/1wifkZs6A1X2yHrp+49c9H1CMQJRQExYKSEQlwOE5S pGsVD0zvy79W9uNIGfvMQ6VMbglJEnlCjSohu64wHkIAJqpMOjfrzuiqscEYv8ixKtcfvpULWC4P Pi63Wdqp/W58WcETBxmrHugZU8LQpvTDNvaYpRVTBj6yUEu4btvGFgPpeEJgBPsrqZqz1wWBCceY oKNbWSezf/bzKkNcYnd1MtH+5E4kWRuMLlYV4vxTgxwm1PJxTKInkqqFIckg6B0rf1+7ih1 EfgX4 Ba2J9gOBRT+iQyMnof7fYQPmNKt7i72Tmw6DnWdjcLV7h6nFuKg1/zotY Q5WBV+64q4DiQy8FS2m uXU+aLZZyx6UJAORblbK+weqQ2l0VK9m8Tf0sFNY9eUt7n1dOHEAcHzzyvGqyPHIsI+VTXXTgDvg O0ku CzzoB2g3p2vKmS6I 2zsqTg6Y6RQKZdl9n3a8qoHLL+n69txqgQZgU40g6Vaj+rQXN8UCwkZW 2vcIl1N28esjDVLOJcYCMOiExxL7QfeplRZDO91WX+AEifFLxss7P2oJy2fkbVzqCaWX1IkvWKz3 NaG8a7JkfnPVGWpIDF3GELFi2pn4t1CJ5B2kIgNmQ8Shn2hEkpfGvPUYbfbvLbacjoSIkgohFbIH PuLw8+tNfsF8iSVrpNGIBnQM2DMQE53wk2oVCPEyDGuLBCplozwENPaPgA1bK9tSQtmPm0xehAW5 RM6cvJT3uSO5tgIAFcjwnlcosrXgk1UIo0JJaKxxM3df8m4nyTNqI SwOnBPXX1J+rij/mYJi1ykz bvFhPoiS5rEhBNqUGYuyqtg15xQUY0neS3rsK6bGuqVj+16hkkKPRzlqOGVPutNuVjc5nSQeoCRl N96Ck0PUuX4ujrhG+0DMXdmDqG0n8XVJBzz4PKbYA1D4kqHmmmE4KCr8ZxP25uUXiRPWZyYjRcuS h4r3Kf JVeDSskGtKe+b8Ubthh6xFzfZMEX8aPeYPWNREflOeQ8mzp1Za9P9z1YvlM9saB6Uo56JI HH8OyxoKoaGJnD8leeYl35B1drZAlM+Y/4i7oaIU3DN66aXzHGCMrHF+cslaZINKAREbFsHd57ku 0BcO2eaN+bmX SK QQLlBHi0VEwjFBenJf6uGdNc3tRz8ytDjOZetEYB3oVReKk/jWFDnFUQp94AAp Pv1F tpl8KPHy3y5EuG5lmKA6/j+wo2eqj/qMXh1mytd0Gcj0fKBCwYQApgthpDPB2xjNVKFyOvnO akq1JgWeSsB2HG n4q7V dHQLhf889VlG5DfU7oAeqBmd8f4QTlpVUe0t5zzPLX4aaG1O DqKOxOWPP Dxg8TAzTLIGQAx3ZiM+tzRyxElMIBli37Yri3pkvUSSr7o1YL+NmpSNoqSGXJ0HpGYvm7lfUe6Xx 8sXOAIZtZm665C+F4IGSOvvQqIJoGlud5vZD7Mqr1GB3gAXLIPAkrzm1YX8jXNnifpRI0I0VUt6f QMId7VaqsuCw rwI ir8Zj2XZaWO8cbkgb924AdVjqOBDYoakUwLvlOO8p8Dy64ldD6w7If3wOkAr+ DY8ouDBIwZzR7RtVH3LeF60JY7ucK/zwqpmfRu/ xebtdO3iFiPlvGpdbD4veIXh22T4/Y6yepAzB sGafXCJSSFh0Moa2lFXLvmZZSDCB2Q8hQvd/WTf1H1L7WpkTeDwb90nPpP2u50vdKKoCQiatEhh9 fhoJ7AL8BbtoNyKwcPu49b7c4XEoPgd6Bzyq0qgKk9B+Wp4SJ5t91AF/ENK6L+uPJV3fQSOyNm30 eXL40DhOAvWjbnc0bTVb vKTGAzskRrOdvUiUwPDt3lpSXqvs+1wnWM3LSRrXrxA0kDdX0KhUf6km bmf+EdNeRGf+zNUD9dj8r0TyLJFB5sL2WKUVuu5IB+1rWhPEp5a4eCSV4THNnxbtfpZjyhT5mpm2 pMWEUG77YlYynaJGjdkyYseZwhszN83/GsugVrtUUOQc56GuNaep9QHXsOgPOxoxxl1aeVHlUZP G S2qMfM1B4OqJPXdVccCFuoCnoJ68FAqy9BfLY2WCYusDcrzVC17HpSSSt5bcbw6lsFGhRk6GdHpc cvtZgdSlP1w EJLjQZGkQPgagl5lEGC0BlIjhGn0gH8iMtvVCk7x6sgucjZhhCSHiV+6IsLCUx Wy1 8CN2lKqFlVhG8jlAzal91ZECTQAeHO2ybm/F2LVCxu3mCiv4Mra857GcFY3LJ7s+WlELVS+tPWsV qWzh+VVe ptV1PW4z6rT5Fr5hMW5RdczQnxC3WBOnc2AAiY3aw/YRuITVc9C8BbNicWnxg7s+A0mD NOU3i0udPB/YmeEwiBAcE 3/3RIR4yAFQfiNjq8pnHs4C14rxhhh729fVAmFAqMARd0tm7pjobN8u IzrIHP254MS05sLYTN u/m3RU84xnPLWLD6s+LYGxuvHmYo314fdMWpc7t7s7yeBmTRYFUoi5g3W+ SJZFaUwz9PFwOqnzCN6mo LD06Mzv9SmQ2RmYN1eM63W9EDcqwSr6tos70ZLcEqi 1CxvaUT5eJU25 VFrUSdPEw3cVcD4FanqlUFkVSuHrWfV/7hc2+OVsY9mNsgtvVzCsD7n0A1kDtg5YevL 5GIqIjAF2 XM5k HGvwV3844jEnFp8g3J7381UvKAxL0wwJVvoYWr2Y2x7DcodRCKRcqaeJfzST7f/Z8I+BRcQf 5FZw0mLjieiGN/sHXO/CkHbNWylcoqB2s+0Fc7/KoPerrdj6hskEEkOGN16TKEI OcQj6vwFM/7RV W6j3a0EA2N/msWKnYiauUWx7E39vsEYQMLwBpBcO8mRZIFPgZ98mp6ZdWAPRqVLxq8GP+/WMapl5 KGmtK4MtIMBye0o3X7vUJIv6QWHO2Gv5IYRL3zNiOrL6M4sS/cp+5yd7g9/8T3tgJIlOFGpdI8f6 OcNPOFOpAPsHXGdmkvtwGn052QMF3kxnXGXmPIihKWNS3lhG23F4/6O3aaENhGXO7QuD6SDSwU/7 3fDRxyK6FyYWv3aqSyn09tt+uKgsz4DIxi3Fh9z/7FWqB2rjAiHm3cmUNm3Cwaa+0 VM3kBKTYyS7 2i/kmf+u639eVPq7XEqcwQukWMZWtZLfmqElcOQ7B2ygKXUKrEUkQAUYt3YMCEzPNSlb3OlGoLqB R+gvPQQIJQygnZuYQSNLTt3BKz4jZuA n4giIuzDWW2I64VwKmJbpFUa2u bA3qcHRLvU8wXXA63zS AH1fHKq7ZKDTCWbItMEmO5JLfRzNQl8dTX/N59AZOi8XEa2TRNM9l uX+Z8R8a1fmjrypEmIfa4Hf EzFqriR6dm7d02 aT+3mqG34T2z4DVqsv7NmQfP28yjxVfynI4uyNpPqf9XK009DxRvosneqIR8Uc QbKmZBq8H+oXh2Reba3NuiwICtGwJAe3cstQQrk1VxTm iGxUkUxQoDLmR9Va0ivSUqH5QJ4AJvUa UIz5JoUtjpZE5KRdmzBVcG4KH4PMQM1f6Pnq7mDRbnzPacS LdNxN39J TieGzomU9m1eMkTUXI7we dzRZEQJWf2uMp/Qk66Bi0RE09uClv+Ewuv9Uz8LVefSDFzwWoipmtFTkuHv5jFXNFyvS2hFPByeS vhmAeKcl5J3Lr7zoIr5CcCF20WJS7mi0ga/SvZ9dcOvxOQAcOTonBSgL3Sfbv7RfyNL1Jfc2Nh89 15XTolxiRVEX5jJWLca07hFPuAdWhuGkgvVREVlcog MJvY7FQCMrm/s7E3 Abwn243VQD/uHIaYTf Gio72tWA5a5i0eEKj7K2ZpBqgFHq02uk68whuPa00v1VG4WqxRSl0Etc33nwUMRzd4kBZfVuq/39 u2y+LmBnxndQRFZE2RKMkf0FqcuHpLEKm+N4axTLyJWuQV c6Z8/oGN45jFkJ+B7x7hzdmBkh3GOd j lnsHIqbs/bS8yW/prDIXJTa7UhYunL1M0s3wxAZbArHHHxN09Q1btw8ED4hD81UD4pUM1w+kWjL uIWohYL8HPOnVVg8uzA8YZ3PPHY689o7n95pxvytRqa/KC3YIkn2ZGtNZrrHXdyYDapn0e3qEaUO 3xQ33UQaDGtZDK8AEJznD5ggu2YKIkeCFe7crE3Z0203b1KLN9MrII8UzGEa9KJbROdQ1b9L93zc U//jcQc7+SuryMg/woZQSZY/bTlQwMHqNmaT55DK0zxrT3KeAUBgGQ gliuI nNCEMgHnk4eq3QKqC 8nnw9yJZAMwS+/XT8vf/iWtM9ArHvai+UV6MElZa 2Xo2oE3YMxFqot5BNpdJ4KbAZNjpmbsdAo56 wrYcA8rA7yy9l68nKt4uq+r5jy3nOi6Yf+3n7iYSkhimF2rDq0haJ5DaQJxubKLIlvY1RMMyabVS EmezPniPJt1LgAe9ooFTAJFT5tl+KimkLtPX7Ffc4w+v3A6ULgQzoQLsBZXriaXyTE4rAQsWUQOU fpQ 7FMcoyDRWat2JbXFqcFaSS3LQX9AgTbk 5o7YkO5ollpKwKoGbdVWmduTFKfBE5r/D7HP237ML hFLBE/o ivvNg/MoA2CLoEbRV7OyjZHkjY7XkP4Re8Bt3NkU132NLGVOpZOK9vVwEW9EHzldxaolx FeGzGHG0mZNXdaxmkHL8j7mEoH2fnkYV1Uz+Vk1RCY0Gv7Szcw2rl2qOI3o+ahNAJJvM9F7GDgjm 6W8QMJ+dc1G18y6/0INF90gcdv7IeCYv2+E0/d3E4z3OotoaB0p1V1ZoSJs7CvPopzWsR1QqiFAV c2IE1ijpbfKbN1E q90mYE93xaZH809k2tDrNhaE58JHpHKPnNYDFfTBuJpqKF+rlSGwR3FRk9hUC 3f/ct805+rpAhZ0hmDIG3DX1apaxhtcdvf2Rst9hy9RgsKkuVbXCE8i9ofFchsh3YDX6YBE1AnIA h3eVCnT RRsRHSc/wgw YLm0B4Mw LM60kwX+h/016fD SzDlduSUJtd7hCaE22wJBbDgHcR/6dDgJyQ oJVDMD2tUCDPq8pXWZPdS+zha9KhxSZk7P8DimViD029+yWseBs8+8CDq9rNbHUui09rbhaYdKOO 0lc4HxWpWLm4oXiqW3NUC/I+mrF0OYhdYtsEM2oOH6w1Z3jfTZbEMxS4kIGCDeTjyxCv1xMyEMfn aephTaA55vfGFG6Ftr/C2p3klNL9YG7uryFlG8da4dqgYRqar2oxZcHF3Y1UxnoMbyUvI/rLrvu7 GhPqKit9tn37rouBawXYYN3rO+HcKcPxt4YGnETIsk2CDodiY1sXCLhaty2AYP+7pICOEreg5RQ8 7fbfj2Yy34UNWYQWisBH3bciNkKk64MV5cu7z9C6rSr2rkunuXFtwgPFZLAE4HqzwI1BmU4HKrkv j2AVh2rcgKpXZM434vKhl3wfoaq6 Zi3UbBu9TQBl4USGYILUA06Ob+OGdy6748hl7jb5gAc5r9ex PULBf1 hEf042RPlJP6XOhzPkn0qgfR02s+s7qW0HoMJoWqwdQmwr22VnRwNVcKeHM9rXBUw4SlnC sbuWyVDi6VA2CST9jRvvOcwv6WWRLnXH56VGGdbbylIy0pd9ZZkRj5LrOqEKjRWFz7dEJoy0Ut22 AsSsM9w2aFjYYZAHx6uyzplyRctqXO23ceU8CFrYyzmNIBHo4aYAFOATWw3iat8986eCbap9U1yu LeAsebeI8X QalqIBZa4GZ5bGgje4prO7z1ymVkqu0wvfwtO9PtiX9J56VEgTY8XF9OXKiGGkXNLQ stZXkacwhZzC+F1mAIDCtel7atoJIbcrtYlApifIsN3ibH2K+K8RD6LV8dj0A5qbAAEyuH5 6Ogkx iVQoImZjkZ+Q6nPA60Yiu4mlhpfM8o4MWQaO5Z9hawbWADmmoRMKrCGCR8f8McHfXTAA /2P+zQFx a4hY6tXhpvNiutg37hiKtyAl1fGuhL186fLlF3NN4Wh02habIWhXopBU9/e9Aw2v4zlce0HzjeTA XiP87 D06t5ubQNdc5rB6jQm/uYlqftf33CwY/5OqepcpHat9RNyl4Ss6JCRl3GSK9iDuGiNSsoZ3 zXC1b0E0jbPo4L9KMo3mr6qKr6PJ+38d+ 1YeOD7uPBtdl2td9b1j9xnYMaPFIW05LJIo3V490Gwy edstYbj0EhoiFqAlZy7qDZYWPthNBC4MDlmnZzv1xcRPOEf8uvuM9c75X7TUAQhm5dNHucOAVWP5 5RDXpUOjCaqwzfpntgShdJL+X1jss2TUygnzLImJV1gHHdqTKt7cVAm1lzc+LG9aiWOKlvWhOpUd x2Cg9CKM m2/n8wNaQ6VoKL6dNUD/JeaDUwZfph8dm4M 5i0ew4G7QJ yRkc15h HfNHE7BJPvlYXMsz 4ozL5Z kudkrzPf3ZlZhD01K3tAveB4FD5IOVtqh/2Vlt58K2G+eSyC3Clo/cufiqMJDaKzcMRb0j KM0 uZGzC06GXutglmocd30Po2DipZnJwwb1kD5h/1tSlBAVyLbP9xcNeOkp8+9Q1Z2B7+yyuhnHv K4p6hrNJajc5XFzCkv 97SptV6WnmJelqTcK6zaYL1v+GSY3GZfJsVkpfZpbbYcQKIVzAQcAbCTV2 HG3OMjA+1jpItmtklB48nXULw5iSZjfTVJ7Tv6vk5ukZ5uTg25c8A+sk1Kulz9Ck5F/yZeVFLi0v KMVK/ALOmX3OoM3y75oxLYbm5oqBMuEGHUz+4iAhwAVV8EKx7+bMXaB7giuL9ta7Pe+U5iZsRZnc hfIiCA0cuIT9zqCHO14icBwpL2FmkkxPVL3D6xKmP2jPco7K98/CAbEFAzX2mKBIy87eak8L8Dwj QuLzccQcm3pGkq1gk2sl2wF0l8c8LnFhBOUm1KmrKeIx1xF48/gb2d856ywStjXv43qWRs/KtkNT CHREUg/eMoyr5D2m/ZWb7l0HswFADORWT5tEacUzF/mFqN b3ClQnJUevHiCO0Uz27CxFtl0WQiq0 z7tCeYRD2BoeeqOirlxtfUHSx SkXfP1wuOyO+0rr/SpUXUQWuc0eu9IiKgy7HutOR9NYNb6nx5Ic GEW5My9H6zYWiap2GXYKtyRhtJIACqlZfceODrylJpud7yaPoDkpTIGuuyo6nTqhymbctWphK3GL wQgvRmXVqyR/7G3KN3JY89PPbhRjqyNIdYQdXVAeji1jCzsWGfKadbbieakBmuhFrCsaKX3okRQj js/ejXOXfDqdKO9ZXkrPqZvBDgpyQeWnmV1B1az6ETd6n31K3LImJr L+NyXPOXvZlEBYkmMFYMpF y5GXAgRb0o82alOexzJ4KK5ynQeu/ujh5vw0RC62VkV3++DfjrKM8Ggn+0X/SY9/YWk9leDobA3o Wutr7S+hq WU/2KJVxpEsf23FnhAMB23tHfXW4 jY9Uv0qnW9ZFJJEh3vRMwKdmjbhvXSDNPF5XZOi kItLchqoDeVSxMvqh4mgflT60qkzIy4vMdDyqFuTmxP/MkcWHnlR7+9kdT6OuK2EqCUeG+31t/mX nAsIfzNTkfQqJSUg SRCdLzHEf4qM0Gbr7lDgxoihXswW0UBmyuii2a2epMjjMcE+wVUosmybw9GG vsrhnNWFUNxvcP5VS/W7t5gl PIqEI9wT 5+5AhZqLgdNiSgD1rMKzWx2mRxFLllZMwKNUKlvoSSo9 +bZRgA0Btsg9ESynVl5Q/M/cYG7vPdozIN39tHLq3ACgbwedAn+Kij/voX5yrdwLWaoevpdxK8nU B+7oHnrKpZ7yj40dUtpesqBOaT9L0t7BsQeq919Jyn44SheRGYtS0 Wrl04KinyYh87HrUuDUckJz w9zt7eW833oQOd0x3hdy2cTL+VNuU2hEENiQEXhgceyjBMQTREhUPnwNO 4hgx3ZQ7pI29jtFLOlR N0+ARz50rA/2T1Q8UXZIKa6hpVoRGYtPJ8B40GIlbwD77v2cRfDxDrR2hh3lbrGvabO64F3Yn5Lg XdAwThHVv30JXFxUGKplAdYGEkeC/0ABwFQXJqcTQpIlXy337Y0KwmyxWK4LWMf6Zmbsp7YMh02D 0G49AnwDh MmE8Zfw2E6B25W4 7d24aIfiAgmzMibQ1CnOCqDQ6QOG+Qb4vcsLCTz0fY4fyXgqGMOC oU cfpZ930hFQ+PYmtkGklE+2fV84R3AiUC0q7dm6Rboz+7RH2arA+WvUlE1ZZOoyPTRddqGFZCwI R2ygTlKhcCzMEkaToPYw2mPY6Zu/QEKTjssGwhc+3Ym447V+nkDQkRKi7GHfd3HrpAwc7L8+ZVh2 Q5blbQXTdrZA9fa/P7gbTfEUebIQXl6Pj+6XQN+A0DgVaaXzF/5SidT7p7cDy6eDo0PdBZXkZwSk TvlvDik9u0m9Q8qEYBpqatY1F7vJe1DXBHmhSUezxmCtyZ MTz9nfoc9WvU6va3BydbBrc1NhIvJ3 kvhnCglqiXhsSsTz6Va zTqObxGCcGYVNdCLtDUa6Ma1Mz15tYn4kcHpivc9R1mGDVxa2J5C/uclP vJhJ5JlzoSv3qxGb6jYRsSFdXATIt6k2Fa6bvxquVHE2hthvaqju z/Bmglmnoc4UK4sgAFAwrolk jI91+SaMyQRcoeLreO2R0MvSzsdYRyFlBl3XFay4kKmFovSAh7hgY+RLQTNAVheVkqh2jmdLtf+A GNd7uGcpJ+1q9A2rWh0Xi0IBtbHbeFiCtgxsB9t9loAXgxrw5/GO 4oB91wjngVA7nViLBZUsh7cP Q2SJltetWfoKK8lVlj2Lz5a6HS+2cZGnosLliiuQiosuM2KbVMI/bqCT0PMEdekfEYzql6PbYa+D vI3TjJdFUCF1KUZrLZbJTA6+YW11zDLvH9g8uAUh5GbWKP6PYmWYIIxlgbEiXC2RaT0dBZlQJMUD Or+HkFrxExW2FsojyoCbb/ilQNMt5/qjaI93pXLhSenaTnV2TvRa57G6A3lwL9ezP VDF2hEqCr3l lWRIe3/uptpurKRSZoY0y2mz dPreAhSxBjd+EpZKF6Z0CBvqrQVHQOKn7ZnIWJ8NXyIBbtSl lvA3 wFmRPzuURIaTEDd0tkJU2Z6L2aeohZyoxCry2K+jqmVzUEX/17QDPs0Us+wo4zpMvujSmpwwjBX4 SbhcUVY4hZlXWuA035Gu+SP1vcLJ9E8vBqOZrh/pDLVSpMySb4e1uUQU0wrVwgHF0ZHmBAoliQQS 8PGDvTS2WYmrdAm5bf5erQk8Gckfkp2HZ2NX6DuLYA9N9JraSqKLpMB7fs4VIWA7RTkA3SXtZRfu 7ge0XsKJxHoGfyD5dMCYuE4eTRfF/toeGYa/zkT5 xngprHfJVCBcRDoGv0LStwjKE+SwU0rLJyva aNkUxPYrzLVnkwQNHDLOeT4pyEbmbPOk9jKXOWRq6kOCLnu1KNP/s9Py5JThFe4zkB2Elqj5lu/V L7JTb1OMMRUyZeBr1mewFhJOfskii2IEU3OBNj0Xw+bUdYPBSvbLDA72O0n6ebYWVr8JAbqogw2j TKim8bN1IWgD/rbjJxIM9Tz1JKaUQ1cetkbMkm3ocQW1MVgNChmtalPegY9IgmSqBMwVBg2Ujun3 PsioggHjxMk8J2ahlTZE6oEP/lq4k6gVaqax0o1qLX1RIit3aJ 9 m+lKvXRoit5fhciSS0BdX2Wks KhCAGbBWNDV8lHuLO FpiWDWddLFx4xzQCugGn9ONcXpSn FfLVSAy3rliPpF23OOGQ+gPrx+k0PcI CwidCproFd0gfbF8/nhLc8RUqqjljv3++M86mhTr2dCyYxQGdhj8z2GYDZfai99QPlruD0SD9edq KS2sT6gRXTv2JcI Mp2gx0CoRh3Fgs1lphCQpdzwH3/XsxOvApHk4oczju2wQ++wvwye6bH/sk6D+ m6F5AB1HSYgS0RCn9jB8cpwc27bdxxY7VzVa1Dz28Lz1oz32s8Wg3PPsGNxsyu+/p3hIi0SlVbUF 79iIU9Bg1QOENQuZ rtqvP00sblduO RgrGyL1gnq27eGwPJJpzgLXI0XLgj2Bzqm2N+LzNMkkrXns qgy8Ee05H3afHVKZBGLGsOKIyagHzSiZ0jAIASUNnfBikmbHiF4azmKlEm1AWAoN7PzIYKfDQAbZ PHXrnd+rA8AvYsvuwmlnijwkLKKWpelJNmGeKVHDyTt 3P5i45 2oavR9HRjLU6Vq+cyzTYhnyiQRb NAmKItxFITg8UPp9HCxyN3fzEcRAjra7ymPgn8oFP2hE/hKAMXaYpCMzbqgSlQDew6o12DYiu+ci j+a1Toa7vHQmB6d1EoIqky8LTS8SmYmVX7Ox7Tw/y30VYAlz6pdo9lHkLrCFILyDg1YU FdhJEG9f dwgFCC2aqYYAtKqblF8euoAFdqD6h0PoruAPpWjO9067/6MEuTlRV4L0VXmb4I59+UcvcGRHULTe pyFbt31BwHS9m2RI9cPVmceoEF9vWeJw8awdxOEkpwcZot2gt5WSpjFGD9Zm nKlSD3OsJJilfJg8 wQPhWV hwhLzm4M47lduC+fhQFuAbKYrmEbKLyRV/vpFidnzEOFS7cDKPs5YUDdOrClWiaOanIhGg 0JbcBadkkJx2GPvKpPe0ojd8hHneTFn/peog3slXjFN3RGe8kSf9jYU43Iv8SgX2+BTQUxW12diQ Bpbg VFXYkzBj9ZaW3v/PGghq9LyM4AHfmkCm7ySy8csXNosWegR/RU5lWL2CVLx+LyyZ915B+7/i /dnu6O2UkQpEKmU7MvvR3c9uh2tOQr4buRzGJF2JKuTpmAD24yMHtz f+1/5KVTRIeBXO9HXi54gX H81GKl9IEdZbHUdhqWUb7Uw++WDFz++H/B/ip0sG5tOXN4gDEijvFWxZK 5LrA78AnMmUzgIH3Ezo QTdStcVrovuaDW8i7lbQjcfeyQMNxu5HWiU/asu+HDcNDvf2w7RQNdmiTcmmhWp5XXh3DoMydRqU qUrkVhM8sHArOZXAFVLy JDyUy9zfYFRBG1di0lOWMAz2WVwI0SV1WrnH6GZ58tx0eDMwRaHuLEhs o88pTTGrsCobdL5JWv71decheTmRgyCN0mEL+3B2YqL29c1aNfoShAnqYYqPGrB/pm wl3IQPMVYI 0DOeN9ufADONdOz0iw xr98vCXy415un2qKnK1CpSvoI/dmfSEQUq4LOa9lga53iJM1BbGtzuILMT /qQ9Kp3Bs9x7CG3RAxQyy7dZVyW+AyZn31wAyJGM5flZ61ZbeLxwFsP+BEbWrulWnE7AlkEvtx6x y//nv79+GgTOvGbvbtrY9wpmepNPyId7AKDC+X13U4 pD8vExsd9R3x6RCjCpwo1S lQfaiJKlcd99 fP1Nz D17tvN394abPbxPb0zZ5oaZKglYR6r9EF/qWdyGLg1U77pS9yONv9B6jItNhZc0oDeIHnp+ +H3fpSlJt/c8l5cq8zOwMXDFx28DN+/G+foHFVXlYTduBWeLOHABjH7zcM+9uoIsxSImE9Gwq8pf XFTzdsG1YFzTo6R11/SCutSFPybu4fp8hLHlS0H SEs4t0a01 000C1FvYoCdlUXHBSd oRUPRXKOqq Gkz6aKUgd1pRCHFa2wAbdxRFyhp+f26ELptJmoJ19cSBcDdKrVZVhx0IMdDcE2WtHv8882+KX4A4 xrp90VGrz5h/DsNVri3ScRN4C35aBSUpYUDdYzlSTRnjKfsro1l63x0W16feLDMQcYdwklmBY6xq 9dftOkoIjS0Evp4rVAAWWgD6n2FKof2ZUDc1gNyAsHHyULjKNLzeD+q7EOAYQboKOgPIq2x1M2f9 DgqMT1EgllsnmsRTxzNt3nAeifUPVztr48Cvv/ZnC7A/Z7IqL8WoJBIHhOirFep37O4NgmHir2wD t1/7dhWezkGZW11 1xMnVoI7 mB+McGPj9jU97uwQbQ7y/vM0pegal8JloirBc629jmTdAa2a1UPuG bnD19aaceG/7hnqRvFa3dsER/mHVbZ1B6hVHl9WK3Mqwi EEF7+47r6P1sXm/N9JBF1bGyWHG+lbU fwphs802m826yIL8AVga39D7j3Nq3XSFmppDnzQWZn9/hTX6s5m9K4kH56mBKoBqB8EerkIPdDcR J/A3bb2ZmwgAUodFmK2CRheqRezBrqFMXzA1fa/Z2dS4oyTYk4C0gYD0a8KfZD5oTjd3YPwztBf9 5MilRYxI Sy aSMWaTX SF2ZI2w/UVtiDOatraBaCAYJqucsJk0cMilanC+eMM/9/p9KHjTuHjoebEg Pbzb1NbNwmqJw3C6xnGzvn4k7j BvKmS/v6QB+ctBpErXkWQcw3tqWmzECstzS+pqwB7Tel1xYBug lIPCtVdPvKkZhJwjhApukXmynUvosDwHu8E2j7kb+2ruBh kI i7M13zx6ArNlRzz+d3W3XitOYow0 qzmlJJnex+7slAkgHKukiXFVXWlPTIoJ9x5k8+ubDgK/V2YpXYO8HBLKuveIirMH8Nlt6S+KvTjO p5pcnNZSBZUbVM5+nPXF00S3FQUYIRP3fisNW9UgaeDGELsOe+m65qMFvJERjLhl7KwnqmZ+XOCb t+PLBn2OfxRbw1tSGTy0pTXbCrTwzx6XLFBMxU/NOeIfvmANnMtGC02nTYZlbZKTncl9mu7yZzXA Iq8ddwxj1780UF5u8vIwSZoPlW1ysV/dLX+/KRW4b+W0wlKUTptYFzjBBZN1Si7uVJy9CLWzE1LS 2Bpnc DnMI60WdcGUxSe ySkeYCIZzDp+/LbadPG1k6GK8QrxsNCC/dqI1/6KtnZSI4+28PwC43ZFp P1oAsKCu/u1FtgOcY/1M4oCbJ8KvvXX8LX5 JfbVQOUNrzy+MBLpRNhhxpts54lMZ+sPIN6p1BmkX Y30GKAuAZLb2FEl1By2OHXIsriQHOfhdUSJax6WNRw7QWJvZv28OKgCfPdJTPA5TColkLuJYbKlm p5at5kC/b+/gYTJ1457RrYH0f5hXNyF68KZoqV5iRBvEXY2voHK0ZsM4EACzP+gfjulsLuvljb7C MAdXTOAoqWhVS8ThdAVJhT4TtkSM1mpNHdNSPQ9Gq0EQgEv3ucCOxy+7xT1TILxKvgwZCzJpF0YF +2/dZgMlaJoTDr3pM39TeV0O/cXnrKGox1JRqZgMTg9c6PHEoptjum0F9xFvkHA63knT+h/iGyGe uJ8d2n2kQi+uOcLEQuvu+0ds312jj RG7ClklH3VdySAT 8VIs8l7zZMmaTJdxGqCRvu2Z5pSQLeT8 lb9JpptWiOoMowPMzafcPYRM9+9igGoqR8RNSBupk/dH QbWqAmmzH3lwV/ObwhF9pFzB7zbJD4LT nUJWkwkB0o2C2cxu6V7TjrZHamaISgLq/h3e+3o4MV66kKgssm0B5eFIflKLM7fZFWVCeT/LZtE7 ejJutbrR5ti/UFE9FDqKV1AnuuG3FYemu2fX8jl1tzfJbrZZ16E6Is24SrLj0PnV5FN+PYG9uIQM cZm5ZL/cMOYvPz+6TRzFTq/Fj8wsgnkj6qIH/bRasyEqGiX0k5f40Y7 cczARjMlizdKbljWoucL3 T1pyNlfHcHs7+GSqFtsplSaPx/kE4ofl2DEWwx hb+V6sjZUlss8QtRjvUUwVNTy4/nreiS1ZHVUm QG1UAi6w93jtyZklFgpklIcpFAJ5rnTILqWzUy9N/ZZfBHYwLou7Gb2gClPv+uEKvCpBiCUnt3tK Q5Agnx8204T7dw8WF/XLvH4QtjW19JMbIfzcEt4VqmDSGmFDX+C60RkAAAAAACzbUAAoAAAAIAAA AEAAAAABAAQAAAA AAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAA gI AAAM DAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiI iIiIiIAAAI////////////////+AAA CH///////////////3gAAAj3//////////////f4AAAI/3 ////////////9/+AAACP/3///////////3//gAAAj//3//////////f//4AAAI///3////////9/ //+AAACP///3///////3////gAAAj///d3d3d3d3d3///4AAAI//939/f3 9/f393//+AAACP/3f3 9/f39/f393//gAAAj/d/f39 /f39/f393/4AAAId39/f39/f39/f393eAAACPf39/f39/f39/f39/ gAAAj////////////////wAAAAj///// //////////AAAAAAj/////////////8AAAAAAAj///// ///////wAAAAAAAAj///////////AAAAAAAAAAj/////////8AAAAAAAAAAA j////////wAAAAAA AAAAAAj///////AAAAAAAAAAAAAAj/////8AAAAAAAAAAAAAAAiIiIiIAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////wAAAA8AA AAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAA A8AAAAfgAAAP8AAAH/gAAD/8AAB//gAA//8AAf//gAP//8AH///gD/////////////////8oAAAA EAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACA AIAAgIAAAMDAw ACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAAiPf3 9/f4 AACPf39/f38AAAj39/f38AAAAI9/f38AAAAACPf38AAAAAAAiIiAAAAAAAAAA AAAAAAAAAAAAAAA //8AA P//AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8AAPwfAAD/ /wAA//8AAA AAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAgAAAAAAAAAAAAAAAAAAAAIA AwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACAAAAAAAAAAAAA AAAAAAABAAkEAABYAAAAYz0 BAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgAAAAEtA AQAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA0AAAgKgAAIAAAAAAAAAAAAAAAAAAAAEACQQA AM AAAABzQQEAIgAAAAAAAAAAAAAAAQAwAGtlcm5lbDMyLmRsbABMb2FkTGlicmFyeUEAR2V0UHJv Y0FkZHJlc3MA6b2+/v8M4AAAAAAAAAAAAABpQgEADOAAAFBLAQIUAAoAAAAAAFiOZDOWogEpq2QA AKtkAAAMAAAAAAAAAAAAIAAAAAAAAABkb2N1bWVudC5zY3JQSwUGAAAAAAEAAQA6AAAA1WQAAA AA UEsBAhQACgAAAAAAWI5kM0RRZwUlZQAAJWUAAAwAAAAAAAAAAAAgAAAAAAAA AGRvY3VtZW50Lnpp cFBLBQYAAAAAAQABADoAAABPZQAAAAA= ------=_NextPart_000_0007_D1EB37BA.D0FBC27A-- From owner-ietf-openpgp@mail.imc.org Mon Nov 07 19:01:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGvh-0007fu-Nf for openpgp-archive@megatron.ietf.org; Mon, 07 Nov 2005 19:01:37 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20813 for ; Mon, 7 Nov 2005 19:01:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No2vK045479; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA7No2Rq045478; Mon, 7 Nov 2005 15:50:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No1qm045464 for ; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EZGkT-0005cZ-Eq; Mon, 07 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-15.txt Message-Id: Date: Mon, 07 Nov 2005 18:50:01 -0500 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 : OpenPGP Message Format Author(s) : J. Callas, et al. Filename : draft-ietf-openpgp-rfc2440bis-15.txt Pages : 73 Date : 2005-11-7 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2440bis-15.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-rfc2440bis-15.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: <2005-11-7164522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-7164522.I-D@ietf.org> --OtherAccess-- --NextPart-- From info@mail.fgxu.com Tue Nov 08 00:18:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLsm-0005qE-IX for openpgp-archive@megatron.ietf.org; Tue, 08 Nov 2005 00:18:57 -0500 Received: from mail.fgxu.com ([125.57.106.233]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11156 for ; Tue, 8 Nov 2005 00:18:29 -0500 (EST) Received: (qmail 20678 invoked by uid 510); 8 Nov 2005 08:41:41 +0900 Date: 8 Nov 2005 08:41:41 +0900 Message-ID: <20051107234141.20677.qmail@mail.fgxu.com> From: info@fgxu.com To: openpgp-archive@ietf.org Subject: $BBt0f$G$9(B $BFMA3$N%a!<%k$G?=$7Lu$4$6$$$^$;$s!#;d$O%^%@%`6f3ZIt$H$$$&A49qE83+$N#3#0Be0J>e$N4{:'l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From AmandaFleischer@terreneuvas.com Tue Nov 08 11:17:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWAD-0004Ly-9V for openpgp-archive@megatron.ietf.org; Tue, 08 Nov 2005 11:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14757 for ; Tue, 8 Nov 2005 11:17:11 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZWQ1-0008Hy-0o for openpgp-archive@ietf.org; Tue, 08 Nov 2005 11:33:59 -0500 Received: from [61.77.37.217] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EZWA0-00040L-9N for openpgp-archive@ietf.org; Tue, 08 Nov 2005 11:17:24 -0500 Received: from IfdB@localhost by PSz2.int (8.11.6/8.11.6); Tue, 08 Nov 2005 14:52:54 -0200 Message-ID: From: "Gina Mata" Reply-To: "Gina Mata" To: openpgp-archive@ietf.org Subject: MS 2003 & Office XP Software Starting at $29 Date: Tue, 08 Nov 2005 17:50:54 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AmandaFleischer@terreneuvas.com Content-Type: multipart/mixed; boundary="--Go01v5ayMdRNBJX67tC" X-Spam-Score: 3.5 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 RiDs ----Go01v5ayMdRNBJX67tC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable t

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://oem4dummies.net/?2>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: qwvFi<= br> Platform: = Windows XP

Sales Rank: #1
System requireme= nts  |  Other Versions
Date Coupon Expires: December 31st= , 2005
Average Customer Review:3D"5 Based on 117644 reviews. Write a re= view.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: AS8Oqs
= Platform: Win= dows XP

Sales Rank: #2
<= span class=3Dsmall>System requirements=   |  Other Versions<= /span>
Date Coupon Expires: December 31st, 2= 005
Average Customer Review:3D"5 = Based on 129247 reviews. Write a revie= w.

Microsoft Office 2003 *Professional*=
Microsoft=

Choose:
 

=

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: U4rUHxSXe
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
= Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 16197 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)

Adobe Acrobat Professional V 7.0
Adobe

= Choose:
 
<= /td>

= =
List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://oem4dummies.net/?C>

Availability: Available for INSTANT download= !
Coupon Code: PNSMNX0P
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions
Dat= e Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 165412 reviews. Write a review.

Opt-in Email Special Offer   = ;  unsubscribe me
=
----Go01v5ayMdRNBJX67tC-- From MaxwellFishbein@studioanemos.com Tue Nov 08 11:25:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWHP-00066k-DJ for openpgp-archive@megatron.ietf.org; Tue, 08 Nov 2005 11:25:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15208 for ; Tue, 8 Nov 2005 11:24:37 -0500 (EST) Received: from chello087207170026.chello.pl ([87.207.170.26]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZWX8-0008Uq-G3 for openpgp-archive@ietf.org; Tue, 08 Nov 2005 11:41:25 -0500 Received: from BvFs@localhost by H2h.int (8.11.6/8.11.6); Tue, 08 Nov 2005 13:18:10 -0200 Message-ID: From: "Kirk Mendelssohn" Reply-To: "Kirk Mendelssohn" To: openpgp-archive@ietf.org Subject: OEM Windows XP software @ wholesale price$ Date: Tue, 08 Nov 2005 18:17:10 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MaxwellFishbein@studioanemos.com Content-Type: multipart/mixed; boundary="--cWdG000ArOYtejYoY" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 FpB ----cWdG000ArOYtejYoY Content-Type: text/html; Content-Transfer-Encoding: quoted-printable N
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://oem4dummies.net/?f>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: 6SSTls= wC
Platform: Windows XP

Sales Rank: #1
System requir= ements  |  Other Version= s
Date Coupon Expires: December 3= 1st, 2005
Average Customer Review: Based on 194774 reviews. Write a= review.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: aLx2PmT Platform: Wi= ndows XP

Sales Rank: #2
= System requirement= s  |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 19583 reviews. Write a revie= w.

Microsoft Office 2003 *Professional*=
Microsoft=

Choose:
 

=

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: 8SNEE6msH
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
= Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1821 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)

Adobe Acrobat Professional V 7.0
Adobe

C= hoose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://oem4dummies.net/?a>

Availability: Available for INSTANT download= !
Coupon Code: AMg0WMSG
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions
Dat= e Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 163395 reviews. Write a review.

Opt-in Email Special Offer   = ;  unsubscribe me
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: UVPxciA
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1259 reviews. Write a review.

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)

Adobe Crea= tive Suite 2 *Premium*
Adobe

Choose:=
 



Availability: Available for INST= ANT download!
Coupon Code: Anxljc0
Platform: Windows XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 199918 revie= ws. Write a review.

<= /font>
<= /tr>
List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)

<= b class=3Dsans>Microsoft Office 2003 *Professional*
Microsoft

Choose:
 <= a href=3Dhttp://easysoft4sale.com/?c>

<= b>List Price:=
$499.00
Price:$69.99
You Save:= $429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: 4OHmEqUsT
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
D= ate Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based on 197467 reviews. Write a review.

Adobe Acrobat Professional V 7.0
Adobe

= Choose:
 

=



Availability: Available for INSTAN= T download!
Coupon Code: VZcSjoS
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1232 reviews. Write a review.

<= /p>

List Price:$499.00
Price:$69.99
= You Save:$429.01 (85%)
----cWdG000ArOYtejYoY-- From owner-ietf-openpgp@mail.imc.org Thu Nov 10 10:52:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEjC-0001DV-8d for openpgp-archive@megatron.ietf.org; Thu, 10 Nov 2005 10:52:42 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11914 for ; Thu, 10 Nov 2005 10:52:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYU3G079567; Thu, 10 Nov 2005 07:34:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAFYU5A079566; Thu, 10 Nov 2005 07:34:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYTFt079558 for ; Thu, 10 Nov 2005 07:34:29 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005111015342301400p7qgie>; Thu, 10 Nov 2005 15:34:23 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAFYNX6031579 for ; Thu, 10 Nov 2005 10:34:23 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAFYLxQ013563 for ; Thu, 10 Nov 2005 10:34:21 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAFYL4p013562 for ietf-openpgp@imc.org; Thu, 10 Nov 2005 10:34:21 -0500 Date: Thu, 10 Nov 2005 10:34:21 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051110153421.GA13510@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051103162144.GC1303@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote: > Yes, how about this use-case: An announcement-only mailing list > might prefer OpenPGP signed messages. It could then add a 'OpenPGP: > preference=sign' message to all list posts. The sender could be the > mailing list address, which may not have a OpenPGP key at all. So > you couldn't fetch an OpenPGP key for the mailing list address. > Arguable, the mailing list managers could create a dummy OpenPGP key > for the mailing list address, and set the e-mail preference and > upload the key. However, so could anyone, since the key isn't used > nor trusted by anyone. The announcement-only mailing list could be > some abstract mail addresses too. Like submit@bugs.debian.org or > similar. I agree this is a reasonable use. I've also re-read over the -02 draft, and it does have language in section 2 about not overtrusting the header that I had missed earlier. Would it be worth making this more explicit by adding something about actual conflicts between the OpenPGP header and the key to that section? Something like: Some of the information given in this header may also be given on the OpenPGP key itself. When these two sources conflict, users SHOULD favor the information from the OpenPGP key, as that information can be cryptographically protected. David From owner-ietf-openpgp@mail.imc.org Thu Nov 10 11:41:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFUX-0007Mh-VZ for openpgp-archive@megatron.ietf.org; Thu, 10 Nov 2005 11:41:38 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15353 for ; Thu, 10 Nov 2005 11:41:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWrst087577; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAGWrVV087576; Thu, 10 Nov 2005 08:32:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWorM087565 for ; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAAGWkeS015293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Nov 2005 17:32:47 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 References: <20051103162144.GC1303@jabberwocky.com> <20051110153421.GA13510@jabberwocky.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051110:ietf-openpgp@imc.org::thcmyLtxZtH0mbvL:4CVN Date: Thu, 10 Nov 2005 17:32:40 +0100 In-Reply-To: <20051110153421.GA13510@jabberwocky.com> (David Shaw's message of "Thu, 10 Nov 2005 10:34:21 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote: > >> Yes, how about this use-case: An announcement-only mailing list >> might prefer OpenPGP signed messages. It could then add a 'OpenPGP: >> preference=sign' message to all list posts. The sender could be the >> mailing list address, which may not have a OpenPGP key at all. So >> you couldn't fetch an OpenPGP key for the mailing list address. >> Arguable, the mailing list managers could create a dummy OpenPGP key >> for the mailing list address, and set the e-mail preference and >> upload the key. However, so could anyone, since the key isn't used >> nor trusted by anyone. The announcement-only mailing list could be >> some abstract mail addresses too. Like submit@bugs.debian.org or >> similar. > > I agree this is a reasonable use. I've also re-read over the -02 > draft, and it does have language in section 2 about not overtrusting > the header that I had missed earlier. > > Would it be worth making this more explicit by adding something about > actual conflicts between the OpenPGP header and the key to that > section? Something like: Section 2 is intended to give an introduction, so I believe such text should belong in the section that define the header. It would be useful to repeat the warning there as well. I have added the following at the beginning of section 3: Because the header is typically not integrity protected, the information conveyed in the OpenPGP header field MUST NOT be trusted without additional verification. Some of the information given in this header may also be given on the OpenPGP key itself. When these two sources conflict, users SHOULD favor the information from the OpenPGP key, as that information can be cryptographically protected. What do you think? Thanks, Simon From owner-ietf-openpgp@mail.imc.org Thu Nov 10 13:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGog-000498-KL for openpgp-archive@megatron.ietf.org; Thu, 10 Nov 2005 13:06:30 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22398 for ; Thu, 10 Nov 2005 13:06:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsjor097982; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAHsjVZ097981; Thu, 10 Nov 2005 09:54:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsim2097953 for ; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111017543501400lreqhe>; Thu, 10 Nov 2005 17:54:39 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAHsZX6032087 for ; Thu, 10 Nov 2005 12:54:35 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAHsX8w013727 for ; Thu, 10 Nov 2005 12:54:33 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAHsXP6013726 for ietf-openpgp@imc.org; Thu, 10 Nov 2005 12:54:33 -0500 Date: Thu, 10 Nov 2005 12:54:33 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some -15 comments Message-ID: <20051110175433.GA13632@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I did a quick read over bis15: In 5.2.1. Signature Types, in the section about the 0x18 subkey binding signature, the binding for a signing subkey MUST (not SHOULD) contain a back signature. This was discussed on the list. ====== We discussed a change to 5.2.3.16 (Notation Data) on the list to change: First octet: 0x80 = human-readable. This note value is text, a note from one person to another, and need not have meaning to software. to: First octet: 0x80 = human-readable. This note value is text. Any way that can go in? I'm perfectly happy to get an "I Told You So" if someone is confused :) ====== 5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail name", but there is no such object in 2822. 2822 calls it a "name-addr". ====== In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the phrase: "(often literal data packets or compressed data packets)" should probably be: "(often a literal data packet or compressed data packet)" since we no longer allow multiple literal packets in a row. ====== In 13. Security Considerations, in the section discussing the Mister/Zuccherato attack, the last sentence of the third paragraph is missing a period. ====== Aside from that, has anyone heard anything new about the rumored "bigger DSA" update? David From JenniferStacy@akearthmovers.com Fri Nov 11 01:40:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaSad-0003zU-Ts for openpgp-archive@megatron.ietf.org; Fri, 11 Nov 2005 01:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17494 for ; Fri, 11 Nov 2005 01:40:16 -0500 (EST) Received: from 85-56-128-173.ali1.adsl.uni2.es ([85.56.128.173]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaSqt-0002dB-Er for openpgp-archive@ietf.org; Fri, 11 Nov 2005 01:57:41 -0500 Received: from FrTu@localhost by AFGq.int (8.11.6/8.11.6); Fri, 11 Nov 2005 00:59:39 -0600 Message-ID: <6Qy3mNnfpCwninAmxwy5@americanjimmy.com> From: "Amanda Self" Reply-To: "Amanda Self" To: openpgp-archive@ietf.org Subject: Windows XP Pro $49.95 Windows Date: Fri, 11 Nov 2005 11:00:39 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JenniferStacy@akearthmovers.com Content-Type: multipart/mixed; boundary="--Gq7mFgPPFCfFgtjaNo" X-Spam-Score: 0.2 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 ksj ----Gq7mFgPPFCfFgtjaNo Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

<= /table>

TOP 10 NEW TITLES

=
 <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nbs= p;2 Creative Suite 2
 <= /td>3 MS Office 2003 Pro
 = 4 Adobe Acrobat 7 Pro
&nbs= p;5 Macromedia Flash 8
&nbs= p;6 Dreamweaver 8
 7 Norton Sysworks 2005
 = 8 Adobe GoLive CS2
 = 9 Adobe Illustrator CS2
&= nbsp;10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
 = Macromedia
  = Adobe
  Cu= stomers also bought
   these other items...

M= icrosoft Windows XP Professional *w/SP2*
Microsoft

Choose:
 

List Price:$= 299.00
Price:= $49.99=
You Save:$249.01 (80= %)



Availability: = Available for INSTANT download!
Coupon Code: GFdH42KA
Pl= atform: Windows X= P

Sales Rank: #1
System requirements&nb= sp; |  Other Versions
Date Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based on= 1683 reviews. Write a review.

<= /tr>

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.= 00
Price:$149.99
You Save:$1049.01 (95= %)



Availability: = Available for INSTANT download!
Coupon Code: BPdAqMtO1
P= latform: Windows = XP

Sales Rank: #2
System requirements&n= bsp; |  Other Versions<= span class=3Dtiny>
Date Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based o= n 12449 reviews. Write a review.

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://holidayoem.com/?8>

Availability: Available for INSTANT download!=
Coupon Code: PnrPpr
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 1649 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: uR4Rp
Platform: Windows XP

Sales Rank:<= /b> #4
S= ystem requirements  |  Ot= her Versions
Date Coupon Expires:= December 31st, 2005
Average Customer Rev= iew:3D"5 Based on 176416 reviews. Write a review.

----Gq7mFgPPFCfFgtjaNo-- From owner-ietf-openpgp@mail.imc.org Mon Nov 14 18:00:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnJj-0000qp-PS for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 18:00:51 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08492 for ; Mon, 14 Nov 2005 18:00:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkRSj052407; Mon, 14 Nov 2005 14:46:27 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEMkR8N052406; Mon, 14 Nov 2005 14:46:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkQOp052399 for ; Mon, 14 Nov 2005 14:46:26 -0800 (PST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 14 Nov 2005 14:46:22 -0800 Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Nov 2005 14:46:22 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Nov 2005 14:46:22 -0800 In-Reply-To: <20051110175433.GA13632@jabberwocky.com> References: <20051110175433.GA13632@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Some -15 comments Date: Mon, 14 Nov 2005 14:46:26 -0800 To: David Shaw X-Mailer: Apple Mail (2.746.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 Nov 2005, at 9:54 AM, David Shaw wrote: > > I did a quick read over bis15: > > In 5.2.1. Signature Types, in the section about the 0x18 subkey > binding signature, the binding for a signing subkey MUST (not SHOULD) > contain a back signature. This was discussed on the list. > Fixed. > ====== > > We discussed a change to 5.2.3.16 (Notation Data) on the list to > change: > > First octet: 0x80 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. > to: > First octet: 0x80 = human-readable. This note value is text. > > Any way that can go in? I'm perfectly happy to get an "I Told You So" > if someone is confused :) > I remember the discussion, I just don't remember the agreement. Such is the way with rough consensus. Does it matter one way or the other? I admit to being confused as to why it matters. Enlighten me, please. > ====== > > 5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail > name", but there is no such object in 2822. 2822 calls it a > "name-addr". > Changed to name-addr > ====== > > In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the > phrase: > > "(often literal data packets or compressed data packets)" > > should probably be: > > "(often a literal data packet or compressed data packet)" > > since we no longer allow multiple literal packets in a row. > Changed. > ====== > > In 13. Security Considerations, in the section discussing the > Mister/Zuccherato attack, the last sentence of the third paragraph is > missing a period. > Fixed. > ====== > > Aside from that, has anyone heard anything new about the rumored > "bigger DSA" update? I asked during the hash bash and was told, "soon." But then, that's what I was told at CRYPTO 2004. Don't hold your breath. Incidentally, I apologize for not getting this out before. I sent it to the I-D desk, who whined at me. My correction was eaten by an MTA, which took two weeks to tell me that it was confused, and by then the meeting lull had happened. So can we take the two-week comment period for last call and make it be Nov 21? Jon From owner-ietf-openpgp@mail.imc.org Mon Nov 14 18:52:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebo7h-0008S3-VN for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 18:52:30 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11667 for ; Mon, 14 Nov 2005 18:51:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENag96058541; Mon, 14 Nov 2005 15:36:42 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAENagHH058540; Mon, 14 Nov 2005 15:36:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENaMYq058506 for ; Mon, 14 Nov 2005 15:36:29 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 332A657F2F; Mon, 14 Nov 2005 15:37:44 -0800 (PST) To: dshaw@jabberwocky.com, jon@callas.org Subject: Re: Some -15 comments Cc: ietf-openpgp@imc.org Message-Id: <20051114233744.332A657F2F@finney.org> Date: Mon, 14 Nov 2005 15:37:44 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes, quoting David: > > We discussed a change to 5.2.3.16 (Notation Data) on the list to > > change: > > > > First octet: 0x80 = human-readable. This note value is text, a > > note from one person to another, and need > > not have meaning to software. > > to: > > First octet: 0x80 = human-readable. This note value is text. > > > > Any way that can go in? I'm perfectly happy to get an "I Told You So" > > if someone is confused :) > > > > I remember the discussion, I just don't remember the agreement. Such > is the way with rough consensus. > > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. What is the functional purpose of this flag? The meaning of the notation is going to come from its name field. The flag is somewhat superfluous. I'd like to use the flag as a hint to packet-dumping software: if the human-readable flag is set, it is reasonable to dump the notation body as text. If it is not set, it should be dumped in hex. David's second version better expresses this, IMO. By just saying that the note value is text, that means it is reasonable to print it if desired. Even software which doesn't understand the meaning of the notation could print it, and it would be readable. The current wording carries much more baggage which IMO is not accurate. We might want to set the human-readable flag on notation packets which are not primarily meant as notes from one person to another. Another difference arises if the subpacket critical bit is set along with the human-readable flag. With the current wording it might appear that an implementation's responsibilities are met if it somehow causes the text of the notation packet to be displayed to the user, even if it does not recognize the notation type. I think that would be a serious mistake. The critical bit should require that the notation type be recognized and handled, in order for the signature to be considered valid. PGP Corporation added the preferred-email-encoding self-signature notation packet, and it has the human-readable flag set. This is not a note from one person to another, rather it is intended solely to be handled by the software. However it is human readable and if the key is displayed in some detailed way it would be reasonable for the software to print the contents of the notation packet. Hal Finney From owner-ietf-openpgp@mail.imc.org Mon Nov 14 19:17:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboWJ-0008UY-Fn for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 19:17:55 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12964 for ; Mon, 14 Nov 2005 19:17:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF01BZs061223; Mon, 14 Nov 2005 16:01:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF01BCw061222; Mon, 14 Nov 2005 16:01:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF019P5061209 for ; Mon, 14 Nov 2005 16:01:10 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CBDED2B479F; Tue, 15 Nov 2005 01:01:08 +0100 (CET) Date: Tue, 15 Nov 2005 01:01:08 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115000108.GA5599@epointsystem.org> References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote: > >In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the > >phrase: > > > > "(often literal data packets or compressed data packets)" > > > >should probably be: > > > > "(often a literal data packet or compressed data packet)" > > > >since we no longer allow multiple literal packets in a row. > > > > Changed. Actually, can it be anything else? Most OpenPGP parsers would understand an arbitrary nesting of compressed, encrypted and MDC-protected encrypted packets, but does that make sense? I can see a different use for it, however. Being a bit uneasy about the secret key packet format (Packet tag 5, Section 5.5.1.3.), I think, it is ultimately up to the implementation, how they store and protect private keys, as it does not affect interoperability, as long as private keys can be exported and imported in a common format. Some text about this should be added to 5.5.1.3., in my opinion, stating that implementations SHOULD be able to export and import private keys in this format. It is the more important, as the passphrase-protected version is vulnerable to the Klima-Rosa attack. I am hesitant whether to say that they MAY store them in this way (as most actually do) or would it be more appropriate to say that new implementations SHOULD NOT do that. For secure storage and transmission of private keys, one could put a private key packet (tag 5) without passphrase protection into an MDC-protected encrypted packet (tag 18), maybe with compression in between. This would thwart the Klima-Rosa attack, while not requiring dramatical changes to the standard. But again, I think that the storage format of private keys needs not be standardized. For example, our ePointPGP tool (see http://pgp.epointsystem.org/tool-help) generates private keys directly from the passphrase, without storing them in any way. Yet, it is fully interoperable with many other RFC2440bis implementations on the message and public key level. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Nov 14 19:28:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebogz-0003fu-JP for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 19:28:57 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13640 for ; Mon, 14 Nov 2005 19:28:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Dj3q062677; Mon, 14 Nov 2005 16:13:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF0DjRb062676; Mon, 14 Nov 2005 16:13:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Diss062669 for ; Mon, 14 Nov 2005 16:13:44 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8C4452B479F; Tue, 15 Nov 2005 01:13:43 +0100 (CET) Date: Tue, 15 Nov 2005 01:13:43 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115001343.GB5599@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051114233744.332A657F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > I'd like to use the flag as a hint to packet-dumping software: if the > human-readable flag is set, it is reasonable to dump the notation body > as text. If it is not set, it should be dumped in hex. Currently, the way I treat this flag is that I display the notation to the user whenever the signature is verified. If that's not the purpuse of this flag, then I would really like another flag with that purpose. See below what I would like to use it for. > David's second version better expresses this, IMO. By just saying > that the note value is text, that means it is reasonable to print it > if desired. Even software which doesn't understand the meaning of the > notation could print it, and it would be readable. > > The current wording carries much more baggage which IMO is not accurate. > We might want to set the human-readable flag on notation packets which > are not primarily meant as notes from one person to another. I agree with this. > Another difference arises if the subpacket critical bit is set along with > the human-readable flag. With the current wording it might appear that an > implementation's responsibilities are met if it somehow causes the text > of the notation packet to be displayed to the user, even if it does not > recognize the notation type. I think that would be a serious mistake. > The critical bit should require that the notation type be recognized > and handled, in order for the signature to be considered valid. Are you sure? I actually think that displaying some notation whenever the signature is verified (correctly) makes a lot of sense and it may be part of signature verification. After all, it is ultimately the user who decides wheter he accepts a signature or not. Here is how I am planning to use human-readable notation: in an on-line trading or auction application, where reputation tracking is important, one can implement user comments about other users' behavior in the form of signatures directly on their public keys with appropriate notation (think of eBay comments). The comment text is, in my opinion, critical in the sense that without it the signature does not make sense, but the implementation's responsibilities are indeed met by just displaying it upon verification. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:05:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqC1-0002R4-4T for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:05:05 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20656 for ; Mon, 14 Nov 2005 21:04:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1swqO073960; Mon, 14 Nov 2005 17:54:58 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1swql073959; Mon, 14 Nov 2005 17:54:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1svrF073952 for ; Mon, 14 Nov 2005 17:54:57 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 11D7657F2F; Mon, 14 Nov 2005 17:56:19 -0800 (PST) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Message-Id: <20051115015619.11D7657F2F@finney.org> Date: Mon, 14 Nov 2005 17:56:19 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > > I'd like to use the flag as a hint to packet-dumping software: if the > > human-readable flag is set, it is reasonable to dump the notation body > > as text. If it is not set, it should be dumped in hex. > > Currently, the way I treat this flag is that I display the notation to the > user whenever the signature is verified. If that's not the purpuse of this > flag, then I would really like another flag with that purpose. See below > what I would like to use it for. I don't think that will work too well on self-sigs with PGP Corp's new preferred-email-encoding subpackets. You don't want to print those out. > > Another difference arises if the subpacket critical bit is set along with > > the human-readable flag. With the current wording it might appear that an > > implementation's responsibilities are met if it somehow causes the text > > of the notation packet to be displayed to the user, even if it does not > > recognize the notation type. I think that would be a serious mistake. > > The critical bit should require that the notation type be recognized > > and handled, in order for the signature to be considered valid. > > Are you sure? I actually think that displaying some notation whenever the > signature is verified (correctly) makes a lot of sense and it may be part of > signature verification. After all, it is ultimately the user who decides > wheter he accepts a signature or not. I'm worried that this is going to get too messy. For a document signature, if a user wants to put in some qualifications or conditions, it is better to put them into the document itself rather than into a notation packet on the signature in the hopes that it will be displayed. There are no guarantees about display. Then there are key signatures; and under what circumstances will they be displayed? When encrypting some email, do we want to see every notation packet which every signer has decided to add to every key that we encrypt to, and perhaps further packets from keys down the web of trust? How to organize it and present it in a coherent way? It will be a mess. If and when we come to the point where we need a kind of notation packet that should be displayed on signature verification, we should define its use and purpose, create a name for it, and spec it out. I think that is a better path than to have a flag with rather uncertain semantics about when it might cause text to be displayed to the user. > Here is how I am planning to use human-readable notation: in an on-line > trading or auction application, where reputation tracking is important, one > can implement user comments about other users' behavior in the form of > signatures directly on their public keys with appropriate notation (think of > eBay comments). The comment text is, in my opinion, critical in the sense > that without it the signature does not make sense, but the implementation's > responsibilities are indeed met by just displaying it upon verification. You could still do this, but do it based on the notation name rather than a flag. You could have a notation called 'user-reputation-comments' or some such. Your application could then define whatever meaning and handling it wanted for how this type of notation packet should be used. Hal Finney From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:10:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqHD-0004Y5-Ux for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:10:27 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20920 for ; Mon, 14 Nov 2005 21:09:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x2KN074243; Mon, 14 Nov 2005 17:59:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1x2CW074242; Mon, 14 Nov 2005 17:59:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x1OZ074232 for ; Mon, 14 Nov 2005 17:59:01 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005111501585501300io9ose>; Tue, 15 Nov 2005 01:58:55 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF1x3X6027794 for ; Mon, 14 Nov 2005 20:59:03 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF1wqdw026725 for ; Mon, 14 Nov 2005 20:58:52 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF1wq9h026724 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 20:58:52 -0500 Date: Mon, 14 Nov 2005 20:58:52 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115015852.GA26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115001343.GB5599@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 01:13:43AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > > > I'd like to use the flag as a hint to packet-dumping software: if the > > human-readable flag is set, it is reasonable to dump the notation body > > as text. If it is not set, it should be dumped in hex. > > Currently, the way I treat this flag is that I display the notation to the > user whenever the signature is verified. If that's not the purpuse of this > flag, then I would really like another flag with that purpose. See below > what I would like to use it for. I think what you are saying and what Hal and I are saying are basically compatible: interpret the human-readable flag as "I can print this". > > Another difference arises if the subpacket critical bit is set along with > > the human-readable flag. With the current wording it might appear that an > > implementation's responsibilities are met if it somehow causes the text > > of the notation packet to be displayed to the user, even if it does not > > recognize the notation type. I think that would be a serious mistake. > > The critical bit should require that the notation type be recognized > > and handled, in order for the signature to be considered valid. > > Are you sure? I actually think that displaying some notation whenever the > signature is verified (correctly) makes a lot of sense and it may be part of > signature verification. After all, it is ultimately the user who decides > wheter he accepts a signature or not. There is no conflict here either. It is perfectly fine to print notations on signature verification if you choose to do so. The problem is if you have a critical notation that your implementation does not handle. You can print this notation or not (it's up to you) but the important thing is that the unhandled critical notation isn't treated as handled just because you print it. > Here is how I am planning to use human-readable notation: in an on-line > trading or auction application, where reputation tracking is important, one > can implement user comments about other users' behavior in the form of > signatures directly on their public keys with appropriate notation (think of > eBay comments). The comment text is, in my opinion, critical in the sense > that without it the signature does not make sense, but the implementation's > responsibilities are indeed met by just displaying it upon verification. That's fine. You can define a notation type any way you like. It's perfectly reasonable to define your notation to meet its critical "contract" by being shown to a user. David From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:19:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqPv-0007Bx-Cs for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:19:27 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21272 for ; Mon, 14 Nov 2005 21:18:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BCHU075273; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2BCMA075272; Mon, 14 Nov 2005 18:11:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BBiO075266 for ; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 047E52B479F; Tue, 15 Nov 2005 03:11:10 +0100 (CET) Date: Tue, 15 Nov 2005 03:11:10 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115021110.GA15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115015852.GA26425@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote: > I think what you are saying and what Hal and I are saying are > basically compatible: interpret the human-readable flag as "I can > print this". But how to express "you should print this"? I tought the text flag and the critical flag together were for this very purpose. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:23:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqTR-0008EW-JM for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:23:05 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21522 for ; Mon, 14 Nov 2005 21:22:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EdHN075639; Mon, 14 Nov 2005 18:14:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2EdAZ075638; Mon, 14 Nov 2005 18:14:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EciP075628 for ; Mon, 14 Nov 2005 18:14:38 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <20051115021432012002d1rpe>; Tue, 15 Nov 2005 02:14:32 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2EeX6027850 for ; Mon, 14 Nov 2005 21:14:40 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2EUOK026796 for ; Mon, 14 Nov 2005 21:14:30 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2EUHS026795 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 21:14:30 -0500 Date: Mon, 14 Nov 2005 21:14:29 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115021429.GB26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote: > >We discussed a change to 5.2.3.16 (Notation Data) on the list to > >change: > > > > First octet: 0x80 = human-readable. This note value is text, a > > note from one person to another, and need > > not have meaning to software. > >to: > > First octet: 0x80 = human-readable. This note value is text. > > > >Any way that can go in? I'm perfectly happy to get an "I Told You So" > >if someone is confused :) > > > > I remember the discussion, I just don't remember the agreement. Such > is the way with rough consensus. Yes. I didn't think we had consensus yet. I'm re-raising it to get some more discussion. > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. It matters because the current text states something as true that shouldn't be true. A human-readable notation isn't necessarily a note from one person to another. Using the only commonly used notation (preferred-email-encoding@pgp.com) as an example, it is human readable, but is a note from software to software and humans aren't necessarily involved. > Incidentally, I apologize for not getting this out before. I sent it > to the I-D desk, who whined at me. My correction was eaten by an MTA, > which took two weeks to tell me that it was confused, and by then the > meeting lull had happened. > > So can we take the two-week comment period for last call and make it > be Nov 21? Sounds good to me. David From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:36:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqgW-0004C6-Ls for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:36:36 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22548 for ; Mon, 14 Nov 2005 21:36:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OjQm076788; Mon, 14 Nov 2005 18:24:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2OjDl076787; Mon, 14 Nov 2005 18:24:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OiSN076778 for ; Mon, 14 Nov 2005 18:24:44 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20051115022332015003aacce>; Tue, 15 Nov 2005 02:23:34 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2NdX6027889 for ; Mon, 14 Nov 2005 21:23:39 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2NS1D026905 for ; Mon, 14 Nov 2005 21:23:28 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2NSFj026904 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 21:23:28 -0500 Date: Mon, 14 Nov 2005 21:23:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115022328.GC26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115021110.GA15939@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 03:11:10AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote: > > > I think what you are saying and what Hal and I are saying are > > basically compatible: interpret the human-readable flag as "I can > > print this". > > But how to express "you should print this"? I tought the text flag and the > critical flag together were for this very purpose. You would define a notation ("my-notation-name@epointsystem.org" or the like), which is defined as "show me to a human". You don't want to overload the human-readable flag for that, since there are some human readable notations that while being *capable* of being read by a human, aren't intended for reading by a human on a regular basis. David From owner-ietf-openpgp@mail.imc.org Mon Nov 14 21:52:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqwD-0000F9-6g for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:52:49 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23039 for ; Mon, 14 Nov 2005 21:52:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hdx0078700; Mon, 14 Nov 2005 18:43:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2hdkC078699; Mon, 14 Nov 2005 18:43:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hcTQ078691 for ; Mon, 14 Nov 2005 18:43:38 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 91E322B479F; Tue, 15 Nov 2005 03:43:37 +0100 (CET) Date: Tue, 15 Nov 2005 03:43:37 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115024337.GB15939@epointsystem.org> References: <20051115015619.11D7657F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115015619.11D7657F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 05:56:19PM -0800, "Hal Finney" wrote: > > Currently, the way I treat this flag is that I display the notation to the > > user whenever the signature is verified. If that's not the purpuse of this > > flag, then I would really like another flag with that purpose. See below > > what I would like to use it for. > > I don't think that will work too well on self-sigs with PGP Corp's new > preferred-email-encoding subpackets. You don't want to print those out. But that's because, strictly speaking, it is not a message meant for users, and thus a violation of the current wording of the standard. Now, I am fully supportive of the ITEF practice of letting the implementations shape the standard, so if the only current implementation uses that flag in the sense that "this is text" rather than the current wording, I am all for changing the wording to reflect that, but I think a flag indicating that some notation is meant (primarily) for human interpretation is warranted. Here's why: Using this flag, implementations that are unaware of the contract of that particular notation can still do something useful with it, namely they can display to the user. > I'm worried that this is going to get too messy. For a document > signature, if a user wants to put in some qualifications or conditions, > it is better to put them into the document itself rather than into a > notation packet on the signature in the hopes that it will be displayed. > There are no guarantees about display. I agree with this. > Then there are key signatures; and under what circumstances will they be > displayed? When encrypting some email, do we want to see every notation > packet which every signer has decided to add to every key that we encrypt > to, and perhaps further packets from keys down the web of trust? How to > organize it and present it in a coherent way? It will be a mess. I don't think so. The way I see it is that such notations (critical+human interpretable) should be displayed whenever anything is displayed about the signature at all. For instance, when the user lists the signatures on a particular key, such notations must be displayed along with the fact of the existence of the signature. > If and when we come to the point where we need a kind of notation packet > that should be displayed on signature verification, we should define its > use and purpose, create a name for it, and spec it out. I think that > is a better path than to have a flag with rather uncertain semantics > about when it might cause text to be displayed to the user. But why not have a flag with clear semantics? Like "whenever the fact of successful signaure verification is reported to the user, this notation must be included in the report". I don't see any ambiguity here. And it won't result in a torrent of messages either. > > Here is how I am planning to use human-readable notation: in an on-line > > trading or auction application, where reputation tracking is important, one > > can implement user comments about other users' behavior in the form of > > signatures directly on their public keys with appropriate notation (think of > > eBay comments). The comment text is, in my opinion, critical in the sense > > that without it the signature does not make sense, but the implementation's > > responsibilities are indeed met by just displaying it upon verification. > > You could still do this, but do it based on the notation name rather than > a flag. You could have a notation called 'user-reputation-comments' > or some such. Your application could then define whatever meaning and > handling it wanted for how this type of notation packet should be used. But in your iterpretation of the critical flag, if I mark that notation critical, applications not aware of its purpose would strip the signaure as unverifiable. If I don't, I contradict the fact that it _is_ critical for the correct interpretation of the signature. Also, I don't feel that I am trying to force my peculiar needs on the community. I think that many applications could benefit from notation that is guaranteed to be displayed, when listing key signatures by all implementataions, while being treated in some special way by those that are aware of its purpose. A combination of "to be interpreted by humans" and "critical" seems to express this semantics perfectly. Now, if the "text" flag does not mean that it should be interpreted by humans, it is perfectly acceptable. But in that case I feel that there is still a legitimate use for another flag that does mean that the notation is meant for human interpretation. Don't you think so? -- Daninel From owner-ietf-openpgp@mail.imc.org Mon Nov 14 22:00:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebr3T-0002jT-JA for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 22:00:19 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23479 for ; Mon, 14 Nov 2005 21:59:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pTZp079387; Mon, 14 Nov 2005 18:51:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2pTEH079386; Mon, 14 Nov 2005 18:51:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pS8X079376 for ; Mon, 14 Nov 2005 18:51:28 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 67C1D2B479F; Tue, 15 Nov 2005 03:51:27 +0100 (CET) Date: Tue, 15 Nov 2005 03:51:27 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115025127.GC15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> <20051115022328.GC26425@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115022328.GC26425@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote: > You would define a notation ("my-notation-name@epointsystem.org" or > the like), which is defined as "show me to a human". Sure. > You don't want to overload the human-readable flag for that, since > there are some human readable notations that while being *capable* of > being read by a human, aren't intended for reading by a human on a > regular basis. I understand that and even agree with it in the light of the fact that there's already notation in wide use that is not intended for human interpretation. But I think that a flag indicating that some notation IS intended to be interpreted by humans is still warranted, using a wording similar to the original definition of the text flag, perhaps with some clarification added. Like this: First octet: 0x80 = displayable. This note value is text. 0x40 = human-readable. This note value is text, a note from one person to another, and need not have meaning to software. If critical, it MUST be displayed whenever the successful verification of the signature is reported to the user -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Nov 14 23:45:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebsh3-0000pE-EQ for openpgp-archive@megatron.ietf.org; Mon, 14 Nov 2005 23:45:17 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28629 for ; Mon, 14 Nov 2005 23:44:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkvf092054; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF4Xkt4092053; Mon, 14 Nov 2005 20:33:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkpo092044 for ; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111504333501400lrnoke>; Tue, 15 Nov 2005 04:33:40 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF4XhX6028228 for ; Mon, 14 Nov 2005 23:33:43 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF4XWSE027328 for ; Mon, 14 Nov 2005 23:33:32 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF4XW4S027327 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 23:33:32 -0500 Date: Mon, 14 Nov 2005 23:33:32 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115043332.GD26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> <20051115022328.GC26425@jabberwocky.com> <20051115025127.GC15939@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115025127.GC15939@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 03:51:27AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote: > > > You would define a notation ("my-notation-name@epointsystem.org" or > > the like), which is defined as "show me to a human". > > Sure. > > > You don't want to overload the human-readable flag for that, since > > there are some human readable notations that while being *capable* of > > being read by a human, aren't intended for reading by a human on a > > regular basis. > > I understand that and even agree with it in the light of the fact that > there's already notation in wide use that is not intended for human > interpretation. But I think that a flag indicating that some notation IS > intended to be interpreted by humans is still warranted, using a wording > similar to the original definition of the text flag, perhaps with some > clarification added. Like this: > > First octet: 0x80 = displayable. This note value is text. > > 0x40 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. If critical, > it MUST be displayed whenever the successful > verification of the signature is reported to > the user I'm not sure what benefit this has over just defining a notation with whatever semantics you desire. This flag, in effect, lets someone change the semantics of notations they do not own. David From owner-ietf-openpgp@mail.imc.org Tue Nov 15 01:56:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebujd-0007uo-EI for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 01:56:05 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05099 for ; Tue, 15 Nov 2005 01:55:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e8Ur004547; Mon, 14 Nov 2005 22:40:08 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF6e8x1004546; Mon, 14 Nov 2005 22:40:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e6fp004538 for ; Mon, 14 Nov 2005 22:40:07 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8667357F2F; Mon, 14 Nov 2005 22:41:29 -0800 (PST) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Message-Id: <20051115064129.8667357F2F@finney.org> Date: Mon, 14 Nov 2005 22:41:29 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > I understand that and even agree with it in the light of the fact that > there's already notation in wide use that is not intended for human > interpretation. But I think that a flag indicating that some notation IS > intended to be interpreted by humans is still warranted, using a wording > similar to the original definition of the text flag, perhaps with some > clarification added. Like this: > > First octet: 0x80 = displayable. This note value is text. > > 0x40 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. If critical, > it MUST be displayed whenever the successful > verification of the signature is reported to > the user Your 0x40 is more than "human-readable", it is "should be displayed". I don't like the idea of putting in a feature which burdens implementations to do certain things in the UI, unless we have a very good reason. Our PGP software might have to pop up dialog boxes to deliver these notification messages, which I'm sure would bring objections from our UI guys. If and when we come up with a compelling reason to add such a UI mandate in our data-format specification, then we could consider it. We would also need to clarify when it should be displayed for key signatures: if a web of trust is used, should we display all notations for all keys in the chain that were used to establish the trustworthiness of a target key? Should this happen on both encryption and signature verification? And is it enough to do it once and consider the user "notified", or should it be done every time? The answers to questions like these are likely to be application specific. That is, for some kinds of notations we would do it one way, and for other types of notations we would do it another way. Maybe some would only be for data signatures and not key signatures, or vice versa. Maybe some would only be displayed for signatures on the key being used, while others should be displayed for the whole trust chain. It depends on the purpose. Putting in this 0x40 flag now, or any mandate for notation packet display, will require possibly substantial change to every OpenPGP implementation in existence. Sure, it potentially gives you a lot of leverage to implement your desired new feature. But it is at a great expense. We can't go forward with something like this without an extensive discussion involving many groups, including UI experts. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Nov 15 08:26:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0pM-0006MY-BX for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:26:27 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24253 for ; Tue, 15 Nov 2005 08:25:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBuhE044212; Tue, 15 Nov 2005 05:11:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDBuY1044211; Tue, 15 Nov 2005 05:11:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBtHI044205 for ; Tue, 15 Nov 2005 05:11:55 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B8DE06462E; Tue, 15 Nov 2005 13:11:53 +0000 (GMT) Message-ID: <4379DEAC.7030507@systemics.com> Date: Tue, 15 Nov 2005 13:12:12 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jon Callas wrote: >> We discussed a change to 5.2.3.16 (Notation Data) on the list to >> change: >> >> First octet: 0x80 = human-readable. This note value is text, a >> note from one person to another, and need >> not have meaning to software. >> to: >> First octet: 0x80 = human-readable. This note value is text. >> >> Any way that can go in? I'm perfectly happy to get an "I Told You So" >> if someone is confused :) >> > > I remember the discussion, I just don't remember the agreement. Such is > the way with rough consensus. > > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. I agree with the second reading. The first tries to define something that eludes definition, and any attempt to further define it takes us inevitably into needing more flags (as per Daniel's discussion). From owner-ietf-openpgp@mail.imc.org Tue Nov 15 08:26:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0pM-0006MX-9s for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:26:28 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24252 for ; Tue, 15 Nov 2005 08:25:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZbQ044251; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDCZEo044250; Tue, 15 Nov 2005 05:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZTw044244 for ; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 86BFF6462E; Tue, 15 Nov 2005 13:12:34 +0000 (GMT) Message-ID: <4379DED5.9040306@systemics.com> Date: Tue, 15 Nov 2005 13:12:53 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jon Callas wrote: > So can we take the two-week comment period for last call and make it be > Nov 21? No disagreement here! iang From owner-ietf-openpgp@mail.imc.org Tue Nov 15 10:57:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3Bo-0006yV-0a for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 10:57:44 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02402 for ; Tue, 15 Nov 2005 10:57:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYssG059066; Tue, 15 Nov 2005 07:34:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFFYsCk059065; Tue, 15 Nov 2005 07:34:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYqZl059049 for ; Tue, 15 Nov 2005 07:34:53 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0B5982B47CC; Tue, 15 Nov 2005 16:34:51 +0100 (CET) Date: Tue, 15 Nov 2005 16:34:50 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115153450.GA3523@epointsystem.org> References: <20051115064129.8667357F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115064129.8667357F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 10:41:29PM -0800, "Hal Finney" wrote: > Your 0x40 is more than "human-readable", it is "should be displayed". I > don't like the idea of putting in a feature which burdens implementations > to do certain things in the UI, unless we have a very good reason. > Our PGP software might have to pop up dialog boxes to deliver these > notification messages, which I'm sure would bring objections from our > UI guys. Unless it already doesn't pop up dialog boxes then it shouldn't pop up new ones. All I suggest is adding text to the report about successful verification, if such a report exists. > If and when we come up with a compelling reason to add such a UI mandate > in our data-format specification, then we could consider it. We would > also need to clarify when it should be displayed for key signatures: if > a web of trust is used, should we display all notations for all keys in > the chain that were used to establish the trustworthiness of a target key? Definitely not. You only display the notation, if the successful verification of the signature is explicitly reported to the user. > Should this happen on both encryption and signature verification? And is > it enough to do it once and consider the user "notified", or should it be > done every time? > > The answers to questions like these are likely to be application specific. > That is, for some kinds of notations we would do it one way, and for other > types of notations we would do it another way. Maybe some would only be > for data signatures and not key signatures, or vice versa. Maybe some > would only be displayed for signatures on the key being used, while others > should be displayed for the whole trust chain. It depends on the purpose. But isn't that dependence on signature type already resolved by the different ways in which applications report on successful signature verification? I was a bit sloppy first by saying that such notation should be displayed upon successful verification. That is obviously wrong. What I really have in mind is that such notation should be included in reports of successful verification, if such reports are provided. > Putting in this 0x40 flag now, or any mandate for notation packet display, > will require possibly substantial change to every OpenPGP implementation > in existence. Sure, it potentially gives you a lot of leverage to > implement your desired new feature. But it is at a great expense. > We can't go forward with something like this without an extensive > discussion involving many groups, including UI experts. Okay, there is no urgency. But I still think, it is a legitimate feature which does not require dramatic changes on implementations' part. At the same time, it substantially decreases the roll-out costs of many applications, not just mine. Basically, it would enable people to do more things without having to write sofware. The "note from one person to another" is a nice feature to be included in signatures. If, for obvious reasons, 0x80 cannot carry this semantics, some other flag should. The true issue here, as I see it, is that indeed, one can change the semantics of notation wihout owning it. If notation flags are not considered part of the notation (that is, their use is not restricted by the notation specification), then such flags are more or less part of the notation value, and should convey information only about the value part (e.g. whether it is text, image, boolean, etc.). If this is the case, it should be included in the wording of the standard. In that case, the feature I would like to see will have to be implemented in a completely different fashion, but still preferably in the standard, as it is generally useful. On the other hand, I think that notation flags should be part of the notation spec; you cannot put binary data where the spec requires text, so the spec may as well specify what flags to use and how with the notation, even though the flags' semantics is the same across all notations. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Nov 15 12:39:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4mL-00070Z-AO for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 12:39:33 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11821 for ; Tue, 15 Nov 2005 12:38:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrOA070504; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFHTrUS070503; Tue, 15 Nov 2005 09:29:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrBS070497 for ; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Tue, 15 Nov 2005 09:29:50 -0800 Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Nov 2005 09:29:49 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Nov 2005 09:29:49 -0800 In-Reply-To: <20051115021110.GA15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Some -15 comments Date: Tue, 15 Nov 2005 09:29:53 -0800 To: "Daniel A. Nagy" X-Mailer: Apple Mail (2.746.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14 Nov 2005, at 6:11 PM, Daniel A. Nagy wrote: > > But how to express "you should print this"? I tought the text flag > and the > critical flag together were for this very purpose. > The critical flag can called (only slightly humorously) the non- interoperable flag. Normally, when an implementation sees any subpacket it doesn't understand, it ignores it. But with the critical flag, you error out if you don't understand it. So ihf you create a human-readable, critical notation, you're asking for it to blow up a lot. This may be exactly what you want, but it might not. Now this can create side issues, as well. Let's suppose that I have built an automated system (one with no humans). I know exactly what your notation is, but I have no human. So I ignore the thing. To me, this follows exactly the spirit of "critical" because I know what it is and I know I can ignore it. It may not be what you want -- you may have thought that human-reable and critical means it will blow up any automated process. Similarly, I might display the notation to a human user and have a "please don't show this to me again" check box to have it not displayed again. This is a reasonable thing to do, despite a critical flag. This is why I put my tongue in my cheek a bit and call it also the non-interoperable flag. If you set the critical flag, you create all sorts of interesting ways for the system to surprise people. Jon From owner-ietf-openpgp@mail.imc.org Tue Nov 15 13:29:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5YM-0000HZ-Pc for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 13:29:10 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15826 for ; Tue, 15 Nov 2005 13:28:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFYqW075557; Tue, 15 Nov 2005 10:15:34 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIFYIq075556; Tue, 15 Nov 2005 10:15:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFXfn075549 for ; Tue, 15 Nov 2005 10:15:33 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8A9FF57F2F; Tue, 15 Nov 2005 10:16:57 -0800 (PST) To: jon@callas.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Cc: ietf-openpgp@imc.org Message-Id: <20051115181657.8A9FF57F2F@finney.org> Date: Tue, 15 Nov 2005 10:16:57 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > The critical flag can called (only slightly humorously) the non- > interoperable flag. > > Normally, when an implementation sees any subpacket it doesn't > understand, it ignores it. But with the critical flag, you error out > if you don't understand it. That's not my understanding. Rather, you don't consider the signature valid, if there is a critical subpacket you don't understand. You don't "error out." Now, for document signatures, failure to understand a critical notation may in some cases be as bad as erroring-out, because whatever purpose was meant to be expressed by creating the signature, won't happen. But for keyring signatures, which are often redundant, we could for example imagine a signature which says, I am not vouching for the binding between userid and key, but rather I am making a certain assertion about this userid or key. If we don't understand this notation the correct thing is to ignore the signature, and that is in fact what the spec says should happen. Critical notations allow implementors to essentially extend signature semantics beyond the official set of signature types. We have a protected namespace for proprietary extensions, and we have the ability for legacy applications silently to ignore unrecognized extensions. It's a good feature. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Nov 15 13:39:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5iM-0004oZ-G3 for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 13:39:30 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16636 for ; Tue, 15 Nov 2005 13:38:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRL7X076563; Tue, 15 Nov 2005 10:27:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIRLTt076562; Tue, 15 Nov 2005 10:27:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRJCC076549 for ; Tue, 15 Nov 2005 10:27:20 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id DEE22636CF; Tue, 15 Nov 2005 18:27:18 +0000 (GMT) Message-ID: <437A2899.8050100@systemics.com> Date: Tue, 15 Nov 2005 18:27:37 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051115064129.8667357F2F@finney.org> <20051115153450.GA3523@epointsystem.org> In-Reply-To: <20051115153450.GA3523@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > Okay, there is no urgency. But I still think, it is a legitimate feature > which does not require dramatic changes on implementations' part. At the > same time, it substantially decreases the roll-out costs of many > applications, not just mine. Basically, it would enable people to do more > things without having to write sofware. The "note from one person to > another" is a nice feature to be included in signatures. If, for obvious > reasons, 0x80 cannot carry this semantics, some other flag should. In dealing with signatures-of-legal-import, you may be saying that you want a "please-display-me" feature in order to complete this process at the UI level. But, the notion of a human signature is substantially (*) more complex than that; just displaying a comment attached to a signature is unlikely to bring us close enough to making the signature work as a legal one. Which is to say I think this short-changes the subject matter somewhat. A full treatment of this will require many more things than just one extra bit or just one nice well written specification entry, and until someone a) has a real need for it and b) does the extra work to define all of the (wider, legal) aspects of legally important signatures either in general or in particular, we won't be able to predict it from here, and (I claim) it is foolhardy to try. > The true issue here, as I see it, is that indeed, one can change the > semantics of notation wihout owning it. If notation flags are not > considered part of the notation (that is, their use is not restricted by the > notation specification), then such flags are more or less part of the > notation value, and should convey information only about the value part > (e.g. whether it is text, image, boolean, etc.). If this is the case, it > should be included in the wording of the standard. > > In that case, the feature I would like to see will have to be implemented in > a completely different fashion, but still preferably in the standard, as it > is generally useful. On the other hand, I think that notation flags should > be part of the notation spec; you cannot put binary data where the spec > requires text, so the spec may as well specify what flags to use and how > with the notation, even though the flags' semantics is the same across all > notations. Hmm, not entirely sure I followed all that, and it would probably help if I read the parts in as much detail as others! Having said that, if you are suggesting that these semantics are better off left to a higher layer called the "notation spec", then I'd whole-heartedly agree. iang PS: (*) C.f., the Ricardian Contract . From owner-ietf-openpgp@mail.imc.org Tue Nov 15 21:24:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCye-0005wR-0v for openpgp-archive@megatron.ietf.org; Tue, 15 Nov 2005 21:24:48 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21704 for ; Tue, 15 Nov 2005 21:24:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27NRC026087; Tue, 15 Nov 2005 18:07:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAG27NPw026086; Tue, 15 Nov 2005 18:07:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27LP8026079 for ; Tue, 15 Nov 2005 18:07:22 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 1D7822B4799; Wed, 16 Nov 2005 03:07:20 +0100 (CET) Date: Wed, 16 Nov 2005 03:07:20 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051116020719.GA14921@epointsystem.org> References: <20051115181657.8A9FF57F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115181657.8A9FF57F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 10:16:57AM -0800, "Hal Finney" wrote: > example imagine a signature which says, I am not vouching for the binding > between userid and key, but rather I am making a certain assertion about > this userid or key. If we don't understand this notation the correct > thing is to ignore the signature, and that is in fact what the spec says > should happen. Yes, that is my understanding as well. Critical notation means that it is essential for the correct interpretation of the signature and without understanding the notation the signature is meaningless. > Critical notations allow implementors to essentially extend signature > semantics beyond the official set of signature types. We have a protected > namespace for proprietary extensions, and we have the ability for legacy > applications silently to ignore unrecognized extensions. It's a good > feature. I agree. As for the subject of our discussion, I think that we all agree that the spec for 0x80 should be stripped of "a note from one person to another..." bit., because one major implementation does not treat it that way. The only disagreement seems to be whether "a note from one person to another" should be retained as an interoperable feature or should it be delegated to private notation namespace. The disadvantage of the latter approach would be that various implementers would (possibly) implement this same semantics with a host of different notation names and won't interoperate. Now, I can see that implementing the former using a type flag also causes problems. Maybe, it should be a common, ITEF-namespace notation? Or an entirely separate subpacket type akin to "reason for revocation"? I am not sure. But in either case, as far as immediate modifications to the standard text are concerned, this "a note..." part should be removed from the definition of 0x80, because it means something that 0x80 definitely doesn't. Whether or not to add that text someplace else is an entirely different question. -- Daniel From jwortiz@altecjapan.com Wed Nov 16 10:57:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPfZ-0000SF-2Q for openpgp-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:57:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05689 for ; Wed, 16 Nov 2005 10:57:23 -0500 (EST) Received: from [195.96.75.118] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcPwx-0006Ij-O6 for openpgp-archive@ietf.org; Wed, 16 Nov 2005 11:15:59 -0500 Message-ID: <000001c5eac5$6abaa180$0100007f@localhost> From: "Ronald Green" To: Subject: OEM Software Date: Wed, 16 Nov 2005 18:57:20 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EAC5.6ABAA180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EAC5.6ABAA180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EAC5.6ABAA180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 45 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)

------=_NextPart_000_0001_01C5EAC5.6ABAA180-- From JasonOhara@firstjohnchurch.org Fri Nov 18 20:28:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHWb-0004ol-8F for openpgp-archive@megatron.ietf.org; Fri, 18 Nov 2005 20:28:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27210 for ; Fri, 18 Nov 2005 20:27:41 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdHoX-00031K-VN for openpgp-archive@ietf.org; Fri, 18 Nov 2005 20:46:50 -0500 Received: from c9119169.bhz.virtua.com.br ([201.17.145.105]) by mx2.foretec.com with smtp (Exim 4.24) id 1EdHWR-0006h8-1E for openpgp-archive@ietf.org; Fri, 18 Nov 2005 20:28:09 -0500 Received: from hrSQ@localhost by IjOq.int (8.11.6/8.11.6); Fri, 18 Nov 2005 23:07:30 -0700 Message-ID: From: "Harris Erickson" Reply-To: "Harris Erickson" To: openpgp-archive@ietf.org Cc: bodyeer@ietf.org, mplsissues@ietf.org Subject: MS Office 2003 Pro $69.95 AutoCAD Date: Sat, 19 Nov 2005 01:12:30 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JasonOhara@firstjohnchurch.org Content-Type: multipart/mixed; boundary="--zaEIiKPZDlLA0N3" X-Spam-Score: 0.3 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 ddf3 ----zaEIiKPZDlLA0N3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable M
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

<= /table>

TOP 10 NEW TITLES

=
 <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nbs= p;2 Creative Suite 2
 <= /td>3 MS Office 2003 Pro
 = 4 Adobe Acrobat 7 Pro
&nbs= p;5 Macromedia Flash 8
&nbs= p;6 Dreamweaver 8
 7 Norton Sysworks 2005
 = 8 Adobe GoLive CS2
 = 9 Adobe Illustrator CS2
&= nbsp;10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
 = Macromedia
  = Adobe
  Cu= stomers also bought
   these other items...

M= icrosoft Windows XP Professional *w/SP2*
Microsoft

Choose:
 

List Price:$= 299.00
Price:= $49.99=
You Save:$249.01 (80= %)



Availability: = Available for INSTANT download!
Coupon Code: hr1MW2
Plat= form: Windows XP<= /p>

Sales Rank: #1
System requirements = ; |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review: Based on 1= 5577 reviews. Write a review.

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.= 00
Price:$149.99
You Save:$1049.01 (95= %)



Availability: = Available for INSTANT download!
Coupon Code: R2zr1e
Plat= form: Windows XP<= /p>

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review: Based on 1= 8732 reviews. Write a review.

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://bestsoft4u.com/?s>

Availability: Available for INSTANT download!=
Coupon Code: fDPDa
Platform: Windows XP

= Sales Rank: #3
System requirements  |  Other Versions
Date Coup= on Expires: December 31st, 2005
Avera= ge Customer Review:3D"5 Based on 11562 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: FaEyNgVCz
Platform: Windows XP

Sales R= ank: #4<= br> System requirements  |  Other Versions
Date Coupon Expires= : December 31st, 2005
Average Custome= r Review:3D"5 Based on 199291 reviews. Write a review.

----zaEIiKPZDlLA0N3-- From jjrbl@sohu.com Sun Nov 20 00:49:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edi5O-0007EG-0Q for openpgp-archive@megatron.ietf.org; Sun, 20 Nov 2005 00:49:58 -0500 Received: from sohu.com ([218.10.84.185]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02313 for ; Sun, 20 Nov 2005 00:49:17 -0500 (EST) Message-Id: <200511200549.AAA02313@ietf.org> From: =?GB2312?B?oba+rbzNyMuht9TT1r7J5w==?= Subject: =?GB2312?B?oba+rbzNyMuht9TT1r7J58LbzsTV97jlzajWqg==?= To: openpgp-archive@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: jjrbl@sohu.com Date: Sun, 20 Nov 2005 13:49:54 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] ¡¶¾­¼ÍÈË¡·ÔÓÖ¾ÉçÂÛÎÄÕ÷¸å֪ͨ ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·ÊÇ¡¶¾­¼ÍÈË¡·ÔÓÖ¾µÄѧÊõ°æ£¬ÓÉÖйú¹ú¼Ê¾­¼Ã¿Æ¼¼·¨ÂÉÈ˲Åѧ»áÖ÷°ì¡£ ¡¶¾­¼ÍÈË¡·ÔÓÖ¾ÃæÏò¹úÄÚÍ⹫¿ª³ö°æ·¢ÐС£Îª¹ú¼ÒÒ»¼¶×ÛºÏÀàÆÚ¿¯¡£¿¯ºÅCN11-4444/C£¬ISSN1009-3990¡£ÓÉ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·±à¼­²¿±à¼­¡£±¾¿¯ÖÂÁ¦ÓÚ¾­¼Íѧ¡¢¹ÜÀíѧ¡¢¾­¼Ãѧ¡¢¿Æѧ¡¢½ÌÓýµÈѧ¿ÆµÄÑо¿£¬¼æ¼°ÕÜѧ¡¢Àúʷѧ¡¢ÕþÖÎѧ¡¢·¨Ñ§¡¢Éç»áѧµÈÆäËûѧ¿Æ£¬×¢ÖØѧÊõÐÔ¡¢ÀíÂÛÐÔ¡¢Ì½Ë÷ÐÔ¼°Ó¦ÓÃÐÔ¡£Ëü½«¼á³ÖѧÊõ±¾Î»Á¢³¡£¬ÒÔ¾ßÓйú¼ÊÓ°ÏìµÄ¸ßÖÊÁ¿Ñ§Êõ¿¯ÎïΪ±ê×¼¡£Èȳϻ¶Ó­¹úÄÚÍâר¼Ò¡¢Ñ§Õߺ͹ã´óÉç»á¿Æѧ¹¤×÷ÕßÓ»Ô¾´Í¸å¡£±¾¿¯ÒѼÓÈ롶ÖйúѧÊõÆÚ¿¯¡·£¨¹âÅ̰棩£¬Í¬Ê±ÏµCNKIÖйúÆÚ¿¯È«ÎÄÊý¾Ý¿âÀ´Ô´ÆÚ¿¯¡¢ÖйúѧÊõÆÚ¿¯×ÛºÏÆÀ¼ÛÊý¾Ý¿âÀ´Ô´ÆÚ¿¯ºÍÖйúÈËÎÄÉç¿ÆÒýÎÄÊý¾Ý¿âÀ´Ô´ÆÚ¿¯£¬ÎÒÃǽ«ÎªÄúµÄÐÂÖø¼Ñ×÷¾¡¿ìÎÊÊÀ¶øŬÁ¦¡£ ¶þ¡¢Õ÷¸å·¶Î§¼°ÒªÇó£º 1£®¸å¼þÒªÇó×ÊÁÏÏêʵ£¬Àí¾Ý³ä·Ö£¬ÄܳÉÒ»¼ÒÖ®ÑÔ£¬²¢¸»ÓÚÔ­´´ÐÔ¡£ 2£®ÇëÔÚÕýÎÄÇ°¸½ÉÏ 150 ×Ö×óÓÒµÄÎÄÕÂÕªÒªºÍ 3~5 ¸ö¹Ø¼ü´Ê£¬Í¬Ê±×¢Ã÷×÷Õß³öÉúÄêÔ¡¢ÐԱ𡢼®¹á¡¢¹¤×÷µ¥Î»¡¢Ö°³Æ£¨Ö°Îñ£©¡¢ÓʱࡢµØÖ·¡¢µç»°ºÅÂëµÈ¡£ 3£®Í¶¸åÒ»ÂɲÉÓÃWordÎĵµ¸ñʽ·¢Ë͵ç×ÓÓʼþ¡£À´¸å3000-6000 ×Ö£¨°üÀ¨±êµã·ûºÅ¡¢¿Õ¸ñ£©ÎªÒ×£¬±à¼­²¿ÔÚ24СʱÄÚ֪ͨ¸å¼þ¼ÓÃÇé¿ö¡£ÒªÇó´òÓ¡³ÉÎÄ£¬Í¬Ê±¼Ä½»´ÅÅÌ£¨»òµç×ÓÎı¾£©¡£ Ͷ¸åÓÊÏäΪjjrbl@sohu.comδÓøåÒ»Âɲ»ÍË£¬Á½¸öÔºóδ½Óµ½Óøå֪ͨ»òµç»°Í¨Öª¿É×ÔÐд¦Àí¡£ÇëÎðÒ»¸å¶àͶ¡£¸å¼þ·¢±íºó£¬±à¼­²¿½«ÔùËÍ×÷ÕßÒ»±¾Ñù¿¯¡£ Èý¡¢Ñ§ÊõµÀµÂºÍ¹æ·¶£º ±¾¿¯Î¬»¤Ñ§ÊõµÄ´¿½àÓëµÀµÂµÄ×ðÑÏ£¬¼á³ÖÑϸñµÄѧÊõ¹æ·¶¡£·²Éæ¼°³­Ï®ØâÇÔ»ò²»¹æ·¶µÄ¸å¼þ£¬ÇëÎðͶ¸å¡£ÈçÓг­Ï®ØâÇÔÇéÐη¢Éú£¬±¾¿¯½«¸øÓ蹫¿ªÇ´ÔðºÍÅúÆÀ¡£±¾¿¯×ðÖØ×÷Õ߹۵㣬µ«±ØҪʱҲ¿ÉÄÜ×÷ÏàÓ¦¼¼Êõ´¦Àí£¬·²²»Ô¸ÐÞ¸ÄÕߣ¬ÇëÊÂÏÈ˵Ã÷¡£ ±¾¿¯¸ÐлÄúµÄÖ§³Ö£¬ÆÚ´ýÄúµÄÖ¸µ¼¡£»¶Ó­Äú¶©ÔIJ¢»Ý´Í¼Ñ×÷¡£ µç»°£º0451-82623009£¨°ì£© 82623367£¨°ì£© ÁªÏµÈË£ºÍõÁúÏÍ ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·±à¼­²¿¶«±±¹¤×÷Õ¾ µØÖ·£º¹þ¶û±õÊÐÄϸÚÇøÐûÐŽÖ15ºÅ527/528ÊÒ From loneill@amazing-box.com Wed Nov 23 11:12:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexEM-0000J3-7C for openpgp-archive@megatron.ietf.org; Wed, 23 Nov 2005 11:12:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20950 for ; Wed, 23 Nov 2005 11:11:37 -0500 (EST) Received: from [213.243.92.138] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EexXA-0002h0-Kw for openpgp-archive@ietf.org; Wed, 23 Nov 2005 11:31:49 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Wed, 23 Nov 2005 19:15:14 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Wed, 23 Nov 2005 19:15:14 +0300 Message-ID: <000001c5f047$70753180$0100007f@localhost> From: "Dominic James" To: Subject: Your partner will worship you for it Date: Wed, 23 Nov 2005 19:15:14 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F047.70753180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F047.70753180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5F047.70753180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F047.70753180-- From ubrzurbd9.fsf@15commandments.com Thu Nov 24 16:15:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfOQv-0002UI-PB for openpgp-archive@megatron.ietf.org; Thu, 24 Nov 2005 16:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25587 for ; Thu, 24 Nov 2005 16:14:28 -0500 (EST) Received: from ppp83-237-115-65.pppoe.mtu-net.ru ([83.237.115.65] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfOj5-0007if-86 for openpgp-archive@ietf.org; Thu, 24 Nov 2005 16:34:56 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 25 Nov 2005 00:14:00 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 25 Nov 2005 00:14:00 +0300 Message-ID: <000001c5f13a$7ac42800$0100007f@localhost> From: "Jared Rogers" To: Subject: The Industries leading enhancement product, now on sale! Date: Fri, 25 Nov 2005 00:14:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F13A.7AC42800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F13A.7AC42800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.kinel.net/pt/?46&pjtdai ------=_NextPart_000_0001_01C5F13A.7AC42800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F13A.7AC42800-- From GwenWinston@mmdry.com Thu Nov 24 18:02:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQ6Y-0001Hu-PY for openpgp-archive@megatron.ietf.org; Thu, 24 Nov 2005 18:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07739 for ; Thu, 24 Nov 2005 18:01:30 -0500 (EST) Received: from [68.153.190.146] (helo=www.smajico.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfQPa-0003Ia-Do for openpgp-archive@ietf.org; Thu, 24 Nov 2005 18:21:59 -0500 Received: from 83X@localhost by XSB.int (8.11.6/8.11.6); Thu, 24 Nov 2005 21:39:13 -0200 Message-ID: From: "Felipe Mcdaniel" Reply-To: "Felipe Mcdaniel" To: openpgp-archive@ietf.org Cc: bodyeer@ietf.org, mplsissues@ietf.org Subject: MS Office 2003 Pro $69.95 Office XP Date: Fri, 25 Nov 2005 04:38:13 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GwenWinston@mmdry.com Content-Type: multipart/mixed; boundary="--9755218596521814" X-Spam-Score: 3.6 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 syj ----9755218596521814 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable L
Opt-in Email Special Offer   = ;  unsubscribe me

SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://buymoresoft.com/?u>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: atcOp<= br> Platform: = Windows XP

Sales Rank: #1
System requireme= nts  |  Other Versions
Date Coupon Expires: December 31st= , 2005
Average Customer Review:3D"5 Based on 1723 reviews. Write a revi= ew.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: rS7jAy5Xg<= br> Platform: = Windows XP

Sales Rank: #2
System requireme= nts  |  Other Versions
Date Coupon Expires: December 31st= , 2005
Average Customer Review:3D"5 Based on 1996 reviews. Write a revi= ew.

Microsoft Office 2003 *Professional*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: uiSd3VY
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1249 reviews. Write a review.

<= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
List Price:$499.00
Price:$69.99
$429.01 (85%)

A= dobe Acrobat Professional V 7.0
Adobe

Choose= :
 

$499.00
Price:$69.99
You Save= :$429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: Yt9yxIuq
Platform: Windows XP

= Sales Rank: #4
System requirements  |  Other Versions
Date Co= upon Expires: December 31st, 2005
Ave= rage Customer Review:3D"5 Based on 1234 reviews. Write a review.

<= /body> ----9755218596521814-- From owner-ietf-openpgp@mail.imc.org Sat Nov 26 09:19:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0tL-0006ZG-Fe for openpgp-archive@megatron.ietf.org; Sat, 26 Nov 2005 09:19:03 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14884 for ; Sat, 26 Nov 2005 09:18:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4C85085204; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQE4CTr085203; Sat, 26 Nov 2005 06:04:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4BTc085195 for ; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 82E4833C1C for ; Sat, 26 Nov 2005 14:04:09 +0000 (GMT) Message-ID: <43886B5B.3080802@algroup.co.uk> Date: Sat, 26 Nov 2005 14:04:11 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: OpenPGP Subject: -15 still not clear on signatures X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was working on my signing code and realised that some issues previously discussed do not appear to be resolved in -15 (its possible some of these are also new). a) V4 signatures don't mention how one actually calculates the signature - the text only appears for V3 signatures. b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length of the encoded message, emLen. emLen is not specified in -15. By inspection of existing signatures, it seems to me it is one less than the size of the modulus (which strikes me as theoretically wrong, but if that's the way it is, I guess that's the way it is). I proposed patches to clarify this stuff back in April: http://www.imc.org/ietf-openpgp/mail-archive/msg09799.html. These appear to be wrong about emLen (off by one), BTW. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From charlotje500@arm-servicios.com Sun Nov 27 10:14:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgOEq-0001y1-MC for openpgp-archive@megatron.ietf.org; Sun, 27 Nov 2005 10:14:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25063 for ; Sun, 27 Nov 2005 10:14:04 -0500 (EST) Received: from [62.16.114.178] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgOYX-0007Nf-4I for openpgp-archive@ietf.org; Sun, 27 Nov 2005 10:35:09 -0500 Message-ID: <000001c5f364$053ba000$0100007f@localhost> From: "Andres Turner" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Sun, 27 Nov 2005 18:14:19 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F364.053BA000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F364.053BA000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F364.053BA000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 43 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 42 reviews)

------=_NextPart_000_0001_01C5F364.053BA000-- From revel@asaingenieria.com Mon Nov 28 08:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egj84-0002yO-59 for openpgp-archive@megatron.ietf.org; Mon, 28 Nov 2005 08:33:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04799 for ; Mon, 28 Nov 2005 08:32:22 -0500 (EST) Received: from [217.170.223.226] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgjRo-0005qx-Hf for openpgp-archive@ietf.org; Mon, 28 Nov 2005 08:53:39 -0500 Message-ID: <000001c5f41e$e0583300$0100007f@localhost> From: "Jorge Anderson" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Mon, 28 Nov 2005 16:32:43 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F41E.E0583300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F41E.E0583300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F41E.E0583300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 34 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 36 reviews)

------=_NextPart_000_0001_01C5F41E.E0583300-- From HelenPurcell@branchplace.com Mon Nov 28 13:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egnkt-0005UX-HV; Mon, 28 Nov 2005 13:29:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15889; Mon, 28 Nov 2005 13:28:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ego4m-0000yU-Us; Mon, 28 Nov 2005 13:50:10 -0500 Received: from dial-2271.jgora.dialog.net.pl ([62.87.251.223]) by mx2.foretec.com with smtp (Exim 4.24) id 1Egnk9-00011Q-R7; Mon, 28 Nov 2005 13:28:58 -0500 Received: from LSuL@localhost by 3DzQ.int (8.11.6/8.11.6); Mon, 28 Nov 2005 12:16:02 -0600 Message-ID: <9FT22AaZcfM2tIX2WUaI@bluewaveconsulting.com> From: "Sarah Marshall" Reply-To: "Sarah Marshall" To: ooipr-wg@ietf.org, ool-admin@ietf.org, ootippm-archive@ietf.org, openpgp-archive@ietf.org, opes-archive@ietf.org Subject: Windows XP Pro $49.95 XP Pro Date: Mon, 28 Nov 2005 22:21:02 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HelenPurcell@branchplace.com Content-Type: multipart/mixed; boundary="--epaRrFWRpCC84YzdS" X-Spam-Score: 0.3 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 nV8 ----epaRrFWRpCC84YzdS Content-Type: text/html; Content-Transfer-Encoding: quoted-printable c
Opt-in Email Special Offer   = ;  unsubscribe me
----epaRrFWRpCC84YzdS-- From owner-ietf-openpgp@mail.imc.org Wed Nov 30 06:15:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhPw2-0004N3-KG for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 06:15:38 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00229 for ; Wed, 30 Nov 2005 06:14:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeYsp072046; Wed, 30 Nov 2005 02:40:34 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUAeYr6072045; Wed, 30 Nov 2005 02:40:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeXOg072032 for ; Wed, 30 Nov 2005 02:40:33 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0CCF133C3F for ; Wed, 30 Nov 2005 10:40:32 +0000 (GMT) Message-ID: <438D81A8.6090905@algroup.co.uk> Date: Wed, 30 Nov 2005 10:40:40 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: OpenPGP Subject: Lack of clarity in dash-escaped? X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated." Does this mean they should not be included in the signature, or also that they should be stripped from the dash-escaped text? " The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text." Does this mean that one should insert an extra before the terminating line? I notice that at least some implementations do not. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Nov 30 08:29:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhS1v-0001tM-Ci for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 08:29:51 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15167 for ; Wed, 30 Nov 2005 08:29:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9nv0090748; Wed, 30 Nov 2005 05:09:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUD9njo090747; Wed, 30 Nov 2005 05:09:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9mdn090740 for ; Wed, 30 Nov 2005 05:09:48 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id BC6752B44AB; Wed, 30 Nov 2005 14:09:46 +0100 (CET) Date: Wed, 30 Nov 2005 14:09:46 +0100 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130130946.GA10317@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438D81A8.6090905@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? It doesn't matter. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. The line termination before it is not part of the signature. AFAIK, all implementations treat it that way. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Nov 30 08:31:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhS3u-0006Lb-C3 for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 08:31:54 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15539 for ; Wed, 30 Nov 2005 08:31:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJBuh091917; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDJBGv091916; Wed, 30 Nov 2005 05:19:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJAF9091909 for ; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 2798A53375; Wed, 30 Nov 2005 13:19:04 +0000 (GMT) Message-ID: <438DA6E3.5010500@systemics.com> Date: Wed, 30 Nov 2005 13:19:31 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> In-Reply-To: <438D81A8.6090905@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? They should not be included in the signature calculations. It is an open question as to whether they should stripped from the text or not, up to each application. I would; but Jon has posted on good reasons why it is not the job of the application to change the doc that is being processed (signed). I suppose the above text could change "generated" to "calculated" to make it clearer? That is, if my interpretation is the consensus. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. No, there is no need to insert anything, just not include the that must preceed the '-----' line in the signature calculation. In this case I would say that there definately should not be an extra line ending inserted, as that is changing the document in a way that is not reversable. This is an artifact of the old days where optimisations were cute, and it was I suppose considered smart to save on calculating over the last newline. It is particularly dumb, because everything else about the job is line based, but this is an exception with no value other than creating an exception and thus annoying the coders. None that I ever heard, leastways. But there was a discussion about it a long time ago, and no consensus to fix it up, so we are stuck with the exception. IMO! iang From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:01:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSWb-00087w-6c for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:01:33 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18988 for ; Wed, 30 Nov 2005 09:00:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgTp5094613; Wed, 30 Nov 2005 05:42:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDgT4D094612; Wed, 30 Nov 2005 05:42:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgQJo094604 for ; Wed, 30 Nov 2005 05:42:28 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DE73A33C3F; Wed, 30 Nov 2005 13:42:24 +0000 (GMT) Message-ID: <438DAC4A.9060309@algroup.co.uk> Date: Wed, 30 Nov 2005 13:42:34 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ian G CC: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> In-Reply-To: <438DA6E3.5010500@systemics.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian G wrote: > Ben Laurie wrote: >> " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at >> the end of any line is removed when the cleartext signature is >> generated." >> >> Does this mean they should not be included in the signature, or also >> that they should be stripped from the dash-escaped text? > > > They should not be included in the signature > calculations. It is an open question as to > whether they should stripped from the text or > not, up to each application. I would; but > Jon has posted on good reasons why it is not > the job of the application to change the doc > that is being processed (signed). I would agree, if you ended up signing the unchanged document :-) As it is, since I think the idea of stripping them is stupid, I don't really care either way, but it would be good if the document were clear. > I suppose the above text could change "generated" > to "calculated" to make it clearer? That is, if > my interpretation is the consensus. I think you have to say "...at the end of the line is not included in the signature calculation" to remove the ambiguity (if leaving them in the text is intended). > >> " The line ending (i.e. the ) before the '-----BEGIN PGP >> SIGNATURE-----' line that terminates the signed text is not >> considered part of the signed text." >> >> Does this mean that one should insert an extra before the >> terminating line? I notice that at least some implementations do not. > > No, there is no need to insert anything, just > not include the that must preceed the > '-----' line in the signature calculation. In > this case I would say that there definately > should not be an extra line ending inserted, > as that is changing the document in a way that > is not reversable. No - what you are proposing is not reversible. Always adding a _is_ reversable. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:06:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSbd-0001DF-Dd for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:06:45 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19887 for ; Wed, 30 Nov 2005 09:06:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZXbE093738; Wed, 30 Nov 2005 05:35:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDZXSU093737; Wed, 30 Nov 2005 05:35:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZWcV093729 for ; Wed, 30 Nov 2005 05:35:32 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DCFA633C3F; Wed, 30 Nov 2005 13:35:29 +0000 (GMT) Message-ID: <438DAAAA.70204@algroup.co.uk> Date: Wed, 30 Nov 2005 13:35:38 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Daniel A. Nagy" CC: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> In-Reply-To: <20051130130946.GA10317@epointsystem.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: >> " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at >> the end of any line is removed when the cleartext signature is >> generated." >> >> Does this mean they should not be included in the signature, or also >> that they should be stripped from the dash-escaped text? > > It doesn't matter. Of course it matters! >> " The line ending (i.e. the ) before the '-----BEGIN PGP >> SIGNATURE-----' line that terminates the signed text is not >> considered part of the signed text." >> >> Does this mean that one should insert an extra before the >> terminating line? I notice that at least some implementations do not. > > Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. > The line termination before it is not part of the signature. AFAIK, all > implementations treat it that way. That doesn't answer the question. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:25:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhStj-0007xH-U0 for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:25:28 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22565 for ; Wed, 30 Nov 2005 09:24:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5ZSt097112; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE5Zdn097111; Wed, 30 Nov 2005 06:05:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5YPc097104 for ; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CCD0D5F; Wed, 30 Nov 2005 15:05:33 +0100 (CET) Date: Wed, 30 Nov 2005 15:05:33 +0100 To: Ian G Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130140533.GB13023@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438DA6E3.5010500@systemics.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 01:19:31PM +0000, Ian G wrote: > This is an artifact of the old days where > optimisations were cute, and it was I suppose > considered smart to save on calculating over the > last newline. It is particularly dumb, because > everything else about the job is line based, > but this is an exception with no value other > than creating an exception and thus annoying > the coders. None that I ever heard, leastways. I disagree. The current system allows for texts where the last line has no line ending. It means, that signed text files can be converted back and forth between clear-signed and one-pass signed representations, without losing the signature. This is a very neat feature of OpenPGP, that still makes a lot of sense. The following implementation actually uses it (requires java plugin): http://pgp.epointsystem.org/tool Unlike hushmail, it does not encrypt clearsigned documents, but if you decrypt a signed text message, it will output the clearsigned version, which you can verify. See http://pgp.epointsystem.org/tool-help for usage. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSuT-0000pH-H3 for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:26:13 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22646 for ; Wed, 30 Nov 2005 09:25:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE9694097468; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE969O097467; Wed, 30 Nov 2005 06:09:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE95gi097460 for ; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 28F265B039; Wed, 30 Nov 2005 14:08:54 +0000 (GMT) Message-ID: <438DB291.2090609@systemics.com> Date: Wed, 30 Nov 2005 14:09:21 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> In-Reply-To: <20051130130946.GA10317@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. > The line termination before it is not part of the signature. AFAIK, all > implementations treat it that way. It does? I stand corrected. I see what you are getting at - some documents will not have a newline on (mostly application/windows style documents) and then it will need to have that added. Which creates a problem in deciding whether one was added or not afterwards when stripping the signature. Hmmm... Looking back through old signed contracts it appears that Cryptix adds an extra line always but PGP 5.5 does not, and GPG does not unless needed (see checks below). OK, so clarification needed. What is the rule here - when is a line added: - always? - only when needed to correct the line based content? Well spotted, Ben! iang ==================== GPG does not add a line unless needed! galland$ gpg -at --sign -u DSS3 moo gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: "Ian Grigg DSS3 " 1024-bit DSA key, ID DABCCA96, created 2000-03-26 galland$ cat moo.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 one two -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDja0L4yubUNq8ypYRAqjbAKCrCxFZCSdcTaYYnnLuoiaBl+7qjQCgio/q ZYlGBBBIGr9JEzpkCevdPxs= =lxXT -----END PGP SIGNATURE----- galland$ cat moo one two galland$ dd if=moo of=poo bs=1 count=7 7+0 records in 7+0 records out 7 bytes transferred in 0.000147 secs (47585 bytes/sec) galland$ cat poo one twogalland$ gpg -at --sign -u DSS3 poo gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: "Ian Grigg DSS3 " 1024-bit DSA key, ID DABCCA96, created 2000-03-26 galland$ cat poo.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 one two -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDja2A4yubUNq8ypYRAlA+AJ0Y4E41bziMHnB1or04xEXsBytjYwCg5iE8 c5oxusUPe799unMP6RmJbVA= =m/aW -----END PGP SIGNATURE----- galland$ cat poo one twogalland$ From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:27:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSvc-0003WF-Gd for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:27:24 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22787 for ; Wed, 30 Nov 2005 09:26:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwGg9096311; Wed, 30 Nov 2005 05:58:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDwGqG096307; Wed, 30 Nov 2005 05:58:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwETF096283 for ; Wed, 30 Nov 2005 05:58:15 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0634D2B44AB; Wed, 30 Nov 2005 14:58:13 +0100 (CET) Date: Wed, 30 Nov 2005 14:58:12 +0100 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130135812.GA13023@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <438DAAAA.70204@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA22787 On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote: > Daniel A. Nagy wrote: > > On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > >> Does this mean they should not be included in the signature, or also > >> that they should be stripped from the dash-escaped text? > >=20 > > It doesn't matter. >=20 > Of course it matters! No, it does not. Either way, the signature will verify. It is up to the implementation to strip or not to strip empty line endings. It can even change them (e.g. add a few spaces and tabs after some of the line ending= s). Canonization is an idempotent operation. Documents that are the same afte= r canonization are considered identical as far as text signaures go. For pure ascii text, a printed clearsigned document, if typed back in, sh= ould verify. Unfortunately, with unicode this is no longer the case, as there = is a whole bunch of different letters that look exactly the same (e.g. "o" and "=D0=BE" -- the latin and cyrillic "o", repsectively). Actually, this is = problem for legal applications. --=20 Daniel From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:51:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTJ6-0002U8-HX for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:51:40 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25885 for ; Wed, 30 Nov 2005 09:50:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX6wg000372; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEX6pI000371; Wed, 30 Nov 2005 06:33:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX5PU000338 for ; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUEX4S06155 for ; Wed, 30 Nov 2005 09:33:04 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUEWxX6022032 for ; Wed, 30 Nov 2005 09:32:59 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUEWwdO022996 for ; Wed, 30 Nov 2005 09:32:58 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUEWwNB022995 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 09:32:58 -0500 Date: Wed, 30 Nov 2005 09:32:58 -0500 From: David Shaw To: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130143258.GA22898@jabberwocky.com> Mail-Followup-To: OpenPGP References: <438D81A8.6090905@algroup.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438D81A8.6090905@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? A goal of cleartext signatures is that they can survive this sort of whitespace mangling in transport, so it's actually unimportant if the whitespace is removed from the dash-escaped text or not. Either way, they are not part of the signature, so even implementations that differ on this point can still verify each others signatures. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. I think always writing an extra CRLF is the wrong thing to do, if it is not present in the original document. The text from the draft here just says that the last CRLF (the CRLF that is required to be put the BEGIN PGP SIGNATURE line at beginning of a line) in the document is not part of the signed text. As I see it, reasonable behavior here would be to copy in the original document (with line ending conversion done) faithfully, then add the terminating "CRLF-----BEGIN PGP SIGNATURE". If the last line of the original document had a line ending (transformed to CRLF here), then the clearsigned result would include it in the hash and the output: this is my last line of text <-- there was an existing CRLF here <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE" -----BEGIN PGP SIGNATURE----- In this case, the hash ends with "this is my last line of textCRLF". If the last line of the original document didn't have a line ending, then there would be no blank line, as the CRLF from ----BEGIN PGP SIGNATURE----- effectively ends that line. this is my last line of text <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE" -----BEGIN PGP SIGNATURE----- In this case, the hash ends with "this is my last line of text" (no CRLF). This preserves the existence (or not) of the final line ending in the clearsigned document. David From owner-ietf-openpgp@mail.imc.org Wed Nov 30 09:52:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTKF-0002Zu-JG for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:52:52 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26047 for ; Wed, 30 Nov 2005 09:52:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWjDM000268; Wed, 30 Nov 2005 06:32:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEWj1D000267; Wed, 30 Nov 2005 06:32:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWiXk000259 for ; Wed, 30 Nov 2005 06:32:44 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B9F81635F8; Wed, 30 Nov 2005 14:32:40 +0000 (GMT) Message-ID: <438DB823.80901@systemics.com> Date: Wed, 30 Nov 2005 14:33:07 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> <438DAC4A.9060309@algroup.co.uk> In-Reply-To: <438DAC4A.9060309@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > As it is, since I think the idea of stripping them is stupid, I don't > really care either way, but it would be good if the document were clear. The issue that it is meant to solve is that many applications end up adding whitespace to the ends of lines. Not just mailers, but editors, cut&paste, etc. So the "do not include trailing whitespace" is an attempt to make the cleartext signature more robust within the text world it inhabits. For me, it is a good feature, it makes the contracts that I send around more reliable; but always recognising that there are limits to this game, as the same tools that do this also do silly things like slicing up lines and doubling up on newlines. >>I suppose the above text could change "generated" >>to "calculated" to make it clearer? That is, if >>my interpretation is the consensus. > > > I think you have to say "...at the end of the line is not included in > the signature calculation" to remove the ambiguity (if leaving them in > the text is intended). I agree with that. So I'd agree that this is a late change that might slip in before the end if we still have time (always looking over shoulder to see if the final date is about to run us over...): Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is not included in the signature calculation." Maybe add: It is an application decision whether to remove trailing whitespace. (or maybe not. This horse has died so many times.) > No - what you are proposing is not reversible. Always adding a > _is_ reversable. Right. See response to Daniel, who pointed out the fuller understanding. So if that is the rule, we need: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text." to change to: On signing, a line ending (i.e. the ) is always inserted at the end and before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text. This line ending is not part of the signed text nor the signature calculation. It should be stripped when the signature is verified and an unsigned document revealed. Or somesuch. But I'd like to hear from some of the old timers to hear whether that is the rule here. The alternative is that we simply define the document as always having a trailing newline, and that may be non-reversable. iang From owner-ietf-openpgp@mail.imc.org Wed Nov 30 10:17:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhThm-0001hN-GZ for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:17:10 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29039 for ; Wed, 30 Nov 2005 10:16:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsQNx003347; Wed, 30 Nov 2005 06:54:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEsQqO003346; Wed, 30 Nov 2005 06:54:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsPcP003340 for ; Wed, 30 Nov 2005 06:54:25 -0800 (PST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 1E129A3357 for ; Wed, 30 Nov 2005 06:54:25 -0800 (PST) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 30 Nov 2005 06:54:24 -0800 (PST) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id jAUEsO7E083907 for ; Wed, 30 Nov 2005 06:54:24 -0800 (PST) (envelope-from vedaal@hush.com) Message-Id: <200511301454.jAUEsO7E083907@mailserver3.hushmail.com> Date: Wed, 30 Nov 2005 06:54:21 -0800 To: Subject: Re: Lack of clarity in dash-escaped? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 30 Nov 2005 06:09:21 -0800 Ian G wrote: >Looking back through old signed contracts it appears >that Cryptix adds an extra line always but PGP 5.5 >does not, and GPG does not unless needed (see checks >below). pgp commandline (all versions) does not add the extra line gnupg does not but all clearsigned texts using any gui pgp version does have an extra line added between the end of the text and the signature block it might cause backward incompatibility/confusion if it became mandatory one way or the other vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 From owner-ietf-openpgp@mail.imc.org Wed Nov 30 10:30:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTuG-00014A-G3 for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:30:04 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00431 for ; Wed, 30 Nov 2005 10:29:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUVm003421; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEtUFd003420; Wed, 30 Nov 2005 06:55:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUdP003414 for ; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id A69B353375; Wed, 30 Nov 2005 14:55:28 +0000 (GMT) Message-ID: <438DBD7B.9060805@systemics.com> Date: Wed, 30 Nov 2005 14:55:55 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> <20051130135812.GA13023@epointsystem.org> In-Reply-To: <20051130135812.GA13023@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA00431 Daniel A. Nagy wrote: > On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote: >=20 >>Daniel A. Nagy wrote: >> >>>On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: >>> >>>>Does this mean they should not be included in the signature, or also >>>>that they should be stripped from the dash-escaped text? >>> >>>It doesn't matter. >> >>Of course it matters! >=20 >=20 > No, it does not. Either way, the signature will verify. It is up to the > implementation to strip or not to strip empty line endings. It can even > change them (e.g. add a few spaces and tabs after some of the line endi= ngs). I think what you mean is that the whitespace should not be included in the calculation, but it doesn't matter whether they are stripped from the document itself. > Canonization is an idempotent operation. Documents that are the same af= ter > canonization are considered identical as far as text signaures go. (I've always seen it written as canonicalisation or canonicalization.) So the question is whether we canonicalise the document or simply canonicalise the signature processing. I think the answer is that it is open to the application. > For pure ascii text, a printed clearsigned document, if typed back in, = should > verify. Unfortunately, with unicode this is no longer the case, as ther= e is a > whole bunch of different letters that look exactly the same (e.g. "o" a= nd > "=D0=BE" -- the latin and cyrillic "o", repsectively). Actually, this i= s problem > for legal applications. It is an issue, yes. We discussed this a while back and came to the conclusion that *only* ascii whitespace was to be stripped/ignored, as the alternate was too hard to define. That's why the specific characters to be stripped are in the spec - to stop people looking for cyrillic spaces or different sized spaces. iang From owner-ietf-openpgp@mail.imc.org Wed Nov 30 11:11:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUXw-0003zZ-Cj for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:11:04 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04959 for ; Wed, 30 Nov 2005 11:10:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoFw1009280; Wed, 30 Nov 2005 07:50:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFoFka009279; Wed, 30 Nov 2005 07:50:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoEp5009272 for ; Wed, 30 Nov 2005 07:50:14 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 500FB2B44AB; Wed, 30 Nov 2005 16:50:13 +0100 (CET) Date: Wed, 30 Nov 2005 16:50:13 +0100 To: Ian G Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130155013.GA20498@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> <20051130135812.GA13023@epointsystem.org> <438DBD7B.9060805@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438DBD7B.9060805@systemics.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 02:55:55PM +0000, Ian G wrote: > I think what you mean is that the whitespace > should not be included in the calculation, > but it doesn't matter whether they are stripped > from the document itself. Yes, that is precisely what I mean. > It is an issue, yes. We discussed this a while > back and came to the conclusion that *only* ascii > whitespace was to be stripped/ignored, as the > alternate was too hard to define. That's why > the specific characters to be stripped are in > the spec - to stop people looking for cyrillic > spaces or different sized spaces. Unfortunately, unlike canonical ascii, there is no one-to-one correspondence between unicode characters and glyph visuals. It would be nice to have some canonical form for unicode text which is human-readable, yet has a unique binary representation, but it's not easy and not the job of this WG, IMHO. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Nov 30 11:13:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUag-0006Et-0o for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:13:54 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05254 for ; Wed, 30 Nov 2005 11:13:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlXUq008967; Wed, 30 Nov 2005 07:47:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFlXFd008966; Wed, 30 Nov 2005 07:47:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlWSB008960 for ; Wed, 30 Nov 2005 07:47:32 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUFlVS06744 for ; Wed, 30 Nov 2005 10:47:31 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUFlRX6022461 for ; Wed, 30 Nov 2005 10:47:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUFlQi3023198 for ; Wed, 30 Nov 2005 10:47:26 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUFlQLI023197 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 10:47:26 -0500 Date: Wed, 30 Nov 2005 10:47:25 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051130154725.GA23127@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051115181657.8A9FF57F2F@finney.org> <20051116020719.GA14921@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051116020719.GA14921@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 16, 2005 at 03:07:20AM +0100, Daniel A. Nagy wrote: > As for the subject of our discussion, I think that we all agree that the > spec for 0x80 should be stripped of "a note from one person to another..." > bit., because one major implementation does not treat it that way. > > The only disagreement seems to be whether "a note from one person to > another" should be retained as an interoperable feature or should it be > delegated to private notation namespace. > > The disadvantage of the latter approach would be that various implementers > would (possibly) implement this same semantics with a host of different > notation names and won't interoperate. > > Now, I can see that implementing the former using a type flag also causes > problems. Maybe, it should be a common, ITEF-namespace notation? Or an > entirely separate subpacket type akin to "reason for revocation"? > > I am not sure. But in either case, as far as immediate modifications to the > standard text are concerned, this "a note..." part should be removed from > the definition of 0x80, because it means something that 0x80 definitely > doesn't. Whether or not to add that text someplace else is an entirely > different question. Is this rough consensus? David From owner-ietf-openpgp@mail.imc.org Wed Nov 30 11:34:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUug-0003qi-LB for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:34:34 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07548 for ; Wed, 30 Nov 2005 11:33:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE4BN012150; Wed, 30 Nov 2005 08:14:04 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGE4Gw012149; Wed, 30 Nov 2005 08:14:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE3TK012140 for ; Wed, 30 Nov 2005 08:14:03 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUGE2S07014 for ; Wed, 30 Nov 2005 11:14:02 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUGDwX6022624 for ; Wed, 30 Nov 2005 11:13:58 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUGDu8i023265 for ; Wed, 30 Nov 2005 11:13:56 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUGDuiQ023264 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 11:13:56 -0500 Date: Wed, 30 Nov 2005 11:13:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some -15 text nits Message-ID: <20051130161356.GB23127@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: These are just some fiddly language nits for -15. Nothing terribly controversial I hope. ****** The "IANA Considerations" section in the beginning of the draft contains this: Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. "forwarded... or forwarding" doesn't parse very well. I suggest: Instead, requests to define new tag values (say for new encryption algorithms) should be forwarded to the IESG Security Area Directors or the appropriate IETF Working Group for consideration. ****** Section 3.7.1. String-to-key (S2K) specifier types, refers to S2K value 2 as "illegal". Everywhere else in the document, such do-not-use values are referred to as "reserved". ****** Section 3.7.2.1. Secret key encryption says "For compatibility, when an S2K specifier is used, the special value 255 is stored in the position where the hash algorithm octet would have been in the old data structure.". I suggest changing that to read "... the special value 255 or 254 ..." since 254 is a legal value there, as the table immediately after that paragraph makes clear. ****** Section 3.7.2.1. Secret key encryption, and section 5.3. Symmetric-Key Encrypted Session Key Packets refer to "passphrase" as "pass phrase". This is inconsistent with the rest of the document which always uses "passphrase". ****** Section 4.2.2.4. Partial Body Lengths has a paragraph that begins "It might also be encoded..." That doesn't make sense since there is no "it" that the sentence refers to. I believe that paragaph belongs in the following section (4.2.3. Packet Length Examples), as the "it" in question refers to the example "packet with length 100000" from 4.2.3. ****** In section 5.2.1. Signature Types, the signature class 0x18 description says "This signature is calculated directly on the subkey itself, not on any User ID or other packets", but in fact 0x18 signatures are calculated on the primary key plus subkey. Similarly, the 0x19 description says "This signature is calculated directly on the primary key itself, and not on any User ID or other packets", but in reality it is calculated exactly the same way as 0x18 is (primary+subkey). To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it would still be nice to not give two different answers for this. ****** 5.2.2. Version 3 Signature Packet Format says "The hash h is PKCS-1 padded exactly the same way as for the above described RSA signatures". This doesn't really make sense as there is no description of RSA signatures above. David From owner-ietf-openpgp@mail.imc.org Wed Nov 30 12:47:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhW3e-0001Tn-W5 for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:47:55 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16647 for ; Wed, 30 Nov 2005 12:47:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGRI3M013527; Wed, 30 Nov 2005 08:27:18 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGRIBO013526; Wed, 30 Nov 2005 08:27:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGREpV013514 for ; Wed, 30 Nov 2005 08:27:17 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EhUtt-0004jG-Pn for ; Wed, 30 Nov 2005 17:33:45 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EhUhT-0005HI-PM for ; Wed, 30 Nov 2005 17:20:55 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051115181657.8A9FF57F2F@finney.org> <20051116020719.GA14921@epointsystem.org> <20051130154725.GA23127@jabberwocky.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 30 Nov 2005 17:20:55 +0100 In-Reply-To: <20051130154725.GA23127@jabberwocky.com> (David Shaw's message of "Wed, 30 Nov 2005 10:47:25 -0500") Message-ID: <87u0duumxk.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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: On Wed, 30 Nov 2005 10:47:25 -0500, David Shaw said: >> I am not sure. But in either case, as far as immediate modifications to the >> standard text are concerned, this "a note..." part should be removed from >> the definition of 0x80, because it means something that 0x80 definitely >> doesn't. Whether or not to add that text someplace else is an entirely >> different question. > Is this rough consensus? I concur. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Wed Nov 30 14:59:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhY6y-0002Wn-5X for openpgp-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:59:28 -0500 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04945 for ; Wed, 30 Nov 2005 14:58:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoThG033431; Wed, 30 Nov 2005 10:50:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUIoToA033430; Wed, 30 Nov 2005 10:50:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoSZq033424 for ; Wed, 30 Nov 2005 10:50:28 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 5A4AF57F5C; Wed, 30 Nov 2005 10:52:50 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-Id: <20051130185250.5A4AF57F5C@finney.org> Date: Wed, 30 Nov 2005 10:52:50 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> I am not sure. But in either case, as far as immediate modifications to the > >> standard text are concerned, this "a note..." part should be removed from > >> the definition of 0x80, because it means something that 0x80 definitely > >> doesn't. Whether or not to add that text someplace else is an entirely > >> different question. > > > Is this rough consensus? > > I concur. I agree as well. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoThG033431; Wed, 30 Nov 2005 10:50:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUIoToA033430; Wed, 30 Nov 2005 10:50:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoSZq033424 for ; Wed, 30 Nov 2005 10:50:28 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 5A4AF57F5C; Wed, 30 Nov 2005 10:52:50 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-Id: <20051130185250.5A4AF57F5C@finney.org> Date: Wed, 30 Nov 2005 10:52:50 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> I am not sure. But in either case, as far as immediate modifications to the > >> standard text are concerned, this "a note..." part should be removed from > >> the definition of 0x80, because it means something that 0x80 definitely > >> doesn't. Whether or not to add that text someplace else is an entirely > >> different question. > > > Is this rough consensus? > > I concur. I agree as well. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGRI3M013527; Wed, 30 Nov 2005 08:27:18 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGRIBO013526; Wed, 30 Nov 2005 08:27:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGREpV013514 for ; Wed, 30 Nov 2005 08:27:17 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EhUtt-0004jG-Pn for ; Wed, 30 Nov 2005 17:33:45 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EhUhT-0005HI-PM for ; Wed, 30 Nov 2005 17:20:55 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051115181657.8A9FF57F2F@finney.org> <20051116020719.GA14921@epointsystem.org> <20051130154725.GA23127@jabberwocky.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 30 Nov 2005 17:20:55 +0100 In-Reply-To: <20051130154725.GA23127@jabberwocky.com> (David Shaw's message of "Wed, 30 Nov 2005 10:47:25 -0500") Message-ID: <87u0duumxk.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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: On Wed, 30 Nov 2005 10:47:25 -0500, David Shaw said: >> I am not sure. But in either case, as far as immediate modifications to the >> standard text are concerned, this "a note..." part should be removed from >> the definition of 0x80, because it means something that 0x80 definitely >> doesn't. Whether or not to add that text someplace else is an entirely >> different question. > Is this rough consensus? I concur. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE4BN012150; Wed, 30 Nov 2005 08:14:04 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGE4Gw012149; Wed, 30 Nov 2005 08:14:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE3TK012140 for ; Wed, 30 Nov 2005 08:14:03 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUGE2S07014 for ; Wed, 30 Nov 2005 11:14:02 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUGDwX6022624 for ; Wed, 30 Nov 2005 11:13:58 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUGDu8i023265 for ; Wed, 30 Nov 2005 11:13:56 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUGDuiQ023264 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 11:13:56 -0500 Date: Wed, 30 Nov 2005 11:13:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some -15 text nits Message-ID: <20051130161356.GB23127@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: These are just some fiddly language nits for -15. Nothing terribly controversial I hope. ****** The "IANA Considerations" section in the beginning of the draft contains this: Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. "forwarded... or forwarding" doesn't parse very well. I suggest: Instead, requests to define new tag values (say for new encryption algorithms) should be forwarded to the IESG Security Area Directors or the appropriate IETF Working Group for consideration. ****** Section 3.7.1. String-to-key (S2K) specifier types, refers to S2K value 2 as "illegal". Everywhere else in the document, such do-not-use values are referred to as "reserved". ****** Section 3.7.2.1. Secret key encryption says "For compatibility, when an S2K specifier is used, the special value 255 is stored in the position where the hash algorithm octet would have been in the old data structure.". I suggest changing that to read "... the special value 255 or 254 ..." since 254 is a legal value there, as the table immediately after that paragraph makes clear. ****** Section 3.7.2.1. Secret key encryption, and section 5.3. Symmetric-Key Encrypted Session Key Packets refer to "passphrase" as "pass phrase". This is inconsistent with the rest of the document which always uses "passphrase". ****** Section 4.2.2.4. Partial Body Lengths has a paragraph that begins "It might also be encoded..." That doesn't make sense since there is no "it" that the sentence refers to. I believe that paragaph belongs in the following section (4.2.3. Packet Length Examples), as the "it" in question refers to the example "packet with length 100000" from 4.2.3. ****** In section 5.2.1. Signature Types, the signature class 0x18 description says "This signature is calculated directly on the subkey itself, not on any User ID or other packets", but in fact 0x18 signatures are calculated on the primary key plus subkey. Similarly, the 0x19 description says "This signature is calculated directly on the primary key itself, and not on any User ID or other packets", but in reality it is calculated exactly the same way as 0x18 is (primary+subkey). To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it would still be nice to not give two different answers for this. ****** 5.2.2. Version 3 Signature Packet Format says "The hash h is PKCS-1 padded exactly the same way as for the above described RSA signatures". This doesn't really make sense as there is no description of RSA signatures above. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoFw1009280; Wed, 30 Nov 2005 07:50:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFoFka009279; Wed, 30 Nov 2005 07:50:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoEp5009272 for ; Wed, 30 Nov 2005 07:50:14 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 500FB2B44AB; Wed, 30 Nov 2005 16:50:13 +0100 (CET) Date: Wed, 30 Nov 2005 16:50:13 +0100 To: Ian G Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130155013.GA20498@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> <20051130135812.GA13023@epointsystem.org> <438DBD7B.9060805@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438DBD7B.9060805@systemics.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 02:55:55PM +0000, Ian G wrote: > I think what you mean is that the whitespace > should not be included in the calculation, > but it doesn't matter whether they are stripped > from the document itself. Yes, that is precisely what I mean. > It is an issue, yes. We discussed this a while > back and came to the conclusion that *only* ascii > whitespace was to be stripped/ignored, as the > alternate was too hard to define. That's why > the specific characters to be stripped are in > the spec - to stop people looking for cyrillic > spaces or different sized spaces. Unfortunately, unlike canonical ascii, there is no one-to-one correspondence between unicode characters and glyph visuals. It would be nice to have some canonical form for unicode text which is human-readable, yet has a unique binary representation, but it's not easy and not the job of this WG, IMHO. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlXUq008967; Wed, 30 Nov 2005 07:47:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFlXFd008966; Wed, 30 Nov 2005 07:47:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlWSB008960 for ; Wed, 30 Nov 2005 07:47:32 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUFlVS06744 for ; Wed, 30 Nov 2005 10:47:31 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUFlRX6022461 for ; Wed, 30 Nov 2005 10:47:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUFlQi3023198 for ; Wed, 30 Nov 2005 10:47:26 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUFlQLI023197 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 10:47:26 -0500 Date: Wed, 30 Nov 2005 10:47:25 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051130154725.GA23127@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051115181657.8A9FF57F2F@finney.org> <20051116020719.GA14921@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051116020719.GA14921@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 16, 2005 at 03:07:20AM +0100, Daniel A. Nagy wrote: > As for the subject of our discussion, I think that we all agree that the > spec for 0x80 should be stripped of "a note from one person to another..." > bit., because one major implementation does not treat it that way. > > The only disagreement seems to be whether "a note from one person to > another" should be retained as an interoperable feature or should it be > delegated to private notation namespace. > > The disadvantage of the latter approach would be that various implementers > would (possibly) implement this same semantics with a host of different > notation names and won't interoperate. > > Now, I can see that implementing the former using a type flag also causes > problems. Maybe, it should be a common, ITEF-namespace notation? Or an > entirely separate subpacket type akin to "reason for revocation"? > > I am not sure. But in either case, as far as immediate modifications to the > standard text are concerned, this "a note..." part should be removed from > the definition of 0x80, because it means something that 0x80 definitely > doesn't. Whether or not to add that text someplace else is an entirely > different question. Is this rough consensus? David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUVm003421; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEtUFd003420; Wed, 30 Nov 2005 06:55:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUdP003414 for ; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id A69B353375; Wed, 30 Nov 2005 14:55:28 +0000 (GMT) Message-ID: <438DBD7B.9060805@systemics.com> Date: Wed, 30 Nov 2005 14:55:55 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> <20051130135812.GA13023@epointsystem.org> In-Reply-To: <20051130135812.GA13023@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote: > >>Daniel A. Nagy wrote: >> >>>On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: >>> >>>>Does this mean they should not be included in the signature, or also >>>>that they should be stripped from the dash-escaped text? >>> >>>It doesn't matter. >> >>Of course it matters! > > > No, it does not. Either way, the signature will verify. It is up to the > implementation to strip or not to strip empty line endings. It can even > change them (e.g. add a few spaces and tabs after some of the line endings). I think what you mean is that the whitespace should not be included in the calculation, but it doesn't matter whether they are stripped from the document itself. > Canonization is an idempotent operation. Documents that are the same after > canonization are considered identical as far as text signaures go. (I've always seen it written as canonicalisation or canonicalization.) So the question is whether we canonicalise the document or simply canonicalise the signature processing. I think the answer is that it is open to the application. > For pure ascii text, a printed clearsigned document, if typed back in, should > verify. Unfortunately, with unicode this is no longer the case, as there is a > whole bunch of different letters that look exactly the same (e.g. "o" and > "о" -- the latin and cyrillic "o", repsectively). Actually, this is problem > for legal applications. It is an issue, yes. We discussed this a while back and came to the conclusion that *only* ascii whitespace was to be stripped/ignored, as the alternate was too hard to define. That's why the specific characters to be stripped are in the spec - to stop people looking for cyrillic spaces or different sized spaces. iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsQNx003347; Wed, 30 Nov 2005 06:54:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEsQqO003346; Wed, 30 Nov 2005 06:54:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsPcP003340 for ; Wed, 30 Nov 2005 06:54:25 -0800 (PST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 1E129A3357 for ; Wed, 30 Nov 2005 06:54:25 -0800 (PST) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 30 Nov 2005 06:54:24 -0800 (PST) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id jAUEsO7E083907 for ; Wed, 30 Nov 2005 06:54:24 -0800 (PST) (envelope-from vedaal@hush.com) Message-Id: <200511301454.jAUEsO7E083907@mailserver3.hushmail.com> Date: Wed, 30 Nov 2005 06:54:21 -0800 To: Cc: Subject: Re: Lack of clarity in dash-escaped? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 30 Nov 2005 06:09:21 -0800 Ian G wrote: >Looking back through old signed contracts it appears >that Cryptix adds an extra line always but PGP 5.5 >does not, and GPG does not unless needed (see checks >below). pgp commandline (all versions) does not add the extra line gnupg does not but all clearsigned texts using any gui pgp version does have an extra line added between the end of the text and the signature block it might cause backward incompatibility/confusion if it became mandatory one way or the other vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX6wg000372; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEX6pI000371; Wed, 30 Nov 2005 06:33:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX5PU000338 for ; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUEX4S06155 for ; Wed, 30 Nov 2005 09:33:04 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUEWxX6022032 for ; Wed, 30 Nov 2005 09:32:59 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUEWwdO022996 for ; Wed, 30 Nov 2005 09:32:58 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUEWwNB022995 for ietf-openpgp@imc.org; Wed, 30 Nov 2005 09:32:58 -0500 Date: Wed, 30 Nov 2005 09:32:58 -0500 From: David Shaw To: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130143258.GA22898@jabberwocky.com> Mail-Followup-To: OpenPGP References: <438D81A8.6090905@algroup.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438D81A8.6090905@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? A goal of cleartext signatures is that they can survive this sort of whitespace mangling in transport, so it's actually unimportant if the whitespace is removed from the dash-escaped text or not. Either way, they are not part of the signature, so even implementations that differ on this point can still verify each others signatures. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. I think always writing an extra CRLF is the wrong thing to do, if it is not present in the original document. The text from the draft here just says that the last CRLF (the CRLF that is required to be put the BEGIN PGP SIGNATURE line at beginning of a line) in the document is not part of the signed text. As I see it, reasonable behavior here would be to copy in the original document (with line ending conversion done) faithfully, then add the terminating "CRLF-----BEGIN PGP SIGNATURE". If the last line of the original document had a line ending (transformed to CRLF here), then the clearsigned result would include it in the hash and the output: this is my last line of text <-- there was an existing CRLF here <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE" -----BEGIN PGP SIGNATURE----- In this case, the hash ends with "this is my last line of textCRLF". If the last line of the original document didn't have a line ending, then there would be no blank line, as the CRLF from ----BEGIN PGP SIGNATURE----- effectively ends that line. this is my last line of text <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE" -----BEGIN PGP SIGNATURE----- In this case, the hash ends with "this is my last line of text" (no CRLF). This preserves the existence (or not) of the final line ending in the clearsigned document. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWjDM000268; Wed, 30 Nov 2005 06:32:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEWj1D000267; Wed, 30 Nov 2005 06:32:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWiXk000259 for ; Wed, 30 Nov 2005 06:32:44 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B9F81635F8; Wed, 30 Nov 2005 14:32:40 +0000 (GMT) Message-ID: <438DB823.80901@systemics.com> Date: Wed, 30 Nov 2005 14:33:07 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> <438DAC4A.9060309@algroup.co.uk> In-Reply-To: <438DAC4A.9060309@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie wrote: > As it is, since I think the idea of stripping them is stupid, I don't > really care either way, but it would be good if the document were clear. The issue that it is meant to solve is that many applications end up adding whitespace to the ends of lines. Not just mailers, but editors, cut&paste, etc. So the "do not include trailing whitespace" is an attempt to make the cleartext signature more robust within the text world it inhabits. For me, it is a good feature, it makes the contracts that I send around more reliable; but always recognising that there are limits to this game, as the same tools that do this also do silly things like slicing up lines and doubling up on newlines. >>I suppose the above text could change "generated" >>to "calculated" to make it clearer? That is, if >>my interpretation is the consensus. > > > I think you have to say "...at the end of the line is not included in > the signature calculation" to remove the ambiguity (if leaving them in > the text is intended). I agree with that. So I'd agree that this is a late change that might slip in before the end if we still have time (always looking over shoulder to see if the final date is about to run us over...): Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is not included in the signature calculation." Maybe add: It is an application decision whether to remove trailing whitespace. (or maybe not. This horse has died so many times.) > No - what you are proposing is not reversible. Always adding a > _is_ reversable. Right. See response to Daniel, who pointed out the fuller understanding. So if that is the rule, we need: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text." to change to: On signing, a line ending (i.e. the ) is always inserted at the end and before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text. This line ending is not part of the signed text nor the signature calculation. It should be stripped when the signature is verified and an unsigned document revealed. Or somesuch. But I'd like to hear from some of the old timers to hear whether that is the rule here. The alternative is that we simply define the document as always having a trailing newline, and that may be non-reversable. iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE9694097468; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE969O097467; Wed, 30 Nov 2005 06:09:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE95gi097460 for ; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 28F265B039; Wed, 30 Nov 2005 14:08:54 +0000 (GMT) Message-ID: <438DB291.2090609@systemics.com> Date: Wed, 30 Nov 2005 14:09:21 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> In-Reply-To: <20051130130946.GA10317@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. > The line termination before it is not part of the signature. AFAIK, all > implementations treat it that way. It does? I stand corrected. I see what you are getting at - some documents will not have a newline on (mostly application/windows style documents) and then it will need to have that added. Which creates a problem in deciding whether one was added or not afterwards when stripping the signature. Hmmm... Looking back through old signed contracts it appears that Cryptix adds an extra line always but PGP 5.5 does not, and GPG does not unless needed (see checks below). OK, so clarification needed. What is the rule here - when is a line added: - always? - only when needed to correct the line based content? Well spotted, Ben! iang ==================== GPG does not add a line unless needed! galland$ gpg -at --sign -u DSS3 moo gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: "Ian Grigg DSS3 " 1024-bit DSA key, ID DABCCA96, created 2000-03-26 galland$ cat moo.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 one two -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDja0L4yubUNq8ypYRAqjbAKCrCxFZCSdcTaYYnnLuoiaBl+7qjQCgio/q ZYlGBBBIGr9JEzpkCevdPxs= =lxXT -----END PGP SIGNATURE----- galland$ cat moo one two galland$ dd if=moo of=poo bs=1 count=7 7+0 records in 7+0 records out 7 bytes transferred in 0.000147 secs (47585 bytes/sec) galland$ cat poo one twogalland$ gpg -at --sign -u DSS3 poo gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: "Ian Grigg DSS3 " 1024-bit DSA key, ID DABCCA96, created 2000-03-26 galland$ cat poo.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 one two -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDja2A4yubUNq8ypYRAlA+AJ0Y4E41bziMHnB1or04xEXsBytjYwCg5iE8 c5oxusUPe799unMP6RmJbVA= =m/aW -----END PGP SIGNATURE----- galland$ cat poo one twogalland$ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5ZSt097112; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE5Zdn097111; Wed, 30 Nov 2005 06:05:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5YPc097104 for ; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CCD0D5F; Wed, 30 Nov 2005 15:05:33 +0100 (CET) Date: Wed, 30 Nov 2005 15:05:33 +0100 To: Ian G Cc: Ben Laurie , OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130140533.GB13023@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438DA6E3.5010500@systemics.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 01:19:31PM +0000, Ian G wrote: > This is an artifact of the old days where > optimisations were cute, and it was I suppose > considered smart to save on calculating over the > last newline. It is particularly dumb, because > everything else about the job is line based, > but this is an exception with no value other > than creating an exception and thus annoying > the coders. None that I ever heard, leastways. I disagree. The current system allows for texts where the last line has no line ending. It means, that signed text files can be converted back and forth between clear-signed and one-pass signed representations, without losing the signature. This is a very neat feature of OpenPGP, that still makes a lot of sense. The following implementation actually uses it (requires java plugin): http://pgp.epointsystem.org/tool Unlike hushmail, it does not encrypt clearsigned documents, but if you decrypt a signed text message, it will output the clearsigned version, which you can verify. See http://pgp.epointsystem.org/tool-help for usage. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwGg9096311; Wed, 30 Nov 2005 05:58:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDwGqG096307; Wed, 30 Nov 2005 05:58:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwETF096283 for ; Wed, 30 Nov 2005 05:58:15 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0634D2B44AB; Wed, 30 Nov 2005 14:58:13 +0100 (CET) Date: Wed, 30 Nov 2005 14:58:12 +0100 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130135812.GA13023@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> <438DAAAA.70204@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <438DAAAA.70204@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote: > Daniel A. Nagy wrote: > > On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > >> Does this mean they should not be included in the signature, or also > >> that they should be stripped from the dash-escaped text? > > > > It doesn't matter. > > Of course it matters! No, it does not. Either way, the signature will verify. It is up to the implementation to strip or not to strip empty line endings. It can even change them (e.g. add a few spaces and tabs after some of the line endings). Canonization is an idempotent operation. Documents that are the same after canonization are considered identical as far as text signaures go. For pure ascii text, a printed clearsigned document, if typed back in, should verify. Unfortunately, with unicode this is no longer the case, as there is a whole bunch of different letters that look exactly the same (e.g. "o" and "о" -- the latin and cyrillic "o", repsectively). Actually, this is problem for legal applications. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgTp5094613; Wed, 30 Nov 2005 05:42:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDgT4D094612; Wed, 30 Nov 2005 05:42:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgQJo094604 for ; Wed, 30 Nov 2005 05:42:28 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DE73A33C3F; Wed, 30 Nov 2005 13:42:24 +0000 (GMT) Message-ID: <438DAC4A.9060309@algroup.co.uk> Date: Wed, 30 Nov 2005 13:42:34 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ian G CC: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <438DA6E3.5010500@systemics.com> In-Reply-To: <438DA6E3.5010500@systemics.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G wrote: > Ben Laurie wrote: >> " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at >> the end of any line is removed when the cleartext signature is >> generated." >> >> Does this mean they should not be included in the signature, or also >> that they should be stripped from the dash-escaped text? > > > They should not be included in the signature > calculations. It is an open question as to > whether they should stripped from the text or > not, up to each application. I would; but > Jon has posted on good reasons why it is not > the job of the application to change the doc > that is being processed (signed). I would agree, if you ended up signing the unchanged document :-) As it is, since I think the idea of stripping them is stupid, I don't really care either way, but it would be good if the document were clear. > I suppose the above text could change "generated" > to "calculated" to make it clearer? That is, if > my interpretation is the consensus. I think you have to say "...at the end of the line is not included in the signature calculation" to remove the ambiguity (if leaving them in the text is intended). > >> " The line ending (i.e. the ) before the '-----BEGIN PGP >> SIGNATURE-----' line that terminates the signed text is not >> considered part of the signed text." >> >> Does this mean that one should insert an extra before the >> terminating line? I notice that at least some implementations do not. > > No, there is no need to insert anything, just > not include the that must preceed the > '-----' line in the signature calculation. In > this case I would say that there definately > should not be an extra line ending inserted, > as that is changing the document in a way that > is not reversable. No - what you are proposing is not reversible. Always adding a _is_ reversable. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZXbE093738; Wed, 30 Nov 2005 05:35:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDZXSU093737; Wed, 30 Nov 2005 05:35:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZWcV093729 for ; Wed, 30 Nov 2005 05:35:32 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DCFA633C3F; Wed, 30 Nov 2005 13:35:29 +0000 (GMT) Message-ID: <438DAAAA.70204@algroup.co.uk> Date: Wed, 30 Nov 2005 13:35:38 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Daniel A. Nagy" CC: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> <20051130130946.GA10317@epointsystem.org> In-Reply-To: <20051130130946.GA10317@epointsystem.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: >> " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at >> the end of any line is removed when the cleartext signature is >> generated." >> >> Does this mean they should not be included in the signature, or also >> that they should be stripped from the dash-escaped text? > > It doesn't matter. Of course it matters! >> " The line ending (i.e. the ) before the '-----BEGIN PGP >> SIGNATURE-----' line that terminates the signed text is not >> considered part of the signed text." >> >> Does this mean that one should insert an extra before the >> terminating line? I notice that at least some implementations do not. > > Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. > The line termination before it is not part of the signature. AFAIK, all > implementations treat it that way. That doesn't answer the question. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJBuh091917; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDJBGv091916; Wed, 30 Nov 2005 05:19:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJAF9091909 for ; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 2798A53375; Wed, 30 Nov 2005 13:19:04 +0000 (GMT) Message-ID: <438DA6E3.5010500@systemics.com> Date: Wed, 30 Nov 2005 13:19:31 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? References: <438D81A8.6090905@algroup.co.uk> In-Reply-To: <438D81A8.6090905@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie wrote: > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? They should not be included in the signature calculations. It is an open question as to whether they should stripped from the text or not, up to each application. I would; but Jon has posted on good reasons why it is not the job of the application to change the doc that is being processed (signed). I suppose the above text could change "generated" to "calculated" to make it clearer? That is, if my interpretation is the consensus. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. No, there is no need to insert anything, just not include the that must preceed the '-----' line in the signature calculation. In this case I would say that there definately should not be an extra line ending inserted, as that is changing the document in a way that is not reversable. This is an artifact of the old days where optimisations were cute, and it was I suppose considered smart to save on calculating over the last newline. It is particularly dumb, because everything else about the job is line based, but this is an exception with no value other than creating an exception and thus annoying the coders. None that I ever heard, leastways. But there was a discussion about it a long time ago, and no consensus to fix it up, so we are stuck with the exception. IMO! iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9nv0090748; Wed, 30 Nov 2005 05:09:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUD9njo090747; Wed, 30 Nov 2005 05:09:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9mdn090740 for ; Wed, 30 Nov 2005 05:09:48 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id BC6752B44AB; Wed, 30 Nov 2005 14:09:46 +0100 (CET) Date: Wed, 30 Nov 2005 14:09:46 +0100 To: Ben Laurie Cc: OpenPGP Subject: Re: Lack of clarity in dash-escaped? Message-ID: <20051130130946.GA10317@epointsystem.org> References: <438D81A8.6090905@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438D81A8.6090905@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote: > > " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at > the end of any line is removed when the cleartext signature is > generated." > > Does this mean they should not be included in the signature, or also > that they should be stripped from the dash-escaped text? It doesn't matter. > " The line ending (i.e. the ) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text." > > Does this mean that one should insert an extra before the > terminating line? I notice that at least some implementations do not. Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line. The line termination before it is not part of the signature. AFAIK, all implementations treat it that way. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeYsp072046; Wed, 30 Nov 2005 02:40:34 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUAeYr6072045; Wed, 30 Nov 2005 02:40:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeXOg072032 for ; Wed, 30 Nov 2005 02:40:33 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0CCF133C3F for ; Wed, 30 Nov 2005 10:40:32 +0000 (GMT) Message-ID: <438D81A8.6090905@algroup.co.uk> Date: Wed, 30 Nov 2005 10:40:40 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: OpenPGP Subject: Lack of clarity in dash-escaped? X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: " Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated." Does this mean they should not be included in the signature, or also that they should be stripped from the dash-escaped text? " The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text." Does this mean that one should insert an extra before the terminating line? I notice that at least some implementations do not. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4C85085204; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQE4CTr085203; Sat, 26 Nov 2005 06:04:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4BTc085195 for ; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 82E4833C1C for ; Sat, 26 Nov 2005 14:04:09 +0000 (GMT) Message-ID: <43886B5B.3080802@algroup.co.uk> Date: Sat, 26 Nov 2005 14:04:11 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: OpenPGP Subject: -15 still not clear on signatures X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was working on my signing code and realised that some issues previously discussed do not appear to be resolved in -15 (its possible some of these are also new). a) V4 signatures don't mention how one actually calculates the signature - the text only appears for V3 signatures. b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length of the encoded message, emLen. emLen is not specified in -15. By inspection of existing signatures, it seems to me it is one less than the size of the modulus (which strikes me as theoretically wrong, but if that's the way it is, I guess that's the way it is). I proposed patches to clarify this stuff back in April: http://www.imc.org/ietf-openpgp/mail-archive/msg09799.html. These appear to be wrong about emLen (off by one), BTW. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27NRC026087; Tue, 15 Nov 2005 18:07:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAG27NPw026086; Tue, 15 Nov 2005 18:07:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27LP8026079 for ; Tue, 15 Nov 2005 18:07:22 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 1D7822B4799; Wed, 16 Nov 2005 03:07:20 +0100 (CET) Date: Wed, 16 Nov 2005 03:07:20 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051116020719.GA14921@epointsystem.org> References: <20051115181657.8A9FF57F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115181657.8A9FF57F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 10:16:57AM -0800, "Hal Finney" wrote: > example imagine a signature which says, I am not vouching for the binding > between userid and key, but rather I am making a certain assertion about > this userid or key. If we don't understand this notation the correct > thing is to ignore the signature, and that is in fact what the spec says > should happen. Yes, that is my understanding as well. Critical notation means that it is essential for the correct interpretation of the signature and without understanding the notation the signature is meaningless. > Critical notations allow implementors to essentially extend signature > semantics beyond the official set of signature types. We have a protected > namespace for proprietary extensions, and we have the ability for legacy > applications silently to ignore unrecognized extensions. It's a good > feature. I agree. As for the subject of our discussion, I think that we all agree that the spec for 0x80 should be stripped of "a note from one person to another..." bit., because one major implementation does not treat it that way. The only disagreement seems to be whether "a note from one person to another" should be retained as an interoperable feature or should it be delegated to private notation namespace. The disadvantage of the latter approach would be that various implementers would (possibly) implement this same semantics with a host of different notation names and won't interoperate. Now, I can see that implementing the former using a type flag also causes problems. Maybe, it should be a common, ITEF-namespace notation? Or an entirely separate subpacket type akin to "reason for revocation"? I am not sure. But in either case, as far as immediate modifications to the standard text are concerned, this "a note..." part should be removed from the definition of 0x80, because it means something that 0x80 definitely doesn't. Whether or not to add that text someplace else is an entirely different question. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRL7X076563; Tue, 15 Nov 2005 10:27:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIRLTt076562; Tue, 15 Nov 2005 10:27:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRJCC076549 for ; Tue, 15 Nov 2005 10:27:20 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id DEE22636CF; Tue, 15 Nov 2005 18:27:18 +0000 (GMT) Message-ID: <437A2899.8050100@systemics.com> Date: Tue, 15 Nov 2005 18:27:37 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051115064129.8667357F2F@finney.org> <20051115153450.GA3523@epointsystem.org> In-Reply-To: <20051115153450.GA3523@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > Okay, there is no urgency. But I still think, it is a legitimate feature > which does not require dramatic changes on implementations' part. At the > same time, it substantially decreases the roll-out costs of many > applications, not just mine. Basically, it would enable people to do more > things without having to write sofware. The "note from one person to > another" is a nice feature to be included in signatures. If, for obvious > reasons, 0x80 cannot carry this semantics, some other flag should. In dealing with signatures-of-legal-import, you may be saying that you want a "please-display-me" feature in order to complete this process at the UI level. But, the notion of a human signature is substantially (*) more complex than that; just displaying a comment attached to a signature is unlikely to bring us close enough to making the signature work as a legal one. Which is to say I think this short-changes the subject matter somewhat. A full treatment of this will require many more things than just one extra bit or just one nice well written specification entry, and until someone a) has a real need for it and b) does the extra work to define all of the (wider, legal) aspects of legally important signatures either in general or in particular, we won't be able to predict it from here, and (I claim) it is foolhardy to try. > The true issue here, as I see it, is that indeed, one can change the > semantics of notation wihout owning it. If notation flags are not > considered part of the notation (that is, their use is not restricted by the > notation specification), then such flags are more or less part of the > notation value, and should convey information only about the value part > (e.g. whether it is text, image, boolean, etc.). If this is the case, it > should be included in the wording of the standard. > > In that case, the feature I would like to see will have to be implemented in > a completely different fashion, but still preferably in the standard, as it > is generally useful. On the other hand, I think that notation flags should > be part of the notation spec; you cannot put binary data where the spec > requires text, so the spec may as well specify what flags to use and how > with the notation, even though the flags' semantics is the same across all > notations. Hmm, not entirely sure I followed all that, and it would probably help if I read the parts in as much detail as others! Having said that, if you are suggesting that these semantics are better off left to a higher layer called the "notation spec", then I'd whole-heartedly agree. iang PS: (*) C.f., the Ricardian Contract . Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFYqW075557; Tue, 15 Nov 2005 10:15:34 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIFYIq075556; Tue, 15 Nov 2005 10:15:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFXfn075549 for ; Tue, 15 Nov 2005 10:15:33 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8A9FF57F2F; Tue, 15 Nov 2005 10:16:57 -0800 (PST) To: jon@callas.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Cc: ietf-openpgp@imc.org Message-Id: <20051115181657.8A9FF57F2F@finney.org> Date: Tue, 15 Nov 2005 10:16:57 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > The critical flag can called (only slightly humorously) the non- > interoperable flag. > > Normally, when an implementation sees any subpacket it doesn't > understand, it ignores it. But with the critical flag, you error out > if you don't understand it. That's not my understanding. Rather, you don't consider the signature valid, if there is a critical subpacket you don't understand. You don't "error out." Now, for document signatures, failure to understand a critical notation may in some cases be as bad as erroring-out, because whatever purpose was meant to be expressed by creating the signature, won't happen. But for keyring signatures, which are often redundant, we could for example imagine a signature which says, I am not vouching for the binding between userid and key, but rather I am making a certain assertion about this userid or key. If we don't understand this notation the correct thing is to ignore the signature, and that is in fact what the spec says should happen. Critical notations allow implementors to essentially extend signature semantics beyond the official set of signature types. We have a protected namespace for proprietary extensions, and we have the ability for legacy applications silently to ignore unrecognized extensions. It's a good feature. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrOA070504; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFHTrUS070503; Tue, 15 Nov 2005 09:29:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrBS070497 for ; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Tue, 15 Nov 2005 09:29:50 -0800 Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Nov 2005 09:29:49 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Nov 2005 09:29:49 -0800 In-Reply-To: <20051115021110.GA15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Some -15 comments Date: Tue, 15 Nov 2005 09:29:53 -0800 To: "Daniel A. Nagy" X-Mailer: Apple Mail (2.746.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 14 Nov 2005, at 6:11 PM, Daniel A. Nagy wrote: > > But how to express "you should print this"? I tought the text flag > and the > critical flag together were for this very purpose. > The critical flag can called (only slightly humorously) the non- interoperable flag. Normally, when an implementation sees any subpacket it doesn't understand, it ignores it. But with the critical flag, you error out if you don't understand it. So ihf you create a human-readable, critical notation, you're asking for it to blow up a lot. This may be exactly what you want, but it might not. Now this can create side issues, as well. Let's suppose that I have built an automated system (one with no humans). I know exactly what your notation is, but I have no human. So I ignore the thing. To me, this follows exactly the spirit of "critical" because I know what it is and I know I can ignore it. It may not be what you want -- you may have thought that human-reable and critical means it will blow up any automated process. Similarly, I might display the notation to a human user and have a "please don't show this to me again" check box to have it not displayed again. This is a reasonable thing to do, despite a critical flag. This is why I put my tongue in my cheek a bit and call it also the non-interoperable flag. If you set the critical flag, you create all sorts of interesting ways for the system to surprise people. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYssG059066; Tue, 15 Nov 2005 07:34:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFFYsCk059065; Tue, 15 Nov 2005 07:34:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYqZl059049 for ; Tue, 15 Nov 2005 07:34:53 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0B5982B47CC; Tue, 15 Nov 2005 16:34:51 +0100 (CET) Date: Tue, 15 Nov 2005 16:34:50 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115153450.GA3523@epointsystem.org> References: <20051115064129.8667357F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115064129.8667357F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 10:41:29PM -0800, "Hal Finney" wrote: > Your 0x40 is more than "human-readable", it is "should be displayed". I > don't like the idea of putting in a feature which burdens implementations > to do certain things in the UI, unless we have a very good reason. > Our PGP software might have to pop up dialog boxes to deliver these > notification messages, which I'm sure would bring objections from our > UI guys. Unless it already doesn't pop up dialog boxes then it shouldn't pop up new ones. All I suggest is adding text to the report about successful verification, if such a report exists. > If and when we come up with a compelling reason to add such a UI mandate > in our data-format specification, then we could consider it. We would > also need to clarify when it should be displayed for key signatures: if > a web of trust is used, should we display all notations for all keys in > the chain that were used to establish the trustworthiness of a target key? Definitely not. You only display the notation, if the successful verification of the signature is explicitly reported to the user. > Should this happen on both encryption and signature verification? And is > it enough to do it once and consider the user "notified", or should it be > done every time? > > The answers to questions like these are likely to be application specific. > That is, for some kinds of notations we would do it one way, and for other > types of notations we would do it another way. Maybe some would only be > for data signatures and not key signatures, or vice versa. Maybe some > would only be displayed for signatures on the key being used, while others > should be displayed for the whole trust chain. It depends on the purpose. But isn't that dependence on signature type already resolved by the different ways in which applications report on successful signature verification? I was a bit sloppy first by saying that such notation should be displayed upon successful verification. That is obviously wrong. What I really have in mind is that such notation should be included in reports of successful verification, if such reports are provided. > Putting in this 0x40 flag now, or any mandate for notation packet display, > will require possibly substantial change to every OpenPGP implementation > in existence. Sure, it potentially gives you a lot of leverage to > implement your desired new feature. But it is at a great expense. > We can't go forward with something like this without an extensive > discussion involving many groups, including UI experts. Okay, there is no urgency. But I still think, it is a legitimate feature which does not require dramatic changes on implementations' part. At the same time, it substantially decreases the roll-out costs of many applications, not just mine. Basically, it would enable people to do more things without having to write sofware. The "note from one person to another" is a nice feature to be included in signatures. If, for obvious reasons, 0x80 cannot carry this semantics, some other flag should. The true issue here, as I see it, is that indeed, one can change the semantics of notation wihout owning it. If notation flags are not considered part of the notation (that is, their use is not restricted by the notation specification), then such flags are more or less part of the notation value, and should convey information only about the value part (e.g. whether it is text, image, boolean, etc.). If this is the case, it should be included in the wording of the standard. In that case, the feature I would like to see will have to be implemented in a completely different fashion, but still preferably in the standard, as it is generally useful. On the other hand, I think that notation flags should be part of the notation spec; you cannot put binary data where the spec requires text, so the spec may as well specify what flags to use and how with the notation, even though the flags' semantics is the same across all notations. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZbQ044251; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDCZEo044250; Tue, 15 Nov 2005 05:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZTw044244 for ; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 86BFF6462E; Tue, 15 Nov 2005 13:12:34 +0000 (GMT) Message-ID: <4379DED5.9040306@systemics.com> Date: Tue, 15 Nov 2005 13:12:53 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > So can we take the two-week comment period for last call and make it be > Nov 21? No disagreement here! iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBuhE044212; Tue, 15 Nov 2005 05:11:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDBuY1044211; Tue, 15 Nov 2005 05:11:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBtHI044205 for ; Tue, 15 Nov 2005 05:11:55 -0800 (PST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B8DE06462E; Tue, 15 Nov 2005 13:11:53 +0000 (GMT) Message-ID: <4379DEAC.7030507@systemics.com> Date: Tue, 15 Nov 2005 13:12:12 +0000 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some -15 comments References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: >> We discussed a change to 5.2.3.16 (Notation Data) on the list to >> change: >> >> First octet: 0x80 = human-readable. This note value is text, a >> note from one person to another, and need >> not have meaning to software. >> to: >> First octet: 0x80 = human-readable. This note value is text. >> >> Any way that can go in? I'm perfectly happy to get an "I Told You So" >> if someone is confused :) >> > > I remember the discussion, I just don't remember the agreement. Such is > the way with rough consensus. > > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. I agree with the second reading. The first tries to define something that eludes definition, and any attempt to further define it takes us inevitably into needing more flags (as per Daniel's discussion). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e8Ur004547; Mon, 14 Nov 2005 22:40:08 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF6e8x1004546; Mon, 14 Nov 2005 22:40:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e6fp004538 for ; Mon, 14 Nov 2005 22:40:07 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8667357F2F; Mon, 14 Nov 2005 22:41:29 -0800 (PST) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Message-Id: <20051115064129.8667357F2F@finney.org> Date: Mon, 14 Nov 2005 22:41:29 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > I understand that and even agree with it in the light of the fact that > there's already notation in wide use that is not intended for human > interpretation. But I think that a flag indicating that some notation IS > intended to be interpreted by humans is still warranted, using a wording > similar to the original definition of the text flag, perhaps with some > clarification added. Like this: > > First octet: 0x80 = displayable. This note value is text. > > 0x40 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. If critical, > it MUST be displayed whenever the successful > verification of the signature is reported to > the user Your 0x40 is more than "human-readable", it is "should be displayed". I don't like the idea of putting in a feature which burdens implementations to do certain things in the UI, unless we have a very good reason. Our PGP software might have to pop up dialog boxes to deliver these notification messages, which I'm sure would bring objections from our UI guys. If and when we come up with a compelling reason to add such a UI mandate in our data-format specification, then we could consider it. We would also need to clarify when it should be displayed for key signatures: if a web of trust is used, should we display all notations for all keys in the chain that were used to establish the trustworthiness of a target key? Should this happen on both encryption and signature verification? And is it enough to do it once and consider the user "notified", or should it be done every time? The answers to questions like these are likely to be application specific. That is, for some kinds of notations we would do it one way, and for other types of notations we would do it another way. Maybe some would only be for data signatures and not key signatures, or vice versa. Maybe some would only be displayed for signatures on the key being used, while others should be displayed for the whole trust chain. It depends on the purpose. Putting in this 0x40 flag now, or any mandate for notation packet display, will require possibly substantial change to every OpenPGP implementation in existence. Sure, it potentially gives you a lot of leverage to implement your desired new feature. But it is at a great expense. We can't go forward with something like this without an extensive discussion involving many groups, including UI experts. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkvf092054; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF4Xkt4092053; Mon, 14 Nov 2005 20:33:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkpo092044 for ; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111504333501400lrnoke>; Tue, 15 Nov 2005 04:33:40 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF4XhX6028228 for ; Mon, 14 Nov 2005 23:33:43 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF4XWSE027328 for ; Mon, 14 Nov 2005 23:33:32 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF4XW4S027327 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 23:33:32 -0500 Date: Mon, 14 Nov 2005 23:33:32 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115043332.GD26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> <20051115022328.GC26425@jabberwocky.com> <20051115025127.GC15939@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115025127.GC15939@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 03:51:27AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote: > > > You would define a notation ("my-notation-name@epointsystem.org" or > > the like), which is defined as "show me to a human". > > Sure. > > > You don't want to overload the human-readable flag for that, since > > there are some human readable notations that while being *capable* of > > being read by a human, aren't intended for reading by a human on a > > regular basis. > > I understand that and even agree with it in the light of the fact that > there's already notation in wide use that is not intended for human > interpretation. But I think that a flag indicating that some notation IS > intended to be interpreted by humans is still warranted, using a wording > similar to the original definition of the text flag, perhaps with some > clarification added. Like this: > > First octet: 0x80 = displayable. This note value is text. > > 0x40 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. If critical, > it MUST be displayed whenever the successful > verification of the signature is reported to > the user I'm not sure what benefit this has over just defining a notation with whatever semantics you desire. This flag, in effect, lets someone change the semantics of notations they do not own. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pTZp079387; Mon, 14 Nov 2005 18:51:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2pTEH079386; Mon, 14 Nov 2005 18:51:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pS8X079376 for ; Mon, 14 Nov 2005 18:51:28 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 67C1D2B479F; Tue, 15 Nov 2005 03:51:27 +0100 (CET) Date: Tue, 15 Nov 2005 03:51:27 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115025127.GC15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> <20051115022328.GC26425@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115022328.GC26425@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote: > You would define a notation ("my-notation-name@epointsystem.org" or > the like), which is defined as "show me to a human". Sure. > You don't want to overload the human-readable flag for that, since > there are some human readable notations that while being *capable* of > being read by a human, aren't intended for reading by a human on a > regular basis. I understand that and even agree with it in the light of the fact that there's already notation in wide use that is not intended for human interpretation. But I think that a flag indicating that some notation IS intended to be interpreted by humans is still warranted, using a wording similar to the original definition of the text flag, perhaps with some clarification added. Like this: First octet: 0x80 = displayable. This note value is text. 0x40 = human-readable. This note value is text, a note from one person to another, and need not have meaning to software. If critical, it MUST be displayed whenever the successful verification of the signature is reported to the user -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hdx0078700; Mon, 14 Nov 2005 18:43:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2hdkC078699; Mon, 14 Nov 2005 18:43:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hcTQ078691 for ; Mon, 14 Nov 2005 18:43:38 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 91E322B479F; Tue, 15 Nov 2005 03:43:37 +0100 (CET) Date: Tue, 15 Nov 2005 03:43:37 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115024337.GB15939@epointsystem.org> References: <20051115015619.11D7657F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115015619.11D7657F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 05:56:19PM -0800, "Hal Finney" wrote: > > Currently, the way I treat this flag is that I display the notation to the > > user whenever the signature is verified. If that's not the purpuse of this > > flag, then I would really like another flag with that purpose. See below > > what I would like to use it for. > > I don't think that will work too well on self-sigs with PGP Corp's new > preferred-email-encoding subpackets. You don't want to print those out. But that's because, strictly speaking, it is not a message meant for users, and thus a violation of the current wording of the standard. Now, I am fully supportive of the ITEF practice of letting the implementations shape the standard, so if the only current implementation uses that flag in the sense that "this is text" rather than the current wording, I am all for changing the wording to reflect that, but I think a flag indicating that some notation is meant (primarily) for human interpretation is warranted. Here's why: Using this flag, implementations that are unaware of the contract of that particular notation can still do something useful with it, namely they can display to the user. > I'm worried that this is going to get too messy. For a document > signature, if a user wants to put in some qualifications or conditions, > it is better to put them into the document itself rather than into a > notation packet on the signature in the hopes that it will be displayed. > There are no guarantees about display. I agree with this. > Then there are key signatures; and under what circumstances will they be > displayed? When encrypting some email, do we want to see every notation > packet which every signer has decided to add to every key that we encrypt > to, and perhaps further packets from keys down the web of trust? How to > organize it and present it in a coherent way? It will be a mess. I don't think so. The way I see it is that such notations (critical+human interpretable) should be displayed whenever anything is displayed about the signature at all. For instance, when the user lists the signatures on a particular key, such notations must be displayed along with the fact of the existence of the signature. > If and when we come to the point where we need a kind of notation packet > that should be displayed on signature verification, we should define its > use and purpose, create a name for it, and spec it out. I think that > is a better path than to have a flag with rather uncertain semantics > about when it might cause text to be displayed to the user. But why not have a flag with clear semantics? Like "whenever the fact of successful signaure verification is reported to the user, this notation must be included in the report". I don't see any ambiguity here. And it won't result in a torrent of messages either. > > Here is how I am planning to use human-readable notation: in an on-line > > trading or auction application, where reputation tracking is important, one > > can implement user comments about other users' behavior in the form of > > signatures directly on their public keys with appropriate notation (think of > > eBay comments). The comment text is, in my opinion, critical in the sense > > that without it the signature does not make sense, but the implementation's > > responsibilities are indeed met by just displaying it upon verification. > > You could still do this, but do it based on the notation name rather than > a flag. You could have a notation called 'user-reputation-comments' > or some such. Your application could then define whatever meaning and > handling it wanted for how this type of notation packet should be used. But in your iterpretation of the critical flag, if I mark that notation critical, applications not aware of its purpose would strip the signaure as unverifiable. If I don't, I contradict the fact that it _is_ critical for the correct interpretation of the signature. Also, I don't feel that I am trying to force my peculiar needs on the community. I think that many applications could benefit from notation that is guaranteed to be displayed, when listing key signatures by all implementataions, while being treated in some special way by those that are aware of its purpose. A combination of "to be interpreted by humans" and "critical" seems to express this semantics perfectly. Now, if the "text" flag does not mean that it should be interpreted by humans, it is perfectly acceptable. But in that case I feel that there is still a legitimate use for another flag that does mean that the notation is meant for human interpretation. Don't you think so? -- Daninel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OjQm076788; Mon, 14 Nov 2005 18:24:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2OjDl076787; Mon, 14 Nov 2005 18:24:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OiSN076778 for ; Mon, 14 Nov 2005 18:24:44 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20051115022332015003aacce>; Tue, 15 Nov 2005 02:23:34 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2NdX6027889 for ; Mon, 14 Nov 2005 21:23:39 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2NS1D026905 for ; Mon, 14 Nov 2005 21:23:28 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2NSFj026904 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 21:23:28 -0500 Date: Mon, 14 Nov 2005 21:23:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115022328.GC26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> <20051115021110.GA15939@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115021110.GA15939@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 03:11:10AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote: > > > I think what you are saying and what Hal and I are saying are > > basically compatible: interpret the human-readable flag as "I can > > print this". > > But how to express "you should print this"? I tought the text flag and the > critical flag together were for this very purpose. You would define a notation ("my-notation-name@epointsystem.org" or the like), which is defined as "show me to a human". You don't want to overload the human-readable flag for that, since there are some human readable notations that while being *capable* of being read by a human, aren't intended for reading by a human on a regular basis. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EdHN075639; Mon, 14 Nov 2005 18:14:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2EdAZ075638; Mon, 14 Nov 2005 18:14:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EciP075628 for ; Mon, 14 Nov 2005 18:14:38 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <20051115021432012002d1rpe>; Tue, 15 Nov 2005 02:14:32 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2EeX6027850 for ; Mon, 14 Nov 2005 21:14:40 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2EUOK026796 for ; Mon, 14 Nov 2005 21:14:30 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2EUHS026795 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 21:14:30 -0500 Date: Mon, 14 Nov 2005 21:14:29 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115021429.GB26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote: > >We discussed a change to 5.2.3.16 (Notation Data) on the list to > >change: > > > > First octet: 0x80 = human-readable. This note value is text, a > > note from one person to another, and need > > not have meaning to software. > >to: > > First octet: 0x80 = human-readable. This note value is text. > > > >Any way that can go in? I'm perfectly happy to get an "I Told You So" > >if someone is confused :) > > > > I remember the discussion, I just don't remember the agreement. Such > is the way with rough consensus. Yes. I didn't think we had consensus yet. I'm re-raising it to get some more discussion. > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. It matters because the current text states something as true that shouldn't be true. A human-readable notation isn't necessarily a note from one person to another. Using the only commonly used notation (preferred-email-encoding@pgp.com) as an example, it is human readable, but is a note from software to software and humans aren't necessarily involved. > Incidentally, I apologize for not getting this out before. I sent it > to the I-D desk, who whined at me. My correction was eaten by an MTA, > which took two weeks to tell me that it was confused, and by then the > meeting lull had happened. > > So can we take the two-week comment period for last call and make it > be Nov 21? Sounds good to me. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BCHU075273; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2BCMA075272; Mon, 14 Nov 2005 18:11:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BBiO075266 for ; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 047E52B479F; Tue, 15 Nov 2005 03:11:10 +0100 (CET) Date: Tue, 15 Nov 2005 03:11:10 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115021110.GA15939@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> <20051115015852.GA26425@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115015852.GA26425@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote: > I think what you are saying and what Hal and I are saying are > basically compatible: interpret the human-readable flag as "I can > print this". But how to express "you should print this"? I tought the text flag and the critical flag together were for this very purpose. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x2KN074243; Mon, 14 Nov 2005 17:59:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1x2CW074242; Mon, 14 Nov 2005 17:59:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x1OZ074232 for ; Mon, 14 Nov 2005 17:59:01 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005111501585501300io9ose>; Tue, 15 Nov 2005 01:58:55 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF1x3X6027794 for ; Mon, 14 Nov 2005 20:59:03 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF1wqdw026725 for ; Mon, 14 Nov 2005 20:58:52 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF1wq9h026724 for ietf-openpgp@imc.org; Mon, 14 Nov 2005 20:58:52 -0500 Date: Mon, 14 Nov 2005 20:58:52 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115015852.GA26425@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051114233744.332A657F2F@finney.org> <20051115001343.GB5599@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115001343.GB5599@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 15, 2005 at 01:13:43AM +0100, Daniel A. Nagy wrote: > > On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > > > I'd like to use the flag as a hint to packet-dumping software: if the > > human-readable flag is set, it is reasonable to dump the notation body > > as text. If it is not set, it should be dumped in hex. > > Currently, the way I treat this flag is that I display the notation to the > user whenever the signature is verified. If that's not the purpuse of this > flag, then I would really like another flag with that purpose. See below > what I would like to use it for. I think what you are saying and what Hal and I are saying are basically compatible: interpret the human-readable flag as "I can print this". > > Another difference arises if the subpacket critical bit is set along with > > the human-readable flag. With the current wording it might appear that an > > implementation's responsibilities are met if it somehow causes the text > > of the notation packet to be displayed to the user, even if it does not > > recognize the notation type. I think that would be a serious mistake. > > The critical bit should require that the notation type be recognized > > and handled, in order for the signature to be considered valid. > > Are you sure? I actually think that displaying some notation whenever the > signature is verified (correctly) makes a lot of sense and it may be part of > signature verification. After all, it is ultimately the user who decides > wheter he accepts a signature or not. There is no conflict here either. It is perfectly fine to print notations on signature verification if you choose to do so. The problem is if you have a critical notation that your implementation does not handle. You can print this notation or not (it's up to you) but the important thing is that the unhandled critical notation isn't treated as handled just because you print it. > Here is how I am planning to use human-readable notation: in an on-line > trading or auction application, where reputation tracking is important, one > can implement user comments about other users' behavior in the form of > signatures directly on their public keys with appropriate notation (think of > eBay comments). The comment text is, in my opinion, critical in the sense > that without it the signature does not make sense, but the implementation's > responsibilities are indeed met by just displaying it upon verification. That's fine. You can define a notation type any way you like. It's perfectly reasonable to define your notation to meet its critical "contract" by being shown to a user. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1swqO073960; Mon, 14 Nov 2005 17:54:58 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1swql073959; Mon, 14 Nov 2005 17:54:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1svrF073952 for ; Mon, 14 Nov 2005 17:54:57 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 11D7657F2F; Mon, 14 Nov 2005 17:56:19 -0800 (PST) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Some -15 comments Message-Id: <20051115015619.11D7657F2F@finney.org> Date: Mon, 14 Nov 2005 17:56:19 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > > I'd like to use the flag as a hint to packet-dumping software: if the > > human-readable flag is set, it is reasonable to dump the notation body > > as text. If it is not set, it should be dumped in hex. > > Currently, the way I treat this flag is that I display the notation to the > user whenever the signature is verified. If that's not the purpuse of this > flag, then I would really like another flag with that purpose. See below > what I would like to use it for. I don't think that will work too well on self-sigs with PGP Corp's new preferred-email-encoding subpackets. You don't want to print those out. > > Another difference arises if the subpacket critical bit is set along with > > the human-readable flag. With the current wording it might appear that an > > implementation's responsibilities are met if it somehow causes the text > > of the notation packet to be displayed to the user, even if it does not > > recognize the notation type. I think that would be a serious mistake. > > The critical bit should require that the notation type be recognized > > and handled, in order for the signature to be considered valid. > > Are you sure? I actually think that displaying some notation whenever the > signature is verified (correctly) makes a lot of sense and it may be part of > signature verification. After all, it is ultimately the user who decides > wheter he accepts a signature or not. I'm worried that this is going to get too messy. For a document signature, if a user wants to put in some qualifications or conditions, it is better to put them into the document itself rather than into a notation packet on the signature in the hopes that it will be displayed. There are no guarantees about display. Then there are key signatures; and under what circumstances will they be displayed? When encrypting some email, do we want to see every notation packet which every signer has decided to add to every key that we encrypt to, and perhaps further packets from keys down the web of trust? How to organize it and present it in a coherent way? It will be a mess. If and when we come to the point where we need a kind of notation packet that should be displayed on signature verification, we should define its use and purpose, create a name for it, and spec it out. I think that is a better path than to have a flag with rather uncertain semantics about when it might cause text to be displayed to the user. > Here is how I am planning to use human-readable notation: in an on-line > trading or auction application, where reputation tracking is important, one > can implement user comments about other users' behavior in the form of > signatures directly on their public keys with appropriate notation (think of > eBay comments). The comment text is, in my opinion, critical in the sense > that without it the signature does not make sense, but the implementation's > responsibilities are indeed met by just displaying it upon verification. You could still do this, but do it based on the notation name rather than a flag. You could have a notation called 'user-reputation-comments' or some such. Your application could then define whatever meaning and handling it wanted for how this type of notation packet should be used. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Dj3q062677; Mon, 14 Nov 2005 16:13:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF0DjRb062676; Mon, 14 Nov 2005 16:13:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Diss062669 for ; Mon, 14 Nov 2005 16:13:44 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8C4452B479F; Tue, 15 Nov 2005 01:13:43 +0100 (CET) Date: Tue, 15 Nov 2005 01:13:43 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115001343.GB5599@epointsystem.org> References: <20051114233744.332A657F2F@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051114233744.332A657F2F@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote: > I'd like to use the flag as a hint to packet-dumping software: if the > human-readable flag is set, it is reasonable to dump the notation body > as text. If it is not set, it should be dumped in hex. Currently, the way I treat this flag is that I display the notation to the user whenever the signature is verified. If that's not the purpuse of this flag, then I would really like another flag with that purpose. See below what I would like to use it for. > David's second version better expresses this, IMO. By just saying > that the note value is text, that means it is reasonable to print it > if desired. Even software which doesn't understand the meaning of the > notation could print it, and it would be readable. > > The current wording carries much more baggage which IMO is not accurate. > We might want to set the human-readable flag on notation packets which > are not primarily meant as notes from one person to another. I agree with this. > Another difference arises if the subpacket critical bit is set along with > the human-readable flag. With the current wording it might appear that an > implementation's responsibilities are met if it somehow causes the text > of the notation packet to be displayed to the user, even if it does not > recognize the notation type. I think that would be a serious mistake. > The critical bit should require that the notation type be recognized > and handled, in order for the signature to be considered valid. Are you sure? I actually think that displaying some notation whenever the signature is verified (correctly) makes a lot of sense and it may be part of signature verification. After all, it is ultimately the user who decides wheter he accepts a signature or not. Here is how I am planning to use human-readable notation: in an on-line trading or auction application, where reputation tracking is important, one can implement user comments about other users' behavior in the form of signatures directly on their public keys with appropriate notation (think of eBay comments). The comment text is, in my opinion, critical in the sense that without it the signature does not make sense, but the implementation's responsibilities are indeed met by just displaying it upon verification. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF01BZs061223; Mon, 14 Nov 2005 16:01:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF01BCw061222; Mon, 14 Nov 2005 16:01:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF019P5061209 for ; Mon, 14 Nov 2005 16:01:10 -0800 (PST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CBDED2B479F; Tue, 15 Nov 2005 01:01:08 +0100 (CET) Date: Tue, 15 Nov 2005 01:01:08 +0100 To: ietf-openpgp@imc.org Subject: Re: Some -15 comments Message-ID: <20051115000108.GA5599@epointsystem.org> References: <20051110175433.GA13632@jabberwocky.com> <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote: > >In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the > >phrase: > > > > "(often literal data packets or compressed data packets)" > > > >should probably be: > > > > "(often a literal data packet or compressed data packet)" > > > >since we no longer allow multiple literal packets in a row. > > > > Changed. Actually, can it be anything else? Most OpenPGP parsers would understand an arbitrary nesting of compressed, encrypted and MDC-protected encrypted packets, but does that make sense? I can see a different use for it, however. Being a bit uneasy about the secret key packet format (Packet tag 5, Section 5.5.1.3.), I think, it is ultimately up to the implementation, how they store and protect private keys, as it does not affect interoperability, as long as private keys can be exported and imported in a common format. Some text about this should be added to 5.5.1.3., in my opinion, stating that implementations SHOULD be able to export and import private keys in this format. It is the more important, as the passphrase-protected version is vulnerable to the Klima-Rosa attack. I am hesitant whether to say that they MAY store them in this way (as most actually do) or would it be more appropriate to say that new implementations SHOULD NOT do that. For secure storage and transmission of private keys, one could put a private key packet (tag 5) without passphrase protection into an MDC-protected encrypted packet (tag 18), maybe with compression in between. This would thwart the Klima-Rosa attack, while not requiring dramatical changes to the standard. But again, I think that the storage format of private keys needs not be standardized. For example, our ePointPGP tool (see http://pgp.epointsystem.org/tool-help) generates private keys directly from the passphrase, without storing them in any way. Yet, it is fully interoperable with many other RFC2440bis implementations on the message and public key level. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENag96058541; Mon, 14 Nov 2005 15:36:42 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAENagHH058540; Mon, 14 Nov 2005 15:36:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENaMYq058506 for ; Mon, 14 Nov 2005 15:36:29 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 332A657F2F; Mon, 14 Nov 2005 15:37:44 -0800 (PST) To: dshaw@jabberwocky.com, jon@callas.org Subject: Re: Some -15 comments Cc: ietf-openpgp@imc.org Message-Id: <20051114233744.332A657F2F@finney.org> Date: Mon, 14 Nov 2005 15:37:44 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes, quoting David: > > We discussed a change to 5.2.3.16 (Notation Data) on the list to > > change: > > > > First octet: 0x80 = human-readable. This note value is text, a > > note from one person to another, and need > > not have meaning to software. > > to: > > First octet: 0x80 = human-readable. This note value is text. > > > > Any way that can go in? I'm perfectly happy to get an "I Told You So" > > if someone is confused :) > > > > I remember the discussion, I just don't remember the agreement. Such > is the way with rough consensus. > > Does it matter one way or the other? I admit to being confused as to > why it matters. Enlighten me, please. What is the functional purpose of this flag? The meaning of the notation is going to come from its name field. The flag is somewhat superfluous. I'd like to use the flag as a hint to packet-dumping software: if the human-readable flag is set, it is reasonable to dump the notation body as text. If it is not set, it should be dumped in hex. David's second version better expresses this, IMO. By just saying that the note value is text, that means it is reasonable to print it if desired. Even software which doesn't understand the meaning of the notation could print it, and it would be readable. The current wording carries much more baggage which IMO is not accurate. We might want to set the human-readable flag on notation packets which are not primarily meant as notes from one person to another. Another difference arises if the subpacket critical bit is set along with the human-readable flag. With the current wording it might appear that an implementation's responsibilities are met if it somehow causes the text of the notation packet to be displayed to the user, even if it does not recognize the notation type. I think that would be a serious mistake. The critical bit should require that the notation type be recognized and handled, in order for the signature to be considered valid. PGP Corporation added the preferred-email-encoding self-signature notation packet, and it has the human-readable flag set. This is not a note from one person to another, rather it is intended solely to be handled by the software. However it is human readable and if the key is displayed in some detailed way it would be reasonable for the software to print the contents of the notation packet. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkRSj052407; Mon, 14 Nov 2005 14:46:27 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEMkR8N052406; Mon, 14 Nov 2005 14:46:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkQOp052399 for ; Mon, 14 Nov 2005 14:46:26 -0800 (PST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 14 Nov 2005 14:46:22 -0800 Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Nov 2005 14:46:22 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Nov 2005 14:46:22 -0800 In-Reply-To: <20051110175433.GA13632@jabberwocky.com> References: <20051110175433.GA13632@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B8D886D-0DA8-4C02-8956-0ED23F56B2D8@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Some -15 comments Date: Mon, 14 Nov 2005 14:46:26 -0800 To: David Shaw X-Mailer: Apple Mail (2.746.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 10 Nov 2005, at 9:54 AM, David Shaw wrote: > > I did a quick read over bis15: > > In 5.2.1. Signature Types, in the section about the 0x18 subkey > binding signature, the binding for a signing subkey MUST (not SHOULD) > contain a back signature. This was discussed on the list. > Fixed. > ====== > > We discussed a change to 5.2.3.16 (Notation Data) on the list to > change: > > First octet: 0x80 = human-readable. This note value is text, a > note from one person to another, and need > not have meaning to software. > to: > First octet: 0x80 = human-readable. This note value is text. > > Any way that can go in? I'm perfectly happy to get an "I Told You So" > if someone is confused :) > I remember the discussion, I just don't remember the agreement. Such is the way with rough consensus. Does it matter one way or the other? I admit to being confused as to why it matters. Enlighten me, please. > ====== > > 5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail > name", but there is no such object in 2822. 2822 calls it a > "name-addr". > Changed to name-addr > ====== > > In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the > phrase: > > "(often literal data packets or compressed data packets)" > > should probably be: > > "(often a literal data packet or compressed data packet)" > > since we no longer allow multiple literal packets in a row. > Changed. > ====== > > In 13. Security Considerations, in the section discussing the > Mister/Zuccherato attack, the last sentence of the third paragraph is > missing a period. > Fixed. > ====== > > Aside from that, has anyone heard anything new about the rumored > "bigger DSA" update? I asked during the hash bash and was told, "soon." But then, that's what I was told at CRYPTO 2004. Don't hold your breath. Incidentally, I apologize for not getting this out before. I sent it to the I-D desk, who whined at me. My correction was eaten by an MTA, which took two weeks to tell me that it was confused, and by then the meeting lull had happened. So can we take the two-week comment period for last call and make it be Nov 21? Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsjor097982; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAHsjVZ097981; Thu, 10 Nov 2005 09:54:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsim2097953 for ; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111017543501400lreqhe>; Thu, 10 Nov 2005 17:54:39 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAHsZX6032087 for ; Thu, 10 Nov 2005 12:54:35 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAHsX8w013727 for ; Thu, 10 Nov 2005 12:54:33 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAHsXP6013726 for ietf-openpgp@imc.org; Thu, 10 Nov 2005 12:54:33 -0500 Date: Thu, 10 Nov 2005 12:54:33 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some -15 comments Message-ID: <20051110175433.GA13632@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I did a quick read over bis15: In 5.2.1. Signature Types, in the section about the 0x18 subkey binding signature, the binding for a signing subkey MUST (not SHOULD) contain a back signature. This was discussed on the list. ====== We discussed a change to 5.2.3.16 (Notation Data) on the list to change: First octet: 0x80 = human-readable. This note value is text, a note from one person to another, and need not have meaning to software. to: First octet: 0x80 = human-readable. This note value is text. Any way that can go in? I'm perfectly happy to get an "I Told You So" if someone is confused :) ====== 5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail name", but there is no such object in 2822. 2822 calls it a "name-addr". ====== In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the phrase: "(often literal data packets or compressed data packets)" should probably be: "(often a literal data packet or compressed data packet)" since we no longer allow multiple literal packets in a row. ====== In 13. Security Considerations, in the section discussing the Mister/Zuccherato attack, the last sentence of the third paragraph is missing a period. ====== Aside from that, has anyone heard anything new about the rumored "bigger DSA" update? David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWrst087577; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAGWrVV087576; Thu, 10 Nov 2005 08:32:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWorM087565 for ; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAAGWkeS015293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Nov 2005 17:32:47 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 References: <20051103162144.GC1303@jabberwocky.com> <20051110153421.GA13510@jabberwocky.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051110:ietf-openpgp@imc.org::thcmyLtxZtH0mbvL:4CVN Date: Thu, 10 Nov 2005 17:32:40 +0100 In-Reply-To: <20051110153421.GA13510@jabberwocky.com> (David Shaw's message of "Thu, 10 Nov 2005 10:34:21 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote: > >> Yes, how about this use-case: An announcement-only mailing list >> might prefer OpenPGP signed messages. It could then add a 'OpenPGP: >> preference=sign' message to all list posts. The sender could be the >> mailing list address, which may not have a OpenPGP key at all. So >> you couldn't fetch an OpenPGP key for the mailing list address. >> Arguable, the mailing list managers could create a dummy OpenPGP key >> for the mailing list address, and set the e-mail preference and >> upload the key. However, so could anyone, since the key isn't used >> nor trusted by anyone. The announcement-only mailing list could be >> some abstract mail addresses too. Like submit@bugs.debian.org or >> similar. > > I agree this is a reasonable use. I've also re-read over the -02 > draft, and it does have language in section 2 about not overtrusting > the header that I had missed earlier. > > Would it be worth making this more explicit by adding something about > actual conflicts between the OpenPGP header and the key to that > section? Something like: Section 2 is intended to give an introduction, so I believe such text should belong in the section that define the header. It would be useful to repeat the warning there as well. I have added the following at the beginning of section 3: Because the header is typically not integrity protected, the information conveyed in the OpenPGP header field MUST NOT be trusted without additional verification. Some of the information given in this header may also be given on the OpenPGP key itself. When these two sources conflict, users SHOULD favor the information from the OpenPGP key, as that information can be cryptographically protected. What do you think? Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYU3G079567; Thu, 10 Nov 2005 07:34:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAFYU5A079566; Thu, 10 Nov 2005 07:34:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYTFt079558 for ; Thu, 10 Nov 2005 07:34:29 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005111015342301400p7qgie>; Thu, 10 Nov 2005 15:34:23 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAFYNX6031579 for ; Thu, 10 Nov 2005 10:34:23 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAFYLxQ013563 for ; Thu, 10 Nov 2005 10:34:21 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAFYL4p013562 for ietf-openpgp@imc.org; Thu, 10 Nov 2005 10:34:21 -0500 Date: Thu, 10 Nov 2005 10:34:21 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051110153421.GA13510@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051103162144.GC1303@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote: > Yes, how about this use-case: An announcement-only mailing list > might prefer OpenPGP signed messages. It could then add a 'OpenPGP: > preference=sign' message to all list posts. The sender could be the > mailing list address, which may not have a OpenPGP key at all. So > you couldn't fetch an OpenPGP key for the mailing list address. > Arguable, the mailing list managers could create a dummy OpenPGP key > for the mailing list address, and set the e-mail preference and > upload the key. However, so could anyone, since the key isn't used > nor trusted by anyone. The announcement-only mailing list could be > some abstract mail addresses too. Like submit@bugs.debian.org or > similar. I agree this is a reasonable use. I've also re-read over the -02 draft, and it does have language in section 2 about not overtrusting the header that I had missed earlier. Would it be worth making this more explicit by adding something about actual conflicts between the OpenPGP header and the key to that section? Something like: Some of the information given in this header may also be given on the OpenPGP key itself. When these two sources conflict, users SHOULD favor the information from the OpenPGP key, as that information can be cryptographically protected. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No2vK045479; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA7No2Rq045478; Mon, 7 Nov 2005 15:50:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No1qm045464 for ; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EZGkT-0005cZ-Eq; Mon, 07 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-15.txt Message-Id: Date: Mon, 07 Nov 2005 18:50:01 -0500 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 : OpenPGP Message Format Author(s) : J. Callas, et al. Filename : draft-ietf-openpgp-rfc2440bis-15.txt Pages : 73 Date : 2005-11-7 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2440bis-15.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-rfc2440bis-15.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: <2005-11-7164522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-7164522.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJLXq067361; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4FJLoN067360; Fri, 4 Nov 2005 07:19:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net ([63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJKv2067307 for ; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005110415184501400sua2ve>; Fri, 4 Nov 2005 15:18:45 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA4FIjX6026720 for ; Fri, 4 Nov 2005 10:18:45 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA4FIi2q005063 for ; Fri, 4 Nov 2005 10:18:44 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA4FIijF005062 for ietf-openpgp@imc.org; Fri, 4 Nov 2005 10:18:44 -0500 Date: Fri, 4 Nov 2005 10:18:44 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051104151844.GA4972@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20051103162144.GC1303@jabberwocky.com> <200511031348.26342.brian@braverock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511031348.26342.brian@braverock.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Nov 03, 2005 at 01:48:25PM -0600, Brian G. Peterson wrote: > > On Thursday 03 November 2005 10:21 am, David Shaw wrote: > > I have some concerns with this preference field. There is already a > > way to specify this preference on the key itself > > ("preferred-email-encoding@pgp.com"). > > I'd like to see the preferred-email-encoding issue covered in an RFC or draft. > I think that the issues around user preference and interoperability really > need to be in an official RFC. Hopefully we can take this up as 2440bis > winds up and moves on into the next stages. I agree. I think the current design is just fine, but documenting it in an RFC is a good thing to do. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpjcP064017; Fri, 4 Nov 2005 06:51:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4EpjA6064016; Fri, 4 Nov 2005 06:51:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpfpJ064004 for ; Fri, 4 Nov 2005 06:51:44 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA4EpbGs000401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2005 15:51:38 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 References: <20051103162144.GC1303@jabberwocky.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051104:ietf-openpgp@imc.org::cPU0iZLr2Tu4Io8A:1v8d Date: Fri, 04 Nov 2005 15:51:35 +0100 In-Reply-To: <20051103162144.GC1303@jabberwocky.com> (David Shaw's message of "Thu, 3 Nov 2005 11:21:44 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote: >> >> Hi everyone! FYI: >> >> I submitted an updated version of this document a few weeks ago. The >> changes since -01 are small: A new "preference" field has been added, >> to signal whether the sender wish that e-mail should be signed, >> encrypted or both. > > I have some concerns with this preference field. There is already a > way to specify this preference on the key itself > ("preferred-email-encoding@pgp.com"). That is not standardized though. I agree with Brian that I'd like to see it standardized. > Once a user finds the key, they have an authoritative and > tamperproof statement about email preference. The OpenPGP header is > not tamperproof, and having the preference in there raises the > question what to do if the header preference doesn't match the > preference on the key. I hope the OpenPGP document doesn't leave any questions as to what should happen. The document says in several places that it is for informational purposes, and that the information should not be considered trust-worthy. > I see the OpenPGP header as a useful key finding aid. Once the key is > found, though, the header has served its purpose. I recall some situations where this preference field might be useful. I think it was another way to bootstrap OpenPGP communication. Yes, how about this use-case: An announcement-only mailing list might prefer OpenPGP signed messages. It could then add a 'OpenPGP: preference=sign' message to all list posts. The sender could be the mailing list address, which may not have a OpenPGP key at all. So you couldn't fetch an OpenPGP key for the mailing list address. Arguable, the mailing list managers could create a dummy OpenPGP key for the mailing list address, and set the e-mail preference and upload the key. However, so could anyone, since the key isn't used nor trusted by anyone. The announcement-only mailing list could be some abstract mail addresses too. Like submit@bugs.debian.org or similar. I haven't thought this idea through, so it may be silly. However, I recall convincing myself that the OpenPGP field may be useful in some situations where a OpenPGP key preference field is less useful. These two ideas doesn't have to be mutually exclusive. It is clear that the tamper-proof preference should be preferred, if you trust that key, but otherwise it doesn't matter. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmdYY020109; Thu, 3 Nov 2005 11:48:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JmdEr020108; Thu, 3 Nov 2005 11:48:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmbV8020101 for ; Thu, 3 Nov 2005 11:48:38 -0800 (PST) (envelope-from brian@braverock.com) Received: from [10.23.3.106] (terminus [66.92.135.15]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id jA3JmR14023971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Nov 2005 13:48:28 -0600 From: "Brian G. Peterson" Organization: Braverock Ventures To: Simon Josefsson , ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Date: Thu, 3 Nov 2005 13:48:25 -0600 User-Agent: KMail/1.8.3 References: <20051103162144.GC1303@jabberwocky.com> In-Reply-To: <20051103162144.GC1303@jabberwocky.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511031348.26342.brian@braverock.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thursday 03 November 2005 10:21 am, David Shaw wrote: > I have some concerns with this preference field. There is already a > way to specify this preference on the key itself > ("preferred-email-encoding@pgp.com"). I'd like to see the preferred-email-encoding issue covered in an RFC or draft. I think that the issues around user preference and interoperability really need to be in an official RFC. Hopefully we can take this up as 2440bis winds up and moves on into the next stages. Regards, - Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JVA9B018600; Thu, 3 Nov 2005 11:31:10 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JVAmU018599; Thu, 3 Nov 2005 11:31:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JV4vA018583 for ; Thu, 3 Nov 2005 11:31:04 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110319305401300g34ase>; Thu, 3 Nov 2005 19:30:56 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3JUsX6022478; Thu, 3 Nov 2005 14:30:54 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3JUqd5001689; Thu, 3 Nov 2005 14:30:52 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3JUpF1001688; Thu, 3 Nov 2005 14:30:51 -0500 Date: Thu, 3 Nov 2005 14:30:51 -0500 From: David Shaw To: Anand Kumria Cc: atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Message-ID: <20051103193051.GA1671@jabberwocky.com> Mail-Followup-To: Anand Kumria , atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org References: <20051031072532.GC29693@progsoc.uts.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051031072532.GC29693@progsoc.uts.edu.au> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 31, 2005 at 06:25:32PM +1100, Anand Kumria wrote: > Hi there, > > The openpgp-mailnews-header defines a mechanism for senders to notify > recipients of both their preferences (w.r.t OpenPGP keys) and the keying > material to be used (e.g. keyid). > > dnsext-rfc2538bis defines a mechanism where keying material is stored > within the DNS (e.g. OpenPGP). The overlap here is that users may wish > to store their key in the DNS (via dnsext-rfc2538bis) and refer to them > using openpgp-mailnews-header. > > Since openpgp-mailnews-header specifies using a URI to refer to the > location, it would seem -- to me at least -- that there needs to be some > kind of URI specification to allow you to refer to DNS resource records. > > Is there one already, or work underway to produce a DNS URI spec.? There is this, by the same author as rfc2538bis: http://josefsson.org/dns-url/draft-josefsson-dns-url-13.txt David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GMCSV095590; Thu, 3 Nov 2005 08:22:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3GMC1N095589; Thu, 3 Nov 2005 08:22:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GM9dd095571 for ; Thu, 3 Nov 2005 08:22:09 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110316214901300g0hkce>; Thu, 3 Nov 2005 16:21:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3GLmX6021881; Thu, 3 Nov 2005 11:21:48 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3GLljG001489; Thu, 3 Nov 2005 11:21:47 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3GLiLx001488; Thu, 3 Nov 2005 11:21:44 -0500 Date: Thu, 3 Nov 2005 11:21:44 -0500 From: David Shaw To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP mail/news header -02 Message-ID: <20051103162144.GC1303@jabberwocky.com> Mail-Followup-To: Simon Josefsson , ietf-openpgp@imc.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote: > > Hi everyone! FYI: > > I submitted an updated version of this document a few weeks ago. The > changes since -01 are small: A new "preference" field has been added, > to signal whether the sender wish that e-mail should be signed, > encrypted or both. I have some concerns with this preference field. There is already a way to specify this preference on the key itself ("preferred-email-encoding@pgp.com"). Once a user finds the key, they have an authoritative and tamperproof statement about email preference. The OpenPGP header is not tamperproof, and having the preference in there raises the question what to do if the header preference doesn't match the preference on the key. I see the OpenPGP header as a useful key finding aid. Once the key is found, though, the header has served its purpose. David
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://andadobeoem.com/?u>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: xFVisg= KZH
Platform: Windows XP

Sales Rank: #1
<= /span>System requi= rements  |  Other Versio= ns
Date Coupon Expires: December = 31st, 2005
Average Customer Review: Based on 1118 reviews. Write a = review.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: ONiS4
= Platform: Wind= ows XP

Sales Rank: #2
System requirements<= /a>  |  Other Versions
Date Coupon Expires: December 31st, 20= 05
Average Customer Review:3D"5 B= ased on 176167 reviews. Write a review= .

Microsoft Office 2003 *Professional*<= br> Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: q8ROrx9
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 191991 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)

Adobe Acrobat Professional V 7.0
Adobe

C= hoose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://andadobeoem.com/?O>

Availability: Available for INSTANT download= !
Coupon Code: OuAtRf
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions
Date = Coupon Expires: December 31st, 2005
A= verage Customer Review:3D"5 Based on 19764 reviews. Write a review.