Re: Some -15 comments

[[e-mail] ("Hal Finney")]

> >> I am not sure. But in either case, as far as immediate modifications to the
> >> standard text are concerned, this "a note..." part should be removed from
> >> the definition of 0x80, because it means something that 0x80 definitely
> >> doesn't. Whether or not to add that text someplace else is  an entirely
> >> different question.
>
> > Is this rough consensus?
>
> I concur.

I agree as well.

Hal Finney





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoThG033431; Wed, 30 Nov 2005 10:50:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUIoToA033430; Wed, 30 Nov 2005 10:50:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUIoSZq033424 for <[e-mail]>; Wed, 30 Nov 2005 10:50:28 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 5A4AF57F5C; Wed, 30 Nov 2005 10:52:50 -0800 (PST)
To: [e-mail]
Subject: Re: Some -15 comments
Message-Id: <[e-mail]>
Date: Wed, 30 Nov 2005 10:52:50 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> >> I am not sure. But in either case, as far as immediate modifications to the
> >> standard text are concerned, this "a note..." part should be removed from
> >> the definition of 0x80, because it means something that 0x80 definitely
> >> doesn't. Whether or not to add that text someplace else is  an entirely
> >> different question.
>
> > Is this rough consensus?
>
> I concur.

I agree as well.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGRI3M013527; Wed, 30 Nov 2005 08:27:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGRIBO013526; Wed, 30 Nov 2005 08:27:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGREpV013514 for <[e-mail]>; Wed, 30 Nov 2005 08:27:17 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EhUtt-0004jG-Pn for <[e-mail]>; Wed, 30 Nov 2005 17:33:45 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EhUhT-0005HI-PM for <[e-mail]>; Wed, 30 Nov 2005 17:20:55 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Wed, 30 Nov 2005 17:20:55 +0100
In-Reply-To: <[e-mail]> (David Shaw's message of "Wed, 30 Nov 2005 10:47:25 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 30 Nov 2005 10:47:25 -0500, David Shaw said:

>> I am not sure. But in either case, as far as immediate modifications to the
>> standard text are concerned, this "a note..." part should be removed from
>> the definition of 0x80, because it means something that 0x80 definitely
>> doesn't. Whether or not to add that text someplace else is  an entirely
>> different question.

> Is this rough consensus?

I concur.


Salam-Shalom,

   Werner



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE4BN012150; Wed, 30 Nov 2005 08:14:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGE4Gw012149; Wed, 30 Nov 2005 08:14:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGE3TK012140 for <[e-mail]>; Wed, 30 Nov 2005 08:14:03 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUGE2S07014 for <[e-mail]>; Wed, 30 Nov 2005 11:14:02 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUGDwX6022624 for <[e-mail]>; Wed, 30 Nov 2005 11:13:58 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUGDu8i023265 for <[e-mail]>; Wed, 30 Nov 2005 11:13:56 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUGDuiQ023264 for [e-mail]; Wed, 30 Nov 2005 11:13:56 -0500
Date: Wed, 30 Nov 2005 11:13:56 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Some -15 text nits
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

These are just some fiddly language nits for -15.  Nothing terribly
controversial I hope.

******

The "IANA Considerations" section in the beginning of the draft
contains this:

 Instead requests to define new tag values (say for new encryption
 algorithms for example) should be forwarded to the IESG Security Area
 Directors for consideration or forwarding to the appropriate IETF
 Working Group for consideration.

"forwarded... or forwarding" doesn't parse very well.  I suggest:

 Instead, requests to define new tag values (say for new encryption
 algorithms) should be forwarded to the IESG Security Area Directors
 or the appropriate IETF Working Group for consideration.

******

Section 3.7.1. String-to-key (S2K) specifier types, refers to S2K
value 2 as "illegal".  Everywhere else in the document, such
do-not-use values are referred to as "reserved".

******

Section 3.7.2.1. Secret key encryption says "For compatibility, when
an S2K specifier is used, the special value 255 is stored in the
position where the hash algorithm octet would have been in the old
data structure.".  I suggest changing that to read "... the special
value 255 or 254 ..." since 254 is a legal value there, as the table
immediately after that paragraph makes clear.

******

Section 3.7.2.1. Secret key encryption, and section 5.3. Symmetric-Key
Encrypted Session Key Packets refer to "passphrase" as "pass phrase".
This is inconsistent with the rest of the document which always uses
"passphrase".

******

Section 4.2.2.4. Partial Body Lengths has a paragraph that begins "It
might also be encoded..."  That doesn't make sense since there is no
"it" that the sentence refers to.  I believe that paragaph belongs in
the following section (4.2.3. Packet Length Examples), as the "it" in
question refers to the example "packet with length 100000" from 4.2.3.

******

In section 5.2.1. Signature Types, the signature class 0x18
description says "This signature is calculated directly on the subkey
itself, not on any User ID or other packets", but in fact 0x18
signatures are calculated on the primary key plus subkey.  Similarly,
the 0x19 description says "This signature is calculated directly on
the primary key itself, and not on any User ID or other packets", but
in reality it is calculated exactly the same way as 0x18 is
(primary+subkey).

To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it
would still be nice to not give two different answers for this.

******

5.2.2. Version 3 Signature Packet Format says "The hash h is PKCS-1
padded exactly the same way as for the above described RSA
signatures".  This doesn't really make sense as there is no
description of RSA signatures above.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoFw1009280; Wed, 30 Nov 2005 07:50:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFoFka009279; Wed, 30 Nov 2005 07:50:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFoEp5009272 for <[e-mail]>; Wed, 30 Nov 2005 07:50:14 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 500FB2B44AB; Wed, 30 Nov 2005 16:50:13 +0100 (CET)
Date: Wed, 30 Nov 2005 16:50:13 +0100
To: Ian G <[e-mail]>
Cc: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 30, 2005 at 02:55:55PM +0000, Ian G wrote:

> I think what you mean is that the whitespace
> should not be included in the calculation,
> but it doesn't matter whether they are stripped
> from the document itself.

Yes, that is precisely what I mean.
 
> It is an issue, yes.  We discussed this a while
> back and came to the conclusion that *only* ascii
> whitespace was to be stripped/ignored, as the
> alternate was too hard to define.  That's why
> the specific characters to be stripped are in
> the spec - to stop people looking for cyrillic
> spaces or different sized spaces.

Unfortunately, unlike canonical ascii, there is no one-to-one correspondence
between unicode characters and glyph visuals. It would be nice to have some
canonical form for unicode text which is human-readable, yet has a unique
binary representation, but it's not easy and not the job of this WG, IMHO.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlXUq008967; Wed, 30 Nov 2005 07:47:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUFlXFd008966; Wed, 30 Nov 2005 07:47:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUFlWSB008960 for <[e-mail]>; Wed, 30 Nov 2005 07:47:32 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUFlVS06744 for <[e-mail]>; Wed, 30 Nov 2005 10:47:31 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUFlRX6022461 for <[e-mail]>; Wed, 30 Nov 2005 10:47:27 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUFlQi3023198 for <[e-mail]>; Wed, 30 Nov 2005 10:47:26 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUFlQLI023197 for [e-mail]; Wed, 30 Nov 2005 10:47:26 -0500
Date: Wed, 30 Nov 2005 10:47:25 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 16, 2005 at 03:07:20AM +0100, Daniel A. Nagy wrote:

> As for the subject of our discussion, I think that we all agree that the
> spec for 0x80 should be stripped of "a note from one person to another..."
> bit., because one major implementation does not treat it that way.
> 
> The only disagreement seems to be whether "a note from one person to
> another" should be retained as an interoperable feature or should it be
> delegated to private notation namespace.
> 
> The disadvantage of the  latter approach would be that various implementers
> would (possibly) implement this same semantics with a host of different
> notation names and won't interoperate.
> 
> Now, I can see that implementing the former using a type flag also causes
> problems. Maybe, it should be a common, ITEF-namespace notation? Or an
> entirely separate subpacket type akin to "reason for revocation"?
> 
> I am not sure. But in either case, as far as immediate modifications to the
> standard text are concerned, this "a note..." part should be removed from
> the definition of 0x80, because it means something that 0x80 definitely
> doesn't. Whether or not to add that text someplace else is  an entirely
> different question.

Is this rough consensus?

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUVm003421; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEtUFd003420; Wed, 30 Nov 2005 06:55:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEtUdP003414 for <[e-mail]>; Wed, 30 Nov 2005 06:55:30 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id A69B353375; Wed, 30 Nov 2005 14:55:28 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 14:55:55 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
Cc: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel A. Nagy wrote:
> On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote:
> 
>>Daniel A. Nagy wrote:
>>
>>>On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote:
>>>
>>>>Does this mean they should not be included in the signature, or also
>>>>that they should be stripped from the dash-escaped text?
>>>
>>>It doesn't matter.
>>
>>Of course it matters!
> 
> 
> No, it does not. Either way, the signature will verify. It is up to the
> implementation to strip or not to strip empty line endings. It can even
> change them (e.g. add a few spaces and tabs after some of the line endings).


I think what you mean is that the whitespace
should not be included in the calculation,
but it doesn't matter whether they are stripped
from the document itself.

> Canonization is an idempotent operation. Documents that are the same after
> canonization are considered identical as far as text signaures go.

(I've always seen it written as canonicalisation
or canonicalization.)  So the question is whether
we canonicalise the document or simply canonicalise
the signature processing.  I think the answer is
that it is open to the application.

> For pure ascii text, a printed clearsigned document, if typed back in, should
> verify. Unfortunately, with unicode this is no longer the case, as there is a
> whole bunch of different letters that look exactly the same (e.g. "o" and
> "о" -- the latin and cyrillic "o", repsectively). Actually, this is problem
> for legal applications.

It is an issue, yes.  We discussed this a while
back and came to the conclusion that *only* ascii
whitespace was to be stripped/ignored, as the
alternate was too hard to define.  That's why
the specific characters to be stripped are in
the spec - to stop people looking for cyrillic
spaces or different sized spaces.

iang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsQNx003347; Wed, 30 Nov 2005 06:54:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEsQqO003346; Wed, 30 Nov 2005 06:54:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEsPcP003340 for <[e-mail]>; Wed, 30 Nov 2005 06:54:25 -0800 (PST) (envelope-from [e-mail])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 1E129A3357 for <[e-mail]>; Wed, 30 Nov 2005 06:54:25 -0800 (PST)
Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for <[e-mail]>; Wed, 30 Nov 2005 06:54:24 -0800 (PST)
Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id jAUEsO7E083907 for <[e-mail]>; Wed, 30 Nov 2005 06:54:24 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Wed, 30 Nov 2005 06:54:21 -0800
To: <[e-mail]>
Cc: 
Subject: Re: Lack of clarity in dash-escaped?
From: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 30 Nov 2005 06:09:21 -0800 Ian G <[e-mail]> 
wrote:

>Looking back through old signed contracts it appears
>that Cryptix adds an extra line always but PGP 5.5
>does not, and GPG does not unless needed (see checks
>below).

pgp commandline (all versions) does not add the extra line

gnupg does not

but all clearsigned texts using any gui pgp version
does have an extra line added between the end of the text and the 
signature block

it might cause backward incompatibility/confusion
if it became mandatory one way or the other


vedaal



Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX6wg000372; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEX6pI000371; Wed, 30 Nov 2005 06:33:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEX5PU000338 for <[e-mail]>; Wed, 30 Nov 2005 06:33:06 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jAUEX4S06155 for <[e-mail]>; Wed, 30 Nov 2005 09:33:04 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAUEWxX6022032 for <[e-mail]>; Wed, 30 Nov 2005 09:32:59 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAUEWwdO022996 for <[e-mail]>; Wed, 30 Nov 2005 09:32:58 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAUEWwNB022995 for [e-mail]; Wed, 30 Nov 2005 09:32:58 -0500
Date: Wed, 30 Nov 2005 09:32:58 -0500
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote:
> 
> "   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>     the end of any line is removed when the cleartext signature is
>     generated."
> 
> Does this mean they should not be included in the signature, or also
> that they should be stripped from the dash-escaped text?

A goal of cleartext signatures is that they can survive this sort of
whitespace mangling in transport, so it's actually unimportant if the
whitespace is removed from the dash-escaped text or not.  Either way,
they are not part of the signature, so even implementations that
differ on this point can still verify each others signatures.

> "   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>     SIGNATURE-----' line that terminates the signed text is not
>     considered part of the signed text."
> 
> Does this mean that one should insert an extra <CR><LF> before the
> terminating line? I notice that at least some implementations do not.

I think always writing an extra CRLF is the wrong thing to do, if it
is not present in the original document.  The text from the draft here
just says that the last CRLF (the CRLF that is required to be put the
BEGIN PGP SIGNATURE line at beginning of a line) in the document is
not part of the signed text.

As I see it, reasonable behavior here would be to copy in the original
document (with line ending conversion done) faithfully, then add the
terminating "CRLF-----BEGIN PGP SIGNATURE".  If the last line of the
original document had a line ending (transformed to CRLF here), then
the clearsigned result would include it in the hash and the output:

  this is my last line of text  <-- there was an existing CRLF here
  <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE"
  -----BEGIN PGP SIGNATURE-----

In this case, the hash ends with "this is my last line of textCRLF".

If the last line of the original document didn't have a line ending,
then there would be no blank line, as the CRLF from ----BEGIN PGP
SIGNATURE----- effectively ends that line.

  this is my last line of text  <--- this is the CRLF from "CRLF-----BEGIN PGP SIGNATURE"
  -----BEGIN PGP SIGNATURE-----

In this case, the hash ends with "this is my last line of text" (no
CRLF).

This preserves the existence (or not) of the final line ending in the
clearsigned document.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWjDM000268; Wed, 30 Nov 2005 06:32:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUEWj1D000267; Wed, 30 Nov 2005 06:32:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUEWiXk000259 for <[e-mail]>; Wed, 30 Nov 2005 06:32:44 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B9F81635F8; Wed, 30 Nov 2005 14:32:40 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 14:33:07 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ben Laurie wrote:
> As it is, since I think the idea of stripping them is stupid, I don't
> really care either way, but it would be good if the document were clear.

The issue that it is meant to solve is that
many applications end up adding whitespace
to the ends of lines.  Not just mailers, but
editors, cut&paste, etc.

So the "do not include trailing whitespace"
is an attempt to make the cleartext signature
more robust within the text world it inhabits.
For me, it is a good feature, it makes the
contracts that I send around more reliable;
but always recognising that there are limits
to this game, as the same tools that do this
also do silly things like slicing up lines
and doubling up on newlines.

>>I suppose the above text could change "generated"
>>to "calculated" to make it clearer?  That is, if
>>my interpretation is the consensus.
> 
> 
> I think you have to say "...at the end of the line is not included in
> the signature calculation" to remove the ambiguity (if leaving them in
> the text is intended).


