OpenPGP mail/news header -02

[Simon Josefsson <[e-mail]>]

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.

Given previous discussions, I feel that we won't be able to reach
consensus on a "supports" token, to signal preference between
PGP/MIME, inline PGP (or even a combined PGP+MIME mode), so I am will
drop it altogether unless someone proposes text.  The problem in
proposing text is that there is no specifications, at least that I
know about, that describe how OpenPGP is used in e-mail, except for
PGP/MIME.  And no, RFC 2440 is not sufficient, as it doesn't describe
interaction with non-ASCII, format=flowed, attachments, UseNet
signatures and perhaps other things that I forget.

The remaining issue is to fix the ABNF schema.  Once that is finished,
I will ask the IESG to publish this as an individual draft.

Thanks,
Simon

[e-mail] writes:

> 	Title		: The OpenPGP mail and news header
> 	Author(s)	: A. Smasher, S. Josefsson
> 	Filename	: draft-josefsson-openpgp-mailnews-header-02.txt
> 	
>    This document describes the OpenPGP mail and news header field.  The
>    field provide information about the sender's OpenPGP key.
>
>    See <http://josefsson.org/openpgp-header/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-02.txt





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 j9VAC5sY042742; Mon, 31 Oct 2005 02:12:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9VAC533042741; Mon, 31 Oct 2005 02:12:05 -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 j9VAC3xn042732 for <[e-mail]>; Mon, 31 Oct 2005 02:12:04 -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 j9VABv4h019126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Mon, 31 Oct 2005 11:11:58 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: OpenPGP mail/news header -02
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:051031:[e-mail]::jwZBWJ4Itu1Fic7K:lQb
X-Hashcash: 1:21:051031:[e-mail]::JItYRLh7T1K5U6yQ:4Cl0
X-Hashcash: 1:21:051031:[e-mail]::yTYX5gQnqWtXdlY9:F/D
Date: Mon, 31 Oct 2005 11:11:56 +0100
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Fri, 23 Sep 2005 15:50:01 -0400")
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.5 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>

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.

Given previous discussions, I feel that we won't be able to reach
consensus on a "supports" token, to signal preference between
PGP/MIME, inline PGP (or even a combined PGP+MIME mode), so I am will
drop it altogether unless someone proposes text.  The problem in
proposing text is that there is no specifications, at least that I
know about, that describe how OpenPGP is used in e-mail, except for
PGP/MIME.  And no, RFC 2440 is not sufficient, as it doesn't describe
interaction with non-ASCII, format=flowed, attachments, UseNet
signatures and perhaps other things that I forget.

The remaining issue is to fix the ABNF schema.  Once that is finished,
I will ask the IESG to publish this as an individual draft.

Thanks,
Simon

[e-mail] writes:

> 	Title		: The OpenPGP mail and news header
> 	Author(s)	: A. Smasher, S. Josefsson
> 	Filename	: draft-josefsson-openpgp-mailnews-header-02.txt
> 	
>    This document describes the OpenPGP mail and news header field.  The
>    field provide information about the sender's OpenPGP key.
>
>    See <http://josefsson.org/openpgp-header/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-02.txt



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 j9V9K43K037293; Mon, 31 Oct 2005 01:20:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9V9K4nq037292; Mon, 31 Oct 2005 01:20:04 -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 j9V9JxPC037282 for <[e-mail]>; Mon, 31 Oct 2005 01:20:02 -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 j9V9Jo67015082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2005 10:19:51 +0100
From: Simon Josefsson <[e-mail]>
To: Anand Kumria <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:051031:[e-mail]::zps4UTjWjQPDkkXk:DFD
X-Hashcash: 1:21:051031:[e-mail]::65CcOm6jPNVce6UH:05TY
X-Hashcash: 1:21:051031:[e-mail]::CMH89fihcir08DM5:32Lv
X-Hashcash: 1:21:051031:[e-mail]::5o48/ciODQblpBLq:4HKV
Date: Mon, 31 Oct 2005 10:19:49 +0100
In-Reply-To: <[e-mail]> (Anand Kumria's message of "Mon, 31 Oct 2005 18:25:32 +1100")
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=-1.7 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>

Anand Kumria <[e-mail]> writes:

> 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.?

Hi Anand!  Thanks for your interest.  The document you refer to is in
the RFC Editor's queue; see also <http://josefsson.org/dns-url/>.

Cheers,
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 j9P7iaGH071065; Tue, 25 Oct 2005 00:44:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9P7iaVd071064; Tue, 25 Oct 2005 00:44:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9P7iY6G071040 for <[e-mail]>; Tue, 25 Oct 2005 00:44:35 -0700 (PDT) (envelope-from [e-mail])
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9P7iSZB137818 for <[e-mail]>; Tue, 25 Oct 2005 07:44:28 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9P7iSm3233590 for <[e-mail]>; Tue, 25 Oct 2005 09:44:28 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9P7iS2q003296 for <[e-mail]>; Tue, 25 Oct 2005 09:44:28 +0200
Received: from d12ml065.megacenter.de.ibm.com (d12ml065.megacenter.de.ibm.com [9.149.167.11]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9P7iSfY003293 for <[e-mail]>; Tue, 25 Oct 2005 09:44:28 +0200
To: [e-mail]
MIME-Version: 1.0
Subject: Calculation of signature in OpenPGP 
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Peter Byldner <[e-mail]>
Date: Tue, 25 Oct 2005 09:44:27 +0200
X-MIMETrack: Serialize by Router on D12ML065/12/M/IBM(Release 6.53HF247 | January 6, 2005) at 25/10/2005 09:44:28, Serialize complete at 25/10/2005 09:44:28
Content-Type: multipart/alternative; boundary="=_alternative 002A85B5C12570A5_="
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>

This is a multipart message in MIME format.
--=_alternative 002A85B5C12570A5_=
Content-Type: text/plain; charset="US-ASCII"

I have question regarding the PGP digital signature (RFC3156).

On page 5 you have the well known sample:

 MIME Security with OpenPGP            August 2001


         Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
           protocol="application/pgp-signature"

         --bar
      & Content-Type: text/plain; charset=iso-8859-1
      & Content-Transfer-Encoding: quoted-printable
      &
      & =A1Hola!
      &
      & Did you know that talking to yourself is a sign of senility?
      &
      & It's generally a good idea to encode lines that begin with
      & From=20because some mail transport agents will insert a greater-
      & than (>) sign, thus invalidating the signature.
      &
      & Also, in some cases it might be desirable to encode any   =20
      & trailing whitespace that occurs on lines in order to ensure  =20
      & that the message signature is not invalidated when passing =20
      & a gateway that modifies such whitespace (like BITNET). =20
      &
      & me

      --bar

      Content-Type: application/pgp-signature

      -----BEGIN PGP MESSAGE-----
      Version: 2.6.2

      iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
      jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
      uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
      HOxEa44b+EI=
      =ndaj
      -----END PGP MESSAGE-----

      --bar--

   The "&"s in the previous example indicate the portion of the data
   over which the signature was calculated. 


**************************

For me it is not clear, which CRLF should be included in the signature.

Because I have the problem to code in a non ascii and line oriented 
environment (IBM z/OS) I have chosen to
first translate the text to ascii (in case of binary data  I can skip this 
step) and then to base64. In this matter I  can be
sure that trailing white spaces and control characters within the text are 
not disturbing in the recipient's verify phase.

I assume that I have to sign over the following parts:

Headers (in ascii) and CRLF (one or 2 after the last header ?)

Content-Type: application/octet-stream (CRLF)
Content-Transfer-Encoding: base64    (CRLF ) 2x   ?

base64 stream (without CRLF between nor ending with one ) ?


It's a try to use PGM MIME in the environment I'm working......the 
encryption part is easier

 

Kind regards

Peter 

--=_alternative 002A85B5C12570A5_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">I have question regarding the PGP digital
signature (RFC3156).</font>
<br>
<br><font size=2 face="sans-serif">On page 5 you have the well known sample:</font>
<br>
<br><font size=3><tt>&nbsp;MIME Security with OpenPGP &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;August 2001<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; Content-Type: multipart/signed; boundary=bar;
micalg=pgp-md5;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; protocol=&quot;application/pgp-signature&quot;<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; --bar<br>
 &nbsp; &nbsp; &nbsp;&amp; Content-Type: text/plain; charset=iso-8859-1<br>
 &nbsp; &nbsp; &nbsp;&amp; Content-Transfer-Encoding: quoted-printable<br>
 &nbsp; &nbsp; &nbsp;&amp;<br>
 &nbsp; &nbsp; &nbsp;&amp; =A1Hola!<br>
 &nbsp; &nbsp; &nbsp;&amp;<br>
 &nbsp; &nbsp; &nbsp;&amp; Did you know that talking to yourself is a sign
of senility?<br>
 &nbsp; &nbsp; &nbsp;&amp;<br>
 &nbsp; &nbsp; &nbsp;&amp; It's generally a good idea to encode lines that
begin with<br>
 &nbsp; &nbsp; &nbsp;&amp; From=20because some mail transport agents will
insert a greater-<br>
 &nbsp; &nbsp; &nbsp;&amp; than (&gt;) sign, thus invalidating the signature.<br>
 &nbsp; &nbsp; &nbsp;&amp;<br>
 &nbsp; &nbsp; &nbsp;&amp; Also, in some cases it might be desirable to
encode any &nbsp; =20<br>
 &nbsp; &nbsp; &nbsp;&amp; trailing whitespace that occurs on lines in
order to ensure &nbsp;=20<br>
 &nbsp; &nbsp; &nbsp;&amp; that the message signature is not invalidated
when passing =20<br>
 &nbsp; &nbsp; &nbsp;&amp; a gateway that modifies such whitespace (like
BITNET). =20<br>
 &nbsp; &nbsp; &nbsp;&amp;<br>
 &nbsp; &nbsp; &nbsp;&amp; me<br>
<br>
 &nbsp; &nbsp; &nbsp;--bar<br>
<br>
 &nbsp; &nbsp; &nbsp;Content-Type: application/pgp-signature<br>
<br>
 &nbsp; &nbsp; &nbsp;-----BEGIN PGP MESSAGE-----<br>
 &nbsp; &nbsp; &nbsp;Version: 2.6.2<br>
<br>
 &nbsp; &nbsp; &nbsp;iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//<br>
 &nbsp; &nbsp; &nbsp;jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq<br>
 &nbsp; &nbsp; &nbsp;uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn<br>
 &nbsp; &nbsp; &nbsp;HOxEa44b+EI=<br>
 &nbsp; &nbsp; &nbsp;=ndaj<br>
 &nbsp; &nbsp; &nbsp;-----END PGP MESSAGE-----<br>
<br>
 &nbsp; &nbsp; &nbsp;--bar--<br>
<br>
 &nbsp; The &quot;&amp;&quot;s in the previous example indicate the portion
of the data<br>
 &nbsp; over which the signature was calculated.</tt></font><font size=2 face="sans-serif">
</font>
<br>
<br>
<br><font size=2 face="sans-serif">**************************</font>
<br>
<br><font size=2 face="sans-serif">For me it is not clear, which CRLF should
be included in the signature.</font>
<br>
<br><font size=2 face="sans-serif">Because I have the problem to code in
a non ascii and line oriented environment (IBM z/OS) I have chosen to</font>
<br><font size=2 face="sans-serif">first translate the text to ascii (in
case of binary data &nbsp;I can skip this step) and then to base64. In
this matter I &nbsp;can be</font>
<br><font size=2 face="sans-serif">sure that trailing white spaces and
control characters within the text are not disturbing in the recipient's
verify phase.</font>
<br>
<br><font size=2 face="sans-serif">I assume that I have to sign over the
following parts:</font>
<br>
<br><font size=2 face="sans-serif">Headers (in ascii) and CRLF (one or
2 after the last header ?)</font>
<br>
<br><font size=3><tt><i>Content-Type: application/octet-stream</i></tt></font><font size=2 face="sans-serif"><i>
(CRLF)</i></font>
<br><font size=2 face="sans-serif"><i>Content-Transfer-Encoding: base64
&nbsp; &nbsp;(CRLF ) 2x &nbsp; ?</i></font>
<br>
<br><font size=2 face="sans-serif">base64 stream (without CRLF between
nor ending with one ) ?</font>
<br>
<br>
<br><font size=2 face="sans-serif">It's a try to use PGM MIME in the environment
I'm working......the encryption part is easier</font>
<br>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Kind regards</font>
<br><font size=2 face="sans-serif"><br>
Peter <br>
</font>
--=_alternative 002A85B5C12570A5_=--



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 j9F5Lrv2040159; Fri, 14 Oct 2005 22:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9F5LrpV040158; Fri, 14 Oct 2005 22:21:53 -0700 (PDT)
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 j9F5Lqvc040111 for <[e-mail]>; Fri, 14 Oct 2005 22:21:52 -0700 (PDT) (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.6); Fri, 14 Oct 2005 22:21:49 -0700
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Oct 2005 22:21:49 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Oct 2005 22:21:49 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
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: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT // empty line
Date: Fri, 14 Oct 2005 22:21:45 -0700
To: "<[e-mail]>" <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 Oct 2005, at 6:17 AM, <[e-mail]> <[e-mail]> wrote:

> it's not the pgp implementations,
>
> but it does happen 'always'
> when generating a pdf that has a pgp message as an illustration
>
> the pdf treats the empty line as 'whitespace'
> rather than a 'line return'
>
> and the pgp program trying to decrypt/verify the pdf example
> is dealing with a functional omission of the empty line
>
> this is true both in Adobe Writer (all versions through 6, anyway)
> and PDFCreator
>
> not a reason to change the standard,
> just something to be aware of
>
> a simple workaround when creating pdf's, is to manually add a colon
> on the 'empty line' of the pgp message
>
> this will render in pdf, and will be recognizable by all the pgp
> implementations

Okay, so you have described a great reason why an implementation  
might want to accept such a data block despite it not being up to  
spec. It's a great reason.

But that's not a reason to change the spec.

     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 j9EDHa0Q078844; Fri, 14 Oct 2005 06:17:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EDHaHN078843; Fri, 14 Oct 2005 06:17:36 -0700 (PDT)
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 j9EDHXcb078831 for <[e-mail]>; Fri, 14 Oct 2005 06:17:35 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 24249A3569 for <[e-mail]>; Fri, 14 Oct 2005 06:17:33 -0700 (PDT)
Received: from mailserver5.hushmail.com (mailserver5.hushmail.com [65.39.178.19]) by smtp3.hushmail.com (Postfix) with ESMTP for <[e-mail]>; Fri, 14 Oct 2005 06:17:30 -0700 (PDT)
Received: by mailserver5.hushmail.com (Postfix, from userid 65534) id 2C6C733C58; Fri, 14 Oct 2005 06:17:30 -0700 (PDT)
Date: Fri, 14 Oct 2005 06:17:26 -0700
To: <[e-mail]>
Cc: 
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT // empty line
From: <[e-mail]>
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 Wed, 12 Oct 2005 10:42:05 -0700 Jon Callas <[e-mail]> 
wrote:
>On 12 Oct 2005, at 2:42 AM, Ben Laurie wrote:
>
>>
>> I've only seen this in email, so I'm not actually sure whether 
>its  
>> the PGP implementation or the MUA. I could gather version 
>strings  
>> (for some instances) if that helps?
>>
>
>I'm happy to work merely with the anecdotal evidence that it 
>happens  
>a lot.

it's not the pgp implementations,

but it does happen 'always'
when generating a pdf that has a pgp message as an illustration

the pdf treats the empty line as 'whitespace'
rather than a 'line return'

and the pgp program trying to decrypt/verify the pdf example
is dealing with a functional omission of the empty line

this is true both in Adobe Writer (all versions through 6, anyway)
and PDFCreator

not a reason to change the standard,
just something to be aware of

a simple workaround when creating pdf's, is to manually add a colon 
on the 'empty line' of the pgp message

this will render in pdf, and will be recognizable by all the pgp 
implementations


vedaal



Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427



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 j9ED8ZNi076522; Fri, 14 Oct 2005 06:08:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9ED8Zpa076521; Fri, 14 Oct 2005 06:08:35 -0700 (PDT)
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 j9ED8ZuS076511 for <[e-mail]>; Fri, 14 Oct 2005 06:08:35 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 7DBB9A3567 for <[e-mail]>; Fri, 14 Oct 2005 06:08:34 -0700 (PDT)
Received: from mailserver5.hushmail.com (mailserver5.hushmail.com [65.39.178.19]) by smtp3.hushmail.com (Postfix) with ESMTP for <[e-mail]>; Fri, 14 Oct 2005 06:08:31 -0700 (PDT)
Received: by mailserver5.hushmail.com (Postfix, from userid 65534) id F02D933C24; Fri, 14 Oct 2005 06:08:30 -0700 (PDT)
Date: Fri, 14 Oct 2005 06:08:28 -0700
To: <[e-mail]>
Cc: 
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: <[e-mail]>
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 Wed, 12 Oct 2005 06:06:40 -0700 "Daniel A. Nagy" 
<[e-mail]> wrote:

>I am not aware of any actual implementation of 
>multiple
>cleartext signatures.

gnupg has had them implemented for some time now,

they can be very useful in introducing a new signing key or signing 
subkey

the message introduces the new signing key, and includes all its 
identifying data,

and then is signed with both the old (already trusted) signing key,
as well as the new signing key


vedaal



Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427



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 j9DHxTrC068770; Thu, 13 Oct 2005 10:59:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9DHxTBI068769; Thu, 13 Oct 2005 10:59:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cliodev.pgp.com (nsc69.38.10-97.newsouth.net [69.38.10.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DHxR3l068693 for <[e-mail]>; Thu, 13 Oct 2005 10:59:27 -0700 (PDT) (envelope-from [e-mail])
Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j9DHw2m6012589; Thu, 13 Oct 2005 13:58:02 -0400
Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j9DHw0m2012586; Thu, 13 Oct 2005 13:58:00 -0400
X-Authentication-Warning: cliodev.pgp.com: warlord set sender to [e-mail] using -f
From: Derek Atkins <[e-mail]>
To: Ben Laurie <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 13 Oct 2005 13:58:00 -0400
In-Reply-To: <[e-mail]> (Ben Laurie's message of "Thu, 13 Oct 2005 09:39:19 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (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>

Ben Laurie <[e-mail]> writes:

> Now that the spec is clear to me, I'd say we should leave it as it is.

The question remains, why was it unclear before?  The text in the spec
should be unambigious.  If you were confused about what it meant, an
extra explanatory sentence is in order to make sure a future developer
does not fall into the same ambiguous interpretation that you did.

-derek
-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant



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 j9D8dKem031190; Thu, 13 Oct 2005 01:39:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9D8dKvl031189; Thu, 13 Oct 2005 01:39:20 -0700 (PDT)
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 j9D8dJUh031181 for <[e-mail]>; Thu, 13 Oct 2005 01:39:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DA0A433C1D; Thu, 13 Oct 2005 09:39:17 +0100 (BST)
Message-ID: <[e-mail]>
Date: Thu, 13 Oct 2005 09:39:19 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> On 12 Oct 2005, at 2:42 AM, Ben Laurie wrote:
> 
>>
>> I've only seen this in email, so I'm not actually sure whether its  
>> the PGP implementation or the MUA. I could gather version strings  
>> (for some instances) if that helps?
>>
> 
> I'm happy to work merely with the anecdotal evidence that it happens  a 
> lot.
> 
> The only question is whether we should do anything, and if so, what?  
> Since the spec really says that the blank line should be there, the  
> what would be to relax or eliminate the requirement. I could find the  
> right place to add "typically" for example, to indicate that it's  
> common convention, but not required.
> 
> But that would make any implementation that adheres strictly to the  
> present spec to be broken.

Now that the spec is clear to me, I'd say we should leave it as it is.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9CKLHbt066999; Wed, 12 Oct 2005 13:21:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CKLHFe066998; Wed, 12 Oct 2005 13:21:17 -0700 (PDT)
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 j9CKLGm2066984 for <[e-mail]>; Wed, 12 Oct 2005 13:21:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 00A1133C1D; Wed, 12 Oct 2005 21:21:15 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 21:21:16 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> On 12 Oct 2005, at 2:42 AM, Ben Laurie wrote:
> 
>>
>> I've only seen this in email, so I'm not actually sure whether its  
>> the PGP implementation or the MUA. I could gather version strings  
>> (for some instances) if that helps?
>>
> 
> I'm happy to work merely with the anecdotal evidence that it happens  a 
> lot.
> 
> The only question is whether we should do anything, and if so, what?  
> Since the spec really says that the blank line should be there, the  
> what would be to relax or eliminate the requirement. I could find the  
> right place to add "typically" for example, to indicate that it's  
> common convention, but not required.
> 
> But that would make any implementation that adheres strictly to the  
> present spec to be broken.

Encouraging random processing of text strikes me as a bad idea, so let's 
not change the words.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9CHvEAp051791; Wed, 12 Oct 2005 10:57:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CHvEkn051790; Wed, 12 Oct 2005 10:57:14 -0700 (PDT)
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 j9CHvEp3051783 for <[e-mail]>; Wed, 12 Oct 2005 10:57:14 -0700 (PDT) (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.6); Wed, 12 Oct 2005 10:57:12 -0700
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Wed, 12 Oct 2005 10:57:12 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 12 Oct 2005 10:57:12 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
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: Human-readable notation language
Date: Wed, 12 Oct 2005 10:57:12 -0700
To: David Shaw <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 12 Oct 2005, at 9:04 AM, David Shaw wrote:

>
> Section 5.2.3.16 (Notation Data) has this:
>
>      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 my reading, this says more or less, "this is a note from one person
> to another except when it isn't".  Especially given such notations as
> [e-mail] which are always human-readable, I
> suggest this:
>
>      First octet: 0x80 = human-readable. This note value is text.
>
> It's just simpler.


Yes, but. The reason we have that text in there is because of debates  
over what to do about it. The present text says that software doesn't  
have to anything. Yes, I know that other parts of the document also  
say that *any* subpacket that you don't understand can be ignored  
(modulo critical), but that doesn't mean that the issue won't come  
back again.

That text also more or less says, "You can ignore these any time you  
want to. Really. Yes, really. Uh huh. Trust me, really." It says this  
because that has been needed.

I'm happy to remove it, but I get an "I told you so" when someone  
asks about it later.

     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 j9CHoOQp051141; Wed, 12 Oct 2005 10:50:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CHoO6q051140; Wed, 12 Oct 2005 10:50:24 -0700 (PDT)
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 j9CHoNtc051134 for <[e-mail]>; Wed, 12 Oct 2005 10:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 3580957EF9; Wed, 12 Oct 2005 10:51:32 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: Re: Human-readable notation language
Message-Id: <[e-mail]>
Date: Wed, 12 Oct 2005 10:51:32 -0700 (PDT)
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>

David Shaw writes:
> Section 5.2.3.16 (Notation Data) has this:
>
>      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 my reading, this says more or less, "this is a note from one person
> to another except when it isn't".  Especially given such notations as
> [e-mail] which are always human-readable, I
> suggest this:
>
>      First octet: 0x80 = human-readable. This note value is text.
>
> It's just simpler.

I agree with David on this.  My interpretation of the human-readable
flag is not that it is a note from one person to another, but rather,
it is something that humans would be able to read.  It may well be
used purely for software purposes.

The practical implication is, when printing out signature fields in a
program like pgpdump, it is a reasonable idea to print out this notation
in text form.  If teh human-readable flag is not set, the notation should
be printed in binary form.

The semantics of the notation are entirely in its name field and not
related in any way to the human-readable flag, IMO.

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 j9CHg6fv050327; Wed, 12 Oct 2005 10:42:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CHg6ww050326; Wed, 12 Oct 2005 10:42:06 -0700 (PDT)
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 j9CHg6tG050317 for <[e-mail]>; Wed, 12 Oct 2005 10:42:06 -0700 (PDT) (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.6); Wed, 12 Oct 2005 10:42:04 -0700
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Wed, 12 Oct 2005 10:42:04 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 12 Oct 2005 10:42:04 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: OpenPGP <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Date: Wed, 12 Oct 2005 10:42:05 -0700
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 12 Oct 2005, at 2:42 AM, Ben Laurie wrote:

>
> I've only seen this in email, so I'm not actually sure whether its  
> the PGP implementation or the MUA. I could gather version strings  
> (for some instances) if that helps?
>

I'm happy to work merely with the anecdotal evidence that it happens  
a lot.

The only question is whether we should do anything, and if so, what?  
Since the spec really says that the blank line should be there, the  
what would be to relax or eliminate the requirement. I could find the  
right place to add "typically" for example, to indicate that it's  
common convention, but not required.

But that would make any implementation that adheres strictly to the  
present spec to be broken.

     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 j9CG4hvw041538; Wed, 12 Oct 2005 09:04:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CG4h2U041537; Wed, 12 Oct 2005 09:04:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CG4gSq041435 for <[e-mail]>; Wed, 12 Oct 2005 09:04:42 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005101216043601500bccq0e>; Wed, 12 Oct 2005 16:04:36 +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 j9CG4a0m008412 for <[e-mail]>; Wed, 12 Oct 2005 12:04:36 -0400
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 j9CG4Y15003582 for <[e-mail]>; Wed, 12 Oct 2005 12:04:34 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9CG4YLP003581 for [e-mail]; Wed, 12 Oct 2005 12:04:34 -0400
Date: Wed, 12 Oct 2005 12:04:34 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Human-readable notation language
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.8i
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>

Section 5.2.3.16 (Notation Data) has this:

     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 my reading, this says more or less, "this is a note from one person
to another except when it isn't".  Especially given such notations as
[e-mail] which are always human-readable, I
suggest this:

     First octet: 0x80 = human-readable. This note value is text.

It's just simpler.

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 j9CFlFL7039636; Wed, 12 Oct 2005 08:47:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFlFFA039635; Wed, 12 Oct 2005 08:47:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cliodev.pgp.com (nsc69.38.10-97.newsouth.net [69.38.10.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CFlFkG039627 for <[e-mail]>; Wed, 12 Oct 2005 08:47:15 -0700 (PDT) (envelope-from [e-mail])
Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j9CFl9YJ000922 for <[e-mail]>; Wed, 12 Oct 2005 11:47:09 -0400
Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j9CFl9tQ000919; Wed, 12 Oct 2005 11:47:09 -0400
X-Authentication-Warning: cliodev.pgp.com: warlord set sender to [e-mail] using -f
From: Derek Atkins <[e-mail]>
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Oct 2005 11:47:09 -0400
In-Reply-To: <[e-mail]> (David Shaw's message of "Wed, 12 Oct 2005 11:13:08 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (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>

David Shaw <[e-mail]> writes:

> I definitely agree they are useful, but given that 2440bis last call
> ends in 16 days and we have no implementations (much less two
> interoperable ones), let's move this to a new RFC.

We don't need this now.  That's needed to go to DRAFT standard.
2440bis is going to PROPOSED (because there's been significant
churn).

To go from PROPOSED to DRAFT we need the implementation experience,
and the draft can only clarify or remove, not add or change.  I.e.,
you cannot change a packet format, but you can clarify ambiguities or
remove packets that haven't been implemented.  But this wont happen
until next year.

> David

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant



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 j9CFiDKF039335; Wed, 12 Oct 2005 08:44:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFiD3F039334; Wed, 12 Oct 2005 08:44:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cliodev.pgp.com (nsc69.38.10-97.newsouth.net [69.38.10.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CFiBH3039318 for <[e-mail]>; Wed, 12 Oct 2005 08:44:11 -0700 (PDT) (envelope-from [e-mail])
Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j9CFi577000915 for <[e-mail]>; Wed, 12 Oct 2005 11:44:05 -0400
Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j9CFi2cm000912; Wed, 12 Oct 2005 11:44:02 -0400
X-Authentication-Warning: cliodev.pgp.com: warlord set sender to [e-mail] using -f
From: Derek Atkins <[e-mail]>
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
References: <[e-mail]> <[e-mail]>
Date: Wed, 12 Oct 2005 11:44:02 -0400
In-Reply-To: <[e-mail]> (David Shaw's message of "Wed, 12 Oct 2005 11:10:16 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (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>

<chair hat on>

As a process point..  2440bis is going into PROPOSED standard, which
means we don't need the deployment experience right now.  There's
no need to rip out this section now -- we can always remove it
before going to DRAFT standard if we don't get the experience
by then.

So, if there is concensus to remove it now we can..  But from
a process standpoint there's no need to remove it if we think
the language is clear about how to create and parse and understand
the packet type.

</chair hat off>

-derek

David Shaw <[e-mail]> writes:

> On Wed, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:
>
>> I am a bit uncomfortable with the notarization signature in general.
>> We have it in the draft but have no experience with it in reality,
>> which is kind of the opposite of the usual IETF procedure.  I guess it
>> was somebody's bright idea that got stuck in, in case people might want
>> to use it someday.
>> 
>> The fact that we may have to add further rules clarifying how to use it
>> just emphasizes our lack of experience with the construct.  Often with
>> these things you don't find the problems until you actually try to use it
>> for something and interoperate with others.  Given that notary signatures
>> have been in the draft in some form or other for years without seeing
>> any use that I know of, should we consider taking them out?
>
> While I hate to say it, given the number of hours that went into it
> thus far, I think I agree.  Last call is approaching, and we have no
> implementations of it and no experience with it.
>
> This isn't to say that I think we should scrap notary signatures -
> just that it might be a good idea to bump them into their own RFC so
> as not to delay 2440bis.  I don't believe that implementation and
> experience can be achieved in time, and I'd rather see them done right
> than done in 2440bis.
>
> David

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant



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 j9CFZikh038740; Wed, 12 Oct 2005 08:35:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFZioK038739; Wed, 12 Oct 2005 08:35:44 -0700 (PDT)
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 j9CFZh8K038733 for <[e-mail]>; Wed, 12 Oct 2005 08:35:44 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 915CF2B47E9; Wed, 12 Oct 2005 17:35:39 +0200 (CEST)
Date: Wed, 12 Oct 2005 17:35:39 +0200
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
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, Oct 12, 2005 at 11:10:16AM -0400, David Shaw wrote:

> While I hate to say it, given the number of hours that went into it
> thus far, I think I agree.  Last call is approaching, and we have no
> implementations of it and no experience with it.
> 
> This isn't to say that I think we should scrap notary signatures -
> just that it might be a good idea to bump them into their own RFC so
> as not to delay 2440bis.  I don't believe that implementation and
> experience can be achieved in time, and I'd rather see them done right
> than done in 2440bis.

What is already there is vague and general enough not to interfere with
future implementations and at least gives some guidelines to implementers,
who may come up with interoperable solutions on their own. Please do not
remove the notary signature types from this RFC.

The actual, detailed specification with examples backed up by an open-source
implementation will go into a new RFC; I have no problem with that.

-- 
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 j9CFVVbD038327; Wed, 12 Oct 2005 08:31:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFVVFm038326; Wed, 12 Oct 2005 08:31:31 -0700 (PDT)
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 j9CFVUJi038319 for <[e-mail]>; Wed, 12 Oct 2005 08:31:31 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0D9302B47DD; Wed, 12 Oct 2005 17:31:30 +0200 (CEST)
Date: Wed, 12 Oct 2005 17:31:30 +0200
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Message-ID: <[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]>
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, Oct 12, 2005 at 11:13:08AM -0400, David Shaw wrote:

> I definitely agree they are useful, but given that 2440bis last call
> ends in 16 days and we have no implementations (much less two
> interoperable ones), let's move this to a new RFC.

Sure, the true specs will be in the new RFC, but please don't remove from
RFC2440bis what is already there.

-- 
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 j9CFDLqD035914; Wed, 12 Oct 2005 08:13:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFDLQh035913; Wed, 12 Oct 2005 08:13:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CFDLxA035900 for <[e-mail]>; Wed, 12 Oct 2005 08:13:21 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <200510121513100140090fore>; Wed, 12 Oct 2005 15:13:15 +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 j9CFD90m008238 for <[e-mail]>; Wed, 12 Oct 2005 11:13:09 -0400
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 j9CFD8nk003502 for <[e-mail]>; Wed, 12 Oct 2005 11:13:08 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9CFD83i003501 for [e-mail]; Wed, 12 Oct 2005 11:13:08 -0400
Date: Wed, 12 Oct 2005 11:13:08 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
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, Oct 12, 2005 at 09:50:32AM -0500, Brian G. Peterson wrote:
> 
> On Wed, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:
> > > The fact that we may have to add further rules clarifying how to use it
> > > just emphasizes our lack of experience with the construct.  Often with
> > > these things you don't find the problems until you actually try to use it
> > > for something and interoperate with others.  Given that notary signatures
> > > have been in the draft in some form or other for years without seeing
> > > any use that I know of, should we consider taking them out?
> 
> On Wednesday 12 October 2005 08:06 am, Daniel A. Nagy wrote:
> > Please don't. I do have a very good use for them and I'm going to go ahead
> > with an implementation. As soon as it's working reliably and securely, I
> > will write up the specifications for inclusion in the standard.
> 
> I second this.  A workable notary signature method for both clear-signed and 
> pgp/mime is badly needed for evidentiary reasons.  

I definitely agree they are useful, but given that 2440bis last call
ends in 16 days and we have no implementations (much less two
interoperable ones), let's move this to a new RFC.

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 j9CFAQwN035632; Wed, 12 Oct 2005 08:10:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CFAQox035631; Wed, 12 Oct 2005 08:10:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CFAPMq035621 for <[e-mail]>; Wed, 12 Oct 2005 08:10:25 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <2005101215101801200p5at1e>; Wed, 12 Oct 2005 15:10:18 +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 j9CFAI0m008224 for <[e-mail]>; Wed, 12 Oct 2005 11:10:18 -0400
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 j9CFAGqv003495 for <[e-mail]>; Wed, 12 Oct 2005 11:10:16 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9CFAGd5003494 for [e-mail]; Wed, 12 Oct 2005 11:10:16 -0400
Date: Wed, 12 Oct 2005 11:10:16 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Message-ID: <[e-mail]>
Mail-Followup-To: [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.8i
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, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:

> I am a bit uncomfortable with the notarization signature in general.
> We have it in the draft but have no experience with it in reality,
> which is kind of the opposite of the usual IETF procedure.  I guess it
> was somebody's bright idea that got stuck in, in case people might want
> to use it someday.
> 
> The fact that we may have to add further rules clarifying how to use it
> just emphasizes our lack of experience with the construct.  Often with
> these things you don't find the problems until you actually try to use it
> for something and interoperate with others.  Given that notary signatures
> have been in the draft in some form or other for years without seeing
> any use that I know of, should we consider taking them out?

While I hate to say it, given the number of hours that went into it
thus far, I think I agree.  Last call is approaching, and we have no
implementations of it and no experience with it.

This isn't to say that I think we should scrap notary signatures -
just that it might be a good idea to bump them into their own RFC so
as not to delay 2440bis.  I don't believe that implementation and
experience can be achieved in time, and I'd rather see them done right
than done in 2440bis.

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 j9CEor3n033756; Wed, 12 Oct 2005 07:50:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CEor8Q033755; Wed, 12 Oct 2005 07:50:53 -0700 (PDT)
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 j9CEoqOn033749 for <[e-mail]>; Wed, 12 Oct 2005 07:50:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.23.3.126] (terminus [66.92.135.15]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id j9CEog4V021445 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Oct 2005 09:50:43 -0500
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Date: Wed, 12 Oct 2005 09:50:32 -0500
User-Agent: KMail/1.8.1
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9CEorOn033750
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, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:
> > The fact that we may have to add further rules clarifying how to use it
> > just emphasizes our lack of experience with the construct.  Often with
> > these things you don't find the problems until you actually try to use it
> > for something and interoperate with others.  Given that notary signatures
> > have been in the draft in some form or other for years without seeing
> > any use that I know of, should we consider taking them out?

On Wednesday 12 October 2005 08:06 am, Daniel A. Nagy wrote:
> Please don't. I do have a very good use for them and I'm going to go ahead
> with an implementation. As soon as it's working reliably and securely, I
> will write up the specifications for inclusion in the standard.

I second this.  A workable notary signature method for both clear-signed and 
pgp/mime is badly needed for evidentiary reasons.  

The hypothetical human rights example discussed a few weeks ago applies 
clearly here, where a file/message may pass through multiple hands before 
arriving at it's final destination, and the original signer may be dead by 
the time it gets to the final destination.  Having a notary chain of 
signatures over the same original can provide valuable chain of evidence 
information.

Regards,

  - Brian Peterson



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 j9CE1mqk027430; Wed, 12 Oct 2005 07:01:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CE1mdk027429; Wed, 12 Oct 2005 07:01:48 -0700 (PDT)
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 j9CE1l4n027421 for <[e-mail]>; Wed, 12 Oct 2005 07:01:48 -0700 (PDT) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EPhHF-0008MP-MF for <[e-mail]>; Wed, 12 Oct 2005 16:08:17 +0200
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EPh4X-0001QK-Hn for <[e-mail]>; Wed, 12 Oct 2005 15:55:09 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Signature calculation language
References: <[e-mail]> <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Wed, 12 Oct 2005 15:55:09 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Tue, 11 Oct 2005 22:50:34 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (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 Tue, 11 Oct 2005 22:50:34 -0400, David Shaw said:

> I support making 0x19 backsigs a MUST.

I concur with David.  I am actually a heavy user of signing subkeys
because they allow to keep the primary key offline.


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 j9CD6it1020831; Wed, 12 Oct 2005 06:06:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CD6i1V020830; Wed, 12 Oct 2005 06:06:44 -0700 (PDT)
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 j9CD6g9Q020793 for <[e-mail]>; Wed, 12 Oct 2005 06:06:43 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 820152B47EE; Wed, 12 Oct 2005 15:06:40 +0200 (CEST)
Date: Wed, 12 Oct 2005 15:06:40 +0200
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
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, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:
> 
> Daniel Nagy writes about multiple cleartext signatures:
> > Some details are missing. For instance, is the order salient? One-pass
> > signantures have to be bracketed, and clearsigned documents are supposed be
> > verifiable in one pass as well. But it does not necessarily imply that the
> > hash algorithms should be listed in reverse signature order in the
> > beginning. Actually, the standard says very little on how to go about it.
> 
> I don't think there is much benefit to putting the hashes in the (reverse)
> order of the signatures.  Rather, you list all of the hashes that will
> be used by any of the signatures, then simultaneously accumulate all
> hash values as you scan the message in one pass.  Now you can verify
> each signature and you would have the hash value at hand.

Actually, the hash value is not enough; you need to carry the whole message
digest object with its internal state. In a system/library where it is not
cloneable, this might be a problem. But I agree that it's no big deal. What
you write above is perfectly consistent with the standard and my planned
implementation. I am not aware of any actual implementation of multiple
cleartext signatures.
 
> I am a bit uncomfortable with the notarization signature in general.
> We have it in the draft but have no experience with it in reality,
> which is kind of the opposite of the usual IETF procedure.  I guess it
> was somebody's bright idea that got stuck in, in case people might want
> to use it someday.
>
> The fact that we may have to add further rules clarifying how to use it
> just emphasizes our lack of experience with the construct.  Often with
> these things you don't find the problems until you actually try to use it
> for something and interoperate with others.  Given that notary signatures
> have been in the draft in some form or other for years without seeing
> any use that I know of, should we consider taking them out?

Please don't. I do have a very good use for them and I'm going to go ahead
with an implementation. As soon as it's working reliably and securely, I
will write up the specifications for inclusion in the standard.

-- 
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 j9CB2giu007868; Wed, 12 Oct 2005 04:02:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9CB2g7K007867; Wed, 12 Oct 2005 04:02:42 -0700 (PDT)
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 j9CB2fc0007829 for <[e-mail]>; Wed, 12 Oct 2005 04:02:41 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 88BC162C7C; Wed, 12 Oct 2005 12:02:34 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 12:03:11 +0100
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: Hal Finney <[e-mail]>
Cc: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
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>

Hal Finney wrote:

> I am a bit uncomfortable with the notarization signature in general.
> We have it in the draft but have no experience with it in reality,
> which is kind of the opposite of the usual IETF procedure.  I guess it
> was somebody's bright idea that got stuck in, in case people might want
> to use it someday.
> 
> The fact that we may have to add further rules clarifying how to use it
> just emphasizes our lack of experience with the construct.  Often with
> these things you don't find the problems until you actually try to use it
> for something and interoperate with others.  Given that notary signatures
> have been in the draft in some form or other for years without seeing
> any use that I know of, should we consider taking them out?

I think as long as the semantics - the legal
or otherwise meaning - of the digsig are left
explicitly vague and up to the signing and
relying parties, then the existance of a notary
signature form just represents a spot where
two cooperating parties could agree to do a
notary-like signature.  It's up to them all to
sort out the details...

Looking at the section 5.2.1. Signature Types
There is this odd para half way through the
list:

         Please note that the vagueness of these certification claims is
         not a flaw, but a feature of the system. Because OpenPGP places
         final authority for validity upon the receiver of a
         certification, it may be that one authority's casual
         certification might be more rigorous than some other authority's
         positive certification. These classifications allow a
         certification authority to issue fine-grained claims.

I suggest that this is out of place and may be
better served being moved to the front or back
of the section, so that it serves as a general
caveat of vagueness and user-authority on the
issue of signature semantics.

I would prefer the disclaimer to vaguery to be
at the beginning because that's how lawyers like
it.  So, Something like this:

   5.2.1. Signature Types

     There are a number of possible meanings for a signature, which
     may be indicated in a signature type octet in any given signature.
     Please note that the vagueness of these meanings is
     not a flaw, but a feature of the system. Because OpenPGP places
     final authority for validity upon the receiver of a
     signature, it may be that one signer's casual
     act might be more rigorous than some other authority's
     positive act.

     These meanings are:

     0x01:...

iang



PS: The concept of technology doing signatures is
quite scary, and notary signatures are a step
further into that area;  this group has no real
tools to deal with it as we have no lawyers
here, and even if we did, we'd need to cover
different codes (common, civil, islamic...)
and different digsig laws.  Before this ever
gets to be a tech question, it's a major academic
challenge.  The people who looked at basic digsigs
in the mid 90s bungled it comprehensively, so it's
not as if we can even say "well, just pay someone..."

It's the sort of thing that might fit much more
nicely in another document.  "Notary Signatures
Extension to OpenPGP."  But as you say, I'd prefer
to see someone *do it* in code and in practice to
flush out the lessons.



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 j9C9gEoo099820; Wed, 12 Oct 2005 02:42:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C9gEaJ099819; Wed, 12 Oct 2005 02:42:14 -0700 (PDT)
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 j9C9gDLb099813 for <[e-mail]>; Wed, 12 Oct 2005 02:42:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6634633C1A; Wed, 12 Oct 2005 10:42:13 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 10:42:14 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> 
> 
> On 11 Oct 2005, at 2:39 PM, Ian G wrote:
> 
>> Jon Callas wrote:
>>
>>
>>> The possible outside exception is the "Cleartext Signatures"  
>>> thread,  where I believe there's no consensus for a change, but I  
>>> don't see  anything that can't be added in WGLC if that's not the  case.
>>>
>>
>> Ben raised an issue about the blank line separating
>> the headers from the armour.  Is that mandatory or
>> not?  I think it should be.
>>
> 
> My opinion is that the spec clearly says that the blank line is  
> required. If in the real world, there are implementations that don't  
> put it in, and yet are generally accepted, then well, okay, but  that's 
> a standards violation.
> 
> I suppose that's reason enough to discuss taking it out, that it's  more 
> nodded to than observed, but I haven't noticed it being ignored.  I was 
> surprised that anyone didn't do it.

I've only seen this in email, so I'm not actually sure whether its the 
PGP implementation or the MUA. I could gather version strings (for some 
instances) if that helps?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9C9WKYf098906; Wed, 12 Oct 2005 02:32:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C9WK9i098905; Wed, 12 Oct 2005 02:32:20 -0700 (PDT)
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 j9C9WJ0j098899 for <[e-mail]>; Wed, 12 Oct 2005 02:32:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C13A533C1B; Wed, 12 Oct 2005 10:32:18 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 10:32:19 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

David Shaw wrote:
> On Mon, Oct 10, 2005 at 06:58:03PM +0100, Ben Laurie wrote:
> 
>>Daniel A. Nagy wrote:
>>
>>>On Mon, Oct 10, 2005 at 03:30:29PM +0100, Ben Laurie wrote:
>>>
>>>
>>>
>>>>That mantra has shown to be a less than great idea recently, since it 
>>>>promotes interestingly obscure security holes, so I still would like to 
>>>>know what the correct behaviour is, and I'd like the I-D to accurately 
>>>>document that behaviour.
>>>
>>>
>>>In that case, the empty line should be mandated,
>>
>>I agree.
> 
> 
> As do I, but it seems to me that it is already mandated.  Section 6.2
> (Forming ASCII Armor) mandates the line.  Section 7 (Cleartext
> signature framework) refers to "The ASCII armored signature(s)".
> Doesn't it them follow that the armored signature (like all armor)
> mandates the line?  Am I reading into something that isn't there?

I guess careful reading supports this, but the fact that it explicitly 
mentions Header and Tail Lines but _not_ the headers is confusing.

Also, it seems quite a few implementations miss them out, so I'm not the 
only confused one.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9C9SZUQ098466; Wed, 12 Oct 2005 02:28:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C9SZL9098465; Wed, 12 Oct 2005 02:28:35 -0700 (PDT)
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 j9C9SYEY098455 for <[e-mail]>; Wed, 12 Oct 2005 02:28:34 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F3CBF33C1A; Wed, 12 Oct 2005 10:28:32 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 12 Oct 2005 10:28:33 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: Ian G <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> The spec as it stands is clear, and someone who puts this into mail  has 
> to deal with long body lines in a cleartext message, anyway.  They're 
> the mail expert, I'm not.

OK, so what about the original problem (lack of clarity about headers)?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9C766Lo084574; Wed, 12 Oct 2005 00:06:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C7666R084573; Wed, 12 Oct 2005 00:06:06 -0700 (PDT)
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 j9C7664M084567 for <[e-mail]>; Wed, 12 Oct 2005 00:06:06 -0700 (PDT) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 38B2957EFB; Wed, 12 Oct 2005 00:07:13 -0700 (PDT)
To: [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Message-Id: <[e-mail]>
Date: Wed, 12 Oct 2005 00:07:13 -0700 (PDT)
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 about multiple cleartext signatures:
> Some details are missing. For instance, is the order salient? One-pass
> signantures have to be bracketed, and clearsigned documents are supposed be
> verifiable in one pass as well. But it does not necessarily imply that the
> hash algorithms should be listed in reverse signature order in the
> beginning. Actually, the standard says very little on how to go about it.

I don't think there is much benefit to putting the hashes in the (reverse)
order of the signatures.  Rather, you list all of the hashes that will
be used by any of the signatures, then simultaneously accumulate all
hash values as you scan the message in one pass.  Now you can verify
each signature and you would have the hash value at hand.

> It
> would definitely help one-pass verification, if signatures that refer to
> other signatures (e.g. notarization sigs) were mandated to either follow or
> precede the signatures they are refering to. Both solutions have their
> benefits, but deciding one way or another would be better than allowing
> arbitrary order. It would be nice to have a paragraph or two elaborating on
> these issues.

I am a bit uncomfortable with the notarization signature in general.
We have it in the draft but have no experience with it in reality,
which is kind of the opposite of the usual IETF procedure.  I guess it
was somebody's bright idea that got stuck in, in case people might want
to use it someday.

The fact that we may have to add further rules clarifying how to use it
just emphasizes our lack of experience with the construct.  Often with
these things you don't find the problems until you actually try to use it
for something and interoperate with others.  Given that notary signatures
have been in the draft in some form or other for years without seeing
any use that I know of, should we consider taking them out?

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 j9C4MjjL073219; Tue, 11 Oct 2005 21:22:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C4Mjdk073218; Tue, 11 Oct 2005 21:22:45 -0700 (PDT)
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 j9C4MiGv073212 for <[e-mail]>; Tue, 11 Oct 2005 21:22:45 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 956822B47A3; Wed, 12 Oct 2005 06:22:43 +0200 (CEST)
Date: Wed, 12 Oct 2005 06:22:43 +0200
To: David Shaw <[e-mail]>, [e-mail]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
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 Tue, Oct 11, 2005 at 06:11:27PM -0400, David Shaw wrote:

> Yes, they are supported, and the putting all of them in a single
> armored signature block is the way to do it.  Section 7 refers to "The
> ASCII armored signature(s)" in the signature block.  The text seems
> reasonably clear to me - what is not good here?

Some details are missing. For instance, is the order salient? One-pass
signantures have to be bracketed, and clearsigned documents are supposed be
verifiable in one pass as well. But it does not necessarily imply that the
hash algorithms should be listed in reverse signature order in the
beginning. Actually, the standard says very little on how to go about it. It
would definitely help one-pass verification, if signatures that refer to
other signatures (e.g. notarization sigs) were mandated to either follow or
precede the signatures they are refering to. Both solutions have their
benefits, but deciding one way or another would be better than allowing
arbitrary order. It would be nice to have a paragraph or two elaborating on
these issues.

-- 
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 j9C2pGPR065818; Tue, 11 Oct 2005 19:51:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C2pGXa065817; Tue, 11 Oct 2005 19:51:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9C2pE8h065806 for <[e-mail]>; Tue, 11 Oct 2005 19:51:15 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <20051012025037011009ku5de>; Wed, 12 Oct 2005 02:50:37 +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 j9C2oh0m005766 for <[e-mail]>; Tue, 11 Oct 2005 22:50:43 -0400
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 j9C2oY08014750 for <[e-mail]>; Tue, 11 Oct 2005 22:50:34 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9C2oYwG014749 for [e-mail]; Tue, 11 Oct 2005 22:50:34 -0400
Date: Tue, 11 Oct 2005 22:50:34 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Signature calculation language
Message-ID: <[e-mail]>
Mail-Followup-To: [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.8i
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, Oct 11, 2005 at 03:25:00PM -0700, "Hal Finney" wrote:

> So it does seem like it must be a MUST in order to be an effective
> deterrent.
> 
> One possible problem is if there is any substantial set of signing subkeys
> in use that don't have the 0x19 signature.  Signatures issued by those
> keys might become invalid.  I don't think we have any from pgp.com,
> we did not previously support signing subkeys.

GPG supports signing subkeys, and there are a number of them in use.
(A number, it should be said though, that is utterly dwarfed by the
number of people using their primary key as their signing key.)

I am concerned about the users of signing subkeys, so I have a
transition planned for GPG.  GPG has offered 0x19 backsigs as a
build-time option for a while now.  As of the next release (1.4.3),
backsigs are on by default so all new signing subkeys have them.  At
some point in the future (after more subkeys get backsigs), GPG will
start complaining if it does not see a backsig.  At some point even
further, GPG will start treating signatures issued by a signing subkey
without a backsig as invalid, but there will be a way to tell GPG to
ignore the missing backsigs for backwards compatibility.

I think such a transition in GPG and other programs that support
signing subkeys is a reasonable solution for the existing signing
subkeys out there, and it shouldn't impact doing the right thing in
the standard for future use.

I support making 0x19 backsigs a MUST.

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 j9C21Ocm062256; Tue, 11 Oct 2005 19:01:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C21OtM062255; Tue, 11 Oct 2005 19:01:24 -0700 (PDT)
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 j9C21Ntm062246 for <[e-mail]>; Tue, 11 Oct 2005 19:01:24 -0700 (PDT) (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.6) for <[e-mail]>; Tue, 11 Oct 2005 19:01:21 -0700
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Oct 2005 19:01:21 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Oct 2005 19:01:21 -0700
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Date: Tue, 11 Oct 2005 19:01:23 -0700
To: OpenPGP <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 11 Oct 2005, at 2:39 PM, Ian G wrote:

> Jon Callas wrote:
>
>
>> The possible outside exception is the "Cleartext Signatures"  
>> thread,  where I believe there's no consensus for a change, but I  
>> don't see  anything that can't be added in WGLC if that's not the  
>> case.
>>
>
> Ben raised an issue about the blank line separating
> the headers from the armour.  Is that mandatory or
> not?  I think it should be.
>

My opinion is that the spec clearly says that the blank line is  
required. If in the real world, there are implementations that don't  
put it in, and yet are generally accepted, then well, okay, but  
that's a standards violation.

I suppose that's reason enough to discuss taking it out, that it's  
more nodded to than observed, but I haven't noticed it being ignored.  
I was surprised that anyone didn't do it.

If consensus is to do something -- hey, that's why it's last call.

     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 j9C0NQ6S053914; Tue, 11 Oct 2005 17:23:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9C0NQK9053913; Tue, 11 Oct 2005 17:23:26 -0700 (PDT)
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 j9C0NPu9053907 for <[e-mail]>; Tue, 11 Oct 2005 17:23:26 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 5CD782B47A3; Wed, 12 Oct 2005 02:23:24 +0200 (CEST)
Date: Wed, 12 Oct 2005 02:23:24 +0200
To: [e-mail]
Subject: Re: Signature calculation language
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, Oct 11, 2005 at 03:25:00PM -0700, "Hal Finney" wrote:

> One possible problem is if there is any substantial set of signing subkeys
> in use that don't have the 0x19 signature.  Signatures issued by those
> keys might become invalid.  I don't think we have any from pgp.com,
> we did not previously support signing subkeys.

I have encountered only one signature subkey so far, but I do intend to use
signature subkeys in the future myself. I agree that signature theft is a
very serious issue, and mandating 0x19 signatures is necessary to prevent
it.

Signature subkeys currently in use are not that much of a problem, because
the owners can always create the missing 0x19 signature. If they don't, it's
in everybody's interest (including their own) that the signatures become
invalid.

I actually wanted to do a survey of public keys for algorithms, key sizes,
subkeys, etc. for a long time. What I really want to know is what algorithms
and key sizes are used for certification, encryption and document signature,
and what proportion of users use subkeys.

If there's additional interest for such a survey, please let me know: it
will provide me with the additional motivation I need to actually carry it
out. Most of the software has already been written, but it's a horrible
processor hog of a task, estimated to keep a server busy for several hours.
As a side benefit, I could email all known signature subkey owners about
signing their subkey both ways. But that can only happen when major
implementations (PGP and GPG) can actually do it.

Also, there's a significant number of keys corrupted by keyservers that
can't handle multiple subkeys correctly. While natural in some way, it still
amazes me how much worse the quality of keyservers are compared to other
OpenPGP software.

-- 
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 j9BMODFf041194; Tue, 11 Oct 2005 15:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BMODMr041193; Tue, 11 Oct 2005 15:24:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BMODqg041183 for <[e-mail]>; Tue, 11 Oct 2005 15:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005101122240701500b7u8ke>; Tue, 11 Oct 2005 22:24:07 +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 j9BMOC0m004980 for <[e-mail]>; Tue, 11 Oct 2005 18:24:12 -0400
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 j9BMO4Ct004923 for <[e-mail]>; Tue, 11 Oct 2005 18:24:04 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9BMO4c5004922 for [e-mail]; Tue, 11 Oct 2005 18:24:04 -0400
Date: Tue, 11 Oct 2005 18:24:04 -0400
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[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.8i
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 10, 2005 at 06:58:03PM +0100, Ben Laurie wrote:
> 
> Daniel A. Nagy wrote:
> >On Mon, Oct 10, 2005 at 03:30:29PM +0100, Ben Laurie wrote:
> >
> >
> >>That mantra has shown to be a less than great idea recently, since it 
> >>promotes interestingly obscure security holes, so I still would like to 
> >>know what the correct behaviour is, and I'd like the I-D to accurately 
> >>document that behaviour.
> >
> >
> >In that case, the empty line should be mandated,
> 
> I agree.

As do I, but it seems to me that it is already mandated.  Section 6.2
(Forming ASCII Armor) mandates the line.  Section 7 (Cleartext
signature framework) refers to "The ASCII armored signature(s)".
Doesn't it them follow that the armored signature (like all armor)
mandates the line?  Am I reading into something that isn't there?

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 j9BMO0qO041177; Tue, 11 Oct 2005 15:24:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BMO00W041176; Tue, 11 Oct 2005 15:24:00 -0700 (PDT)
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 j9BMNsff041166 for <[e-mail]>; Tue, 11 Oct 2005 15:23:59 -0700 (PDT) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 0352B57EF9; Tue, 11 Oct 2005 15:25:00 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: Re: Signature calculation language
Message-Id: <[e-mail]>
Date: Tue, 11 Oct 2005 15:25:00 -0700 (PDT)
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>

David Shaw writes:
> Wondering - should the embedded 0x19 signature be a MUST?  Lacking a
> 0x19 allows the signing subkey to be "stolen" onto another primary
> key.

To remind readers, the 0x19 signature is issued by signing subkeys on
top-level keys, so that we have two-way binding.  The top key signs the
subkey and the subkey signs the top key, so each key agrees that they
belong together in a pair.

The problem is that if it is not a MUST, someone who does create
such a 0x19 back signature to bind his subkey is still at risk of it
being stolen.  The thief would bring just the subkey over and put a new
signature on it by his top key, and there would be no sign of the 0x19
signature the victim had created to try to stop this theft.  There would
be no 0x19 signature on the new key, but if it is not a MUST then we
might have to assume that this was just a choice by the key holder not
to create one.

So it does seem like it must be a MUST in order to be an effective
deterrent.

One possible problem is if there is any substantial set of signing subkeys
in use that don't have the 0x19 signature.  Signatures issued by those
keys might become invalid.  I don't think we have any from pgp.com,
we did not previously support signing subkeys.

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 j9BMBdRl040252; Tue, 11 Oct 2005 15:11:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BMBdcG040251; Tue, 11 Oct 2005 15:11:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BMBcR0040240 for <[e-mail]>; Tue, 11 Oct 2005 15:11:39 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <2005101122113001200p8kcae>; Tue, 11 Oct 2005 22:11:31 +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 j9BMBZ0m004938 for <[e-mail]>; Tue, 11 Oct 2005 18:11:35 -0400
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 j9BMBRZg004899 for <[e-mail]>; Tue, 11 Oct 2005 18:11:27 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9BMBRPb004896 for [e-mail]; Tue, 11 Oct 2005 18:11:27 -0400
Date: Tue, 11 Oct 2005 18:11:27 -0400
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[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.8i
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 10, 2005 at 04:27:04PM +0200, Daniel A. Nagy wrote:

> I also have a question regarding clearsigned documents. Are multiple
> signatures in clearsigned documents supported by OpenPGP (the fact
> that multiple hash algorithms are allowed suggests that they are)?
> And if so, how exactly? I would put all of them in a single armored
> signature block, but the standard does not explicitly specify this
> or any other method.

Yes, they are supported, and the putting all of them in a single
armored signature block is the way to do it.  Section 7 refers to "The
ASCII armored signature(s)" in the signature block.  The text seems
reasonably clear to me - what is not good here?

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 j9BLdIL7036687; Tue, 11 Oct 2005 14:39:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BLdItC036686; Tue, 11 Oct 2005 14:39:18 -0700 (PDT)
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 j9BLdIZe036680 for <[e-mail]>; Tue, 11 Oct 2005 14:39:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 81FFE630A0; Tue, 11 Oct 2005 22:39:15 +0100 (BST)
Message-ID: <[e-mail]>
Date: Tue, 11 Oct 2005 22:39:52 +0100
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: Derek Atkins <[e-mail]>, [e-mail], [e-mail]
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
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:

> The possible outside exception is the "Cleartext Signatures" thread,  
> where I believe there's no consensus for a change, but I don't see  
> anything that can't be added in WGLC if that's not the case.

Ben raised an issue about the blank line separating
the headers from the armour.  Is that mandatory or
not?  I think it should be.

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 j9BLL0Px035360; Tue, 11 Oct 2005 14:21:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BLL0xQ035359; Tue, 11 Oct 2005 14:21:00 -0700 (PDT)
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 j9BLKxFI035339 for <[e-mail]>; Tue, 11 Oct 2005 14:20:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 11ECB6309D; Tue, 11 Oct 2005 22:20:57 +0100 (BST)
Message-ID: <[e-mail]>
Date: Tue, 11 Oct 2005 22:21:34 +0100
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: Ben Laurie <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[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: 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:

> The spec as it stands is clear, and someone who puts this into mail  has 
> to deal with long body lines in a cleartext message, anyway.  They're 
> the mail expert, I'm not.

No problem, I withdraw the suggestion.  (I actually
tried to make it more concrete ... but found some
other issues that got into the cross-domain issues
that you mention.)

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 j9BL3m5A032909; Tue, 11 Oct 2005 14:03:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BL3mYY032908; Tue, 11 Oct 2005 14:03:48 -0700 (PDT)
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 j9BL3mnG032893 for <[e-mail]>; Tue, 11 Oct 2005 14:03:48 -0700 (PDT) (envelope-from [e-mail])
Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005101121034201500b72oqe>; Tue, 11 Oct 2005 21:03:42 +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 j9BL3l0m004690 for <[e-mail]>; Tue, 11 Oct 2005 17:03:47 -0400
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 j9BL3dkV004804 for <[e-mail]>; Tue, 11 Oct 2005 17:03:39 -0400
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j9BL3doo004803 for [e-mail]; Tue, 11 Oct 2005 17:03:39 -0400
Date: Tue, 11 Oct 2005 17:03:39 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Signature calculation language
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.8i
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, Oct 11, 2005 at 01:44:53PM -0700, Jon Callas wrote:
> On 5 Oct 2005, at 2:11 PM, Hal Finney wrote:

> >    0x18: Subkey Binding Signature
> >        This signature is a statement by the top-level signing key  
> >that
> >        indicates that it owns the subkey. This signature is  
> >calculated
> >        directly on the subkey itself, not on any User ID or other
> >        packets. A signature that binds a signing subkey also has an
> >        embedded signature subpacket in this binding signature which
> >        contains a 0x19 signature made by the signing subkey on the
> >        primary key.
> >
> >The signature is actually calculated over both the primary key and
> >subkey packets, although here it says it is not calcualted over any
> >other packets.
> >
> >(A separate issue is that the last sentence here should have a SHOULD:
> >"A signature that binds a signing subkey SHOULD have an embedded...")
> >
> 
> Done.

Wondering - should the embedded 0x19 signature be a MUST?  Lacking a
0x19 allows the signing subkey to be "stolen" onto another primary
key.

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 j9BKsI6T031792; Tue, 11 Oct 2005 13:54:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BKsIGK031791; Tue, 11 Oct 2005 13:54:18 -0700 (PDT)
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 j9BKsH5J031785 for <[e-mail]>; Tue, 11 Oct 2005 13:54:17 -0700 (PDT) (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.6); Tue, 11 Oct 2005 13:54:16 -0700
Received: from [216.102.208.14] ([216.102.208.14]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Oct 2005 13:54:15 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Oct 2005 13:54:15 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail], [e-mail]
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Date: Tue, 11 Oct 2005 13:54:09 -0700
To: Derek Atkins <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 11 Oct 2005, at 1:23 PM, Derek Atkins wrote:

>
> Jon assures me that draft-15 will be out tonight, so this should  
> provide
> ample time for everyone to read and comment on the draft by the Last
> Call end-time.
>

It'll be out as soon as I check for massively stupid errors, like  
wrong years, bad paragraph breaks, etc. (which have happened in the  
past).

I believe that this covers all open issues. Derek and I went through  
all the ones on his list and mine, and they're both empty now. If I'm  
wrong, drop me a message.

The possible outside exception is the "Cleartext Signatures" thread,  
where I believe there's no consensus for a change, but I don't see  
anything that can't be added in WGLC if that's not the case.

     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 j9BKj3cm030937; Tue, 11 Oct 2005 13:45:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BKj3nj030936; Tue, 11 Oct 2005 13:45:03 -0700 (PDT)
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 j9BKj2wc030930 for <[e-mail]>; Tue, 11 Oct 2005 13:45:02 -0700 (PDT) (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.6); Tue, 11 Oct 2005 13:44:55 -0700
Received: from [216.102.208.14] ([216.102.208.14]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Oct 2005 13:44:55 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Oct 2005 13:44:55 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
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: Signature calculation language
Date: Tue, 11 Oct 2005 13:44:53 -0700
To: Hal Finney <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 5 Oct 2005, at 2:11 PM, Hal Finney wrote:

>
> Some of the language in the draft about signature calculations is
> confusing and misleading.  The brief descriptions in 5.2.1 Signature
> Types are contradicted by 5.2.4 Computing Signatures.
>
> We should make clear that 5.2.4 is authoritative.  I suggest that  
> we add
> to the beginning of 5.2.1, "See section 5.2.4 for detailed information
> on how to compute and verify signatures of each type."
>

Added.

> Particular problems:
>
>     0x18: Subkey Binding Signature
>         This signature is a statement by the top-level signing key  
> that
>         indicates that it owns the subkey. This signature is  
> calculated
>         directly on the subkey itself, not on any User ID or other
>         packets. A signature that binds a signing subkey also has an
>         embedded signature subpacket in this binding signature which
>         contains a 0x19 signature made by the signing subkey on the
>         primary key.
>
> The signature is actually calculated over both the primary key and
> subkey packets, although here it says it is not calcualted over any
> other packets.
>
> (A separate issue is that the last sentence here should have a SHOULD:
> "A signature that binds a signing subkey SHOULD have an embedded...")
>

Done.

>     0x19 Primary Key Binding Signature
>         This signature is a statement by a signing subkey, indicating
>         that it is owned by the primary key.  This signature is
>         calculated directly on the primary key itself, and not on any
>         User ID or other packets.
>
> Same issue here, the signature is calculated over both the primary key
> and the subkey packets.
>
>     0x28: Subkey revocation signature
>         The signature is calculated directly on the subkey being
>         revoked.  A revoked subkey is not to be used.  Only revocation
>         signatures by the top-level signature key that is bound to  
> this
>         subkey, or by an authorized revocation key, should be  
> considered
>         valid revocation signatures.
>
> This is actually correct, I guess (I don't think PGP supports  
> subpacket
> revocation signatures).  According to 5.2.4 the hash is over just the
> subkey packet and does not include the primary key packet, unlike  
> ordinary
> subkey signatures.  That seems a little inconsistent to me - is  
> this how
> other people have implemented it?
>
> A couple of comments on section 5.2.4:
>
>     When a signature is made over a signature packet, the hash data
>     starts with the octet 0x88, followed by the four-octet length  
> of the
>     signature, and then the body of the signature packet. The unhashed
>     subpacket data of the signature packet being hashed is not  
> included
>     in the hash and the unhashed subpacket data length value is set to
>     zero. (Note that this is an old-style packet header for a  
> signature
>     packet with the length-of-length set to zero).
>
> The parenthetical note at the end should go after the first sentence.
>

Done.

> For consistency with other descriptions in this section, we should  
> refer
> explicitly here to the Third-Party Confirmation Signature, type 0x50,
> which I think is the only one for which this description applies.
>

Done.

> One thing that is missing in these two sections is a clear  
> statement that
> certificate revocation signatures are calculated over the same data  
> as the
> certificate being revoked.  5.2.1 just says:
>
>     0x30: Certification revocation signature
>         This signature revokes an earlier User ID certification
>         signature (signature class 0x10 through 0x13) or direct-key
>         signature (0x1F). It should be issued by the same key that
>         issued the revoked signature or an authorized revocation key.
>         The signature should have a later creation date than the
>         signature it revokes.
>
> with no comments about what it is computed over, and 5.2.4 doesn't  
> clearly
> describe this case either.  We could change that last sentence to say,
> "The signature is computed over the same data as the certificate that
> it revokes, and should have a later creation date than that  
> certificate."
>

Done.

> I am also not in love with the classic description of document  
> signatures
> in 5.2.4:
>
>     The signature data is simple to compute for document signatures
>     (types 0x00 and 0x01), for which the document itself is the data.
>
> First, it is presumptuous and uninformative to say something is  
> simple.
> "The document itself is the data" has a certain Zen koan quality  
> but does
> not plainly say what it means.  And this fails to distinguish between
> text and binary signatures; for text signatures, the document  
> itself is
> not the (hashed) data, but rather the canonicalized document.
>
> How about this:
>
> "For binary document signatures (type 0x00), the document data is  
> hashed
> directly.  For text document signatures (type 0x01), the document is
> canonicalized by converting line endings to <CR><LF>, and the  
> resulting
> data is hashed."

Done.

     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 j9BKQlUI028778; Tue, 11 Oct 2005 13:26:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BKQkkq028777; Tue, 11 Oct 2005 13:26:47 -0700 (PDT)
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 j9BKQkCE028770 for <[e-mail]>; Tue, 11 Oct 2005 13:26:46 -0700 (PDT) (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.6); Tue, 11 Oct 2005 13:26:42 -0700
Received: from [216.102.208.14] ([216.102.208.14]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Oct 2005 13:26:42 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Oct 2005 13:26:42 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Ben Laurie <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: Cleartext Signatures
Date: Tue, 11 Oct 2005 13:26:38 -0700
To: Ian G <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 Oct 2005, at 11:48 AM, Ian G wrote:

>
> Ben Laurie wrote:
>
>> Sigh. The I-D says armour lines are at most 76 characters.
>>
>
>
> !IIRC, so replace 'standard' with fixed.
>
> Getting back to the point of vedaal's kindly
> provided suggestion, the length of the armour
> lines is not fixed, and successive implementations
> have wrestled with the length, gradually setting
> it less as newer mailer and editor artifacts pop
> out of the electronic woodwork.
>
> My point is that the length of the Header/Tail Lines
> and/or the Armor lines suggests a more effective
> maximum to the length of the headers, as then the
> headers themselves won't cause any problems.
>
> If it is a big enough issue, I'd suggest adding
> the following guidance:
>
>     The format of an Armor Header is that of a key-value pair.  A  
> colon
>     (':' 0x38) and a single space (0x20) separate the key and value.
>     OpenPGP should consider improperly formatted Armor Headers to be
>     corruption of the ASCII Armor.  Unknown keys should be reported to
>     the user, but OpenPGP should continue to process the message.
>   ******
>     From experience, implementations may limit or warn if the length
>     of any Armor Header exceeds the length of other lines.
>   ******
>
> Or somesuch, towards end of page 49.  Here's an alternate:
>
>   ******
>     As messages may experience various transformations during
>     transport, resiliance may be improved if Armor Headers are
>     kept short, by for example being no longer than the length
>     of other lines (Armor Header Lines or the Armor itself).
>   *****

Okay, but.

OpenPGP is not an email standard. It is a data format standard.

Yes, many uses of OpenPGP are in email. But not all, and possibly  
even not most. (I have heard it asserted that there are more signed  
files than emails.)

I remember a past argument about the comment header, for example,  
noting that an appropriately clever person could make a comment that  
would do something that someone doesn't like because of high-bit  
issues, character sets, etc. Our ending decision was to note that if  
you hurt yourself, you hurt yourself.

The only reason I would prefer not doing anything here is that I  
don't want to keep putting in hints for good interactions with  
mailers in 2440bis. We are a superset of mail.

The spec as it stands is clear, and someone who puts this into mail  
has to deal with long body lines in a cleartext message, anyway.  
They're the mail expert, I'm not.

     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 j9BKNHLU028544; Tue, 11 Oct 2005 13:23:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BKNH7S028543; Tue, 11 Oct 2005 13:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BKNG7s028537 for <[e-mail]>; Tue, 11 Oct 2005 13:23:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.63] (adsl-068-157-135-002.sip.asm.bellsouth.net [68.157.135.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ihtfp.org (Postfix) with ESMTP id 14EEEBD8420; Tue, 11 Oct 2005 16:23:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 11 Oct 2005 16:23:09 -0400
From: Derek Atkins <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
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>

Hi,

The new openpgp internet-draft (version 15) should be out and in the
archives really soon.  The editor and I believe that all open issues
have been incorporated into this version of the draft.  Therefore I am
declaring a Working Group Last Call on draft-ietf-openpgp-openpgp-15
that will end at 1700 US/EDT on Friday, October 28th.

Jon assures me that draft-15 will be out tonight, so this should provide
ample time for everyone to read and comment on the draft by the Last
Call end-time.

Issues should be sent to the list.  If you feel you want to remain
private you can send them to jon <[e-mail]> and myself.  If you
wish to remain ultra-private you are welcome to send the issues just to
me and I will forward them on anonymized.

Happy reading.

-derek
-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant



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 j9BJLNcC023098; Tue, 11 Oct 2005 12:21:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9BJLNvI023097; Tue, 11 Oct 2005 12:21:23 -0700 (PDT)
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 j9BJLMMq023089 for <[e-mail]>; Tue, 11 Oct 2005 12:21:22 -0700 (PDT) (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.6); Tue, 11 Oct 2005 12:21:21 -0700
Received: from [216.102.208.14] ([216.102.208.14]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Oct 2005 12:21:20 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Oct 2005 12:21:20 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: ISSUE: misleading hash instructions
Date: Tue, 11 Oct 2005 12:21:18 -0700
To: David Shaw <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 27 Aug 2005, at 6:59 AM, David Shaw wrote:

>
> This one is really easy to fix.  In section 5.2.4 (Computing
> Signatures), the paragraph ordering implies incorrect things about a
> user ID certification signature (which hashes the public key plus user
> ID packet).  The description of a user ID certification signature
> refers to "the data above", which given the paragraph ordering, is how
> to hash a signature for signing, and not a public key.
>
> If we just switch the position of the paragraph beginning "When a
> signature is made over a signature packet" with the paragraph
> beginning "A certification signature (type 0x10 through 0x13)" the
> problem goes away.
>

Fixed.

     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 j9AIm6sb055108; Mon, 10 Oct 2005 11:48:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AIm6bx055107; Mon, 10 Oct 2005 11:48:06 -0700 (PDT)
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 j9AIm6Sk055099 for <[e-mail]>; Mon, 10 Oct 2005 11:48:06 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 72D7D63627; Mon, 10 Oct 2005 19:48:04 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 19:48:40 +0100
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: [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
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:
> Sigh. The I-D says armour lines are at most 76 characters.


!IIRC, so replace 'standard' with fixed.

Getting back to the point of vedaal's kindly
provided suggestion, the length of the armour
lines is not fixed, and successive implementations
have wrestled with the length, gradually setting
it less as newer mailer and editor artifacts pop
out of the electronic woodwork.

My point is that the length of the Header/Tail Lines
and/or the Armor lines suggests a more effective
maximum to the length of the headers, as then the
headers themselves won't cause any problems.

If it is a big enough issue, I'd suggest adding
the following guidance:

     The format of an Armor Header is that of a key-value pair.  A colon
     (':' 0x38) and a single space (0x20) separate the key and value.
     OpenPGP should consider improperly formatted Armor Headers to be
     corruption of the ASCII Armor.  Unknown keys should be reported to
     the user, but OpenPGP should continue to process the message.
   ******
     From experience, implementations may limit or warn if the length
     of any Armor Header exceeds the length of other lines.
   ******

Or somesuch, towards end of page 49.  Here's an alternate:

   ******
     As messages may experience various transformations during
     transport, resiliance may be improved if Armor Headers are
     kept short, by for example being no longer than the length
     of other lines (Armor Header Lines or the Armor itself).
   *****

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 j9AI6pG5051708; Mon, 10 Oct 2005 11:06:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AI6p6C051707; Mon, 10 Oct 2005 11:06:51 -0700 (PDT)
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 j9AI6o5m051698 for <[e-mail]>; Mon, 10 Oct 2005 11:06:50 -0700 (PDT) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EP29I-00083c-Qy for <[e-mail]>; Mon, 10 Oct 2005 20:13:20 +0200
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EP1x7-0001pj-GZ; Mon, 10 Oct 2005 20:00:45 +0200
To: Ian G <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Mon, 10 Oct 2005 20:00:45 +0200
In-Reply-To: <[e-mail]> (Ian G.'s message of "Mon, 10 Oct 2005 17:58:04 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (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 Mon, 10 Oct 2005 17:58:04 +0100, Ian G said:

> There is no reason why OpenPGP can't impose a
> tighter limit, and a quick scan of the doc did

That won't help.  Some editors used by MUAs feel too clever and don't
allow a user to enter lines longer than the actual window.  When copy
and pasting an OpenPGP armored message it might get wrapped around.
So even 76 chracters may be too much.

A possible solution to this is to have the MUA (plugin) to cut or
remove such headers.


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 j9AI016d050999; Mon, 10 Oct 2005 11:00:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AI0111050998; Mon, 10 Oct 2005 11:00:01 -0700 (PDT)
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 j9AI00j8050985 for <[e-mail]>; Mon, 10 Oct 2005 11:00:00 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 99EC133C1B; Mon, 10 Oct 2005 18:59:59 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 18:58:03 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> On Mon, Oct 10, 2005 at 03:30:29PM +0100, Ben Laurie wrote:
> 
> 
>>That mantra has shown to be a less than great idea recently, since it 
>>promotes interestingly obscure security holes, so I still would like to 
>>know what the correct behaviour is, and I'd like the I-D to accurately 
>>document that behaviour.
> 
> 
> In that case, the empty line should be mandated,

I agree.

> although distinguishing
> between header data and base64 armor is quite straightforward and
> unambiguous: headers always have colons in them, base64 armor never does.

This becomes less straightforward when you hit line length limits.

> Thus, it should be impossible to derail a correct parser with a carefully
> constructed header, though of course, it's easier to write the parser if one
> assumes an empty line before the base64 data.

Mine does either (configurably).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9AGvVoB042699; Mon, 10 Oct 2005 09:57:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AGvVeN042694; Mon, 10 Oct 2005 09:57:31 -0700 (PDT)
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 j9AGvTgA042658 for <[e-mail]>; Mon, 10 Oct 2005 09:57:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id AB65363518; Mon, 10 Oct 2005 17:57:27 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 17:58:04 +0100
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: Werner Koch <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
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>

Werner Koch wrote:
> On Mon, 10 Oct 2005 07:15:07 -0700,   said:
> 
> 
>>could there be a consensus on the maximum length of 
>>a comment or version line,
> 
> 
> This is not OpenPGP's business.  There is a limit in rfc2822 at (iirc)
> 998 characters.  The real problem at hand is that some MUAs break
> lines when they should not do so.

There is no reason why OpenPGP can't impose a
tighter limit, and a quick scan of the doc did
not reveal mention of rfc2822 anywhere.  Either
way, ascii armor documents are OpenPGP's business,
wherever it got the format from.

> [To avoid this once and for all, use PGP/MIME.]

I for one choose not to, but I'm not religious
about it!

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 j9AGKoCI039185; Mon, 10 Oct 2005 09:20:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AGKoCi039184; Mon, 10 Oct 2005 09:20:50 -0700 (PDT)
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 j9AGKnZW039178 for <[e-mail]>; Mon, 10 Oct 2005 09:20:49 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id EC0562B47DB; Mon, 10 Oct 2005 18:20:36 +0200 (CEST)
Date: Mon, 10 Oct 2005 18:20:36 +0200
To: OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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, Oct 10, 2005 at 03:30:29PM +0100, Ben Laurie wrote:

> That mantra has shown to be a less than great idea recently, since it 
> promotes interestingly obscure security holes, so I still would like to 
> know what the correct behaviour is, and I'd like the I-D to accurately 
> document that behaviour.

In that case, the empty line should be mandated, although distinguishing
between header data and base64 armor is quite straightforward and
unambiguous: headers always have colons in them, base64 armor never does.
Thus, it should be impossible to derail a correct parser with a carefully
constructed header, though of course, it's easier to write the parser if one
assumes an empty line before the base64 data.

-- 
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 j9AFNbcM034437; Mon, 10 Oct 2005 08:23:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AFNbOf034436; Mon, 10 Oct 2005 08:23:37 -0700 (PDT)
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 j9AFNaxx034429 for <[e-mail]>; Mon, 10 Oct 2005 08:23:36 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CA98C33C1A; Mon, 10 Oct 2005 16:23:35 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 16:21:39 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ian G <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

Ian G wrote:
> 
> [e-mail] wrote:
> 
>> also,
>> could there be a consensus on the maximum length of a comment or 
>> version line,
>>
>> long version lines (example the freeware pgp editions)
>> wrap in gnupg,
>> and there is an error message of invalid armor heador,
>> and further attempts at decryption/verification are stopped
> 
> 
> It is possible to parse for the next empty line,
> but I agree this is a pain, as there are other
> artifacts that occur when extra empty lines are
> inserted by conversions.
> 
>> would suggest 64 characters, to keep it the same as the rest of the 
>> pgp armor
> 
> 
> The line length of the armor is not standard
> IIRC, so this would not be a good guide.  A
> better guide would be to be no longer than any
> of the Head/Tail lines, as any slicing that
> occurs in the Head/Tail lines will cause more
> than normal chaos.

Sigh. The I-D says armour lines are at most 76 characters.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9AEptGF030693; Mon, 10 Oct 2005 07:51:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AEptgB030692; Mon, 10 Oct 2005 07:51:55 -0700 (PDT)
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 j9AEpsFI030686 for <[e-mail]>; Mon, 10 Oct 2005 07:51:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 4E5436350D; Mon, 10 Oct 2005 15:51:53 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 15:52:29 +0100
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: [e-mail]
Cc: [e-mail]
Subject: Re: Cleartext Signatures
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>

[e-mail] wrote:
> also,
> could there be a consensus on the maximum length of 
> a comment or version line,
> 
> long version lines (example the freeware pgp editions)
> wrap in gnupg,
> and there is an error message of invalid armor heador,
> and further attempts at decryption/verification are stopped

It is possible to parse for the next empty line,
but I agree this is a pain, as there are other
artifacts that occur when extra empty lines are
inserted by conversions.

> would suggest 64 characters, to keep it the same as the rest of the 
> pgp armor

The line length of the armor is not standard
IIRC, so this would not be a good guide.  A
better guide would be to be no longer than any
of the Head/Tail lines, as any slicing that
occurs in the Head/Tail lines will cause more
than normal chaos.

iang

PS:  with a nod to Ben's comment, I mean by
Head/Tail lines those lines that start with
----- in column 1.



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 j9AEppKh030680; Mon, 10 Oct 2005 07:51:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AEpp7X030679; Mon, 10 Oct 2005 07:51:51 -0700 (PDT)
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 j9AEpnvW030671 for <[e-mail]>; Mon, 10 Oct 2005 07:51:50 -0700 (PDT) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EOz6Z-0007Dp-OV for <[e-mail]>; Mon, 10 Oct 2005 16:58:19 +0200
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EOyuH-0001KV-Oy; Mon, 10 Oct 2005 16:45:37 +0200
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Cleartext Signatures
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Mon, 10 Oct 2005 16:45:37 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Mon, 10 Oct 2005 07:15:07 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (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 Mon, 10 Oct 2005 07:15:07 -0700,   said:

> could there be a consensus on the maximum length of 
> a comment or version line,

This is not OpenPGP's business.  There is a limit in rfc2822 at (iirc)
998 characters.  The real problem at hand is that some MUAs break
lines when they should not do so.

[To avoid this once and for all, use PGP/MIME.]


Shalom-Salam,

   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 j9AEWRIQ028130; Mon, 10 Oct 2005 07:32:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AEWR2L028129; Mon, 10 Oct 2005 07:32:27 -0700 (PDT)
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 j9AEWQZK028122 for <[e-mail]>; Mon, 10 Oct 2005 07:32:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3880433C1B; Mon, 10 Oct 2005 15:32:26 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 15:30:29 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Daniel A. Nagy" <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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:
> On Mon, Oct 10, 2005 at 11:43:05AM +0100, Ben Laurie wrote:
> 
>>Section 7 says that the last bit of a cleartext signature is:
>>
>>"The ASCII armored signature(s) including the '-----BEGIN PGP 
>>SIGNATURE-----' Armor Header and Armor Tail Lines."
>>
>>This is ambiguous, since in previous sections "Armor Header" has 
>>referred to name/value pairs, of which there could be none or more than 
>>one, and not the "-----blah-----" line, which is called the "Armor 
>>Header Line".
>>
>>Since I have seen signature both with and without headers (i.e. some 
>>with no headers do not have a blank line between the header line and the 
>>armoured text), I'd like to know what is actually correct here!
> 
> 
> Most implementations that I have encountered or written use headers in the
> signanture part of clearsigned documents and in the absence of any still
> leave an empty line. I think, this is the correct behavior, though the 
> "be liberal in what you accept and conservative in what you send" mantra
> would imply that implementations MAY accept signatures without an empty
> line, but MUST NOT generate them.

That mantra has shown to be a less than great idea recently, since it 
promotes interestingly obscure security holes, so I still would like to 
know what the correct behaviour is, and I'd like the I-D to accurately 
document that behaviour.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j9AER6oB027240; Mon, 10 Oct 2005 07:27:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AER6fu027239; Mon, 10 Oct 2005 07:27:06 -0700 (PDT)
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 j9AER5cY027229 for <[e-mail]>; Mon, 10 Oct 2005 07:27:05 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 2822BF8085; Mon, 10 Oct 2005 16:27:04 +0200 (CEST)
Date: Mon, 10 Oct 2005 16:27:04 +0200
To: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Cleartext Signatures
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, Oct 10, 2005 at 11:43:05AM +0100, Ben Laurie wrote:
> 
> Section 7 says that the last bit of a cleartext signature is:
> 
> "The ASCII armored signature(s) including the '-----BEGIN PGP 
> SIGNATURE-----' Armor Header and Armor Tail Lines."
> 
> This is ambiguous, since in previous sections "Armor Header" has 
> referred to name/value pairs, of which there could be none or more than 
> one, and not the "-----blah-----" line, which is called the "Armor 
> Header Line".
> 
> Since I have seen signature both with and without headers (i.e. some 
> with no headers do not have a blank line between the header line and the 
> armoured text), I'd like to know what is actually correct here!

Most implementations that I have encountered or written use headers in the
signanture part of clearsigned documents and in the absence of any still
leave an empty line. I think, this is the correct behavior, though the 
"be liberal in what you accept and conservative in what you send" mantra
would imply that implementations MAY accept signatures without an empty
line, but MUST NOT generate them.

I also have a question regarding clearsigned documents. Are multiple
signatures in clearsigned documents supported by OpenPGP (the fact that
multiple hash algorithms are allowed suggests that they are)? And if so, how
exactly? I would put all of them in a single armored signature block, but
the standard does not explicitly specify this or any other method.

-- 
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 j9AEFDM7026219; Mon, 10 Oct 2005 07:15:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AEFDUk026218; Mon, 10 Oct 2005 07:15:13 -0700 (PDT)
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 j9AEFCfO026207 for <[e-mail]>; Mon, 10 Oct 2005 07:15:12 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 65917A337F for <[e-mail]>; Mon, 10 Oct 2005 07:15:12 -0700 (PDT)
Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for <[e-mail]>; Mon, 10 Oct 2005 07:15:10 -0700 (PDT)
Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j9AEFAXw002758 for <[e-mail]>; Mon, 10 Oct 2005 07:15:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Mon, 10 Oct 2005 07:15:07 -0700
To: <[e-mail]>
Cc: 
Subject: Re: Cleartext Signatures
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 Mon, 10 Oct 2005 03:43:05 -0700 Ben Laurie <[e-mail]> 
wrote:
>Section 7 says that the last bit of a cleartext signature is:
>
>"The ASCII armored signature(s) including the '-----BEGIN PGP 
>SIGNATURE-----' Armor Header and Armor Tail Lines."
>
>This is ambiguous, since in previous sections "Armor Header" has 
>referred to name/value pairs, of which there could be none or more 

>than 
>one, and not the "-----blah-----" line, which is called the "Armor 

>
>Header Line".
>
>Since I have seen signature both with and without headers (i.e. 
>some 
>with no headers do not have a blank line between the header line 
>and the 
>armoured text), I'd like to know what is actually correct here!
>
>Cheers,

also,
could there be a consensus on the maximum length of 
a comment or version line,

long version lines (example the freeware pgp editions)
wrap in gnupg,
and there is an error message of invalid armor heador,
and further attempts at decryption/verification are stopped

would suggest 64 characters, to keep it the same as the rest of the 
pgp armor

vedaa



Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427



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 j9AAjCMp005121; Mon, 10 Oct 2005 03:45:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AAjCoK005120; Mon, 10 Oct 2005 03:45:12 -0700 (PDT)
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 j9AAj8I2005108 for <[e-mail]>; Mon, 10 Oct 2005 03:45:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A081E33C1B for <[e-mail]>; Mon, 10 Oct 2005 11:45:02 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 10 Oct 2005 11:43:05 +0100
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: Cleartext Signatures
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

Section 7 says that the last bit of a cleartext signature is:

"The ASCII armored signature(s) including the '-----BEGIN PGP 
SIGNATURE-----' Armor Header and Armor Tail Lines."

This is ambiguous, since in previous sections "Armor Header" has 
referred to name/value pairs, of which there could be none or more than 
one, and not the "-----blah-----" line, which is called the "Armor 
Header Line".

Since I have seen signature both with and without headers (i.e. some 
with no headers do not have a blank line between the header line and the 
armoured text), I'd like to know what is actually correct here!

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 j97Frenb031327; Fri, 7 Oct 2005 08:53:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j97FreIm031326; Fri, 7 Oct 2005 08:53:40 -0700 (PDT)
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 j97FrY6N031278 for <[e-mail]>; Fri, 7 Oct 2005 08:53:35 -0700 (PDT) (envelope-from [e-mail])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 81C342B47DA; Fri,  7 Oct 2005 17:53:22 +0200 (CEST)
Date: Fri, 7 Oct 2005 17:53:22 +0200
To: Hal Finney <[e-mail]>, [e-mail]
Subject: Re: Signature calculation language
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>

This, I agree, is the worst part of RFC2440, causing me a lot of trouble (I
would actualy go further: it's almost useless in its present form; I ended
up figuring things out from PGP and GPG sources and interoperability
experiments). Instead of just tweaking the language, however, I would
suggest the inclusion of an overview table in which one can look up which
signature type is calculated on exactly what data, in what format, in which
order. It would be tremendously useful for implementers.

-- 
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 j95LBIY4089777; Wed, 5 Oct 2005 14:11:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j95LBIIw089776; Wed, 5 Oct 2005 14:11:18 -0700 (PDT)
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 j95LBHaC089769 for <[e-mail]>; Wed, 5 Oct 2005 14:11:18 -0700 (PDT) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id EEB1457EF9; Wed,  5 Oct 2005 14:11:58 -0700 (PDT)
To: [e-mail]
Subject: Signature calculation language
Message-Id: <[e-mail]>
Date: Wed,  5 Oct 2005 14:11:58 -0700 (PDT)
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>

Some of the language in the draft about signature calculations is
confusing and misleading.  The brief descriptions in 5.2.1 Signature
Types are contradicted by 5.2.4 Computing Signatures.

We should make clear that 5.2.4 is authoritative.  I suggest that we add
to the beginning of 5.2.1, "See section 5.2.4 for detailed information
on how to compute and verify signatures of each type."

Particular problems:

    0x18: Subkey Binding Signature
        This signature is a statement by the top-level signing key that
        indicates that it owns the subkey. This signature is calculated
        directly on the subkey itself, not on any User ID or other
        packets. A signature that binds a signing subkey also has an
        embedded signature subpacket in this binding signature which
        contains a 0x19 signature made by the signing subkey on the
        primary key.

The signature is actually calculated over both the primary key and
subkey packets, although here it says it is not calcualted over any
other packets.

(A separate issue is that the last sentence here should have a SHOULD:
"A signature that binds a signing subkey SHOULD have an embedded...")

    0x19 Primary Key Binding Signature
        This signature is a statement by a signing subkey, indicating
        that it is owned by the primary key.  This signature is
        calculated directly on the primary key itself, and not on any
        User ID or other packets.

Same issue here, the signature is calculated over both the primary key
and the subkey packets.

    0x28: Subkey revocation signature
        The signature is calculated directly on the subkey being
        revoked.  A revoked subkey is not to be used.  Only revocation
        signatures by the top-level signature key that is bound to this
        subkey, or by an authorized revocation key, should be considered
        valid revocation signatures.

This is actually correct, I guess (I don't think PGP supports subpacket
revocation signatures).  According to 5.2.4 the hash is over just the
subkey packet and does not include the primary key packet, unlike ordinary
subkey signatures.  That seems a little inconsistent to me - is this how
other people have implemented it?

A couple of comments on section 5.2.4:

    When a signature is made over a signature packet, the hash data
    starts with the octet 0x88, followed by the four-octet length of the
    signature, and then the body of the signature packet. The unhashed
    subpacket data of the signature packet being hashed is not included
    in the hash and the unhashed subpacket data length value is set to
    zero. (Note that this is an old-style packet header for a signature
    packet with the length-of-length set to zero).

The parenthetical note at the end should go after the first sentence.

For consistency with other descriptions in this section, we should refer
explicitly here to the Third-Party Confirmation Signature, type 0x50,
which I think is the only one for which this description applies.

One thing that is missing in these two sections is a clear statement that
certificate revocation signatures are calculated over the same data as the
certificate being revoked.  5.2.1 just says:

    0x30: Certification revocation signature
        This signature revokes an earlier User ID certification
        signature (signature class 0x10 through 0x13) or direct-key
        signature (0x1F). It should be issued by the same key that
        issued the revoked signature or an authorized revocation key.
        The signature should have a later creation date than the
        signature it revokes.

with no comments about what it is computed over, and 5.2.4 doesn't clearly
describe this case either.  We could change that last sentence to say,
"The signature is computed over the same data as the certificate that
it revokes, and should have a later creation date than that certificate."

I am also not in love with the classic description of document signatures
in 5.2.4:

    The signature data is simple to compute for document signatures
    (types 0x00 and 0x01), for which the document itself is the data.

First, it is presumptuous and uninformative to say something is simple.
"The document itself is the data" has a certain Zen koan quality but does
not plainly say what it means.  And this fails to distinguish between
text and binary signatures; for text signatures, the document itself is
not the (hashed) data, but rather the canonicalized document.

How about this:

"For binary document signatures (type 0x00), the document data is hashed
directly.  For text document signatures (type 0x01), the document is
canonicalized by converting line endings to <CR><LF>, and the resulting
data is hashed."

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 j94FI1oe095439; Tue, 4 Oct 2005 08:18:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j94FI1IK095438; Tue, 4 Oct 2005 08:18:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j94FI0dC095415 for <[e-mail]>; Tue, 4 Oct 2005 08:18:01 -0700 (PDT) (envelope-from [e-mail])
Received: by zproxy.gmail.com with SMTP id 8so235187nzo for <[e-mail]>; Tue, 04 Oct 2005 08:17:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UIzoBoWgTZhQTs0GkTM0IJ7j4yuejS6RDk4XRCMaTVKbSeXXuHgcDKgzY7yud1BSjABQ5AlxHYNE+iQSiULh9xsKZDufLx+N6EVl5V6YZ5/3do/+JGG26l0i9m/q/c8SPzxz7j0rPDbNBW8Xmo5oTLGFQFH9ypny6wKw6Q5iDBU=
Received: by 10.37.2.16 with SMTP id e16mr288850nzi; Tue, 04 Oct 2005 08:17:55 -0700 (PDT)
Received: by 10.36.222.9 with HTTP; Tue, 4 Oct 2005 08:17:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 4 Oct 2005 16:17:55 +0100
From: Rachel Willmer <[e-mail]>
Reply-To: Rachel Willmer <[e-mail]>
To: [e-mail]
Subject: Re: WG Goals and Milestones
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j94FI1dC095432
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 04/10/05, Jon Callas <[e-mail]> wrote:
> Those goals have really all been met.

I rather thought they might have :-)

Derek posted here a while ago
> (but not that long, they're part of the  IETF63 notes) some updated
> goals, but they're not on the website.

doh! should have thought to look there.

thanks
Rachel



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 j942nCBT011836; Mon, 3 Oct 2005 19:49:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j942nCBA011835; Mon, 3 Oct 2005 19:49:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j942nAH9011819 for <[e-mail]>; Mon, 3 Oct 2005 19:49:10 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 81E55343C3; Tue,  4 Oct 2005 15:49:04 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12428-23; Tue,  4 Oct 2005 15:49:04 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id AE98D3469B; Tue,  4 Oct 2005 15:49:03 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4F25E37746; Tue,  4 Oct 2005 15:49:03 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EMcrb-0000Wq-00; Tue, 04 Oct 2005 15:49:07 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Plausible deniability (a feature to think about)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 04 Oct 2005 15:49:07 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
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 <[e-mail]> writes:

>There's nothing wrong with X9.42 technical. Its non-use (and DSA's) are all
>layer 8 and 9 issues.

Actually X9.42 is a pretty awkward way to do key exchange.  You can use
Elgamal as a drop-in replacement for RSA, but X9.42 requires both sender and
receiver certs to establish a key, and mixes in a large pile of other (largely
unnecessary) complexity and extra parameters and data values for no good
reason.  It seems to have been heavily influenced by the Fortezza KEA
mechanism.  It's just a royal pain to implement no matter how you look at it.

While I'm commenting on this, there isn't much problem with key formats, X9.42
and DSA are both from the DLP family so they use the same key generation and
format.  Well, almost, the X9.42 guys copied the DSA spec wrong and reversed
two of the parameters, but apart from that they're identical.

Peter.



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 j93NkNBf087109; Mon, 3 Oct 2005 16:46:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93NkNUI087108; Mon, 3 Oct 2005 16:46:23 -0700 (PDT)
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 j93NkMKf087096 for <[e-mail]>; Mon, 3 Oct 2005 16:46:22 -0700 (PDT) (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.6) for <[e-mail]>; Mon, 3 Oct 2005 16:46:21 -0700
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 03 Oct 2005 16:46:21 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 03 Oct 2005 16:46:21 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
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: WG Goals and Milestones
Date: Mon, 3 Oct 2005 16:46:17 -0700
To: Rachel Willmer <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 3 Oct 2005, at 2:26 AM, Rachel Willmer wrote:

>
> Just looking at the IETF page for the working group
> <http://www.ietf.org/html.charters/openpgp-charter.html>, and it has
> the following under "Goals and Milestones"
>
> Done            Submit PGP/MIME draft to IESG for consideration as
> PROPOSED standard
> May 01          Submit Multiple Sig draft to IESG for consideration as
> PROPOSED standard
> Jul 01          Begin RFC2440, PGP/MIME Interoperability testing
> Aug 01          Request DRAFT status for RFC2440
>
> Are those still the goals the WG is working towards, or are there some
> other more up-to-date ones?

Those goals have really all been met. Derek posted here a while ago  
(but not that long, they're part of the  IETF63 notes) some updated  
goals, but they're not on the website.

Here's what he had:

    Aug 05  WGLC for 2440bis
    Sep 05  Submit 2440bis to IESG as Proposed Standard
    Nov 05  Finish Interop Test Plan
    Jan 06  Begin 2440bis Interop Testing
    Mar 06  Request DRAFT Status for 2440bis




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 j93NhJtw086860; Mon, 3 Oct 2005 16:43:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93NhJ4t086859; Mon, 3 Oct 2005 16:43:19 -0700 (PDT)
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 j93NhI4Q086853 for <[e-mail]>; Mon, 3 Oct 2005 16:43:18 -0700 (PDT) (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.6); Mon, 3 Oct 2005 16:43:14 -0700
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 03 Oct 2005 16:43:14 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 03 Oct 2005 16:43:14 -0700
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v734)
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: Plausible deniability (a feature to think about)
Date: Mon, 3 Oct 2005 16:43:09 -0700
To: "Daniel A. Nagy" <[e-mail]>
X-Mailer: Apple Mail (2.734)
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 22 Sep 2005, at 6:56 AM, Daniel A. Nagy wrote:

>>> Now, there exists a cryptographic solution for this problem,  
>>> moreover,
>>> RFC2440 even hints that it might be implemented in OpenPGP,  
>>> though I have
>>> never seen it used: X9.42 Diffie-Hellman key agreement (see also  
>>> RFC2630,
>>> RFC2631 and RFC2633).
>>>
>>
>> X9.42 was only added to S/MIME for political reasons.  AFAIK only one
>> implementation ever supported it, and that was the USG-funded  
>> reference
>> implementation that was required to support it.  In addition, MS  
>> supported a
>> read-only implementation just so they couldn't be accused of not  
>> supporting
>> it.
>>
>
> What political reasons? And why is there a reserved ID in OpenPGP?
>

Peter explained the political reasons around X9.42 in S/MIME. There  
are a different set of political things in OpenPGP.

Remember that at the time, the RSA algorithm was patented in the US,  
and the US had export restrictions. Consequently, this created an  
amusing window in which what you could do where had very little to do  
with rationality, let alone good technical decisions. Actually, to be  
complete, *all* public key crypto was patented in the US, and nowhere  
else, but the discrete log patents all expired in late '97, and the  
RSA patent in late '00. Add to this the zaniness of The Internet Boom.

The IETF as a whole decided in Munich in July '97 that all standards  
had to have discrete-log algorithms as MUST-implement algorithms,  
because of patent concerns. Just about everyone picked DSA for  
signing, but there was differences in ideas about what to pick for  
encryption.

OpenPGP is based on PGP 3, which already had been built using Elgamal  
keys. That was decided. Other protocols, which had been RSA-only,  
looked around for what to do. The S/MIME people picked X9.42.

Another factor in various discussions has been how to deal with  
certificate formats. It's pretty trivial to come up with an  
isomorphism between X.509 certs and OpenPGP certs for RSA keys.  
However, with OpenPGP using Elgamal, and S/MIME using X9.42, there  
was a difference. Consequently, to bridge any gap, we put in  
identifiers for X9.42 in OpenPGP, so that if they became popular, we  
could support them. As Peter Gutmann has said, it isn't clear that  
anyone ever used a single X9.42 key outside of interop testing. There  
aren't that many people using DSA certs, either. I don't think I've  
ever seen one in the wild. At PGP, we don't do any X.509/OpenPGP  
unification for discrete log keys. If you want that, you use RSA.

>
>> (I remember having a conversation with a rather baffled security  
>> application
>>  developer who wanted to see X9.42 in an S/MIME toolkit and just  
>> couldn't
>>  understand that although the spec had it as a MUST requirement,  
>> all the
>>  implementors knew that you should ignore it).
>>
>
> X9.42 may be flawed (is it?), but DH key agreement is one of the  
> strongest
> primitives in asymmetric cryptography.

There's nothing wrong with X9.42 technical. Its non-use (and DSA's)  
are all layer 8 and 9 issues.

     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 j93JcnJj059686; Mon, 3 Oct 2005 12:38:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j93JcnPM059683; Mon, 3 Oct 2005 12:38:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from srv224 (eva222.named1.com [69.31.86.150] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id j93JcmuP059620 for <[e-mail]>; Mon, 3 Oct 2005 12:38:48 -0700 (PDT) (envelope-from [e-mail])
Date: Mon, 3 Oct 2005 12:38:48 -0700 (PDT)
From: [e-mail]
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>

 	Received: from jpdtoisw (0.112.18.237)
	by srv224; Mon, 3 Oct 2005 12:38:48 -0700
Message-ID: <003801c47b9c$ed37f2bb$dd834d08@jpdtoisw>
Reply-To:  <[e-mail]>
From:  <[e-mail]>
To:  <[e-mail]>
Subject: HOMEMADE PETROL? YES!
Date: Mon, 3 Oct 2005 12:38:48 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_0037_01C44D08.DD83F2BB"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165

------=_NextPart_000_0037_01C44D08.DD83F2BB
Content-Type: text/plain;
        charset="windows-1251"
Content-Transfer-Encoding: quoted-printable



Hi!

Your mail is [e-mail]
Your  fax=20
Find OUT HOW to make PETROL FOR YOU CAR with the lowest losses or without t=
hem at all!
=A0
Have you ever heard about making the petrol on your own against buying that=
 at the filling station?
Ask your friends, neighbours or relatives.=20
They wouldn't believe in that!
I suggest you to make the high-octane gasoline for you automobile by yourse=
lf using the simple and cheap technology. This technology allows you to pro=
duce the petrol at home, garage, shed at any place you want.=20
You cut the losses essentially (up to 10 times) for using a personal car fo=
r life and business. Reduced the costs for transport charges in your busine=
ss you can pass ahead of your rivals essentially. You can afford yourself t=
o go to work not thinking about buying the petrol. You can go you relatives=
, friends living very far from you more often.=20
Costs for production 1 liter of high octane gasoline doesn't exceed 0,15 US=
D ! You can make up to 20 liters of high octane gasoline per hour. You need=
n't an expensive equipment and it is enough to have a school education. The=
 whole preparatory process doesn't take more than one week. After that you =
can make the petrol unlimited!
Read more www.petrol.7p.com

2 get ready

------=_NextPart_000_0037_01C44D08.DD83F2BB--




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 j939QAAn051702; Mon, 3 Oct 2005 02:26:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j939QAd1051701; Mon, 3 Oct 2005 02:26:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j939Q9Q1051690 for <[e-mail]>; Mon, 3 Oct 2005 02:26:09 -0700 (PDT) (envelope-from [e-mail])
Received: by zproxy.gmail.com with SMTP id 8so84338nzo for <[e-mail]>; Mon, 03 Oct 2005 02:26:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=e96cluUJR/0fubRO04ID2zqZtgkUGGjp4CkZIOaIEdPeDS5/1KFyjdqkPedkDSFU86aG2Gj9hiY+YhZconBLrH+i4kZfHyzyp3xwmkSRw8D+pIyvAuSr+Uu7l5fS6bIEKzXrQlItTTovMTkhyv1pV6aJTJwF9dztjk0xGgxiPzA=
Received: by 10.36.2.1 with SMTP id 1mr25498nzb; Mon, 03 Oct 2005 02:26:04 -0700 (PDT)
Received: by 10.36.222.9 with HTTP; Mon, 3 Oct 2005 02:26:03 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 3 Oct 2005 10:26:03 +0100
From: Rachel Willmer <[e-mail]>
Reply-To: Rachel Willmer <[e-mail]>
To: [e-mail]
Subject: WG Goals and Milestones
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j939Q9Q1051696
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>

Just looking at the IETF page for the working group
<http://www.ietf.org/html.charters/openpgp-charter.html>, and it has
the following under "Goals and Milestones"

Done            Submit PGP/MIME draft to IESG for consideration as
PROPOSED standard
May 01          Submit Multiple Sig draft to IESG for consideration as
PROPOSED standard
Jul 01          Begin RFC2440, PGP/MIME Interoperability testing
Aug 01          Request DRAFT status for RFC2440

Are those still the goals the WG is working towards, or are there some
other more up-to-date ones?

Rachel