From owner-ietf-openpgp@mail.imc.org Sun Dec 2 13:23:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26399 for ; Sun, 2 Dec 2001 13:23:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB2HuIT11551 for ietf-openpgp-bks; Sun, 2 Dec 2001 09:56:18 -0800 (PST) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB2HuG211547 for ; Sun, 2 Dec 2001 09:56:16 -0800 (PST) Received: (cpmta 12127 invoked from network); 2 Dec 2001 09:56:12 -0800 Received: from 80.130.170.210 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.72) with SMTP; 2 Dec 2001 09:56:12 -0800 X-Sent: 2 Dec 2001 17:56:12 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE Message-Id: <200112022052.21502@sendmail.mutz.com> To: John J Kane , ietf-openpgp@imc.org Subject: Re: prefer "- From " instead of ">From "?? Date: Sun, 2 Dec 2001 20:59:17 +0100 X-Mailer: KMail [version 1.3.7] References: <3C0638F9.BC15DE1F@softhome.net> In-Reply-To: <3C0638F9.BC15DE1F@softhome.net> X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fB2HuG211548 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 November 2001 14:32, John J Kane wrote: > This may be the sanest way to handle that case. > Comments? For an OpenPGP implementation this is OK, I guess. But the real fix is replacing one of the five chars "From " with it's quoted-printable hexchar, e.g. "From=20". This kills all issues at the most appropriate level: The MUA. But this only works for messages encoded in qp, though I wouldn't hesitate forcing the MUA to use qp for text that matches "^From ", KMail/Aegypten in our case. Marc - -- FTAA's anti-circumvention provisions represent US imperialism at its worst. They seek to impose restrictive laws on both the US and other countries, in order to prevent established US businesses from facing both domestic and foreign competition. -- EFF FTAA Alert: Stop Hollywood Forcing Technology Ban on 34 Countries -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8CogV3oWD+L2/6DgRAhfSAJ9H7lkakTnvdG/CGXPIARZZkKisIQCggGpS 5hJdG7n9lplw8Q5SXW22w+U= =vRKV -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Dec 4 18:17:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17241 for ; Tue, 4 Dec 2001 18:17:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB4MqGa22372 for ietf-openpgp-bks; Tue, 4 Dec 2001 14:52:16 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4MqE222367 for ; Tue, 4 Dec 2001 14:52:15 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB4Mpog10420 for ietf-openpgp@imc.org; Tue, 4 Dec 2001 17:51:50 -0500 Date: Tue, 4 Dec 2001 17:51:50 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Notation data language Message-ID: <20011204175150.A10291@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (81% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been writing some code involving notation data (5.3.2.16 in bis-03). As I read it, the human-readable flag applies to the value data of the name=value pair and not to the name data. If I do read this correctly, I'd like to suggest a change in the line "This note is text, a note from one person to another, and has no meaning to software." to read "The value is text, a note from one person...", etc, which would help make clear what the human readable flag applies to. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Dec 5 13:42:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01786 for ; Wed, 5 Dec 2001 13:42:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5IM4t18690 for ietf-openpgp-bks; Wed, 5 Dec 2001 10:22:04 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB5IM3218686 for ; Wed, 5 Dec 2001 10:22:03 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA27718; Wed, 5 Dec 2001 10:18:24 -0800 Date: Wed, 5 Dec 2001 10:18:24 -0800 From: hal@finney.org Message-Id: <200112051818.KAA27718@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org Subject: Re: Notation data language Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I've been writing some code involving notation data (5.3.2.16 in > bis-03). As I read it, the human-readable flag applies to the value > data of the name=value pair and not to the name data. > > If I do read this correctly, I'd like to suggest a change in the line > "This note is text, a note from one person to another, and has no > meaning to software." to read "The value is text, a note from one > person...", etc, which would help make clear what the human readable > flag applies to. I don't fully understand the distinction. You are saying that the "name" part would be machine readable, but the "value" part would not? What would be the point of trying to restrict the name to be machine readable if it couldn't do anything with the value? I think it makes more sense to say that this flag means that machines shouldn't try to read any of the notation, rather than that they can read part of it but not the rest. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Dec 5 13:53:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02337 for ; Wed, 5 Dec 2001 13:53:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5IbmZ19162 for ietf-openpgp-bks; Wed, 5 Dec 2001 10:37:48 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Ibk219158 for ; Wed, 5 Dec 2001 10:37:47 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5IbeQ02119; Wed, 5 Dec 2001 13:37:40 -0500 Date: Wed, 5 Dec 2001 13:37:40 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205133740.A682@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org References: <200112051818.KAA27718@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112051818.KAA27718@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 10:18:24AM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 10:18:24AM -0800, hal@finney.org wrote: > David Shaw writes: > > I've been writing some code involving notation data (5.3.2.16 in > > bis-03). As I read it, the human-readable flag applies to the value > > data of the name=value pair and not to the name data. > > > > If I do read this correctly, I'd like to suggest a change in the line > > "This note is text, a note from one person to another, and has no > > meaning to software." to read "The value is text, a note from one > > person...", etc, which would help make clear what the human readable > > flag applies to. > > I don't fully understand the distinction. You are saying that the > "name" part would be machine readable, but the "value" part would not? Other way around - the language in the draft ("Notation names are arbitrary strings encoded in UTF-8") strongly suggests that the the human-readable flag only applies to the "value", and the "name" is always human readable, albeit UTF8. I was hoping to make the language clearer, or if I misread the document, to make it clearer in the other direction :) David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Dec 5 14:41:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05962 for ; Wed, 5 Dec 2001 14:41:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB5JFoM21937 for ietf-openpgp-bks; Wed, 5 Dec 2001 11:15:50 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5JFn221933 for ; Wed, 5 Dec 2001 11:15:49 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA27637 for ietf-openpgp@imc.org; Wed, 5 Dec 2001 09:59:15 -0800 Date: Wed, 5 Dec 2001 09:59:15 -0800 From: hal@finney.org Message-Id: <200112051759.JAA27637@finney.org> To: ietf-openpgp@imc.org Subject: Text canonicalization Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A few days ago an issue arose on a cryptography mailing list about a failing PGP signature on a software package being distributed. The problem was traced to the fact that the signature was in text mode on this binary package. However it raises some issues in the OpenPGP spec treatment of text mode signatures. Section 5.2.1 of RFC2440 describes the processing for signatures on text documents as "The signature is calculated over the text data with its line endings converted to and trailing blanks removed." There are two problems with this. The first is that it does not make clear what constitutes line endings. In PGP we treat CR LF, CR, and LF all as line endings and convert each one to CR LF. Each of these is used as a line ending on one of the architectures we support; CR LF on Windows, CR on Macintosh, and LF on Unix. We don't restrict the conversion to just native line endings for two reasons. First, in a true text document you will have only native line endings so supporting the others will have no harmful effects; and second, sometimes you run into text documents with non-native line endings (because they were transferred in binary mode from another architecture) and by transforming those line endings as well you increase the chances of verifying a signature correctly. I recommend that we specify this canonicalization rule. The second issue relates to removing trailing blanks. This is an error in the spec, as was pointed out by Ulf M=F6ller less than a month before RFC 2440 issued. Unfortunately in the busy time before the RFC this comment was overlooked and the spec issued with this error. No version of PGP has ever removed trailing blanks in canonicalizing a text document. (They are ignored for *clearsigned* text documents, but that is another matter.) This issue has caused problems for people from time to time since the RFC has issued. I recommend that we solve the problem by changing the spec to conform to how PGP has always worked. We should eliminate the words "and trailing blanks removed" from the section above. Comments? Hal Finney Network Associates From owner-ietf-openpgp@mail.imc.org Wed Dec 5 14:44:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06112 for ; Wed, 5 Dec 2001 14:44:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5JQQO22168 for ietf-openpgp-bks; Wed, 5 Dec 2001 11:26:26 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5JQP222164 for ; Wed, 5 Dec 2001 11:26:25 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5JQLp02970; Wed, 5 Dec 2001 14:26:21 -0500 Date: Wed, 5 Dec 2001 14:26:21 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205142621.C682@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org References: <200112051844.KAA27904@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112051844.KAA27904@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 10:44:46AM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 10:44:46AM -0800, hal@finney.org wrote: > Maybe the best thing would be if you could tell us more about how you > are planning to use notation data. This is not a feature which is > currently used in PGP, it is intended for support of new applications. > It's always difficult to specify a feature when you don't know how it > will be used. Usually in IETF we try to do things the other way around. > But this was intended as an escape clause for future expansion, so we > had to specify it without any practical experience to guide us. Understood. Unfortunately, I'm not sure we're really communicating. I'm not creating any notations. However, I am writing code that can display notations. The question can be boiled down to whether the "name" of the name=value pair is always human readable. "Human readable", to me, meaning that it is made up of characters that can be displayed in some more or less readable way (i.e. printable characters). As I said, the draft seems to say that this is the case. If it isn't the case, that's fine too. I'm just trying to clarify the point. For what it's worth, although none have been officially described by the IETF, some notations are being used. On my keyring at the moment exist a few notations names like "Certification" and "COMMENT" (and a handful of "foo", of course). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Dec 5 15:29:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09400 for ; Wed, 5 Dec 2001 15:29:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5K7ae23558 for ietf-openpgp-bks; Wed, 5 Dec 2001 12:07:36 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5K7Z223551 for ; Wed, 5 Dec 2001 12:07:35 -0800 (PST) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 16BiKH-0004aj-00 for ietf-openpgp@imc.org; Wed, 05 Dec 2001 21:07:29 +0100 To: ietf-openpgp@imc.org Subject: Re: Text canonicalization References: <200112051759.JAA27637@finney.org> From: Florian Weimer Date: 05 Dec 2001 21:07:29 +0100 In-Reply-To: <200112051759.JAA27637@finney.org> (hal@finney.org's message of "Wed, 5 Dec 2001 09:59:15 -0800") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org writes: > The first is that it does not make clear what constitutes line endings. > In PGP we treat CR LF, CR, and LF all as line endings and convert each > one to CR LF. What about the other line ending characters? With Unicode (or even ISO-8859-x close to an EBCDIC environment), there a few more characters which could end a line. What about systems such as VMS with out-of-band signalling for line endings? -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Wed Dec 5 16:34:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13589 for ; Wed, 5 Dec 2001 16:34:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5LFoB27136 for ietf-openpgp-bks; Wed, 5 Dec 2001 13:15:50 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5LFn227131 for ; Wed, 5 Dec 2001 13:15:49 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA27904; Wed, 5 Dec 2001 10:44:46 -0800 Date: Wed, 5 Dec 2001 10:44:46 -0800 From: hal@finney.org Message-Id: <200112051844.KAA27904@finney.org> To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Maybe the best thing would be if you could tell us more about how you are planning to use notation data. This is not a feature which is currently used in PGP, it is intended for support of new applications. It's always difficult to specify a feature when you don't know how it will be used. Usually in IETF we try to do things the other way around. But this was intended as an escape clause for future expansion, so we had to specify it without any practical experience to guide us. Hal From owner-ietf-openpgp@mail.imc.org Wed Dec 5 17:48:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18064 for ; Wed, 5 Dec 2001 17:48:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5MRNc01105 for ietf-openpgp-bks; Wed, 5 Dec 2001 14:27:23 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5MRM201101 for ; Wed, 5 Dec 2001 14:27:22 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Wed, 5 Dec 2001 14:27:05 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20011204175150.A10291@akamai.com> References: <20011204175150.A10291@akamai.com> Date: Wed, 5 Dec 2001 14:26:18 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Notation data language Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You are right, the human-readable flag applies to the data, not the name. I'll add in what you wanted, to make it clearer. As for the name -- well, I have no idea. I have an intuitive sense of what human readable means for the value. For example, "I have read this document, but do not agree with much of its content, call or email for long-winded details" is a fine human-readable notation, and one of the purposes it's there for. I can even understand that the semantic content of that note can be put in any arbitrary language and encoded in whatever alphabets in unicode, and it's still "human readable" even if that human better speak Esperanto. But is "method://whatever/goes/in/a/uri" human-readable? Tim Berners-Lee thinks not. Or thought not. The protocol we describe in 2440bis for names doesn't make them human readable in some sense of the word, and in fact clucks its tongue at a name like "Statement about what my signature means" which is a *fine* human readable name to go along with the human readable value. My opinion is this: Pick your names with a small amount of wisdom. No matter what you do, someone will be sure to tell you that you did the wrong thing. A notation means what its creator wants it to mean. Unlike most data, since this is contained in a signature, there's a known creator of that data. Consequently, the disambiguation we have in the standard is really overkill. However, the reason for a notation is communication, and there are two parties in communication. If you pick a name tag that someone else will interpret differently than what you mean, then you have a problem. That's why a small amount of wisdom is needed, and if you pick some scheme like the one in 2440bis, or the backwards-domain scheme that Java uses, fewer people will cluck their tongues at you than would if you used a name like "a". And yet a name like "ReadMe" is pretty obvious, even if squishy and non-standard. You're a bright guy, there are lots of reasonable things to do. Pick one. Jon From owner-ietf-openpgp@mail.imc.org Wed Dec 5 18:38:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21030 for ; Wed, 5 Dec 2001 18:38:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5NLmF03576 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:21:48 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB5NLl203572 for ; Wed, 5 Dec 2001 15:21:47 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA28651; Wed, 5 Dec 2001 15:14:29 -0800 Date: Wed, 5 Dec 2001 15:14:29 -0800 From: hal@finney.org Message-Id: <200112052314.PAA28651@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the draft language: All undefined flags MUST be zero. Defined flags are: First octet: 0x80 = human-readable. This note is text, a note from one person to another, and has no meaning to software. My interpretation is that this is not so much a guarantee that the data is human readable, as that it is NOT machine readable. In other words the operational effect is that software should not try to interpret it. It would be OK to have it be in some secret language that only one other person could understand. So on this basis if you wanted to put a URL in there that would be fine, setting this flag just says that software shouldn't try to parse and understand it. Hal From owner-ietf-openpgp@mail.imc.org Wed Dec 5 19:12:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22237 for ; Wed, 5 Dec 2001 19:12:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB5NsCg05128 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:54:12 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5NsB205122 for ; Wed, 5 Dec 2001 15:54:11 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5Ns7T08666; Wed, 5 Dec 2001 18:54:07 -0500 Date: Wed, 5 Dec 2001 18:54:07 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Message-ID: <20011205185407.A8367@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org, jon@callas.org References: <200112052314.PAA28651@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112052314.PAA28651@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 03:14:29PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 03:14:29PM -0800, hal@finney.org wrote: > Here is the draft language: > > All undefined flags MUST be zero. Defined flags are: > > First octet: 0x80 = human-readable. This note is text, a note > from one person to another, and has no > meaning to software. > > My interpretation is that this is not so much a guarantee that the data > is human readable, as that it is NOT machine readable. In other words > the operational effect is that software should not try to interpret it. > It would be OK to have it be in some secret language that only one other > person could understand. So on this basis if you wanted to put a URL > in there that would be fine, setting this flag just says that software > shouldn't try to parse and understand it. Hmm. I read this to say that the data was human readable in that it could be shown to a human being without special processing (i.e. that it was printable, and not a chunk of binary data). As I see it (and this departs from the language in the draft), being human readable shouldn't necessarily mean that the data cannot also be machine readable. To use the URL example, if there was a "myhomepage@akamai.com" name (to use the proper user name space from the draft), and that was defined as a URL for my home page, I don't see any particular reason why a machine shouldn't process such data - the processing function would be keyed off of the "name" value, so the program would have a pretty good notion of what was going to be present in the "value" field. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Dec 5 19:14:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22310 for ; Wed, 5 Dec 2001 19:14:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5Ns4v05112 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:54:04 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Ns3205108 for ; Wed, 5 Dec 2001 15:54:03 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5Nrue08660; Wed, 5 Dec 2001 18:53:56 -0500 Date: Wed, 5 Dec 2001 18:53:56 -0500 From: David Shaw To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205185356.C7439@akamai.com> Mail-Followup-To: Jon Callas , ietf-openpgp@imc.org References: <20011204175150.A10291@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Dec 05, 2001 at 02:26:18PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 02:26:18PM -0800, Jon Callas wrote: > You are right, the human-readable flag applies to the data, not the name. > I'll add in what you wanted, to make it clearer. > > As for the name -- well, I have no idea. > > I have an intuitive sense of what human readable means for the value. For > example, "I have read this document, but do not agree with much of its > content, call or email for long-winded details" is a fine human-readable > notation, and one of the purposes it's there for. I can even understand > that the semantic content of that note can be put in any arbitrary language > and encoded in whatever alphabets in unicode, and it's still "human > readable" even if that human better speak Esperanto. I'm not currently generating notations - the question arose from an implementation choice on whether to print all names even if I could not print all values. If I was generating notations, I'd use the 2440bis method - it provides the happy accident of looking like an email address so you can be contacted by someone who wants to add support for the private tag to their implementation. When I read the draft, I assumed human-readable meant that the data was able to be shown to a human being without special processing. Something close to "if I can printf() it, it's human readable" (of course there is UTF8, but I think you get my drift). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Dec 5 19:20:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22438 for ; Wed, 5 Dec 2001 19:20:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB601fn05635 for ietf-openpgp-bks; Wed, 5 Dec 2001 16:01:41 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB601e205630 for ; Wed, 5 Dec 2001 16:01:40 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA28877; Wed, 5 Dec 2001 15:58:08 -0800 Date: Wed, 5 Dec 2001 15:58:08 -0800 From: hal@finney.org Message-Id: <200112052358.PAA28877@finney.org> To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org, jon@callas.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > As I see it (and this departs from the language in the draft), being > human readable shouldn't necessarily mean that the data cannot also be > machine readable. > > To use the URL example, if there was a "myhomepage@akamai.com" name > (to use the proper user name space from the draft), and that was > defined as a URL for my home page, I don't see any particular reason > why a machine shouldn't process such data - the processing function > would be keyed off of the "name" value, so the program would have a > pretty good notion of what was going to be present in the "value" > field. Instead, I would handle this by not setting the human-readable flag, and instead choose a name for the notation which tells the machine that it is a URL. Then the software can know that URLs can be safely displayed to a human. Leaving the human-readable flag clear allows the software to read and try to understand the notation. Nothing prevents it from displaying it to a human if the semantics of that notation imply that it would be reasonable. Hal From owner-ietf-openpgp@mail.imc.org Wed Dec 5 19:22:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22494 for ; Wed, 5 Dec 2001 19:22:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5Nwg105435 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:58:42 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Nwe205426 for ; Wed, 5 Dec 2001 15:58:41 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA09639; Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA270404; Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) Message-ID: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: >For what it's worth, although none have been officially described by the IETF, >some notations are being used. On my keyring at the moment exist a few >notations names like "Certification" and "COMMENT" (and a handful of "foo", of >course). I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) to create PGP signatures. Peter. From owner-ietf-openpgp@mail.imc.org Wed Dec 5 20:05:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23772 for ; Wed, 5 Dec 2001 20:05:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB60K9Q07105 for ietf-openpgp-bks; Wed, 5 Dec 2001 16:20:09 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60K8207099 for ; Wed, 5 Dec 2001 16:20:08 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB60K5S09146; Wed, 5 Dec 2001 19:20:05 -0500 Date: Wed, 5 Dec 2001 19:20:05 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Message-ID: <20011205192005.E7439@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org, jon@callas.org References: <200112052358.PAA28877@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112052358.PAA28877@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 03:58:08PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 03:58:08PM -0800, hal@finney.org wrote: > David Shaw writes: > > As I see it (and this departs from the language in the draft), being > > human readable shouldn't necessarily mean that the data cannot also be > > machine readable. > > > > To use the URL example, if there was a "myhomepage@akamai.com" name > > (to use the proper user name space from the draft), and that was > > defined as a URL for my home page, I don't see any particular reason > > why a machine shouldn't process such data - the processing function > > would be keyed off of the "name" value, so the program would have a > > pretty good notion of what was going to be present in the "value" > > field. > > Instead, I would handle this by not setting the human-readable flag, and > instead choose a name for the notation which tells the machine that it > is a URL. Then the software can know that URLs can be safely displayed > to a human. Leaving the human-readable flag clear allows the software > to read and try to understand the notation. Nothing prevents it from > displaying it to a human if the semantics of that notation imply that > it would be reasonable. Yes, that would work as well. Still, I think that allowing the implementation to look at human-readable notations is more flexible in that a new notation tag can be at least partially supported without code changes. If human-readable meant printf()-able, then the code could just display anything that had the human-readable flag set so at least the user could see the notation and thus have partial support for the new tag. The software implementation could not handle the notation without a upgrade, but I suspect that while automation is nice, many notations could be handled by a user as well (for example: "This key is revoked, please use key 0xXXXXXXXXXX instead"). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Thu Dec 6 12:39:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05359 for ; Thu, 6 Dec 2001 12:39:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6HLwf24776 for ietf-openpgp-bks; Thu, 6 Dec 2001 09:21:58 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6HLu224770 for ; Thu, 6 Dec 2001 09:21:56 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16C2V2-00025D-00; Thu, 06 Dec 2001 18:39:56 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 16C2GU-0004kr-00; Thu, 06 Dec 2001 18:24:54 +0100 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: dshaw@akamai.com, hal@finney.org, ietf-openpgp@imc.org Subject: Re: Notation data language References: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 06 Dec 2001 18:24:54 +0100 In-Reply-To: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz's message of "Thu, 6 Dec 2001 12:58:37 +1300 (NZDT)") Message-ID: <87667kxnvd.fsf@alberti.gnupg.de> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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 Thu, 6 Dec 2001 12:58:37 +1300 (NZDT), Peter Gutmann said: > I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) > to create PGP signatures. encoded according to rfc2253? Does it make sense to encode the name like "oid.1.3.6.1.4.1.11591" so that we have a defined namespace for such extensions? There is also Thomas Roessler's proposal based on DNS domains but for X.509 stuff OIDs are the more natural approach. Werner From owner-ietf-openpgp@mail.imc.org Thu Dec 6 13:02:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06265 for ; Thu, 6 Dec 2001 13:02:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6HXqk25194 for ietf-openpgp-bks; Thu, 6 Dec 2001 09:33:52 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6HXo225188 for ; Thu, 6 Dec 2001 09:33:50 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16C2ge-0002Jm-00; Thu, 06 Dec 2001 18:51:56 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 16C2SI-0004mE-00; Thu, 06 Dec 2001 18:37:06 +0100 To: ietf-openpgp@imc.org Subject: Re: Text canonicalization References: <200112051759.JAA27637@finney.org> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 06 Dec 2001 18:37:06 +0100 In-Reply-To: <200112051759.JAA27637@finney.org> (hal@finney.org's message of "Wed, 5 Dec 2001 09:59:15 -0800") Message-ID: <871yi8xnb1.fsf@alberti.gnupg.de> Lines: 30 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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, 5 Dec 2001 09:59:15 -0800, hal said: > A few days ago an issue arose on a cryptography mailing list about > a failing PGP signature on a software package being distributed. Yet another wu-ftpd bug ;-) > The first is that it does not make clear what constitutes line endings. We are talking about text documents and imho it is cleary defined what makes up a line ending: ANSI defined fopen(3) to take an optional mode flag "b" to prevent translation of local line endings. Anyway, this encoding transformation should not go into OpenPGP but to the next upper layer (MIME), so I consider textmode a compatibilty trick for PGP 2 - rfc3156 tries to sort out all these issues and it does not make sense to change OpenPGP just for this. Well, a note that textmode should be avoided is appropriate. > This issue has caused problems for people from time to time since the RFC > has issued. I recommend that we solve the problem by changing the spec > to conform to how PGP has always worked. We should eliminate the words > "and trailing blanks removed" from the section above. I am not in favor of this. Bugs should not be fixed by changing a standard. RFC2440 has been released more than 3 years ago. Werner From owner-ietf-openpgp@mail.imc.org Fri Dec 7 00:30:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27693 for ; Fri, 7 Dec 2001 00:30:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB758jf29801 for ietf-openpgp-bks; Thu, 6 Dec 2001 21:08:45 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB758h229796 for ; Thu, 6 Dec 2001 21:08:43 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA14576; Fri, 7 Dec 2001 18:08:07 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA303739; Fri, 7 Dec 2001 18:08:06 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 7 Dec 2001 18:08:06 +1300 (NZDT) Message-ID: <200112070508.SAA303739@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, wk@gnupg.org Subject: Re: Notation data language Cc: dshaw@akamai.com, hal@finney.org, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >>I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) >>to create PGP signatures. > >encoded according to rfc2253? Encoded according to DER. This is for finding a cert, not for human use (for one thing half the issuerAndSerialNumbers around wouldn't survive a DER -> text -> DER conversion). Peter. From owner-ietf-openpgp@mail.imc.org Sun Dec 16 16:34:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04922 for ; Sun, 16 Dec 2001 16:34:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBGL56v22992 for ietf-openpgp-bks; Sun, 16 Dec 2001 13:05:06 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBGL55222987 for ; Sun, 16 Dec 2001 13:05:05 -0800 (PST) Received: from softhome.net ([209.6.136.129]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sun, 16 Dec 2001 13:52:39 -0700 Message-ID: <3C1D0A3C.31966941@softhome.net> Date: Sun, 16 Dec 2001 15:55:24 -0500 From: John Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-OpenPGP Subject: text + openpgp != mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some readers of this list, those who are engaged in the noble task of implementing PGP/MIME, seem to have fallen into an email-centric rut and appear to have great difficulty grasping the concept of using RFC2440 in a non-email, non-MIME, non-MUA environment. Am I correct in assuming that there are valid, legitimate uses for standalone OpenPGP implementations which are NOT integrated into a mailreader? Am I also correct in assuming that this list is an appropriate forum for discussing issues relating to plain vanilla RFC2440(bis)? There seems to be a strong tendency to automatically misinterpret any reference to 'text', newlines, or cross-platform issues as somehow being inherently MIME-related. What keywords should people use if they want to indicate that they want to discuss an issue within a pure RFC2440 context, or within a context of addressing legacy-PGP / OpenPGP interop nits? Pardon my blunt language, but this needs to get resolved. Several recent RFC2440 threads have been cut short by posters who change the subject to a non-RFC2440 context. :-( -- John Kane New Hampshire (USA) From owner-ietf-openpgp@mail.imc.org Mon Dec 17 05:12:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28912 for ; Mon, 17 Dec 2001 05:12:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBH9vmf07616 for ietf-openpgp-bks; Mon, 17 Dec 2001 01:57:48 -0800 (PST) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH9vk207612 for ; Mon, 17 Dec 2001 01:57:46 -0800 (PST) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.1/8.12.1) with ESMTP id fBH9vj9Q029145 for ; Mon, 17 Dec 2001 10:57:45 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.1/8.12.1/Submit) id fBH9vjgZ029144 for ietf-openpgp@imc.org; Mon, 17 Dec 2001 10:57:45 +0100 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: text + openpgp != mime Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC) Organization: IKS GmbH Jena Lines: 12 Message-ID: References: <3C1D0A3C.31966941@softhome.net> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1008583064 28976 217.17.192.37 (17 Dec 2001 09:57:44 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * John Kane wrote: >Am I correct in assuming that there are valid, legitimate uses for >standalone OpenPGP implementations which are NOT integrated into a >mailreader? Yes. >What keywords should people use if they want to indicate that they want to >discuss an issue within a pure RFC2440 context, or within a context of >addressing legacy-PGP / OpenPGP interop nits? Binary. From owner-ietf-openpgp@mail.imc.org Mon Dec 17 05:55:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29193 for ; Mon, 17 Dec 2001 05:55:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBHAgwM13172 for ietf-openpgp-bks; Mon, 17 Dec 2001 02:42:58 -0800 (PST) Received: from charybdis.rus.uni-stuttgart.de (charybdis.rus.uni-stuttgart.de [129.69.1.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHAgu213168 for ; Mon, 17 Dec 2001 02:42:56 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by charybdis.rus.uni-stuttgart.de with ESMTP id LAA16379 for ; Mon, 17 Dec 2001 11:42:55 +0100 (MET) env-from (Florian.Weimer@RUS.Uni-Stuttgart.DE) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 16FvEG-0001yI-00 for ietf-openpgp@imc.org; Mon, 17 Dec 2001 11:42:40 +0100 To: ietf-openpgp@imc.org Subject: Re: text + openpgp != mime References: <3C1D0A3C.31966941@softhome.net> From: Florian Weimer Date: 17 Dec 2001 11:42:40 +0100 In-Reply-To: <3C1D0A3C.31966941@softhome.net> (John Kane's message of "Sun, 16 Dec 2001 15:55:24 -0500") Message-ID: Lines: 13 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Kane writes: > There seems to be a strong tendency to automatically misinterpret > any reference to 'text', newlines, or cross-platform issues as > somehow being inherently MIME-related. In the RFC 2440 context, 'text' is defined to be encoded in UTF-8. Perhaps this isn't what you want, either. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Mon Dec 17 11:59:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10797 for ; Mon, 17 Dec 2001 11:59:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHGdGd11654 for ietf-openpgp-bks; Mon, 17 Dec 2001 08:39:16 -0800 (PST) Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHGdF211648 for ; Mon, 17 Dec 2001 08:39:15 -0800 (PST) Received: from knotes.kodak.com (knotes2.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id fBHGd7n21669 for ; Mon, 17 Dec 2001 11:39:07 -0500 (EST) Subject: OpenPGP Toolkits Available? To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Mon, 17 Dec 2001 10:39:03 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 12/17/2001 11:39:06 AM 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: From: John Dlugosz What OpenPGP toolkits are available? I'm specifically looking for something that doesn't have licencing fees. I've found CTClib which has not been updated since 1997, and a new suite in Perl. I'd like to find some free source code in C or C++. --John From owner-ietf-openpgp@mail.imc.org Thu Dec 27 17:26:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21705 for ; Thu, 27 Dec 2001 17:26:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRM2rn16149 for ietf-openpgp-bks; Thu, 27 Dec 2001 14:02:53 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRM2p216143 for ; Thu, 27 Dec 2001 14:02:52 -0800 (PST) Received: from [10.0.1.2] (63.121.144.102) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Thu, 27 Dec 2001 14:02:46 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <871yi8xnb1.fsf@alberti.gnupg.de> References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> Date: Thu, 27 Dec 2001 14:00:41 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Text canonicalization Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In computer science, there are some interesting unsolved problems. A number of them revolve around semantic issues -- what does data mean -- as opposed to syntactic issues. One of these is the notion of text, as opposed to raw data. There are others (like, for example the unsolved question of what a digital signature means). I'm going to blither about text, and its relevancy to OpenPGP in this missive. In the dim and ancient past, everyone had their own character set. Gradually, there came to be standard character sets. Arguably, ASCII was the first standard character set. Then, over the years, it was enhanced to ISO Latin-1 (ISO 8859-1), and then all the 8859 follow-ons for blocks of extra characters. I find it charming that for example that ISO Latin-5 (ISO 8859-5) is Cyrillic. There are also lots of other quasi-standard character sets that are enhancements on ASCII. Then there are all the interesting ones for Asian languages, and so on and so forth, leading up to Unicode and ISO 10646, which in theory should eventually be *the* standard character set. But in all of this, there's been no standardization of what either the syntax or semantics of a "line end" is. I'm going to stay away from the semantics issue, as fun as that could be, because it's really not relevant. (That discussion would cover how a line end differs between languages that go left-to-right and right-to-left, and then progress into how you deal with vertical lines, too.) There are at least four different ways to denote a line end. For the purposes of the discussion, I'm going to assume that when a line ends, you start writing at the left margin, and down one line. I'm doing this for no other reason than that's what I'm using now. These four mechanisms that I can think of are: * Two characters, one that says to go all the way left, one that says go down one line. The "standard" way to do that is with a CR and LF (0x0D, 0x0A). This is also the way that IETF protocols denote line ends. * One character that does both things. People have used each of CR and LF to do this, so this is two mechanisms under one bullet. * Line ends are meta-data. Record-oriented (as opposed to stream-oriented) systems do this. For example, imagine storing a file as a stream of counted strings, each one denoting a line. There's no actual line end in this file, they're inferred by the sizes of each line. It really doesn't matter how you denote any of this stuff (not even character set) until you want to move a chunk of data from one system to another and preserve its semantic content. There are a couple of ways to do this: * Declare an interchange format, and always translate your chunk into this format when you transmit it, and out of it when you receive it. * When you transmit your chunk, tell your partner what format it's in, and let them translate it. It is my belief that in OpenPGP, we do the former -- we have an interchange format for text. That format consists of the ISO 10646 character set that has been encoded into UTF-8. Additionally, we use CRLF line-ends, and perhaps controversially, trim trailing white space from the end of each line. Note that there is at least one more semantic ambiguity in this interchange format -- tabs. Let's not go there right now, but arguably, we should do something about that, too. It is also my belief that when a chunk of data is marked as being "text" that it is an assurance that the chunk of data has been translated into that interchange format. This is what we mean by "text canonicalization." An interesting side-effect of this is that when I verify a signature over a chunk of data, it doesn't matter whether it's "text" or "binary." You can just hash the chunk, compute the signature, and poof, you're done. Also, interestingly, it means that minor errors in canonicalization (let's suppose that someone's canonicalizer occasionally leaves in a trailing space, or it sometimes encodes two blank lines as CR, LF, LF -- I've seen both these errors over the years) don't affect signature checks. Text mode, as we call it, should only come into play when you display text, or want to use that chunk as text (like writing it out into a file). If you verify a signature over a text file (call it foo.c), and then want to write it out on a unix system, you need to translate the CRLFs into LFs. You have to deal with what it means to have a bare CR, what to do about the character set (your user might be using Shift-JIS or Big5), and you'll have to massage that chunk to preserve its semantic content. I believe that when a blob is marked as text mode, it's an *assurance* that you've transformed the blob into "text mode." It is *not* an advisory to tell your partner that every time they see a bare LF they should drop an extra CR into the hash. Should such an implementation exist, I believe it is wrong. Text mode means you have translated the blob from your local format into the interchange format and its binary content is that of the interchange format. The IETF meta-rule we keep coming back to is to be conservative in what you generate, and liberal in what you accept. So -- you should only mark a chunk of data as "text" if it's been run through a canonicalizer that transforms it into our interchange format. On the other hand it is reasonable, but not necessary, that you accept something that's not strictly right. For example, let's suppose that an OpenPGP implementation has a bug in it and that bug is that after the canonicalizer has been run, the message is generated with the pre-canonicalized text. Oops. What we have in this is unix text (LF line-ends, let's say and ignore the character set issues), but a signature that was computed over the same text with CRLF line ends. If an implementation were, after failing to verify the signature on the blob, to use a heuristic that tried to compensate for that encoding error then I think we'd all applaud. That software would say to itself, "Hmm, this signature didn't check. Let me look at the file. Well, well. It's got 37 LFs and not a single CR. I'll bet that someone made a mistake. Let's add in those CRs and check the signature again. Hey, look at that, it works." But that's mostly a digression. The point I'm making is this: Whatever problems text mode, canonicalization, and translations give you, there should be zero problems in signature checking. A signature is a signature is a signature is a signature. The signature should be over the actual data as found in the data packet. While I'm at it, I'll mention that as far as OpenPGP is concerned, there are other things a canonicalizer can do. It can, for example, translate tabs into spaces. Heck, it can translate ANSI escape sequences into HTML, or HTML into RTF, for all OpenPGP cares. The end users may care, but it's OpenPGP compliant. You can always do more than what the standard says. Your users might not like it, but the standard doesn't care. Jon From owner-ietf-openpgp@mail.imc.org Thu Dec 27 18:55:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22416 for ; Thu, 27 Dec 2001 18:55:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBRNLuQ18511 for ietf-openpgp-bks; Thu, 27 Dec 2001 15:21:56 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRNLs218505 for ; Thu, 27 Dec 2001 15:21:54 -0800 (PST) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id fBS0HEt13471; Thu, 27 Dec 2001 16:17:14 -0800 Date: Thu, 27 Dec 2001 16:17:14 -0800 From: hal@finney.org Message-Id: <200112280017.fBS0HEt13471@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Text canonicalization Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That's a good discussion, but it doesn't cover the case of a detached signature on a text document. In that case the document is not subject to OpenPGP text canonicalization on signature creation, and hence cannot be assumed to have been canonicalized on signature verification. We could just rule this case out. I think that's what Jon's analysis would suggest. If you can't canonicalize it, you can't call it text. However there may be some people who would like to use this feature. They want to sign a text document which they are distributing, but they want to put the signature in a separate file. That way the text document is accessible to everyone without being cluttered with crypto crud. The problem with this case is that text documents tend to get transported in two ways, using such transports as FTP. One way converts the document to the native text format of the recipient machine, generally just converting line endings. The other way preserves the document unchanged. Ideally, we could adopt conventions which would allow most of these cases to work correctly. We won't be able to handle every variant and every machine's notion of text, because there are so many obscure ones out there. But we could capture the great majority of cases with some simple rules. These rules are that the document should be canonicalized with all of CRLF, CR and LF being treated as line endings, and being turned into CRLF for hash purposes. This was what I proposed. I continue to believe that this simple rule provides the maximum flexibility to the end user. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Dec 27 20:04:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22789 for ; Thu, 27 Dec 2001 20:04:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBS0XfJ23572 for ietf-openpgp-bks; Thu, 27 Dec 2001 16:33:41 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBS0Xe223568 for ; Thu, 27 Dec 2001 16:33:40 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fBS0XbB29754 for ietf-openpgp@imc.org; Thu, 27 Dec 2001 19:33:37 -0500 Date: Thu, 27 Dec 2001 19:33:37 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text canonicalization Message-ID: <20011227193337.F685@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Thu, Dec 27, 2001 at 02:00:41PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (91% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This sounds very good, but what about detached signatures? A detached signature doesn't carry the text with it, so wouldn't the the text (presumably delivered via http or ftp, which can change line endings) need to be re-canonicalized for signature verification? To a certain degree this applies to a clearsigned document as well. Email delivery of the text is a whole other can of worms, though it could be argued that if it's email, it should be PGP/MIME. Even so, canonical text should be able to handle the most common sorts of email butchery without PGP/MIME. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Fri Dec 28 08:51:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08164 for ; Fri, 28 Dec 2001 08:51:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSDRI512918 for ietf-openpgp-bks; Fri, 28 Dec 2001 05:27:18 -0800 (PST) Received: from hotmail.com (oe24.law3.hotmail.com [209.185.240.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBSDRH212912 for ; Fri, 28 Dec 2001 05:27:17 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Dec 2001 05:16:05 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Subject: Re: Text canonicalization Date: Fri, 28 Dec 2001 08:15:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Dec 2001 13:16:05.0312 (UTC) FILETIME=[CE15B400:01C18FA1] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Shaw" To: Sent: Thursday, December 27, 2001 7:33 PM Subject: Re: Text canonicalization ... > This sounds very good, but what about detached signatures? A detached > signature doesn't carry the text with it, so wouldn't the the text > (presumably delivered via http or ftp, which can change line endings) > need to be re-canonicalized for signature verification? To a certain > degree this applies to a clearsigned document as well. ... also applies somewhat to GnuPG signed and encrypted messages when signed with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key, PGP interprets it as a 'detached' signature, and 'searches' (unsuccessfully) for the file trying to verify it. {not the case with v4 rsa sigs, which seem to act differently} vedaal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSDRI512918 for ietf-openpgp-bks; Fri, 28 Dec 2001 05:27:18 -0800 (PST) Received: from hotmail.com (oe24.law3.hotmail.com [209.185.240.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBSDRH212912 for ; Fri, 28 Dec 2001 05:27:17 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Dec 2001 05:16:05 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Subject: Re: Text canonicalization Date: Fri, 28 Dec 2001 08:15:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Dec 2001 13:16:05.0312 (UTC) FILETIME=[CE15B400:01C18FA1] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "David Shaw" To: Sent: Thursday, December 27, 2001 7:33 PM Subject: Re: Text canonicalization ... > This sounds very good, but what about detached signatures? A detached > signature doesn't carry the text with it, so wouldn't the the text > (presumably delivered via http or ftp, which can change line endings) > need to be re-canonicalized for signature verification? To a certain > degree this applies to a clearsigned document as well. ... also applies somewhat to GnuPG signed and encrypted messages when signed with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key, PGP interprets it as a 'detached' signature, and 'searches' (unsuccessfully) for the file trying to verify it. {not the case with v4 rsa sigs, which seem to act differently} vedaal Received: by above.proper.com (8.11.6/8.11.3) id fBS0XfJ23572 for ietf-openpgp-bks; Thu, 27 Dec 2001 16:33:41 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBS0Xe223568 for ; Thu, 27 Dec 2001 16:33:40 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fBS0XbB29754 for ietf-openpgp@imc.org; Thu, 27 Dec 2001 19:33:37 -0500 Date: Thu, 27 Dec 2001 19:33:37 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text canonicalization Message-ID: <20011227193337.F685@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Thu, Dec 27, 2001 at 02:00:41PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (91% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This sounds very good, but what about detached signatures? A detached signature doesn't carry the text with it, so wouldn't the the text (presumably delivered via http or ftp, which can change line endings) need to be re-canonicalized for signature verification? To a certain degree this applies to a clearsigned document as well. Email delivery of the text is a whole other can of worms, though it could be argued that if it's email, it should be PGP/MIME. Even so, canonical text should be able to handle the most common sorts of email butchery without PGP/MIME. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: by above.proper.com (8.11.6/8.11.3) id fBRNLuQ18511 for ietf-openpgp-bks; Thu, 27 Dec 2001 15:21:56 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRNLs218505 for ; Thu, 27 Dec 2001 15:21:54 -0800 (PST) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id fBS0HEt13471; Thu, 27 Dec 2001 16:17:14 -0800 Date: Thu, 27 Dec 2001 16:17:14 -0800 From: hal@finney.org Message-Id: <200112280017.fBS0HEt13471@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Text canonicalization Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That's a good discussion, but it doesn't cover the case of a detached signature on a text document. In that case the document is not subject to OpenPGP text canonicalization on signature creation, and hence cannot be assumed to have been canonicalized on signature verification. We could just rule this case out. I think that's what Jon's analysis would suggest. If you can't canonicalize it, you can't call it text. However there may be some people who would like to use this feature. They want to sign a text document which they are distributing, but they want to put the signature in a separate file. That way the text document is accessible to everyone without being cluttered with crypto crud. The problem with this case is that text documents tend to get transported in two ways, using such transports as FTP. One way converts the document to the native text format of the recipient machine, generally just converting line endings. The other way preserves the document unchanged. Ideally, we could adopt conventions which would allow most of these cases to work correctly. We won't be able to handle every variant and every machine's notion of text, because there are so many obscure ones out there. But we could capture the great majority of cases with some simple rules. These rules are that the document should be canonicalized with all of CRLF, CR and LF being treated as line endings, and being turned into CRLF for hash purposes. This was what I proposed. I continue to believe that this simple rule provides the maximum flexibility to the end user. Hal Finney Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRM2rn16149 for ietf-openpgp-bks; Thu, 27 Dec 2001 14:02:53 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRM2p216143 for ; Thu, 27 Dec 2001 14:02:52 -0800 (PST) Received: from [10.0.1.2] (63.121.144.102) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Thu, 27 Dec 2001 14:02:46 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <871yi8xnb1.fsf@alberti.gnupg.de> References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> Date: Thu, 27 Dec 2001 14:00:41 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Text canonicalization Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In computer science, there are some interesting unsolved problems. A number of them revolve around semantic issues -- what does data mean -- as opposed to syntactic issues. One of these is the notion of text, as opposed to raw data. There are others (like, for example the unsolved question of what a digital signature means). I'm going to blither about text, and its relevancy to OpenPGP in this missive. In the dim and ancient past, everyone had their own character set. Gradually, there came to be standard character sets. Arguably, ASCII was the first standard character set. Then, over the years, it was enhanced to ISO Latin-1 (ISO 8859-1), and then all the 8859 follow-ons for blocks of extra characters. I find it charming that for example that ISO Latin-5 (ISO 8859-5) is Cyrillic. There are also lots of other quasi-standard character sets that are enhancements on ASCII. Then there are all the interesting ones for Asian languages, and so on and so forth, leading up to Unicode and ISO 10646, which in theory should eventually be *the* standard character set. But in all of this, there's been no standardization of what either the syntax or semantics of a "line end" is. I'm going to stay away from the semantics issue, as fun as that could be, because it's really not relevant. (That discussion would cover how a line end differs between languages that go left-to-right and right-to-left, and then progress into how you deal with vertical lines, too.) There are at least four different ways to denote a line end. For the purposes of the discussion, I'm going to assume that when a line ends, you start writing at the left margin, and down one line. I'm doing this for no other reason than that's what I'm using now. These four mechanisms that I can think of are: * Two characters, one that says to go all the way left, one that says go down one line. The "standard" way to do that is with a CR and LF (0x0D, 0x0A). This is also the way that IETF protocols denote line ends. * One character that does both things. People have used each of CR and LF to do this, so this is two mechanisms under one bullet. * Line ends are meta-data. Record-oriented (as opposed to stream-oriented) systems do this. For example, imagine storing a file as a stream of counted strings, each one denoting a line. There's no actual line end in this file, they're inferred by the sizes of each line. It really doesn't matter how you denote any of this stuff (not even character set) until you want to move a chunk of data from one system to another and preserve its semantic content. There are a couple of ways to do this: * Declare an interchange format, and always translate your chunk into this format when you transmit it, and out of it when you receive it. * When you transmit your chunk, tell your partner what format it's in, and let them translate it. It is my belief that in OpenPGP, we do the former -- we have an interchange format for text. That format consists of the ISO 10646 character set that has been encoded into UTF-8. Additionally, we use CRLF line-ends, and perhaps controversially, trim trailing white space from the end of each line. Note that there is at least one more semantic ambiguity in this interchange format -- tabs. Let's not go there right now, but arguably, we should do something about that, too. It is also my belief that when a chunk of data is marked as being "text" that it is an assurance that the chunk of data has been translated into that interchange format. This is what we mean by "text canonicalization." An interesting side-effect of this is that when I verify a signature over a chunk of data, it doesn't matter whether it's "text" or "binary." You can just hash the chunk, compute the signature, and poof, you're done. Also, interestingly, it means that minor errors in canonicalization (let's suppose that someone's canonicalizer occasionally leaves in a trailing space, or it sometimes encodes two blank lines as CR, LF, LF -- I've seen both these errors over the years) don't affect signature checks. Text mode, as we call it, should only come into play when you display text, or want to use that chunk as text (like writing it out into a file). If you verify a signature over a text file (call it foo.c), and then want to write it out on a unix system, you need to translate the CRLFs into LFs. You have to deal with what it means to have a bare CR, what to do about the character set (your user might be using Shift-JIS or Big5), and you'll have to massage that chunk to preserve its semantic content. I believe that when a blob is marked as text mode, it's an *assurance* that you've transformed the blob into "text mode." It is *not* an advisory to tell your partner that every time they see a bare LF they should drop an extra CR into the hash. Should such an implementation exist, I believe it is wrong. Text mode means you have translated the blob from your local format into the interchange format and its binary content is that of the interchange format. The IETF meta-rule we keep coming back to is to be conservative in what you generate, and liberal in what you accept. So -- you should only mark a chunk of data as "text" if it's been run through a canonicalizer that transforms it into our interchange format. On the other hand it is reasonable, but not necessary, that you accept something that's not strictly right. For example, let's suppose that an OpenPGP implementation has a bug in it and that bug is that after the canonicalizer has been run, the message is generated with the pre-canonicalized text. Oops. What we have in this is unix text (LF line-ends, let's say and ignore the character set issues), but a signature that was computed over the same text with CRLF line ends. If an implementation were, after failing to verify the signature on the blob, to use a heuristic that tried to compensate for that encoding error then I think we'd all applaud. That software would say to itself, "Hmm, this signature didn't check. Let me look at the file. Well, well. It's got 37 LFs and not a single CR. I'll bet that someone made a mistake. Let's add in those CRs and check the signature again. Hey, look at that, it works." But that's mostly a digression. The point I'm making is this: Whatever problems text mode, canonicalization, and translations give you, there should be zero problems in signature checking. A signature is a signature is a signature is a signature. The signature should be over the actual data as found in the data packet. While I'm at it, I'll mention that as far as OpenPGP is concerned, there are other things a canonicalizer can do. It can, for example, translate tabs into spaces. Heck, it can translate ANSI escape sequences into HTML, or HTML into RTF, for all OpenPGP cares. The end users may care, but it's OpenPGP compliant. You can always do more than what the standard says. Your users might not like it, but the standard doesn't care. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHGdGd11654 for ietf-openpgp-bks; Mon, 17 Dec 2001 08:39:16 -0800 (PST) Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHGdF211648 for ; Mon, 17 Dec 2001 08:39:15 -0800 (PST) Received: from knotes.kodak.com (knotes2.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id fBHGd7n21669 for ; Mon, 17 Dec 2001 11:39:07 -0500 (EST) Subject: OpenPGP Toolkits Available? To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Mon, 17 Dec 2001 10:39:03 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 12/17/2001 11:39:06 AM 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: From: John Dlugosz What OpenPGP toolkits are available? I'm specifically looking for something that doesn't have licencing fees. I've found CTClib which has not been updated since 1997, and a new suite in Perl. I'd like to find some free source code in C or C++. --John Received: by above.proper.com (8.11.6/8.11.3) id fBHAgwM13172 for ietf-openpgp-bks; Mon, 17 Dec 2001 02:42:58 -0800 (PST) Received: from charybdis.rus.uni-stuttgart.de (charybdis.rus.uni-stuttgart.de [129.69.1.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHAgu213168 for ; Mon, 17 Dec 2001 02:42:56 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by charybdis.rus.uni-stuttgart.de with ESMTP id LAA16379 for ; Mon, 17 Dec 2001 11:42:55 +0100 (MET) env-from (Florian.Weimer@RUS.Uni-Stuttgart.DE) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 16FvEG-0001yI-00 for ietf-openpgp@imc.org; Mon, 17 Dec 2001 11:42:40 +0100 To: ietf-openpgp@imc.org Subject: Re: text + openpgp != mime References: <3C1D0A3C.31966941@softhome.net> From: Florian Weimer Date: 17 Dec 2001 11:42:40 +0100 In-Reply-To: <3C1D0A3C.31966941@softhome.net> (John Kane's message of "Sun, 16 Dec 2001 15:55:24 -0500") Message-ID: Lines: 13 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Kane writes: > There seems to be a strong tendency to automatically misinterpret > any reference to 'text', newlines, or cross-platform issues as > somehow being inherently MIME-related. In the RFC 2440 context, 'text' is defined to be encoded in UTF-8. Perhaps this isn't what you want, either. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBH9vmf07616 for ietf-openpgp-bks; Mon, 17 Dec 2001 01:57:48 -0800 (PST) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH9vk207612 for ; Mon, 17 Dec 2001 01:57:46 -0800 (PST) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.1/8.12.1) with ESMTP id fBH9vj9Q029145 for ; Mon, 17 Dec 2001 10:57:45 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.1/8.12.1/Submit) id fBH9vjgZ029144 for ietf-openpgp@imc.org; Mon, 17 Dec 2001 10:57:45 +0100 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: text + openpgp != mime Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC) Organization: IKS GmbH Jena Lines: 12 Message-ID: References: <3C1D0A3C.31966941@softhome.net> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1008583064 28976 217.17.192.37 (17 Dec 2001 09:57:44 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * John Kane wrote: >Am I correct in assuming that there are valid, legitimate uses for >standalone OpenPGP implementations which are NOT integrated into a >mailreader? Yes. >What keywords should people use if they want to indicate that they want to >discuss an issue within a pure RFC2440 context, or within a context of >addressing legacy-PGP / OpenPGP interop nits? Binary. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBGL56v22992 for ietf-openpgp-bks; Sun, 16 Dec 2001 13:05:06 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBGL55222987 for ; Sun, 16 Dec 2001 13:05:05 -0800 (PST) Received: from softhome.net ([209.6.136.129]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sun, 16 Dec 2001 13:52:39 -0700 Message-ID: <3C1D0A3C.31966941@softhome.net> Date: Sun, 16 Dec 2001 15:55:24 -0500 From: John Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-OpenPGP Subject: text + openpgp != mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some readers of this list, those who are engaged in the noble task of implementing PGP/MIME, seem to have fallen into an email-centric rut and appear to have great difficulty grasping the concept of using RFC2440 in a non-email, non-MIME, non-MUA environment. Am I correct in assuming that there are valid, legitimate uses for standalone OpenPGP implementations which are NOT integrated into a mailreader? Am I also correct in assuming that this list is an appropriate forum for discussing issues relating to plain vanilla RFC2440(bis)? There seems to be a strong tendency to automatically misinterpret any reference to 'text', newlines, or cross-platform issues as somehow being inherently MIME-related. What keywords should people use if they want to indicate that they want to discuss an issue within a pure RFC2440 context, or within a context of addressing legacy-PGP / OpenPGP interop nits? Pardon my blunt language, but this needs to get resolved. Several recent RFC2440 threads have been cut short by posters who change the subject to a non-RFC2440 context. :-( -- John Kane New Hampshire (USA) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB758jf29801 for ietf-openpgp-bks; Thu, 6 Dec 2001 21:08:45 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB758h229796 for ; Thu, 6 Dec 2001 21:08:43 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA14576; Fri, 7 Dec 2001 18:08:07 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA303739; Fri, 7 Dec 2001 18:08:06 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 7 Dec 2001 18:08:06 +1300 (NZDT) Message-ID: <200112070508.SAA303739@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, wk@gnupg.org Subject: Re: Notation data language Cc: dshaw@akamai.com, hal@finney.org, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >>I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) >>to create PGP signatures. > >encoded according to rfc2253? Encoded according to DER. This is for finding a cert, not for human use (for one thing half the issuerAndSerialNumbers around wouldn't survive a DER -> text -> DER conversion). Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6HXqk25194 for ietf-openpgp-bks; Thu, 6 Dec 2001 09:33:52 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6HXo225188 for ; Thu, 6 Dec 2001 09:33:50 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16C2ge-0002Jm-00; Thu, 06 Dec 2001 18:51:56 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 16C2SI-0004mE-00; Thu, 06 Dec 2001 18:37:06 +0100 To: ietf-openpgp@imc.org Subject: Re: Text canonicalization References: <200112051759.JAA27637@finney.org> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 06 Dec 2001 18:37:06 +0100 In-Reply-To: <200112051759.JAA27637@finney.org> (hal@finney.org's message of "Wed, 5 Dec 2001 09:59:15 -0800") Message-ID: <871yi8xnb1.fsf@alberti.gnupg.de> Lines: 30 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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, 5 Dec 2001 09:59:15 -0800, hal said: > A few days ago an issue arose on a cryptography mailing list about > a failing PGP signature on a software package being distributed. Yet another wu-ftpd bug ;-) > The first is that it does not make clear what constitutes line endings. We are talking about text documents and imho it is cleary defined what makes up a line ending: ANSI defined fopen(3) to take an optional mode flag "b" to prevent translation of local line endings. Anyway, this encoding transformation should not go into OpenPGP but to the next upper layer (MIME), so I consider textmode a compatibilty trick for PGP 2 - rfc3156 tries to sort out all these issues and it does not make sense to change OpenPGP just for this. Well, a note that textmode should be avoided is appropriate. > This issue has caused problems for people from time to time since the RFC > has issued. I recommend that we solve the problem by changing the spec > to conform to how PGP has always worked. We should eliminate the words > "and trailing blanks removed" from the section above. I am not in favor of this. Bugs should not be fixed by changing a standard. RFC2440 has been released more than 3 years ago. Werner Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6HLwf24776 for ietf-openpgp-bks; Thu, 6 Dec 2001 09:21:58 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6HLu224770 for ; Thu, 6 Dec 2001 09:21:56 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16C2V2-00025D-00; Thu, 06 Dec 2001 18:39:56 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 16C2GU-0004kr-00; Thu, 06 Dec 2001 18:24:54 +0100 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: dshaw@akamai.com, hal@finney.org, ietf-openpgp@imc.org Subject: Re: Notation data language References: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 06 Dec 2001 18:24:54 +0100 In-Reply-To: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz's message of "Thu, 6 Dec 2001 12:58:37 +1300 (NZDT)") Message-ID: <87667kxnvd.fsf@alberti.gnupg.de> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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 Thu, 6 Dec 2001 12:58:37 +1300 (NZDT), Peter Gutmann said: > I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) > to create PGP signatures. encoded according to rfc2253? Does it make sense to encode the name like "oid.1.3.6.1.4.1.11591" so that we have a defined namespace for such extensions? There is also Thomas Roessler's proposal based on DNS domains but for X.509 stuff OIDs are the more natural approach. Werner Received: by above.proper.com (8.11.6/8.11.3) id fB60K9Q07105 for ietf-openpgp-bks; Wed, 5 Dec 2001 16:20:09 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60K8207099 for ; Wed, 5 Dec 2001 16:20:08 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB60K5S09146; Wed, 5 Dec 2001 19:20:05 -0500 Date: Wed, 5 Dec 2001 19:20:05 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Message-ID: <20011205192005.E7439@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org, jon@callas.org References: <200112052358.PAA28877@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112052358.PAA28877@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 03:58:08PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 03:58:08PM -0800, hal@finney.org wrote: > David Shaw writes: > > As I see it (and this departs from the language in the draft), being > > human readable shouldn't necessarily mean that the data cannot also be > > machine readable. > > > > To use the URL example, if there was a "myhomepage@akamai.com" name > > (to use the proper user name space from the draft), and that was > > defined as a URL for my home page, I don't see any particular reason > > why a machine shouldn't process such data - the processing function > > would be keyed off of the "name" value, so the program would have a > > pretty good notion of what was going to be present in the "value" > > field. > > Instead, I would handle this by not setting the human-readable flag, and > instead choose a name for the notation which tells the machine that it > is a URL. Then the software can know that URLs can be safely displayed > to a human. Leaving the human-readable flag clear allows the software > to read and try to understand the notation. Nothing prevents it from > displaying it to a human if the semantics of that notation imply that > it would be reasonable. Yes, that would work as well. Still, I think that allowing the implementation to look at human-readable notations is more flexible in that a new notation tag can be at least partially supported without code changes. If human-readable meant printf()-able, then the code could just display anything that had the human-readable flag set so at least the user could see the notation and thus have partial support for the new tag. The software implementation could not handle the notation without a upgrade, but I suspect that while automation is nice, many notations could be handled by a user as well (for example: "This key is revoked, please use key 0xXXXXXXXXXX instead"). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB601fn05635 for ietf-openpgp-bks; Wed, 5 Dec 2001 16:01:41 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB601e205630 for ; Wed, 5 Dec 2001 16:01:40 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA28877; Wed, 5 Dec 2001 15:58:08 -0800 Date: Wed, 5 Dec 2001 15:58:08 -0800 From: hal@finney.org Message-Id: <200112052358.PAA28877@finney.org> To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org, jon@callas.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > As I see it (and this departs from the language in the draft), being > human readable shouldn't necessarily mean that the data cannot also be > machine readable. > > To use the URL example, if there was a "myhomepage@akamai.com" name > (to use the proper user name space from the draft), and that was > defined as a URL for my home page, I don't see any particular reason > why a machine shouldn't process such data - the processing function > would be keyed off of the "name" value, so the program would have a > pretty good notion of what was going to be present in the "value" > field. Instead, I would handle this by not setting the human-readable flag, and instead choose a name for the notation which tells the machine that it is a URL. Then the software can know that URLs can be safely displayed to a human. Leaving the human-readable flag clear allows the software to read and try to understand the notation. Nothing prevents it from displaying it to a human if the semantics of that notation imply that it would be reasonable. Hal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5Nwg105435 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:58:42 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Nwe205426 for ; Wed, 5 Dec 2001 15:58:41 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA09639; Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA270404; Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Thu, 6 Dec 2001 12:58:37 +1300 (NZDT) Message-ID: <200112052358.MAA270404@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: >For what it's worth, although none have been officially described by the IETF, >some notations are being used. On my keyring at the moment exist a few >notations names like "Certification" and "COMMENT" (and a handful of "foo", of >course). I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens) to create PGP signatures. Peter. Received: by above.proper.com (8.11.6/8.11.3) id fB5NsCg05128 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:54:12 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5NsB205122 for ; Wed, 5 Dec 2001 15:54:11 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5Ns7T08666; Wed, 5 Dec 2001 18:54:07 -0500 Date: Wed, 5 Dec 2001 18:54:07 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Message-ID: <20011205185407.A8367@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org, jon@callas.org References: <200112052314.PAA28651@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112052314.PAA28651@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 03:14:29PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 03:14:29PM -0800, hal@finney.org wrote: > Here is the draft language: > > All undefined flags MUST be zero. Defined flags are: > > First octet: 0x80 = human-readable. This note is text, a note > from one person to another, and has no > meaning to software. > > My interpretation is that this is not so much a guarantee that the data > is human readable, as that it is NOT machine readable. In other words > the operational effect is that software should not try to interpret it. > It would be OK to have it be in some secret language that only one other > person could understand. So on this basis if you wanted to put a URL > in there that would be fine, setting this flag just says that software > shouldn't try to parse and understand it. Hmm. I read this to say that the data was human readable in that it could be shown to a human being without special processing (i.e. that it was printable, and not a chunk of binary data). As I see it (and this departs from the language in the draft), being human readable shouldn't necessarily mean that the data cannot also be machine readable. To use the URL example, if there was a "myhomepage@akamai.com" name (to use the proper user name space from the draft), and that was defined as a URL for my home page, I don't see any particular reason why a machine shouldn't process such data - the processing function would be keyed off of the "name" value, so the program would have a pretty good notion of what was going to be present in the "value" field. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5Ns4v05112 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:54:04 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Ns3205108 for ; Wed, 5 Dec 2001 15:54:03 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5Nrue08660; Wed, 5 Dec 2001 18:53:56 -0500 Date: Wed, 5 Dec 2001 18:53:56 -0500 From: David Shaw To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205185356.C7439@akamai.com> Mail-Followup-To: Jon Callas , ietf-openpgp@imc.org References: <20011204175150.A10291@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Dec 05, 2001 at 02:26:18PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (71% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 02:26:18PM -0800, Jon Callas wrote: > You are right, the human-readable flag applies to the data, not the name. > I'll add in what you wanted, to make it clearer. > > As for the name -- well, I have no idea. > > I have an intuitive sense of what human readable means for the value. For > example, "I have read this document, but do not agree with much of its > content, call or email for long-winded details" is a fine human-readable > notation, and one of the purposes it's there for. I can even understand > that the semantic content of that note can be put in any arbitrary language > and encoded in whatever alphabets in unicode, and it's still "human > readable" even if that human better speak Esperanto. I'm not currently generating notations - the question arose from an implementation choice on whether to print all names even if I could not print all values. If I was generating notations, I'd use the 2440bis method - it provides the happy accident of looking like an email address so you can be contacted by someone who wants to add support for the private tag to their implementation. When I read the draft, I assumed human-readable meant that the data was able to be shown to a human being without special processing. Something close to "if I can printf() it, it's human readable" (of course there is UTF8, but I think you get my drift). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5NLmF03576 for ietf-openpgp-bks; Wed, 5 Dec 2001 15:21:48 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB5NLl203572 for ; Wed, 5 Dec 2001 15:21:47 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA28651; Wed, 5 Dec 2001 15:14:29 -0800 Date: Wed, 5 Dec 2001 15:14:29 -0800 From: hal@finney.org Message-Id: <200112052314.PAA28651@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org, jon@callas.org Subject: Re: Notation data language Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the draft language: All undefined flags MUST be zero. Defined flags are: First octet: 0x80 = human-readable. This note is text, a note from one person to another, and has no meaning to software. My interpretation is that this is not so much a guarantee that the data is human readable, as that it is NOT machine readable. In other words the operational effect is that software should not try to interpret it. It would be OK to have it be in some secret language that only one other person could understand. So on this basis if you wanted to put a URL in there that would be fine, setting this flag just says that software shouldn't try to parse and understand it. Hal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5MRNc01105 for ietf-openpgp-bks; Wed, 5 Dec 2001 14:27:23 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5MRM201101 for ; Wed, 5 Dec 2001 14:27:22 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Wed, 5 Dec 2001 14:27:05 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20011204175150.A10291@akamai.com> References: <20011204175150.A10291@akamai.com> Date: Wed, 5 Dec 2001 14:26:18 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Notation data language Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You are right, the human-readable flag applies to the data, not the name. I'll add in what you wanted, to make it clearer. As for the name -- well, I have no idea. I have an intuitive sense of what human readable means for the value. For example, "I have read this document, but do not agree with much of its content, call or email for long-winded details" is a fine human-readable notation, and one of the purposes it's there for. I can even understand that the semantic content of that note can be put in any arbitrary language and encoded in whatever alphabets in unicode, and it's still "human readable" even if that human better speak Esperanto. But is "method://whatever/goes/in/a/uri" human-readable? Tim Berners-Lee thinks not. Or thought not. The protocol we describe in 2440bis for names doesn't make them human readable in some sense of the word, and in fact clucks its tongue at a name like "Statement about what my signature means" which is a *fine* human readable name to go along with the human readable value. My opinion is this: Pick your names with a small amount of wisdom. No matter what you do, someone will be sure to tell you that you did the wrong thing. A notation means what its creator wants it to mean. Unlike most data, since this is contained in a signature, there's a known creator of that data. Consequently, the disambiguation we have in the standard is really overkill. However, the reason for a notation is communication, and there are two parties in communication. If you pick a name tag that someone else will interpret differently than what you mean, then you have a problem. That's why a small amount of wisdom is needed, and if you pick some scheme like the one in 2440bis, or the backwards-domain scheme that Java uses, fewer people will cluck their tongues at you than would if you used a name like "a". And yet a name like "ReadMe" is pretty obvious, even if squishy and non-standard. You're a bright guy, there are lots of reasonable things to do. Pick one. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5LFoB27136 for ietf-openpgp-bks; Wed, 5 Dec 2001 13:15:50 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5LFn227131 for ; Wed, 5 Dec 2001 13:15:49 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA27904; Wed, 5 Dec 2001 10:44:46 -0800 Date: Wed, 5 Dec 2001 10:44:46 -0800 From: hal@finney.org Message-Id: <200112051844.KAA27904@finney.org> To: dshaw@akamai.com, hal@finney.org Subject: Re: Notation data language Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Maybe the best thing would be if you could tell us more about how you are planning to use notation data. This is not a feature which is currently used in PGP, it is intended for support of new applications. It's always difficult to specify a feature when you don't know how it will be used. Usually in IETF we try to do things the other way around. But this was intended as an escape clause for future expansion, so we had to specify it without any practical experience to guide us. Hal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5K7ae23558 for ietf-openpgp-bks; Wed, 5 Dec 2001 12:07:36 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5K7Z223551 for ; Wed, 5 Dec 2001 12:07:35 -0800 (PST) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 16BiKH-0004aj-00 for ietf-openpgp@imc.org; Wed, 05 Dec 2001 21:07:29 +0100 To: ietf-openpgp@imc.org Subject: Re: Text canonicalization References: <200112051759.JAA27637@finney.org> From: Florian Weimer Date: 05 Dec 2001 21:07:29 +0100 In-Reply-To: <200112051759.JAA27637@finney.org> (hal@finney.org's message of "Wed, 5 Dec 2001 09:59:15 -0800") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org writes: > The first is that it does not make clear what constitutes line endings. > In PGP we treat CR LF, CR, and LF all as line endings and convert each > one to CR LF. What about the other line ending characters? With Unicode (or even ISO-8859-x close to an EBCDIC environment), there a few more characters which could end a line. What about systems such as VMS with out-of-band signalling for line endings? -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5JQQO22168 for ietf-openpgp-bks; Wed, 5 Dec 2001 11:26:26 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5JQP222164 for ; Wed, 5 Dec 2001 11:26:25 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5JQLp02970; Wed, 5 Dec 2001 14:26:21 -0500 Date: Wed, 5 Dec 2001 14:26:21 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205142621.C682@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org References: <200112051844.KAA27904@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112051844.KAA27904@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 10:44:46AM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 10:44:46AM -0800, hal@finney.org wrote: > Maybe the best thing would be if you could tell us more about how you > are planning to use notation data. This is not a feature which is > currently used in PGP, it is intended for support of new applications. > It's always difficult to specify a feature when you don't know how it > will be used. Usually in IETF we try to do things the other way around. > But this was intended as an escape clause for future expansion, so we > had to specify it without any practical experience to guide us. Understood. Unfortunately, I'm not sure we're really communicating. I'm not creating any notations. However, I am writing code that can display notations. The question can be boiled down to whether the "name" of the name=value pair is always human readable. "Human readable", to me, meaning that it is made up of characters that can be displayed in some more or less readable way (i.e. printable characters). As I said, the draft seems to say that this is the case. If it isn't the case, that's fine too. I'm just trying to clarify the point. For what it's worth, although none have been officially described by the IETF, some notations are being used. On my keyring at the moment exist a few notations names like "Certification" and "COMMENT" (and a handful of "foo", of course). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: by above.proper.com (8.11.6/8.11.3) id fB5JFoM21937 for ietf-openpgp-bks; Wed, 5 Dec 2001 11:15:50 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5JFn221933 for ; Wed, 5 Dec 2001 11:15:49 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA27637 for ietf-openpgp@imc.org; Wed, 5 Dec 2001 09:59:15 -0800 Date: Wed, 5 Dec 2001 09:59:15 -0800 From: hal@finney.org Message-Id: <200112051759.JAA27637@finney.org> To: ietf-openpgp@imc.org Subject: Text canonicalization Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A few days ago an issue arose on a cryptography mailing list about a failing PGP signature on a software package being distributed. The problem was traced to the fact that the signature was in text mode on this binary package. However it raises some issues in the OpenPGP spec treatment of text mode signatures. Section 5.2.1 of RFC2440 describes the processing for signatures on text documents as "The signature is calculated over the text data with its line endings converted to and trailing blanks removed." There are two problems with this. The first is that it does not make clear what constitutes line endings. In PGP we treat CR LF, CR, and LF all as line endings and convert each one to CR LF. Each of these is used as a line ending on one of the architectures we support; CR LF on Windows, CR on Macintosh, and LF on Unix. We don't restrict the conversion to just native line endings for two reasons. First, in a true text document you will have only native line endings so supporting the others will have no harmful effects; and second, sometimes you run into text documents with non-native line endings (because they were transferred in binary mode from another architecture) and by transforming those line endings as well you increase the chances of verifying a signature correctly. I recommend that we specify this canonicalization rule. The second issue relates to removing trailing blanks. This is an error in the spec, as was pointed out by Ulf M=F6ller less than a month before RFC 2440 issued. Unfortunately in the busy time before the RFC this comment was overlooked and the spec issued with this error. No version of PGP has ever removed trailing blanks in canonicalizing a text document. (They are ignored for *clearsigned* text documents, but that is another matter.) This issue has caused problems for people from time to time since the RFC has issued. I recommend that we solve the problem by changing the spec to conform to how PGP has always worked. We should eliminate the words "and trailing blanks removed" from the section above. Comments? Hal Finney Network Associates Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5IbmZ19162 for ietf-openpgp-bks; Wed, 5 Dec 2001 10:37:48 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Ibk219158 for ; Wed, 5 Dec 2001 10:37:47 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB5IbeQ02119; Wed, 5 Dec 2001 13:37:40 -0500 Date: Wed, 5 Dec 2001 13:37:40 -0500 From: David Shaw To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Notation data language Message-ID: <20011205133740.A682@akamai.com> Mail-Followup-To: hal@finney.org, ietf-openpgp@imc.org References: <200112051818.KAA27718@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112051818.KAA27718@finney.org>; from hal@finney.org on Wed, Dec 05, 2001 at 10:18:24AM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 05, 2001 at 10:18:24AM -0800, hal@finney.org wrote: > David Shaw writes: > > I've been writing some code involving notation data (5.3.2.16 in > > bis-03). As I read it, the human-readable flag applies to the value > > data of the name=value pair and not to the name data. > > > > If I do read this correctly, I'd like to suggest a change in the line > > "This note is text, a note from one person to another, and has no > > meaning to software." to read "The value is text, a note from one > > person...", etc, which would help make clear what the human readable > > flag applies to. > > I don't fully understand the distinction. You are saying that the > "name" part would be machine readable, but the "value" part would not? Other way around - the language in the draft ("Notation names are arbitrary strings encoded in UTF-8") strongly suggests that the the human-readable flag only applies to the "value", and the "name" is always human readable, albeit UTF8. I was hoping to make the language clearer, or if I misread the document, to make it clearer in the other direction :) David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5IM4t18690 for ietf-openpgp-bks; Wed, 5 Dec 2001 10:22:04 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB5IM3218686 for ; Wed, 5 Dec 2001 10:22:03 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA27718; Wed, 5 Dec 2001 10:18:24 -0800 Date: Wed, 5 Dec 2001 10:18:24 -0800 From: hal@finney.org Message-Id: <200112051818.KAA27718@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org Subject: Re: Notation data language Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I've been writing some code involving notation data (5.3.2.16 in > bis-03). As I read it, the human-readable flag applies to the value > data of the name=value pair and not to the name data. > > If I do read this correctly, I'd like to suggest a change in the line > "This note is text, a note from one person to another, and has no > meaning to software." to read "The value is text, a note from one > person...", etc, which would help make clear what the human readable > flag applies to. I don't fully understand the distinction. You are saying that the "name" part would be machine readable, but the "value" part would not? What would be the point of trying to restrict the name to be machine readable if it couldn't do anything with the value? I think it makes more sense to say that this flag means that machines shouldn't try to read any of the notation, rather than that they can read part of it but not the rest. Hal Finney Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB4MqGa22372 for ietf-openpgp-bks; Tue, 4 Dec 2001 14:52:16 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4MqE222367 for ; Tue, 4 Dec 2001 14:52:15 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fB4Mpog10420 for ietf-openpgp@imc.org; Tue, 4 Dec 2001 17:51:50 -0500 Date: Tue, 4 Dec 2001 17:51:50 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Notation data language Message-ID: <20011204175150.A10291@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (81% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been writing some code involving notation data (5.3.2.16 in bis-03). As I read it, the human-readable flag applies to the value data of the name=value pair and not to the name data. If I do read this correctly, I'd like to suggest a change in the line "This note is text, a note from one person to another, and has no meaning to software." to read "The value is text, a note from one person...", etc, which would help make clear what the human readable flag applies to. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: by above.proper.com (8.11.6/8.11.3) id fB2HuIT11551 for ietf-openpgp-bks; Sun, 2 Dec 2001 09:56:18 -0800 (PST) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB2HuG211547 for ; Sun, 2 Dec 2001 09:56:16 -0800 (PST) Received: (cpmta 12127 invoked from network); 2 Dec 2001 09:56:12 -0800 Received: from 80.130.170.210 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.72) with SMTP; 2 Dec 2001 09:56:12 -0800 X-Sent: 2 Dec 2001 17:56:12 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE Message-Id: <200112022052.21502@sendmail.mutz.com> To: John J Kane , ietf-openpgp@imc.org Subject: Re: prefer "- From " instead of ">From "?? Date: Sun, 2 Dec 2001 20:59:17 +0100 X-Mailer: KMail [version 1.3.7] References: <3C0638F9.BC15DE1F@softhome.net> In-Reply-To: <3C0638F9.BC15DE1F@softhome.net> X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fB2HuG211548 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 November 2001 14:32, John J Kane wrote: > This may be the sanest way to handle that case. > Comments? For an OpenPGP implementation this is OK, I guess. But the real fix is replacing one of the five chars "From " with it's quoted-printable hexchar, e.g. "From=20". This kills all issues at the most appropriate level: The MUA. But this only works for messages encoded in qp, though I wouldn't hesitate forcing the MUA to use qp for text that matches "^From ", KMail/Aegypten in our case. Marc - -- FTAA's anti-circumvention provisions represent US imperialism at its worst. They seek to impose restrictive laws on both the US and other countries, in order to prevent established US businesses from facing both domestic and foreign competition. -- EFF FTAA Alert: Stop Hollywood Forcing Technology Ban on 34 Countries -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8CogV3oWD+L2/6DgRAhfSAJ9H7lkakTnvdG/CGXPIARZZkKisIQCggGpS 5hJdG7n9lplw8Q5SXW22w+U= =vRKV -----END PGP SIGNATURE-----