I agree with that.  So I'd agree that this
is a late change that might slip in before
the end if we still have time (always looking
over shoulder to see if the final date is
about to run us over...):


     Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
     the end of any line is not included in the signature calculation."

Maybe add:

     It is an application decision whether to remove trailing whitespace.

(or maybe not.  This horse has died so many times.)


> No - what you are proposing is not reversible. Always adding a <CR><LF>
> _is_ reversable.

Right.  See response to Daniel, who pointed out
the fuller understanding.  So if that is the rule,
we need:

     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text is not
     considered part of the signed text."

to change to:

     On signing, a line ending (i.e. the <CR><LF>) is always
     inserted at the end and before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text.
     This line ending is not part of the signed text nor the
     signature calculation.  It should be stripped when the
     signature is verified and an unsigned document revealed.

Or somesuch.  But I'd like to hear from some of
the old timers to hear whether that is the rule
here.  The alternative is that we simply define
the document as always having a trailing newline,
and that may be non-reversable.

iang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE9694097468; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE969O097467; Wed, 30 Nov 2005 06:09:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE95gi097460 for <[e-mail]>; Wed, 30 Nov 2005 06:09:06 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 28F265B039; Wed, 30 Nov 2005 14:08:54 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 14:09:21 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
Cc: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel A. Nagy wrote:

> Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line.
> The line termination before it is not part of the signature. AFAIK, all
> implementations treat it that way.


It does?  I stand corrected.  I see what you are
getting at - some documents will not have a newline
on (mostly application/windows style documents) and
then it will need to have that added.  Which creates
a problem in deciding whether one was added or not
afterwards when stripping the signature.

Hmmm...

Looking back through old signed contracts it appears
that Cryptix adds an extra line always but PGP 5.5
does not, and GPG does not unless needed (see checks
below).

OK, so clarification needed.  What is the rule here -
when is a line added:

     - always?

     - only when needed to correct the line based content?

Well spotted, Ben!


iang

==================== GPG does not add a line unless needed!

galland$ gpg -at --sign -u DSS3 moo
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information

You need a passphrase to unlock the secret key for
user: "Ian Grigg DSS3 <[e-mail]>"
1024-bit DSA key, ID DABCCA96, created 2000-03-26

galland$ cat moo.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

one
two
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDja0L4yubUNq8ypYRAqjbAKCrCxFZCSdcTaYYnnLuoiaBl+7qjQCgio/q
ZYlGBBBIGr9JEzpkCevdPxs=
=lxXT
-----END PGP SIGNATURE-----
galland$ cat moo
one
two
galland$ dd if=moo of=poo bs=1 count=7
7+0 records in
7+0 records out
7 bytes transferred in 0.000147 secs (47585 bytes/sec)
galland$ cat poo
one
twogalland$ gpg -at --sign -u DSS3 poo
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information

You need a passphrase to unlock the secret key for
user: "Ian Grigg DSS3 <[e-mail]>"
1024-bit DSA key, ID DABCCA96, created 2000-03-26

galland$ cat poo.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

one
two
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDja2A4yubUNq8ypYRAlA+AJ0Y4E41bziMHnB1or04xEXsBytjYwCg5iE8
c5oxusUPe799unMP6RmJbVA=
=m/aW
-----END PGP SIGNATURE-----
galland$ cat poo
one
twogalland$








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5ZSt097112; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUE5Zdn097111; Wed, 30 Nov 2005 06:05:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUE5YPc097104 for <[e-mail]>; Wed, 30 Nov 2005 06:05:35 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id CCD0D5F; Wed, 30 Nov 2005 15:05:33 +0100 (CET)
Date: Wed, 30 Nov 2005 15:05:33 +0100
To: Ian G <[e-mail]>
Cc: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 30, 2005 at 01:19:31PM +0000, Ian G wrote:

> This is an artifact of the old days where
> optimisations were cute, and it was I suppose
> considered smart to save on calculating over the
> last newline.  It is particularly dumb, because
> everything else about the job is line based,
> but this is an exception with no value other
> than creating an exception and thus annoying
> the coders.  None that I ever heard, leastways.

I disagree. The current system allows for texts where the last line has no
line ending. It means, that signed text files can be converted back and
forth between clear-signed and one-pass signed representations, without
losing the signature. This is a very neat feature of OpenPGP, that still
makes a lot of sense.

The following implementation actually uses it (requires java plugin):
http://pgp.epointsystem.org/tool

Unlike hushmail, it does not encrypt clearsigned documents, but if you
decrypt a signed text message, it will output the clearsigned version, which
you can verify. See http://pgp.epointsystem.org/tool-help for usage.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwGg9096311; Wed, 30 Nov 2005 05:58:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDwGqG096307; Wed, 30 Nov 2005 05:58:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDwETF096283 for <[e-mail]>; Wed, 30 Nov 2005 05:58:15 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0634D2B44AB; Wed, 30 Nov 2005 14:58:13 +0100 (CET)
Date: Wed, 30 Nov 2005 14:58:12 +0100
To: Ben Laurie <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 30, 2005 at 01:35:38PM +0000, Ben Laurie wrote:
> Daniel A. Nagy wrote:
> > On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote:
> >> Does this mean they should not be included in the signature, or also
> >> that they should be stripped from the dash-escaped text?
> > 
> > It doesn't matter.
> 
> Of course it matters!

No, it does not. Either way, the signature will verify. It is up to the
implementation to strip or not to strip empty line endings. It can even
change them (e.g. add a few spaces and tabs after some of the line endings).

Canonization is an idempotent operation. Documents that are the same after
canonization are considered identical as far as text signaures go.

