Subject: OpenPGP mail/news header -02

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Oct 2005 11:11:56 +0100

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

[email-masked] 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

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: OpenPGP mail/news header -02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 31 Oct 2005 11:11:56 +0100
Sender: [email-masked]

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

[email-masked] 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

From: Simon Josefsson <[email-masked]>
To: Anand Kumria <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 31 Oct 2005 10:19:49 +0100
Sender: [email-masked]

Anand Kumria <[email-masked]> 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

To: [email-masked]
Subject: Calculation of signature in OpenPGP 
From: Peter Byldner <[email-masked]>
Date: Tue, 25 Oct 2005 09:44:27 +0200
Sender: [email-masked]

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_=--

Cc: <[email-masked]>
From: Jon Callas <[email-masked]>
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: "<[email-masked]>" <[email-masked]>
Sender: [email-masked]

On 14 Oct 2005, at 6:17 AM, <[email-masked]> <[email-masked]> 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

Date: Fri, 14 Oct 2005 06:17:26 -0700
To: <[email-masked]>
Cc: 
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT // empty line
From: <[email-masked]>
Sender: [email-masked]

On Wed, 12 Oct 2005 10:42:05 -0700 Jon Callas <[email-masked]> 
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

Date: Fri, 14 Oct 2005 06:08:28 -0700
To: <[email-masked]>
Cc: 
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: <[email-masked]>
Sender: [email-masked]

On Wed, 12 Oct 2005 06:06:40 -0700 "Daniel A. Nagy" 
<[email-masked]> 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

From: Derek Atkins <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Date: Thu, 13 Oct 2005 13:58:00 -0400
Sender: [email-masked]

Ben Laurie <[email-masked]> 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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Thu, 13 Oct 2005 09:39:19 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 21:21:16 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Sender: [email-masked]

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

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Human-readable notation language
Date: Wed, 12 Oct 2005 10:57:12 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

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
> [email-masked] 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

To: [email-masked], [email-masked]
Subject: Re: Human-readable notation language
Date: Wed, 12 Oct 2005 10:51:32 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

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
> [email-masked] 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

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
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 <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 12:04:34 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Human-readable notation language
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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
[email-masked] which are always human-readable, I
suggest this:

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

It's just simpler.

David

From: Derek Atkins <[email-masked]>
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Date: Wed, 12 Oct 2005 11:47:09 -0400
Sender: [email-masked]

David Shaw <[email-masked]> 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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

From: Derek Atkins <[email-masked]>
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Date: Wed, 12 Oct 2005 11:44:02 -0400
Sender: [email-masked]

<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 <[email-masked]> 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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Wed, 12 Oct 2005 17:35:39 +0200
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 17:31:30 +0200
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 11:13:08 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 11:10:16 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

From: "Brian G. Peterson" <[email-masked]>
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Date: Wed, 12 Oct 2005 09:50:32 -0500
Sender: [email-masked]

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

From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Signature calculation language
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 12 Oct 2005 15:55:09 +0200
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 15:06:40 +0200
To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 12:03:11 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Sender: [email-masked]

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.

Date: Wed, 12 Oct 2005 10:42:14 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 10:32:19 +0100
From: Ben Laurie <[email-masked]>
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 10:28:33 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Ian G <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Date: Wed, 12 Oct 2005 00:07:13 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 06:22:43 +0200
To: David Shaw <[email-masked]>, [email-masked]
Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 22:50:34 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature calculation language
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

From: Jon Callas <[email-masked]>
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Date: Tue, 11 Oct 2005 19:01:23 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 02:23:24 +0200
To: [email-masked]
Subject: Re: Signature calculation language
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 18:24:04 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

To: [email-masked], [email-masked]
Subject: Re: Signature calculation language
Date: Tue, 11 Oct 2005 15:25:00 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 18:11:27 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 22:39:52 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
Cc: Derek Atkins <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 22:21:34 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
Cc: Ben Laurie <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 17:03:39 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature calculation language
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

Cc: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
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 <[email-masked]>
Sender: [email-masked]

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

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Signature calculation language
Date: Tue, 11 Oct 2005 13:44:53 -0700
To: Hal Finney <[email-masked]>
Sender: [email-masked]

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

Cc: Ben Laurie <[email-masked]>, [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Cleartext Signatures
Date: Tue, 11 Oct 2005 13:26:38 -0700
To: Ian G <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 11 Oct 2005 16:23:09 -0400
From: Derek Atkins <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: WGLC for draft-ietf-openpgp-openpgp-15 ends Oct 28 1700EDT
Sender: [email-masked]

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 <[email-masked]> 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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: ISSUE: misleading hash instructions
Date: Tue, 11 Oct 2005 12:21:18 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 19:48:40 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

To: Ian G <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 10 Oct 2005 20:00:45 +0200
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 18:58:03 +0100
From: Ben Laurie <[email-masked]>
To: "Daniel A. Nagy" <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 17:58:04 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Werner Koch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 18:20:36 +0200
To: OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 16:21:39 +0100
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

Ian G wrote:
> 
> [email-masked] 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

Date: Mon, 10 Oct 2005 15:52:29 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Cc: [email-masked]
Subject: Re: Cleartext Signatures
Sender: [email-masked]

[email-masked] 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.

To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Cleartext Signatures
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 10 Oct 2005 16:45:37 +0200
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 15:30:29 +0100
From: Ben Laurie <[email-masked]>
To: "Daniel A. Nagy" <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 16:27:04 +0200
To: Ben Laurie <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Cleartext Signatures
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

Date: Mon, 10 Oct 2005 07:15:07 -0700
To: <[email-masked]>
Cc: 
Subject: Re: Cleartext Signatures
From: <[email-masked]>
Sender: [email-masked]

On Mon, 10 Oct 2005 03:43:05 -0700 Ben Laurie <[email-masked]> 
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

Date: Mon, 10 Oct 2005 11:43:05 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Cleartext Signatures
Sender: [email-masked]

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

Date: Fri, 7 Oct 2005 17:53:22 +0200
To: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Signature calculation language
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

To: [email-masked]
Subject: Signature calculation language
Date: Wed,  5 Oct 2005 14:11:58 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

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

Date: Tue, 4 Oct 2005 16:17:55 +0100
From: Rachel Willmer <[email-masked]>
Reply-To: Rachel Willmer <[email-masked]>
To: [email-masked]
Subject: Re: WG Goals and Milestones
Sender: [email-masked]

On 04/10/05, Jon Callas <[email-masked]> 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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Plausible deniability (a feature to think about)
Cc: [email-masked]
Date: Tue, 04 Oct 2005 15:49:07 +1300
Sender: [email-masked]

Jon Callas <[email-masked]> 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.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: WG Goals and Milestones
Date: Mon, 3 Oct 2005 16:46:17 -0700
To: Rachel Willmer <[email-masked]>
Sender: [email-masked]

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

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Plausible deniability (a feature to think about)
Date: Mon, 3 Oct 2005 16:43:09 -0700
To: "Daniel A. Nagy" <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 3 Oct 2005 12:38:48 -0700 (PDT)
From: [email-masked]
Sender: [email-masked]

 	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:  <[email-masked]>
From:  <[email-masked]>
To:  <[email-masked]>
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 [email-masked]
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--

Date: Mon, 3 Oct 2005 10:26:03 +0100
From: Rachel Willmer <[email-masked]>
Reply-To: Rachel Willmer <[email-masked]>
To: [email-masked]
Subject: WG Goals and Milestones
Sender: [email-masked]

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