For pure ascii text, a printed clearsigned document, if typed back in, should
verify. Unfortunately, with unicode this is no longer the case, as there is a
whole bunch of different letters that look exactly the same (e.g. "o" and
"о" -- the latin and cyrillic "o", repsectively). Actually, this is problem
for legal applications.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgTp5094613; Wed, 30 Nov 2005 05:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDgT4D094612; Wed, 30 Nov 2005 05:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDgQJo094604 for <[e-mail]>; Wed, 30 Nov 2005 05:42:28 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DE73A33C3F; Wed, 30 Nov 2005 13:42:24 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 13:42:34 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Ian G <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ian G wrote:
> Ben Laurie wrote:
>> "   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>>     the end of any line is removed when the cleartext signature is
>>     generated."
>>
>> Does this mean they should not be included in the signature, or also
>> that they should be stripped from the dash-escaped text?
> 
> 
> They should not be included in the signature
> calculations.  It is an open question as to
> whether they should stripped from the text or
> not, up to each application.  I would;  but
> Jon has posted on good reasons why it is not
> the job of the application to change the doc
> that is being processed (signed).

I would agree, if you ended up signing the unchanged document :-)

As it is, since I think the idea of stripping them is stupid, I don't
really care either way, but it would be good if the document were clear.

> I suppose the above text could change "generated"
> to "calculated" to make it clearer?  That is, if
> my interpretation is the consensus.

I think you have to say "...at the end of the line is not included in
the signature calculation" to remove the ambiguity (if leaving them in
the text is intended).

> 
>> "   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>>     SIGNATURE-----' line that terminates the signed text is not
>>     considered part of the signed text."
>>
>> Does this mean that one should insert an extra <CR><LF> before the
>> terminating line? I notice that at least some implementations do not.
> 
> No, there is no need to insert anything, just
> not include the <CR><LF> that must preceed the
> '-----' line in the signature calculation.  In
> this case I would say that there definately
> should not be an extra line ending inserted,
> as that is changing the document in a way that
> is not reversable.

No - what you are proposing is not reversible. Always adding a <CR><LF>
_is_ reversable.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZXbE093738; Wed, 30 Nov 2005 05:35:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDZXSU093737; Wed, 30 Nov 2005 05:35:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDZWcV093729 for <[e-mail]>; Wed, 30 Nov 2005 05:35:32 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DCFA633C3F; Wed, 30 Nov 2005 13:35:29 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 13:35:38 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel A. Nagy wrote:
> On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote:
>> "   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>>     the end of any line is removed when the cleartext signature is
>>     generated."
>>
>> Does this mean they should not be included in the signature, or also
>> that they should be stripped from the dash-escaped text?
> 
> It doesn't matter.

Of course it matters!

>> "   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>>     SIGNATURE-----' line that terminates the signed text is not
>>     considered part of the signed text."
>>
>> Does this mean that one should insert an extra <CR><LF> before the
>> terminating line? I notice that at least some implementations do not.
> 
> Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line.
> The line termination before it is not part of the signature. AFAIK, all
> implementations treat it that way.

That doesn't answer the question.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJBuh091917; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUDJBGv091916; Wed, 30 Nov 2005 05:19:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUDJAF9091909 for <[e-mail]>; Wed, 30 Nov 2005 05:19:11 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 2798A53375; Wed, 30 Nov 2005 13:19:04 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 13:19:31 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ben Laurie wrote:
> "   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>     the end of any line is removed when the cleartext signature is
>     generated."
> 
> Does this mean they should not be included in the signature, or also
> that they should be stripped from the dash-escaped text?


They should not be included in the signature
calculations.  It is an open question as to
whether they should stripped from the text or
not, up to each application.  I would;  but
Jon has posted on good reasons why it is not
the job of the application to change the doc
that is being processed (signed).

I suppose the above text could change "generated"
to "calculated" to make it clearer?  That is, if
my interpretation is the consensus.

> "   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>     SIGNATURE-----' line that terminates the signed text is not
>     considered part of the signed text."
> 
> Does this mean that one should insert an extra <CR><LF> before the
> terminating line? I notice that at least some implementations do not.

No, there is no need to insert anything, just
not include the <CR><LF> that must preceed the
'-----' line in the signature calculation.  In
this case I would say that there definately
should not be an extra line ending inserted,
as that is changing the document in a way that
is not reversable.

This is an artifact of the old days where
optimisations were cute, and it was I suppose
considered smart to save on calculating over the
last newline.  It is particularly dumb, because
everything else about the job is line based,
but this is an exception with no value other
than creating an exception and thus annoying
the coders.  None that I ever heard, leastways.

But there was a discussion about it a long time
ago, and no consensus to fix it up, so we are
stuck with the exception.

IMO!

iang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9nv0090748; Wed, 30 Nov 2005 05:09:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUD9njo090747; Wed, 30 Nov 2005 05:09:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUD9mdn090740 for <[e-mail]>; Wed, 30 Nov 2005 05:09:48 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id BC6752B44AB; Wed, 30 Nov 2005 14:09:46 +0100 (CET)
Date: Wed, 30 Nov 2005 14:09:46 +0100
To: Ben Laurie <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Lack of clarity in dash-escaped?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Nov 30, 2005 at 10:40:40AM +0000, Ben Laurie wrote:
> 
> "   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>     the end of any line is removed when the cleartext signature is
>     generated."
> 
> Does this mean they should not be included in the signature, or also
> that they should be stripped from the dash-escaped text?

It doesn't matter.

> "   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>     SIGNATURE-----' line that terminates the signed text is not
>     considered part of the signed text."
> 
> Does this mean that one should insert an extra <CR><LF> before the
> terminating line? I notice that at least some implementations do not.

Yes, it does. The '-----BEGIN PGP SIGNATURE-----' must begin in a new line.
The line termination before it is not part of the signature. AFAIK, all
implementations treat it that way.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeYsp072046; Wed, 30 Nov 2005 02:40:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUAeYr6072045; Wed, 30 Nov 2005 02:40:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUAeXOg072032 for <[e-mail]>; Wed, 30 Nov 2005 02:40:33 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0CCF133C3F for <[e-mail]>; Wed, 30 Nov 2005 10:40:32 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 10:40:40 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: Lack of clarity in dash-escaped?
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
    the end of any line is removed when the cleartext signature is
    generated."

Does this mean they should not be included in the signature, or also
that they should be stripped from the dash-escaped text?

"   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
    SIGNATURE-----' line that terminates the signed text is not
    considered part of the signed text."

Does this mean that one should insert an extra <CR><LF> before the
terminating line? I notice that at least some implementations do not.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4C85085204; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQE4CTr085203; Sat, 26 Nov 2005 06:04:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQE4BTc085195 for <[e-mail]>; Sat, 26 Nov 2005 06:04:12 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 82E4833C1C for <[e-mail]>; Sat, 26 Nov 2005 14:04:09 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sat, 26 Nov 2005 14:04:11 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: -15 still not clear on signatures
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I was working on my signing code and realised that some issues
previously discussed do not appear to be resolved in -15 (its possible
some of these are also new).

a) V4 signatures don't mention how one actually calculates the signature
- the text only appears for V3 signatures.

b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length
of the encoded message, emLen. emLen is not specified in -15. By
inspection of existing signatures, it seems to me it is one less than
the size of the modulus (which strikes me as theoretically wrong, but if
that's the way it is, I guess that's the way it is).

I proposed patches to clarify this stuff back in April:
http://www.imc.org/ietf-openpgp/mail-archive/msg09799.html.

These appear to be wrong about emLen (off by one), BTW.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27NRC026087; Tue, 15 Nov 2005 18:07:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAG27NPw026086; Tue, 15 Nov 2005 18:07:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAG27LP8026079 for <[e-mail]>; Tue, 15 Nov 2005 18:07:22 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 1D7822B4799; Wed, 16 Nov 2005 03:07:20 +0100 (CET)
Date: Wed, 16 Nov 2005 03:07:20 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Nov 15, 2005 at 10:16:57AM -0800, "Hal Finney" wrote:

> example imagine a signature which says, I am not vouching for the binding
> between userid and key, but rather I am making a certain assertion about
> this userid or key.  If we don't understand this notation the correct
> thing is to ignore the signature, and that is in fact what the spec says
> should happen.

Yes, that is my understanding as well. Critical notation means that it is
essential for the correct interpretation of the signature and without
understanding the notation the signature is meaningless.

> Critical notations allow implementors to essentially extend signature
> semantics beyond the official set of signature types.  We have a protected
> namespace for proprietary extensions, and we have the ability for legacy
> applications silently to ignore unrecognized extensions.  It's a good
> feature.

I agree.

As for the subject of our discussion, I think that we all agree that the
spec for 0x80 should be stripped of "a note from one person to another..."
bit., because one major implementation does not treat it that way.

The only disagreement seems to be whether "a note from one person to
another" should be retained as an interoperable feature or should it be
delegated to private notation namespace.

The disadvantage of the  latter approach would be that various implementers
would (possibly) implement this same semantics with a host of different
notation names and won't interoperate.

Now, I can see that implementing the former using a type flag also causes
problems. Maybe, it should be a common, ITEF-namespace notation? Or an
entirely separate subpacket type akin to "reason for revocation"?

I am not sure. But in either case, as far as immediate modifications to the
standard text are concerned, this "a note..." part should be removed from
the definition of 0x80, because it means something that 0x80 definitely
doesn't. Whether or not to add that text someplace else is  an entirely
different question.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRL7X076563; Tue, 15 Nov 2005 10:27:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIRLTt076562; Tue, 15 Nov 2005 10:27:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIRJCC076549 for <[e-mail]>; Tue, 15 Nov 2005 10:27:20 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id DEE22636CF; Tue, 15 Nov 2005 18:27:18 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 15 Nov 2005 18:27:37 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
Cc: [e-mail]
Subject: Re: Some -15 comments
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel A. Nagy wrote:

> Okay, there is no urgency. But I still think, it is a legitimate feature
> which does not require dramatic changes on implementations' part. At the
> same time, it substantially decreases the roll-out costs of many
> applications, not just mine. Basically, it would enable people to do more
> things without having to write sofware. The "note from one person to
> another" is a nice feature to be included in signatures. If, for obvious
> reasons, 0x80 cannot carry this semantics, some other flag should.


In dealing with signatures-of-legal-import, you may
be saying that you want a "please-display-me" feature
in order to complete this process at the UI level.
But, the notion of a human signature is substantially (*)
more complex than that;  just displaying a comment
attached to a signature is unlikely to bring us close
enough to making the signature work as a legal one.

Which is to say I think this short-changes the subject
matter somewhat.  A full treatment of this will require
many more things than just one extra bit or just one
nice well written specification entry, and until
someone a) has a real need for it and b) does the extra
work to define all of the (wider, legal) aspects of
legally important signatures either in general or in
particular, we won't be able to predict it from here,
and (I claim) it is foolhardy to try.

> The true issue here, as I see it, is that indeed, one can change the
> semantics of notation wihout owning it. If notation flags are not
> considered part of the notation (that is, their use is not restricted by the
> notation specification), then such flags are more or less part of the
> notation value, and should convey information only about the value part
> (e.g. whether it is text, image, boolean, etc.). If this is the case, it
> should be included in the wording of the standard.
> 
> In that case, the feature I would like to see will have to be implemented in
> a completely different fashion, but still preferably in the standard, as it
> is generally useful. On the other hand, I think that notation flags should
> be part of the notation spec; you cannot put binary  data where the spec
> requires text, so the spec may as well specify what flags to use and how
> with the notation, even though the flags' semantics is the same across all
> notations.

Hmm, not entirely sure I followed all that, and it
would probably help if I read the parts in as much
detail as others!  Having said that, if you are
suggesting that these semantics are better off left
to a higher layer called the "notation spec", then
I'd whole-heartedly agree.

iang


PS: (*) C.f., the Ricardian Contract <insert blah blah etc etc here>.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFYqW075557; Tue, 15 Nov 2005 10:15:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFIFYIq075556; Tue, 15 Nov 2005 10:15:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFIFXfn075549 for <[e-mail]>; Tue, 15 Nov 2005 10:15:33 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 8A9FF57F2F; Tue, 15 Nov 2005 10:16:57 -0800 (PST)
To: [e-mail], [e-mail]
Subject: Re: Some -15 comments
Cc: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 15 Nov 2005 10:16:57 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas writes:
> The critical flag can called (only slightly humorously) the non- 
> interoperable flag.
>
> Normally, when an implementation sees any subpacket it doesn't  
> understand, it ignores it. But with the critical flag, you error out  
> if you don't understand it.

That's not my understanding.  Rather, you don't consider the signature
valid, if there is a critical subpacket you don't understand.  You don't
"error out."

Now, for document signatures, failure to understand a critical notation
may in some cases be as bad as erroring-out, because whatever purpose
was meant to be expressed by creating the signature, won't happen.
But for keyring signatures, which are often redundant, we could for
example imagine a signature which says, I am not vouching for the binding
between userid and key, but rather I am making a certain assertion about
this userid or key.  If we don't understand this notation the correct
thing is to ignore the signature, and that is in fact what the spec says
should happen.

Critical notations allow implementors to essentially extend signature
semantics beyond the official set of signature types.  We have a protected
namespace for proprietary extensions, and we have the ability for legacy
applications silently to ignore unrecognized extensions.  It's a good
feature.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrOA070504; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFHTrUS070503; Tue, 15 Nov 2005 09:29:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFHTrBS070497 for <[e-mail]>; Tue, 15 Nov 2005 09:29:53 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Tue, 15 Nov 2005 09:29:50 -0800
Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Nov 2005 09:29:49 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Nov 2005 09:29:49 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: Some -15 comments
Date: Tue, 15 Nov 2005 09:29:53 -0800
To: "Daniel A. Nagy" <[e-mail]>
X-Mailer: Apple Mail (2.746.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 14 Nov 2005, at 6:11 PM, Daniel A. Nagy wrote:

>
> But how to express "you should print this"? I tought the text flag  
> and the
> critical flag together were for this very purpose.
>

The critical flag can called (only slightly humorously) the non- 
interoperable flag.

Normally, when an implementation sees any subpacket it doesn't  
understand, it ignores it. But with the critical flag, you error out  
if you don't understand it.

So ihf you create a human-readable, critical notation, you're asking  
for it to blow up a lot. This may be exactly what you want, but it  
might not.

Now this can create side issues, as well. Let's suppose that I have  
built an automated system (one with no humans). I know exactly what  
your notation is, but I have no human. So I ignore the thing. To me,  
this follows exactly the spirit of "critical" because I know what it  
is and I know I can ignore it. It may not be what you want -- you may  
have thought that human-reable and critical means it will blow up any  
automated process.

Similarly, I might display the notation to a human user and have a  
"please don't show this to me again" check box to have it not  
displayed again. This is a reasonable thing to do, despite a critical  
flag.

This is why I put my tongue in my cheek a bit and call it also the  
non-interoperable flag. If you set the critical flag, you create all  
sorts of interesting ways for the system to surprise people.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYssG059066; Tue, 15 Nov 2005 07:34:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFFYsCk059065; Tue, 15 Nov 2005 07:34:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFFYqZl059049 for <[e-mail]>; Tue, 15 Nov 2005 07:34:53 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0B5982B47CC; Tue, 15 Nov 2005 16:34:51 +0100 (CET)
Date: Tue, 15 Nov 2005 16:34:50 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 10:41:29PM -0800, "Hal Finney" wrote:
> Your 0x40 is more than "human-readable", it is "should be displayed".  I
> don't like the idea of putting in a feature which burdens implementations
> to do certain things in the UI, unless we have a very good reason.
> Our PGP software might have to pop up dialog boxes to deliver these
> notification messages, which I'm sure would bring objections from our
> UI guys.

Unless it already doesn't pop up dialog boxes then it shouldn't pop up new
ones. All I suggest is adding text to the report about successful
verification, if such a report exists.
 
> If and when we come up with a compelling reason to add such a UI mandate
> in our data-format specification, then we could consider it.  We would
> also need to clarify when it should be displayed for key signatures: if
> a web of trust is used, should we display all notations for all keys in
> the chain that were used to establish the trustworthiness of a target key?

Definitely not. You only display the notation, if the successful
verification of the signature is explicitly reported to the user.

> Should this happen on both encryption and signature verification?  And is
> it enough to do it once and consider the user "notified", or should it be
> done every time?
> 
> The answers to questions like these are likely to be application specific.
> That is, for some kinds of notations we would do it one way, and for other
> types of notations we would do it another way.  Maybe some would only be
> for data signatures and not key signatures, or vice versa.  Maybe some
> would only be displayed for signatures on the key being used, while others
> should be displayed for the whole trust chain.  It depends on the purpose.

But isn't that dependence on signature type already resolved by the
different ways in which applications report on successful signature
verification? I was a bit sloppy first by saying that such notation should
be displayed upon successful verification. That is obviously wrong. What I
really have in mind is that such notation should be included in reports of
successful verification, if such reports are provided.

> Putting in this 0x40 flag now, or any mandate for notation packet display,
> will require possibly substantial change to every OpenPGP implementation
> in existence.  Sure, it potentially gives you a lot of leverage to
> implement your desired new feature.  But it is at a great expense.
> We can't go forward with something like this without an extensive
> discussion involving many groups, including UI experts.

Okay, there is no urgency. But I still think, it is a legitimate feature
which does not require dramatic changes on implementations' part. At the
same time, it substantially decreases the roll-out costs of many
applications, not just mine. Basically, it would enable people to do more
things without having to write sofware. The "note from one person to
another" is a nice feature to be included in signatures. If, for obvious
reasons, 0x80 cannot carry this semantics, some other flag should.

The true issue here, as I see it, is that indeed, one can change the
semantics of notation wihout owning it. If notation flags are not
considered part of the notation (that is, their use is not restricted by the
notation specification), then such flags are more or less part of the
notation value, and should convey information only about the value part
(e.g. whether it is text, image, boolean, etc.). If this is the case, it
should be included in the wording of the standard.

In that case, the feature I would like to see will have to be implemented in
a completely different fashion, but still preferably in the standard, as it
is generally useful. On the other hand, I think that notation flags should
be part of the notation spec; you cannot put binary  data where the spec
requires text, so the spec may as well specify what flags to use and how
with the notation, even though the flags' semantics is the same across all
notations.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZbQ044251; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDCZEo044250; Tue, 15 Nov 2005 05:12:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDCZTw044244 for <[e-mail]>; Tue, 15 Nov 2005 05:12:35 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 86BFF6462E; Tue, 15 Nov 2005 13:12:34 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 15 Nov 2005 13:12:53 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: David Shaw <[e-mail]>, [e-mail]
Subject: Re: Some -15 comments
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:

> So can we take the two-week comment period for last call and make it  be 
> Nov 21?

No disagreement here!

iang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBuhE044212; Tue, 15 Nov 2005 05:11:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAFDBuY1044211; Tue, 15 Nov 2005 05:11:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAFDBtHI044205 for <[e-mail]>; Tue, 15 Nov 2005 05:11:55 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id B8DE06462E; Tue, 15 Nov 2005 13:11:53 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 15 Nov 2005 13:12:12 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: David Shaw <[e-mail]>, [e-mail]
Subject: Re: Some -15 comments
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:

>> We discussed a change to 5.2.3.16 (Notation Data) on the list to
>> change:
>>
>>      First octet: 0x80 = human-readable. This note value is text, a
>>                          note from one person to another, and need
>>                          not have meaning to software.
>> to:
>>      First octet: 0x80 = human-readable. This note value is text.
>>
>> Any way that can go in?  I'm perfectly happy to get an "I Told You So"
>> if someone is confused :)
>>
> 
> I remember the discussion, I just don't remember the agreement. Such  is 
> the way with rough consensus.
> 
> Does it matter one way or the other? I admit to being confused as to  
> why it matters. Enlighten me, please.

I agree with the second reading.  The first tries
to define something that eludes definition, and
any attempt to further define it takes us inevitably
into needing more flags (as per Daniel's discussion).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e8Ur004547; Mon, 14 Nov 2005 22:40:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF6e8x1004546; Mon, 14 Nov 2005 22:40:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF6e6fp004538 for <[e-mail]>; Mon, 14 Nov 2005 22:40:07 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 8667357F2F; Mon, 14 Nov 2005 22:41:29 -0800 (PST)
To: [e-mail], [e-mail]
Subject: Re: Some -15 comments
Message-Id: <[e-mail]>
Date: Mon, 14 Nov 2005 22:41:29 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel Nagy writes:
> I understand that and even agree with it in the light of the fact that
> there's already notation in wide use that is not intended for human
> interpretation. But I think that a flag indicating that some notation IS
> intended to be interpreted by humans is still warranted, using a wording
> similar to the original definition of the text flag, perhaps with some
> clarification added. Like this:
>
>         First octet: 0x80 = displayable. This note value is text.
>
>                      0x40 = human-readable. This note value is text, a
>                             note from one person to another, and need
>                             not have meaning to software. If critical,
>                             it MUST be displayed whenever the successful
>                             verification of the signature is reported to
>                             the user

Your 0x40 is more than "human-readable", it is "should be displayed".  I
don't like the idea of putting in a feature which burdens implementations
to do certain things in the UI, unless we have a very good reason.
Our PGP software might have to pop up dialog boxes to deliver these
notification messages, which I'm sure would bring objections from our
UI guys.

If and when we come up with a compelling reason to add such a UI mandate
in our data-format specification, then we could consider it.  We would
also need to clarify when it should be displayed for key signatures: if
a web of trust is used, should we display all notations for all keys in
the chain that were used to establish the trustworthiness of a target key?
Should this happen on both encryption and signature verification?  And is
it enough to do it once and consider the user "notified", or should it be
done every time?

The answers to questions like these are likely to be application specific.
That is, for some kinds of notations we would do it one way, and for other
types of notations we would do it another way.  Maybe some would only be
for data signatures and not key signatures, or vice versa.  Maybe some
would only be displayed for signatures on the key being used, while others
should be displayed for the whole trust chain.  It depends on the purpose.

Putting in this 0x40 flag now, or any mandate for notation packet display,
will require possibly substantial change to every OpenPGP implementation
in existence.  Sure, it potentially gives you a lot of leverage to
implement your desired new feature.  But it is at a great expense.
We can't go forward with something like this without an extensive
discussion involving many groups, including UI experts.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkvf092054; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF4Xkt4092053; Mon, 14 Nov 2005 20:33:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF4Xkpo092044 for <[e-mail]>; Mon, 14 Nov 2005 20:33:46 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111504333501400lrnoke>; Tue, 15 Nov 2005 04:33:40 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF4XhX6028228 for <[e-mail]>; Mon, 14 Nov 2005 23:33:43 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF4XWSE027328 for <[e-mail]>; Mon, 14 Nov 2005 23:33:32 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF4XW4S027327 for [e-mail]; Mon, 14 Nov 2005 23:33:32 -0500
Date: Mon, 14 Nov 2005 23:33:32 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Nov 15, 2005 at 03:51:27AM +0100, Daniel A. Nagy wrote:
> 
> On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote:
> 
> > You would define a notation ("[e-mail]" or
> > the like), which is defined as "show me to a human".
> 
> Sure.
>  
> > You don't want to overload the human-readable flag for that, since
> > there are some human readable notations that while being *capable* of
> > being read by a human, aren't intended for reading by a human on a
> > regular basis.
> 
> I understand that and even agree with it in the light of the fact that
> there's already notation in wide use that is not intended for human
> interpretation. But I think that a flag indicating that some notation IS
> intended to be interpreted by humans is still warranted, using a wording
> similar to the original definition of the text flag, perhaps with some
> clarification added. Like this:
> 
>         First octet: 0x80 = displayable. This note value is text.
> 
>                      0x40 = human-readable. This note value is text, a
>                             note from one person to another, and need
>                             not have meaning to software. If critical,
>                             it MUST be displayed whenever the successful
>                             verification of the signature is reported to
>                             the user

I'm not sure what benefit this has over just defining a notation with
whatever semantics you desire.  This flag, in effect, lets someone
change the semantics of notations they do not own.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pTZp079387; Mon, 14 Nov 2005 18:51:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2pTEH079386; Mon, 14 Nov 2005 18:51:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2pS8X079376 for <[e-mail]>; Mon, 14 Nov 2005 18:51:28 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 67C1D2B479F; Tue, 15 Nov 2005 03:51:27 +0100 (CET)
Date: Tue, 15 Nov 2005 03:51:27 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 09:23:28PM -0500, David Shaw wrote:

> You would define a notation ("[e-mail]" or
> the like), which is defined as "show me to a human".

Sure.
 
> You don't want to overload the human-readable flag for that, since
> there are some human readable notations that while being *capable* of
> being read by a human, aren't intended for reading by a human on a
> regular basis.

I understand that and even agree with it in the light of the fact that
there's already notation in wide use that is not intended for human
interpretation. But I think that a flag indicating that some notation IS
intended to be interpreted by humans is still warranted, using a wording
similar to the original definition of the text flag, perhaps with some
clarification added. Like this:

        First octet: 0x80 = displayable. This note value is text.

                     0x40 = human-readable. This note value is text, a
                            note from one person to another, and need
                            not have meaning to software. If critical,
                            it MUST be displayed whenever the successful
                            verification of the signature is reported to
                            the user

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hdx0078700; Mon, 14 Nov 2005 18:43:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2hdkC078699; Mon, 14 Nov 2005 18:43:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2hcTQ078691 for <[e-mail]>; Mon, 14 Nov 2005 18:43:38 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 91E322B479F; Tue, 15 Nov 2005 03:43:37 +0100 (CET)
Date: Tue, 15 Nov 2005 03:43:37 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 05:56:19PM -0800, "Hal Finney" wrote:

> > Currently, the way I treat this flag is that I display the notation to the
> > user whenever the signature is verified. If that's not the purpuse of this
> > flag, then I would really like another flag with that purpose. See below
> > what I would like to use it for.
> 
> I don't think that will work too well on self-sigs with PGP Corp's new
> preferred-email-encoding subpackets.  You don't want to print those out.

But that's because, strictly speaking, it is not a message meant for users,
and thus a violation of the current wording of the standard. Now, I am
fully supportive of the ITEF practice of letting the implementations shape
the standard, so if the only current implementation uses that flag in the
sense that "this is text" rather than the current wording, I am all for
changing the wording to reflect that, but I think a flag indicating that
some notation is meant (primarily) for human interpretation is warranted.

Here's why: Using this flag, implementations that are unaware of the
contract of that particular notation can still do something useful with it,
namely they can display to the user.
 
> I'm worried that this is going to get too messy.  For a document
> signature, if a user wants to put in some qualifications or conditions,
> it is better to put them into the document itself rather than into a
> notation packet on the signature in the hopes that it will be displayed.
> There are no guarantees about display.

I agree with this.

> Then there are key signatures; and under what circumstances will they be
> displayed?  When encrypting some email, do we want to see every notation
> packet which every signer has decided to add to every key that we encrypt
> to, and perhaps further packets from keys down the web of trust?  How to
> organize it and present it in a coherent way?  It will be a mess.

I don't think so. The way I see it is that such notations (critical+human
interpretable) should be displayed whenever anything is displayed about the
signature at all. For instance, when the user lists the signatures on a
particular key, such notations must be displayed along with the fact of the
existence of the signature.

> If and when we come to the point where we need a kind of notation packet
> that should be displayed on signature verification, we should define its
> use and purpose, create a name for it, and spec it out.  I think that
> is a better path than to have a flag with rather uncertain semantics
> about when it might cause text to be displayed to the user.

But why not have a flag with clear semantics? Like "whenever the fact of
successful signaure verification is reported to the user, this notation must
be included in the report". I don't see any ambiguity here. And it won't
result in a torrent of messages either.
 
> > Here is how I am planning to use human-readable notation: in an on-line
> > trading or auction application, where reputation tracking is important, one
> > can implement user comments about other users' behavior in the form of
> > signatures directly on their public keys with appropriate notation (think of
> > eBay comments). The comment text is, in my opinion, critical in the sense
> > that without it the signature does not make sense, but the implementation's
> > responsibilities are indeed met by just displaying it upon verification.
> 
> You could still do this, but do it based on the notation name rather than
> a flag.  You could have a notation called 'user-reputation-comments'
> or some such.  Your application could then define whatever meaning and
> handling it wanted for how this type of notation packet should be used.

But in your iterpretation of the critical flag, if I mark that notation
critical, applications not aware of its purpose would strip the signaure as
unverifiable. If I don't, I contradict the fact that it _is_ critical for
the correct interpretation of the signature.

Also, I don't feel that I am trying to force my peculiar needs on the
community. I think that many applications could benefit from notation that
is guaranteed to be displayed, when listing key signatures by all
implementataions, while being treated in some special way by those that are
aware of its purpose. A combination of "to be interpreted by humans" and
"critical" seems to express this semantics perfectly. Now, if the "text"
flag does not mean that it should be interpreted by humans, it is perfectly
acceptable. But in that case I feel that there is still a legitimate use for
another flag that does mean that the notation is meant for human interpretation.
Don't you think so?

-- 
Daninel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OjQm076788; Mon, 14 Nov 2005 18:24:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2OjDl076787; Mon, 14 Nov 2005 18:24:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2OiSN076778 for <[e-mail]>; Mon, 14 Nov 2005 18:24:44 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20051115022332015003aacce>; Tue, 15 Nov 2005 02:23:34 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2NdX6027889 for <[e-mail]>; Mon, 14 Nov 2005 21:23:39 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2NS1D026905 for <[e-mail]>; Mon, 14 Nov 2005 21:23:28 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2NSFj026904 for [e-mail]; Mon, 14 Nov 2005 21:23:28 -0500
Date: Mon, 14 Nov 2005 21:23:28 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Nov 15, 2005 at 03:11:10AM +0100, Daniel A. Nagy wrote:
> 
> On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote:
> 
> > I think what you are saying and what Hal and I are saying are
> > basically compatible: interpret the human-readable flag as "I can
> > print this".
> 
> But how to express "you should print this"? I tought the text flag and the
> critical flag together were for this very purpose.

You would define a notation ("[e-mail]" or
the like), which is defined as "show me to a human".

You don't want to overload the human-readable flag for that, since
there are some human readable notations that while being *capable* of
being read by a human, aren't intended for reading by a human on a
regular basis.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EdHN075639; Mon, 14 Nov 2005 18:14:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2EdAZ075638; Mon, 14 Nov 2005 18:14:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2EciP075628 for <[e-mail]>; Mon, 14 Nov 2005 18:14:38 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <20051115021432012002d1rpe>; Tue, 15 Nov 2005 02:14:32 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF2EeX6027850 for <[e-mail]>; Mon, 14 Nov 2005 21:14:40 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF2EUOK026796 for <[e-mail]>; Mon, 14 Nov 2005 21:14:30 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF2EUHS026795 for [e-mail]; Mon, 14 Nov 2005 21:14:30 -0500
Date: Mon, 14 Nov 2005 21:14:29 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote:

> >We discussed a change to 5.2.3.16 (Notation Data) on the list to
> >change:
> >
> >     First octet: 0x80 = human-readable. This note value is text, a
> >                         note from one person to another, and need
> >                         not have meaning to software.
> >to:
> >     First octet: 0x80 = human-readable. This note value is text.
> >
> >Any way that can go in?  I'm perfectly happy to get an "I Told You So"
> >if someone is confused :)
> >
> 
> I remember the discussion, I just don't remember the agreement. Such  
> is the way with rough consensus.

Yes.  I didn't think we had consensus yet.  I'm re-raising it to get
some more discussion.

> Does it matter one way or the other? I admit to being confused as to  
> why it matters. Enlighten me, please.

It matters because the current text states something as true that
shouldn't be true.  A human-readable notation isn't necessarily a note
from one person to another.  Using the only commonly used notation
([e-mail]) as an example, it is human
readable, but is a note from software to software and humans aren't
necessarily involved.

> Incidentally, I apologize for not getting this out before. I sent it  
> to the I-D desk, who whined at me. My correction was eaten by an MTA,  
> which took two weeks to tell me that it was confused, and by then the  
> meeting lull had happened.
> 
> So can we take the two-week comment period for last call and make it  
> be Nov 21?

Sounds good to me.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BCHU075273; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF2BCMA075272; Mon, 14 Nov 2005 18:11:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF2BBiO075266 for <[e-mail]>; Mon, 14 Nov 2005 18:11:12 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 047E52B479F; Tue, 15 Nov 2005 03:11:10 +0100 (CET)
Date: Tue, 15 Nov 2005 03:11:10 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 08:58:52PM -0500, David Shaw wrote:

> I think what you are saying and what Hal and I are saying are
> basically compatible: interpret the human-readable flag as "I can
> print this".

But how to express "you should print this"? I tought the text flag and the
critical flag together were for this very purpose.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x2KN074243; Mon, 14 Nov 2005 17:59:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1x2CW074242; Mon, 14 Nov 2005 17:59:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1x1OZ074232 for <[e-mail]>; Mon, 14 Nov 2005 17:59:01 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005111501585501300io9ose>; Tue, 15 Nov 2005 01:58:55 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAF1x3X6027794 for <[e-mail]>; Mon, 14 Nov 2005 20:59:03 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAF1wqdw026725 for <[e-mail]>; Mon, 14 Nov 2005 20:58:52 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAF1wq9h026724 for [e-mail]; Mon, 14 Nov 2005 20:58:52 -0500
Date: Mon, 14 Nov 2005 20:58:52 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Nov 15, 2005 at 01:13:43AM +0100, Daniel A. Nagy wrote:
> 
> On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote:
> 
> > I'd like to use the flag as a hint to packet-dumping software: if the
> > human-readable flag is set, it is reasonable to dump the notation body
> > as text.  If it is not set, it should be dumped in hex.
> 
> Currently, the way I treat this flag is that I display the notation to the
> user whenever the signature is verified. If that's not the purpuse of this
> flag, then I would really like another flag with that purpose. See below
> what I would like to use it for.

I think what you are saying and what Hal and I are saying are
basically compatible: interpret the human-readable flag as "I can
print this".

> > Another difference arises if the subpacket critical bit is set along with
> > the human-readable flag.  With the current wording it might appear that an
> > implementation's responsibilities are met if it somehow causes the text
> > of the notation packet to be displayed to the user, even if it does not
> > recognize the notation type.  I think that would be a serious mistake.
> > The critical bit should require that the notation type be recognized
> > and handled, in order for the signature to be considered valid.
> 
> Are you sure? I actually think that displaying some notation whenever the
> signature is verified (correctly) makes a lot of sense and it may be part of
> signature verification. After all, it is ultimately the user who decides
> wheter he accepts a signature or not.

There is no conflict here either.  It is perfectly fine to print
notations on signature verification if you choose to do so.  The
problem is if you have a critical notation that your implementation
does not handle.  You can print this notation or not (it's up to you)
but the important thing is that the unhandled critical notation isn't
treated as handled just because you print it.

> Here is how I am planning to use human-readable notation: in an on-line
> trading or auction application, where reputation tracking is important, one
> can implement user comments about other users' behavior in the form of
> signatures directly on their public keys with appropriate notation (think of
> eBay comments). The comment text is, in my opinion, critical in the sense
> that without it the signature does not make sense, but the implementation's
> responsibilities are indeed met by just displaying it upon verification.

That's fine.  You can define a notation type any way you like.  It's
perfectly reasonable to define your notation to meet its critical
"contract" by being shown to a user.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1swqO073960; Mon, 14 Nov 2005 17:54:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1swql073959; Mon, 14 Nov 2005 17:54:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1svrF073952 for <[e-mail]>; Mon, 14 Nov 2005 17:54:57 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 11D7657F2F; Mon, 14 Nov 2005 17:56:19 -0800 (PST)
To: [e-mail], [e-mail]
Subject: Re: Some -15 comments
Message-Id: <[e-mail]>
Date: Mon, 14 Nov 2005 17:56:19 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Daniel Nagy writes:
> On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote:
> > I'd like to use the flag as a hint to packet-dumping software: if the
> > human-readable flag is set, it is reasonable to dump the notation body
> > as text.  If it is not set, it should be dumped in hex.
>
> Currently, the way I treat this flag is that I display the notation to the
> user whenever the signature is verified. If that's not the purpuse of this
> flag, then I would really like another flag with that purpose. See below
> what I would like to use it for.

I don't think that will work too well on self-sigs with PGP Corp's new
preferred-email-encoding subpackets.  You don't want to print those out.


> > Another difference arises if the subpacket critical bit is set along with
> > the human-readable flag.  With the current wording it might appear that an
> > implementation's responsibilities are met if it somehow causes the text
> > of the notation packet to be displayed to the user, even if it does not
> > recognize the notation type.  I think that would be a serious mistake.
> > The critical bit should require that the notation type be recognized
> > and handled, in order for the signature to be considered valid.
>
> Are you sure? I actually think that displaying some notation whenever the
> signature is verified (correctly) makes a lot of sense and it may be part of
> signature verification. After all, it is ultimately the user who decides
> wheter he accepts a signature or not.

I'm worried that this is going to get too messy.  For a document
signature, if a user wants to put in some qualifications or conditions,
it is better to put them into the document itself rather than into a
notation packet on the signature in the hopes that it will be displayed.
There are no guarantees about display.

Then there are key signatures; and under what circumstances will they be
displayed?  When encrypting some email, do we want to see every notation
packet which every signer has decided to add to every key that we encrypt
to, and perhaps further packets from keys down the web of trust?  How to
organize it and present it in a coherent way?  It will be a mess.

If and when we come to the point where we need a kind of notation packet
that should be displayed on signature verification, we should define its
use and purpose, create a name for it, and spec it out.  I think that
is a better path than to have a flag with rather uncertain semantics
about when it might cause text to be displayed to the user.


> Here is how I am planning to use human-readable notation: in an on-line
> trading or auction application, where reputation tracking is important, one
> can implement user comments about other users' behavior in the form of
> signatures directly on their public keys with appropriate notation (think of
> eBay comments). The comment text is, in my opinion, critical in the sense
> that without it the signature does not make sense, but the implementation's
> responsibilities are indeed met by just displaying it upon verification.

You could still do this, but do it based on the notation name rather than
a flag.  You could have a notation called 'user-reputation-comments'
or some such.  Your application could then define whatever meaning and
handling it wanted for how this type of notation packet should be used.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Dj3q062677; Mon, 14 Nov 2005 16:13:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF0DjRb062676; Mon, 14 Nov 2005 16:13:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF0Diss062669 for <[e-mail]>; Mon, 14 Nov 2005 16:13:44 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8C4452B479F; Tue, 15 Nov 2005 01:13:43 +0100 (CET)
Date: Tue, 15 Nov 2005 01:13:43 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote:

> I'd like to use the flag as a hint to packet-dumping software: if the
> human-readable flag is set, it is reasonable to dump the notation body
> as text.  If it is not set, it should be dumped in hex.

Currently, the way I treat this flag is that I display the notation to the
user whenever the signature is verified. If that's not the purpuse of this
flag, then I would really like another flag with that purpose. See below
what I would like to use it for.

> David's second version better expresses this, IMO.  By just saying
> that the note value is text, that means it is reasonable to print it
> if desired.  Even software which doesn't understand the meaning of the
> notation could print it, and it would be readable.
> 
> The current wording carries much more baggage which IMO is not accurate.
> We might want to set the human-readable flag on notation packets which
> are not primarily meant as notes from one person to another.

I agree with this.
 
> Another difference arises if the subpacket critical bit is set along with
> the human-readable flag.  With the current wording it might appear that an
> implementation's responsibilities are met if it somehow causes the text
> of the notation packet to be displayed to the user, even if it does not
> recognize the notation type.  I think that would be a serious mistake.
> The critical bit should require that the notation type be recognized
> and handled, in order for the signature to be considered valid.

Are you sure? I actually think that displaying some notation whenever the
signature is verified (correctly) makes a lot of sense and it may be part of
signature verification. After all, it is ultimately the user who decides
wheter he accepts a signature or not.

Here is how I am planning to use human-readable notation: in an on-line
trading or auction application, where reputation tracking is important, one
can implement user comments about other users' behavior in the form of
signatures directly on their public keys with appropriate notation (think of
eBay comments). The comment text is, in my opinion, critical in the sense
that without it the signature does not make sense, but the implementation's
responsibilities are indeed met by just displaying it upon verification.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF01BZs061223; Mon, 14 Nov 2005 16:01:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF01BCw061222; Mon, 14 Nov 2005 16:01:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF019P5061209 for <[e-mail]>; Mon, 14 Nov 2005 16:01:10 -0800 (PST) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id CBDED2B479F; Tue, 15 Nov 2005 01:01:08 +0100 (CET)
Date: Tue, 15 Nov 2005 01:01:08 +0100
To: [e-mail]
Subject: Re: Some -15 comments
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
From: [e-mail] (Daniel A. Nagy)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote:

> >In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the
> >phrase:
> >
> > "(often literal data packets or compressed data packets)"
> >
> >should probably be:
> >
> > "(often a literal data packet or compressed data packet)"
> >
> >since we no longer allow multiple literal packets in a row.
> >
> 
> Changed.

Actually, can it be anything else? Most OpenPGP parsers would understand an
arbitrary nesting of compressed, encrypted and MDC-protected encrypted
packets, but does that make sense?

I can see a different use for it, however. Being a bit uneasy about the
secret key packet format (Packet tag 5, Section 5.5.1.3.), I think, it is
ultimately up to the implementation, how they store and protect private
keys, as it does not affect interoperability, as long as private keys can be
exported and imported in a common format.

Some text about this should be added to 5.5.1.3., in my opinion, stating that
implementations SHOULD be able to export and import private keys in this
format. It is the more important, as the passphrase-protected version is
vulnerable to the Klima-Rosa attack. I am hesitant whether to say that they
MAY store them in this way (as most actually do) or would it be more
appropriate to say that new implementations SHOULD NOT do that.

For secure storage and transmission of private keys, one could put a
private key packet (tag 5) without passphrase protection into an
MDC-protected encrypted packet (tag 18), maybe with compression in between.
This would thwart the Klima-Rosa attack, while not requiring dramatical
changes to the standard.

But again, I think that the storage format of private keys needs not be
standardized. For example, our ePointPGP tool (see
http://pgp.epointsystem.org/tool-help) generates private keys directly from
the passphrase, without storing them in any way. Yet, it is fully
interoperable with many other RFC2440bis implementations on the message
and public key level.

-- 
Daniel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENag96058541; Mon, 14 Nov 2005 15:36:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAENagHH058540; Mon, 14 Nov 2005 15:36:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAENaMYq058506 for <[e-mail]>; Mon, 14 Nov 2005 15:36:29 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 332A657F2F; Mon, 14 Nov 2005 15:37:44 -0800 (PST)
To: [e-mail], [e-mail]
Subject: Re: Some -15 comments
Cc: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 14 Nov 2005 15:37:44 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon writes, quoting David:
> > We discussed a change to 5.2.3.16 (Notation Data) on the list to
> > change:
> >
> >      First octet: 0x80 = human-readable. This note value is text, a
> >                          note from one person to another, and need
> >                          not have meaning to software.
> > to:
> >      First octet: 0x80 = human-readable. This note value is text.
> >
> > Any way that can go in?  I'm perfectly happy to get an "I Told You So"
> > if someone is confused :)
> >
>
> I remember the discussion, I just don't remember the agreement. Such  
> is the way with rough consensus.
>
> Does it matter one way or the other? I admit to being confused as to  
> why it matters. Enlighten me, please.

What is the functional purpose of this flag?  The meaning of the notation
is going to come from its name field.  The flag is somewhat superfluous.

I'd like to use the flag as a hint to packet-dumping software: if the
human-readable flag is set, it is reasonable to dump the notation body
as text.  If it is not set, it should be dumped in hex.

David's second version better expresses this, IMO.  By just saying
that the note value is text, that means it is reasonable to print it
if desired.  Even software which doesn't understand the meaning of the
notation could print it, and it would be readable.

The current wording carries much more baggage which IMO is not accurate.
We might want to set the human-readable flag on notation packets which
are not primarily meant as notes from one person to another.

Another difference arises if the subpacket critical bit is set along with
the human-readable flag.  With the current wording it might appear that an
implementation's responsibilities are met if it somehow causes the text
of the notation packet to be displayed to the user, even if it does not
recognize the notation type.  I think that would be a serious mistake.
The critical bit should require that the notation type be recognized
and handled, in order for the signature to be considered valid.

PGP Corporation added the preferred-email-encoding self-signature notation
packet, and it has the human-readable flag set.  This is not a note from
one person to another, rather it is intended solely to be handled by
the software.  However it is human readable and if the key is displayed
in some detailed way it would be reasonable for the software to print
the contents of the notation packet.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkRSj052407; Mon, 14 Nov 2005 14:46:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAEMkR8N052406; Mon, 14 Nov 2005 14:46:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAEMkQOp052399 for <[e-mail]>; Mon, 14 Nov 2005 14:46:26 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 14 Nov 2005 14:46:22 -0800
Received: from [192.168.1.2] ([12.104.13.32]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Nov 2005 14:46:22 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Nov 2005 14:46:22 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: Some -15 comments
Date: Mon, 14 Nov 2005 14:46:26 -0800
To: David Shaw <[e-mail]>
X-Mailer: Apple Mail (2.746.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 10 Nov 2005, at 9:54 AM, David Shaw wrote:

>
> I did a quick read over bis15:
>
> In 5.2.1. Signature Types, in the section about the 0x18 subkey
> binding signature, the binding for a signing subkey MUST (not SHOULD)
> contain a back signature.  This was discussed on the list.
>

Fixed.

> ======
>
> We discussed a change to 5.2.3.16 (Notation Data) on the list to
> change:
>
>      First octet: 0x80 = human-readable. This note value is text, a
>                          note from one person to another, and need
>                          not have meaning to software.
> to:
>      First octet: 0x80 = human-readable. This note value is text.
>
> Any way that can go in?  I'm perfectly happy to get an "I Told You So"
> if someone is confused :)
>

I remember the discussion, I just don't remember the agreement. Such  
is the way with rough consensus.

Does it matter one way or the other? I admit to being confused as to  
why it matters. Enlighten me, please.

> ======
>
> 5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail
> name", but there is no such object in 2822.  2822 calls it a
> "name-addr".
>

Changed to name-addr

> ======
>
> In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the
> phrase:
>
>  "(often literal data packets or compressed data packets)"
>
> should probably be:
>
>  "(often a literal data packet or compressed data packet)"
>
> since we no longer allow multiple literal packets in a row.
>

Changed.

> ======
>
> In 13. Security Considerations, in the section discussing the
> Mister/Zuccherato attack, the last sentence of the third paragraph is
> missing a period.
>

Fixed.

> ======
>
> Aside from that, has anyone heard anything new about the rumored
> "bigger DSA" update?


I asked during the hash bash and was told, "soon." But then, that's  
what I was told at CRYPTO 2004. Don't hold your breath.


Incidentally, I apologize for not getting this out before. I sent it  
to the I-D desk, who whined at me. My correction was eaten by an MTA,  
which took two weeks to tell me that it was confused, and by then the  
meeting lull had happened.

So can we take the two-week comment period for last call and make it  
be Nov 21?

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsjor097982; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAHsjVZ097981; Thu, 10 Nov 2005 09:54:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAHsim2097953 for <[e-mail]>; Thu, 10 Nov 2005 09:54:45 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005111017543501400lreqhe>; Thu, 10 Nov 2005 17:54:39 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAHsZX6032087 for <[e-mail]>; Thu, 10 Nov 2005 12:54:35 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAHsX8w013727 for <[e-mail]>; Thu, 10 Nov 2005 12:54:33 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAHsXP6013726 for [e-mail]; Thu, 10 Nov 2005 12:54:33 -0500
Date: Thu, 10 Nov 2005 12:54:33 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Some -15 comments
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I did a quick read over bis15:

In 5.2.1. Signature Types, in the section about the 0x18 subkey
binding signature, the binding for a signing subkey MUST (not SHOULD)
contain a back signature.  This was discussed on the list.

======

We discussed a change to 5.2.3.16 (Notation Data) on the list to
change:
 
     First octet: 0x80 = human-readable. This note value is text, a
                         note from one person to another, and need
                         not have meaning to software. 
to:
     First octet: 0x80 = human-readable. This note value is text.

Any way that can go in?  I'm perfectly happy to get an "I Told You So"
if someone is confused :)

======

5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail
name", but there is no such object in 2822.  2822 calls it a
"name-addr".

======

In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the
phrase:

 "(often literal data packets or compressed data packets)"

should probably be:

 "(often a literal data packet or compressed data packet)"

since we no longer allow multiple literal packets in a row.

======

In 13. Security Considerations, in the section discussing the
Mister/Zuccherato attack, the last sentence of the third paragraph is
missing a period.

======

Aside from that, has anyone heard anything new about the rumored
"bigger DSA" update?

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWrst087577; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAGWrVV087576; Thu, 10 Nov 2005 08:32:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAGWorM087565 for <[e-mail]>; Thu, 10 Nov 2005 08:32:53 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAAGWkeS015293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Thu, 10 Nov 2005 17:32:47 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header -02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:051110:[e-mail]::thcmyLtxZtH0mbvL:4CVN
Date: Thu, 10 Nov 2005 17:32:40 +0100
In-Reply-To: <[e-mail]> (David Shaw's message of "Thu, 10 Nov 2005 10:34:21 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv
X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

> On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote:
>
>> Yes, how about this use-case: An announcement-only mailing list
>> might prefer OpenPGP signed messages.  It could then add a 'OpenPGP:
>> preference=sign' message to all list posts.  The sender could be the
>> mailing list address, which may not have a OpenPGP key at all.  So
>> you couldn't fetch an OpenPGP key for the mailing list address.
>> Arguable, the mailing list managers could create a dummy OpenPGP key
>> for the mailing list address, and set the e-mail preference and
>> upload the key.  However, so could anyone, since the key isn't used
>> nor trusted by anyone.  The announcement-only mailing list could be
>> some abstract mail addresses too.  Like [e-mail] or
>> similar.
>
> I agree this is a reasonable use.  I've also re-read over the -02
> draft, and it does have language in section 2 about not overtrusting
> the header that I had missed earlier.
>
> Would it be worth making this more explicit by adding something about
> actual conflicts between the OpenPGP header and the key to that
> section?  Something like:

Section 2 is intended to give an introduction, so I believe such text
should belong in the section that define the header.  It would be
useful to repeat the warning there as well.

I have added the following at the beginning of section 3:

      <t>Because the header is typically not integrity protected, the
	information conveyed in the OpenPGP header field MUST NOT be
	trusted without additional verification.  Some of the
	information given in this header may also be given on the
	OpenPGP key itself.  When these two sources conflict, users
	SHOULD favor the information from the OpenPGP key, as that
	information can be cryptographically protected.</t>

What do you think?

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYU3G079567; Thu, 10 Nov 2005 07:34:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAAFYU5A079566; Thu, 10 Nov 2005 07:34:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAAFYTFt079558 for <[e-mail]>; Thu, 10 Nov 2005 07:34:29 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005111015342301400p7qgie>; Thu, 10 Nov 2005 15:34:23 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jAAFYNX6031579 for <[e-mail]>; Thu, 10 Nov 2005 10:34:23 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jAAFYLxQ013563 for <[e-mail]>; Thu, 10 Nov 2005 10:34:21 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jAAFYL4p013562 for [e-mail]; Thu, 10 Nov 2005 10:34:21 -0500
Date: Thu, 10 Nov 2005 10:34:21 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header -02
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote:

> Yes, how about this use-case: An announcement-only mailing list
> might prefer OpenPGP signed messages.  It could then add a 'OpenPGP:
> preference=sign' message to all list posts.  The sender could be the
> mailing list address, which may not have a OpenPGP key at all.  So
> you couldn't fetch an OpenPGP key for the mailing list address.
> Arguable, the mailing list managers could create a dummy OpenPGP key
> for the mailing list address, and set the e-mail preference and
> upload the key.  However, so could anyone, since the key isn't used
> nor trusted by anyone.  The announcement-only mailing list could be
> some abstract mail addresses too.  Like [e-mail] or
> similar.

I agree this is a reasonable use.  I've also re-read over the -02
draft, and it does have language in section 2 about not overtrusting
the header that I had missed earlier.

Would it be worth making this more explicit by adding something about
actual conflicts between the OpenPGP header and the key to that
section?  Something like:

  Some of the information given in this header may also be given on
  the OpenPGP key itself.  When these two sources conflict, users
  SHOULD favor the information from the OpenPGP key, as that information
  can be cryptographically protected.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No2vK045479; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA7No2Rq045478; Mon, 7 Nov 2005 15:50:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA7No1qm045464 for <[e-mail]>; Mon, 7 Nov 2005 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EZGkT-0005cZ-Eq; Mon, 07 Nov 2005 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-15.txt 
Message-Id: <[e-mail]>
Date: Mon, 07 Nov 2005 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-15.txt
	Pages		: 73
	Date		: 2005-11-7
	
This document is maintained in order to publish all necessary
    information needed to develop interoperable applications based on
    the OpenPGP format. It is not a step-by-step cookbook for writing an
    application. It describes only the format and methods needed to
    read, check, generate, and write conforming packets crossing any
    network. It does not deal with storage and implementation questions.
    It does, however, discuss implementation issues necessary to avoid
    security flaws.

    OpenPGP software uses a combination of strong public-key and
    symmetric cryptography to provide security services for electronic
    communications and data storage.  These services include
    confidentiality, key management, authentication, and digital
    signatures. This document specifies the message formats used in
    OpenPGP.
    OpenPGP software uses a combination of strong public-key and
    symmetric cryptography to provide security services for electronic
    communications and data storage.  These services include
    confidentiality, key management, authentication, and digital
    signatures. This document specifies the message formats used in
    OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJLXq067361; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4FJLoN067360; Fri, 4 Nov 2005 07:19:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc14.comcast.net ([63.240.77.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4FJKv2067307 for <[e-mail]>; Fri, 4 Nov 2005 07:19:21 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005110415184501400sua2ve>; Fri, 4 Nov 2005 15:18:45 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA4FIjX6026720 for <[e-mail]>; Fri, 4 Nov 2005 10:18:45 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA4FIi2q005063 for <[e-mail]>; Fri, 4 Nov 2005 10:18:44 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA4FIijF005062 for [e-mail]; Fri, 4 Nov 2005 10:18:44 -0500
Date: Fri, 4 Nov 2005 10:18:44 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header -02
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Nov 03, 2005 at 01:48:25PM -0600, Brian G. Peterson wrote:
> 
> On Thursday 03 November 2005 10:21 am, David Shaw wrote:
> > I have some concerns with this preference field.  There is already a
> > way to specify this preference on the key itself
> > ("[e-mail]"). 
> 
> I'd like to see the preferred-email-encoding issue covered in an RFC or draft.  
> I think that the issues around user preference and interoperability really 
> need to be in an official RFC.  Hopefully we can take this up as 2440bis 
> winds up and moves on into the next stages.

I agree.  I think the current design is just fine, but documenting it
in an RFC is a good thing to do.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpjcP064017; Fri, 4 Nov 2005 06:51:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA4EpjA6064016; Fri, 4 Nov 2005 06:51:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA4EpfpJ064004 for <[e-mail]>; Fri, 4 Nov 2005 06:51:44 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA4EpbGs000401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Fri, 4 Nov 2005 15:51:38 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header -02
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:051104:[e-mail]::cPU0iZLr2Tu4Io8A:1v8d
Date: Fri, 04 Nov 2005 15:51:35 +0100
In-Reply-To: <[e-mail]> (David Shaw's message of "Thu, 3 Nov 2005 11:21:44 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed  version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv
X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

> On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote:
>> 
>> Hi everyone!  FYI:
>> 
>> I submitted an updated version of this document a few weeks ago.  The
>> changes since -01 are small: A new "preference" field has been added,
>> to signal whether the sender wish that e-mail should be signed,
>> encrypted or both.
>
> I have some concerns with this preference field.  There is already a
> way to specify this preference on the key itself
> ("[e-mail]").

That is not standardized though.  I agree with Brian that I'd like to
see it standardized.

> Once a user finds the key, they have an authoritative and
> tamperproof statement about email preference.  The OpenPGP header is
> not tamperproof, and having the preference in there raises the
> question what to do if the header preference doesn't match the
> preference on the key.

I hope the OpenPGP document doesn't leave any questions as to what
should happen.  The document says in several places that it is for
informational purposes, and that the information should not be
considered trust-worthy.

> I see the OpenPGP header as a useful key finding aid.  Once the key is
> found, though, the header has served its purpose.

I recall some situations where this preference field might be useful.
I think it was another way to bootstrap OpenPGP communication.

Yes, how about this use-case: An announcement-only mailing list might
prefer OpenPGP signed messages.  It could then add a 'OpenPGP:
preference=sign' message to all list posts.  The sender could be the
mailing list address, which may not have a OpenPGP key at all.  So you
couldn't fetch an OpenPGP key for the mailing list address.  Arguable,
the mailing list managers could create a dummy OpenPGP key for the
mailing list address, and set the e-mail preference and upload the
key.  However, so could anyone, since the key isn't used nor trusted
by anyone.  The announcement-only mailing list could be some abstract
mail addresses too.  Like [e-mail] or similar.

I haven't thought this idea through, so it may be silly.  However, I
recall convincing myself that the OpenPGP field may be useful in some
situations where a OpenPGP key preference field is less useful.  These
two ideas doesn't have to be mutually exclusive.  It is clear that the
tamper-proof preference should be preferred, if you trust that key,
but otherwise it doesn't matter.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmdYY020109; Thu, 3 Nov 2005 11:48:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JmdEr020108; Thu, 3 Nov 2005 11:48:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JmbV8020101 for <[e-mail]>; Thu, 3 Nov 2005 11:48:38 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.3.106] (terminus [66.92.135.15]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id jA3JmR14023971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Nov 2005 13:48:28 -0600
From: "Brian G. Peterson" <[e-mail]>
Organization: Braverock Ventures
To: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: OpenPGP mail/news header -02
Date: Thu, 3 Nov 2005 13:48:25 -0600
User-Agent: KMail/1.8.3
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thursday 03 November 2005 10:21 am, David Shaw wrote:
> I have some concerns with this preference field.  There is already a
> way to specify this preference on the key itself
> ("[e-mail]"). 

I'd like to see the preferred-email-encoding issue covered in an RFC or draft.  
I think that the issues around user preference and interoperability really 
need to be in an official RFC.  Hopefully we can take this up as 2440bis 
winds up and moves on into the next stages.

Regards,

   - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JVA9B018600; Thu, 3 Nov 2005 11:31:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3JVAmU018599; Thu, 3 Nov 2005 11:31:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3JV4vA018583 for <[e-mail]>; Thu, 3 Nov 2005 11:31:04 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110319305401300g34ase>; Thu, 3 Nov 2005 19:30:56 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3JUsX6022478; Thu, 3 Nov 2005 14:30:54 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3JUqd5001689; Thu, 3 Nov 2005 14:30:52 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3JUpF1001688; Thu, 3 Nov 2005 14:30:51 -0500
Date: Thu, 3 Nov 2005 14:30:51 -0500
From: David Shaw <[e-mail]>
To: Anand Kumria <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt
Message-ID: <[e-mail]>
Mail-Followup-To: Anand Kumria <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Oct 31, 2005 at 06:25:32PM +1100, Anand Kumria wrote:
> Hi there,
> 
> The openpgp-mailnews-header defines a mechanism for senders to notify
> recipients of both their preferences (w.r.t OpenPGP keys) and the keying
> material to be used (e.g. keyid).
> 
> dnsext-rfc2538bis defines a mechanism where keying material is stored
> within the DNS (e.g. OpenPGP).  The overlap here is that users may wish
> to store their key in the DNS (via dnsext-rfc2538bis) and refer to them
> using openpgp-mailnews-header.
> 
> Since openpgp-mailnews-header specifies using a URI to refer to the
> location, it would seem -- to me at least -- that there needs to be some
> kind of URI specification to allow you to refer to DNS resource records.
> 
> Is there one already, or work underway to produce a DNS URI spec.?

There is this, by the same author as rfc2538bis:

  http://josefsson.org/dns-url/draft-josefsson-dns-url-13.txt

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GMCSV095590; Thu, 3 Nov 2005 08:22:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3GMC1N095589; Thu, 3 Nov 2005 08:22:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3GM9dd095571 for <[e-mail]>; Thu, 3 Nov 2005 08:22:09 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110316214901300g0hkce>; Thu, 3 Nov 2005 16:21:50 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3GLmX6021881; Thu, 3 Nov 2005 11:21:48 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3GLljG001489; Thu, 3 Nov 2005 11:21:47 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3GLiLx001488; Thu, 3 Nov 2005 11:21:44 -0500
Date: Thu, 3 Nov 2005 11:21:44 -0500
From: David Shaw <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: OpenPGP mail/news header -02
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote:
> 
> Hi everyone!  FYI:
> 
> I submitted an updated version of this document a few weeks ago.  The
> changes since -01 are small: A new "preference" field has been added,
> to signal whether the sender wish that e-mail should be signed,
> encrypted or both.

I have some concerns with this preference field.  There is already a
way to specify this preference on the key itself
("[e-mail]").  Once a user finds the key, they
have an authoritative and tamperproof statement about email
preference.  The OpenPGP header is not tamperproof, and having the
preference in there raises the question what to do if the header
preference doesn't match the preference on the key.

I see the OpenPGP header as a useful key finding aid.  Once the key is
found, though, the header has served its purpose.

David