Subject: private key language

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 28 Dec 2005 10:07:35 +0100

There's another issue I would like to see cleared up. Right now, I think the
private key format is overspecified. This is especially important, since the
format in the specification has known weaknesses.

I think, it should be ultimately up to each implementation how they store
private keys and it does not affect interoperability. It should be made
clear that private key packets are intended only as an export-import format
and that additional security measures (such as enclosing the whole thing
inside an integrity-protected encrypted packet) are recommended, when
transfering private keys.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 28 Dec 2005 09:12:44 -0500

> transfering private keys.

Section 3.6 (Keyrings) says:

   A keyring is a collection of one or more keys in a file or database.
   Traditionally, a keyring is simply a sequential list of keys, but
   may be any suitable database. It is beyond the scope of this
   standard to discuss the details of keyrings or other databases.

Doesn't that pretty much say what needs to be said?  It makes it clear
the standard isn't getting involved in local storage questions.

I don't know about recommending further protection on top of the
current secret key transport format.  It strikes me as something
individual implementations can decide on.  The standard doesn't forbid
it.

What weakness in the private key format are you referring to?

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 28 Dec 2005 16:17:40 +0100

> What weakness in the private key format are you referring to?

The Klima-Rosa attack: the private material is not bound cryptographically
to the public material, thus by changing the public material, the attacker
can reconstruct the private material from just one (corrupted) signature,
and forge that signature to cover up the attack.

Please read the Klima-Rosa paper (poor English, but good content), for more
details.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 28 Dec 2005 12:11:23 -0500

> Please read the Klima-Rosa paper (poor English, but good content), for more

Sure, I know about the Klima-Rosa attack, but I was under the
impression that the SHA-1 protected secret key format (S2K 254)
prevents the attack.  The text in 5.5.3. Secret Key Packet Formats
certainly says so:

  The reason for this is that there are some attacks on the private
  key that can undetectably modify the secret key. Using a SHA-1
  hash prevents this.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 28 Dec 2005 18:33:18 +0100

>   key that can undetectably modify the secret key. Using a SHA-1

No, this is, unfortunately, not the case, as only the secret material is
hashed. In the Klima-Rosa attack, the secret material is not touched; it is
the public matereial that is altered.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 28 Dec 2005 13:21:35 -0500

> the public matereial that is altered.

There is certainly some K-R exposure in modifying the secret key, as
that is what prompted the SHA-1 protected secret key format in the
first place.

It's a shame that the hash only covers the secret material and not the
copy of the public material in the secret key.

David

---

From: Jon Callas <[email-masked]>
Date: Wed, 28 Dec 2005 13:30:44 -0800

> the public matereial that is altered.

Not as I understand it.

The point of the Klima-Rosa attack is that you damage the private  
key, and persuade someone to sign something with the damaged key. You  
use that bogus signature to deduce things about the private key.

I don't understand how you can have an attack on signatures that  
involves only damaging the public key. That would mean that anyone  
can do this, as public keys are well, public.

However, it's been years since I've looked at this. As David Shaw  
said, the tag 254 s2k exists to handle this attack. If I'm missing  
something or have forgotten something, please explain it to me.

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 29 Dec 2005 00:23:50 +0100

Hi,

I think, I should explain the Klima-Rosa attack, because the original paper
is a bit difficult to understand.

It is slightly different for RSA and DSA keys, but the main idea is the
same. In both cases, the private material is an exponent and the public
material has the modulus of an exponentiation, the result of which is part
of the signature. The base of the exponentiation is different for RSA and
DSA (and ElGamal), but it is known in all cases.

Let's stick to the ElGamal example, for the sake of clarity (and because it
isn't covered elsewhere). The signature contains g^k mod p (k is a random
number), so if the attacker corrupts p and g such that discrete logarithms
mod p are easy to solve, he can work back k and from there, the secret x.
The point is that the secret material is revealed by using it in a modified
context.

Now, this attack can be thwarted by a lot of sanity checks on the private
key (e.g. checking that the private part indeed corresponds to the public
part), before outputting the signature, as is done by GPG, but it might be
expensive for less powerful computers/smartcards. If the public-private
binding were provided by the hash-based MDC, it would be a lot cheaper.

Stuff to read:
http://eprint.iacr.org/2002/076 (original paper)
http://www.orlingrabbe.com/DSAflaw_OpenPGP.htm (explaination and exploit code)

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Wed, 28 Dec 2005 15:36:11 -0800

> http://www.orlingrabbe.com/DSAflaw_OpenPGP.htm (explaination and  

Okay, so there isn't anything new here. We fixed this years ago.

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 29 Dec 2005 09:15:01 +0100

> Okay, so there isn't anything new here. We fixed this years ago.

No, we haven't. The public material can still be altered, unless some
expensive checks (like verifying the signature after it has been made) are
in place. Actually, the MDC at the end of the private material that does
not include the public part does exactly nothing against this attack.

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Dec 2005 15:13:19 -0800

Okay, I talked to Hal, and got things explained. The issue is that  
when you do a DSA signature, the signature not only uses the private  
component, but the public ones as well, and those aren't hashed. So  
the question is whether we do something, and if so, what. Here are  
some things I thought of:

* When we do a V5 key, it makes sense to hash (or even better, hmac)  
the entire public components as well as the private.

* This makes the problem better, but it doesn't solve it. For  
example, it would be reasonable for someone to get public components  
from the public key packets and only the private ones from the secret  
packets. In this case, integrity checks on the secret packets aren't  
sufficient.

* There must therefore be some security consideration note that calls  
out that implementations need to do consistency checks on keys,  
particularly when signing.

I propose that we improve the packets when we do V5, but put in the  
security consideration now. Does that sound reasonable?

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 30 Dec 2005 09:34:16 +0100

> security consideration now. Does that sound reasonable?

I agree that putting in the security consideration now is a reasonable thing
to do. As for the packet format, I would like to phase out encrypted private
key packets as such. Unencrypted private key packets encapsulated into
MDC-protected encrypted packets with an S2K in front of them does the job
and leaves us with one less format to maintain. I think, V5 should not have
an encrypted version at all.

-- 
Daniel

---

From: Ben Laurie <[email-masked]>
Date: Fri, 30 Dec 2005 12:42:50 +0000

> security consideration now. Does that sound reasonable?

Yes.

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

---

From: Ian G <[email-masked]>
Date: Fri, 30 Dec 2005 15:07:14 +0000

> security consideration now. Does that sound reasonable?

I agree.

iang

Date: Fri, 30 Dec 2005 15:07:14 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
Cc: "Daniel A. Nagy" <[email-masked]>, [email-masked]
Subject: Re: Short intro on the K-R attack [Re: private key language]
Sender: [email-masked]

> security consideration now. Does that sound reasonable?

I agree.

iang

Date: Fri, 30 Dec 2005 12:42:50 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: "Daniel A. Nagy" <[email-masked]>, [email-masked]
Subject: Re: Short intro on the K-R attack [Re: private key language]
Sender: [email-masked]

Yes.

Date: Fri, 30 Dec 2005 09:34:16 +0100
To: [email-masked]
Subject: Re: Short intro on the K-R attack [Re: private key language]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

-- 
Daniel

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Short intro on the K-R attack [Re: private key language]
Date: Thu, 29 Dec 2005 15:13:19 -0800
To: "Daniel A. Nagy" <[email-masked]>
Sender: [email-masked]

	Jon

Date: Thu, 29 Dec 2005 09:15:01 +0100
To: [email-masked]
Subject: Re: Short intro on the K-R attack [Re: private key language]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

-- 
Daniel

Date: Wed, 28 Dec 2005 23:01:13 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, Dec 28, 2005 at 01:34:56PM -0800, Jon Callas wrote:

> >Which is not to say I care passionately about reversability. I would,
> >however, like to remove the ambiguity.
> >
> >Can we say implementations SHOULD always add a newline, but they MAY
> >omit it if the plaintext ends with a newline (for backwards
> >compatibility)? That way nothing is broken, but future behaviour is  
> >defined.
> 
> I'm happy to make that change. In fact, I just did.

Forgive me, please, but I understood the rule before.  With this
change, I don't think I understand what is expected any longer.  Is
this added newline hashed into the signature?

Wouldn't "always" adding a newline cause text (with no line ending)
to become:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1

  text

  -----BEGIN PGP SIGNATURE-----
  xxxxxx
  -----END PGP SIGNATURE-----

and text\n (with a line ending) to become:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1

  text

  -----BEGIN PGP SIGNATURE-----
  xxxxxx
  -----END PGP SIGNATURE-----

If someone could post an example of what is now expected for "text"
and "text\n", I'd appreciate it.

GPG never adds a final newline to the hashed data, even if the
original document doesn't have one.  If there is a final newline in
the document, it is removed and not hashed into the signature.

Does this change to the draft make GPG noncompliant?

David

Date: Wed, 28 Dec 2005 19:24:54 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Some -15 text nits
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, Dec 28, 2005 at 02:17:45PM -0800, Jon Callas wrote:

> >In section 5.2.1. Signature Types, the signature class 0x18
> >description says "This signature is calculated directly on the subkey
> >itself, not on any User ID or other packets", but in fact 0x18
> >signatures are calculated on the primary key plus subkey.  Similarly,
> >the 0x19 description says "This signature is calculated directly on
> >the primary key itself, and not on any User ID or other packets", but
> >in reality it is calculated exactly the same way as 0x18 is
> >(primary+subkey).
> >
> >To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it
> >would still be nice to not give two different answers for this.
> >
> 
> fixed. Here's what they say now:
> 
>    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 primary key and subkey, not on any User ID or
>        other packets. A signature that binds a signing subkey MUST have
>        an embedded signature subpacket in this binding signature which
>        contains a 0x19 signature made by the signing subkey on the
>        primary key.
> 
>    0x19 Primary Key Binding Signature
>        This signature is a statement by a signing subkey, indicating
>        that it is owned by the primary key and subkey. This signature
>        is calculated directly on the primary key itself, and not on any
>        User ID or other packets.

Minor problem here: 0x19 hashes both the primary key and subkey.  It
is actually the same as 0x18.

David

To: [email-masked], [email-masked]
Subject: Re: Some -15 text nits
Cc: [email-masked]
Date: Wed, 28 Dec 2005 15:47:28 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Jon writes:
> fixed. Here's what they say now:
>
>     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 primary key and subkey, not on any User ID or
>         other packets. A signature that binds a signing subkey MUST have
>         an embedded signature subpacket in this binding signature which
>         contains a 0x19 signature made by the signing subkey on the
>         primary key.
>
>     0x19 Primary Key Binding Signature
>         This signature is a statement by a signing subkey, indicating
>         that it is owned by the primary key and subkey. This signature
>         is calculated directly on the primary key itself, and not on any
>         User ID or other packets.

This last sentence is not right.  Perhaps surprisingly, Primary Key Binding
Signatures (which are issued by subkeys) hash both the primary and subkey
packet bodies.

Hal

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Short intro on the K-R attack [Re: private key language]
Date: Wed, 28 Dec 2005 15:36:11 -0800
To: "Daniel A. Nagy" <[email-masked]>
Sender: [email-masked]

	Jon

Date: Thu, 29 Dec 2005 00:23:50 +0100
To: [email-masked]
Subject: Short intro on the K-R attack [Re: private key language]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

Hi,

Stuff to read:

-- 
Daniel

From: Jon Callas <[email-masked]>
Subject: Re: Some -15 comments
Date: Wed, 28 Dec 2005 14:25:04 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 15 Nov 2005, at 6:07 PM, Daniel A. Nagy wrote:

>
> On Tue, Nov 15, 2005 at 10:16:57AM -0800, "Hal Finney" wrote:
>
>> example imagine a signature which says, I am not vouching for the  
>> binding
>> between userid and key, but rather I am making a certain assertion  
>> about
>> this userid or key.  If we don't understand this notation the correct
>> thing is to ignore the signature, and that is in fact what the  
>> spec says
>> should happen.
>
> Yes, that is my understanding as well. Critical notation means that  
> it is
> essential for the correct interpretation of the signature and without
> understanding the notation the signature is meaningless.
>
>> Critical notations allow implementors to essentially extend signature
>> semantics beyond the official set of signature types.  We have a  
>> protected
>> namespace for proprietary extensions, and we have the ability for  
>> legacy
>> applications silently to ignore unrecognized extensions.  It's a good
>> feature.
>
> I agree.
>

In cleaning things up, I think I should say that despite discussions,  
I don't see anything in what Daniel, Ian, or Hal have said that I  
disagree with, and think we're in violent agreement.

	Jon

From: Jon Callas <[email-masked]>
Subject: Re: Some -15 comments
Date: Wed, 28 Dec 2005 14:19:55 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 30 Nov 2005, at 10:52 AM, Hal Finney wrote:

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

Okay, this now says:

    All undefined flags MUST be zero. Defined flags are:

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

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Some -15 text nits
Date: Wed, 28 Dec 2005 14:17:45 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 30 Nov 2005, at 8:13 AM, David Shaw wrote:

>
> These are just some fiddly language nits for -15.  Nothing terribly
> controversial I hope.
>
> ******
>
> The "IANA Considerations" section in the beginning of the draft
> contains this:
>
>  Instead requests to define new tag values (say for new encryption
>  algorithms for example) should be forwarded to the IESG Security Area
>  Directors for consideration or forwarding to the appropriate IETF
>  Working Group for consideration.
>
> "forwarded... or forwarding" doesn't parse very well.  I suggest:
>
>  Instead, requests to define new tag values (say for new encryption
>  algorithms) should be forwarded to the IESG Security Area Directors
>  or the appropriate IETF Working Group for consideration.
>

This was text given to me by the IESG. In general, I don't mess with  
such things until they tell me to mess with them.

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

changed

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

done

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

removed all uses of "pass phrase" (two words), making them one word.

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

I think you're right. Moved.

> ******
>
> In section 5.2.1. Signature Types, the signature class 0x18
> description says "This signature is calculated directly on the subkey
> itself, not on any User ID or other packets", but in fact 0x18
> signatures are calculated on the primary key plus subkey.  Similarly,
> the 0x19 description says "This signature is calculated directly on
> the primary key itself, and not on any User ID or other packets", but
> in reality it is calculated exactly the same way as 0x18 is
> (primary+subkey).
>
> To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it
> would still be nice to not give two different answers for this.
>

fixed. Here's what they say now:

    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 primary key and subkey, not on any User ID or
        other packets. A signature that binds a signing subkey MUST have
        an embedded signature subpacket in this binding signature which
        contains a 0x19 signature made by the signing subkey on the
        primary key.

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

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

All right, it appears to be unnecessary. Removed.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Some -15 text nits, part 2
Date: Wed, 28 Dec 2005 14:02:35 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 5 Dec 2005, at 11:32 AM, David Shaw wrote:

>
> Here is the second half of a -15 proofreading.  As before, these are
> just language nits, and should not have any functional significance.
> I did note a few items that might be considered functional, but I'm
> sending them in a different mail so as to not mix them up.  Many
> apologies for the late submission of these.
>
> *****
>
> 5.1. Public-Key Encrypted Session Key Packets says "Note that when an
> implementation forms several PKESKs with one session key, forming a
> message that can be decrypted by several keys, the implementation MUST
> make new PKCS-1 encoding for each key."
>
> This needs an "a", so as to read "...MUST make a new PKCS-1
> encoding..."
>

done.

> *****
>
> 5.2.3.3. Notes on Self-Signatures says "If the key is located by key
> ID, the algorithm of the primary User ID of the key provides the
> default symmetric algorithm."  Suggest changing "default" to
> "preferred", as preferred is the word used in all the other examples
> there.
>

done.

> *****
>
> 5.2.3.7. Preferred symmetric algorithms says "Algorithm numbers in
> section 9."  This should be "Algorithm numbers are in section 9."
> (i.e. add an "are").
>

done.

> *****
>
> 5.2.3.15. Revocation key mentions "1 octet of algid" in the
> definition.  Suggest "1 octet of PK algorithm ID" or similar as we
> never define "algid" in the document.

done.

>
> *****
>
> 5.2.3.23. Reason for Revocation has a sentence "Such a revocation
> SHOULD include an 0x20 subpacket."  Suggest changing this to "Such a
> revocation SHOULD include an 0x20 code." or similar.  0x20 in this
> case is not a subpacket, and the rest of this section refers to it as
> a "code".
>

done.

> *****
>
> 5.3. Symmetric-Key Encrypted Session Key Packets has two small
> formatting bugs.  The lines beginning "Zero or more Encrypted Session
> Key packets" and "The decryption result consists" are both indented
> an extra space.
>

done.

> *****
>
> 5.5.2. Public Key Packet Formats says:
>
>    V2 keys are identical to the deprecated V3 keys except for the
>    version number. An implementation MUST NOT generate them and may
>    accept or reject them as it sees fit.
>
> Suggest capitalizing the "may".
>

done.

> *****
>
> 5.5.3. Secret Key Packet Formats has the sentence "The reason for this
> is that there are some attacks on the private key that can
> undetectably modify the secret key".  That doesn't really parse well.
> Suggest "The reason for this is that there are some attacks that
> involve undetectably modifying the secret key".
>

done. (And apropos of other discussions, this is the fix for the  
Klima-Rosa attack, among others.)

> *****
>
> 5.6. Compressed Data Packet (Tag 8) has a note about ZIP and ZLIB,
> but not BZip2.  It might be good to add:
>
>    BZip2-compressed packets are compressed using the BZip2 algorithm.
>

done.

> *****
>
> 6.6. Example of an ASCII Armored Message says "Note that this example
> is indented by two spaces."  The example is, in fact, indented by
> three spaces, but even so should probably be indented by four spaces
> like the rest of the document.  (Hey, I did say these were nits).

Changed to:

Note that this example has extra indenting; an actual armored message  
would have no leading whitespace.

>
> *****
>
> 9.4. Hash Algorithms mentions MD5.  Suggest adding a reminder to this
> section that MD5 is deprecated.
>

done.

> *****
>
> 10.1. Transferable Public Keys has a paragraph beginning "After the
> User ID or Attribute packets there may be one or more Subkey packets."
> This should be "zero or more" Subkey packets, as is correctly stated a
> few paragraphs up from there.
>

done.

> In the same section, there is a paragraph beginning "Each Subkey
> packet must be followed by one Signature packet", there is a sentence
> "For subkeys that can issue signatures, the subkey binding signature
> must contain an embedded signature subpacket with a primary key
> binding signature (0x19) issued by the subkey on the top level key".
> Suggest capitalizing the MUST.

done. Both musts.

>
> *****
>
> In section 10.2. OpenPGP Messages, the paragraph beginning "In
> addition, decrypting a Symmetrically Encrypted Data Packet" has a
> blank line in the middle of the paragraph.
>

Not only did I fix this, but I removed all the places where a period  
was followed by two spaces so that we don't get more of them.

> *****
>
> Section 11.1. Key Structures says "A subkey always has a single
> signature after it that is issued using the primary key to tie the two
> keys together.  This binding signature may be in either V3 or V4
> format, but SHOULD be V4."  Suggest adding "Subkeys that can issue
> signatures must have a V4 binding signature due to the REQUIRED
> embedded primary key binding signature."
>

done, but made it MUST.

> *****
>
> 12.1. Symmetric Algorithm Preferences says "Since it is found on a
> self-signature, it is possible that a keyholder may have different
> preferences." Suggest adding the word "multiple" as in "... multiple
> different preferences."
>
> In the same section, in the last paragraph, suggest removing the
> parentheses around the Alice example.
>

done.

> *****
>
> Section 13. Security Considerations says:
>
>       * SHA384 requires the same work as SHA512. In general, there are
>         few reasons to use it -- you need a situation where one needs
>         more security than SHA256, but do not want to have the 512-bit
>         data length.
>
> "but do not want" should probably be "but does not want".

done

>
> *****
>
> 14. Implementation Nits says:
>
>       * PGP 2.6.X and 5.0 do not trim trailing whitespace from a
>         "canonical text" signature. They only remove it from cleartext
>         signatures. These signatures are not OpenPGP compliant --
>         OpenPGP requires trimming the whitespace. If you wish to
>         interoperate with PGP 2.6.X or PGP 5, you may wish to accept
>         these non-compliant signatures.
>
> This item is no longer needed as the draft no longer requires trimming
> whitespace from canonical text signatures.
>

removed

> *****
>
> In section 16. References (Normative), the reference to BZ2 points to
> <http://sources.redhat.com/bzip2>.  This is no longer correct, and
> should be <http://www.bzip.org/>.

done.

>
> *****
>
> In section 17. References (Non-Normative), some of the references are
> no longer referred to (BLEICHENBACHER, DONNERHACKE, RFC1983).  I'm not
> sure if this is a problem or not, as they are not normative anyway.
> Either way, I do suggest changing "Non-Normative" to "Informative" as
> that is the current recommended wording on rfc-editor.org.
>

I'm leaving them in. Changed to "Informative".

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Date: Wed, 28 Dec 2005 13:36:22 -0800
To: Ian G <[email-masked]>
Sender: [email-masked]

On 28 Dec 2005, at 4:59 AM, Ian G wrote:

> Suggested change from this (1st para, chapter 7):
>
>     It is desirable to sign a textual octet stream without ASCII
>     armoring the stream itself, so the signed text is still readable
>     without special software. In order to bind a signature to such a
>     cleartext, this framework is used.  (Note that RFC 3156 defines
>     another way to sign cleartext messages for environments that  
> support
>     MIME.)
>
> To this (changes are in the parenthesized Note):
>
>     It is desirable to sign a textual octet stream without ASCII
>     armoring the stream itself, so the signed text is still readable
>     without special software. In order to bind a signature to such a
>     cleartext, this framework is used.  (Note that this binding is not
>     intended to be reversible.  RFC 3156 defines another way to sign
>     cleartext messages for environments that support MIME.)
>
> Changes are in the parenthesized Note and amount to the insertion
> of the following CAPS:
>
>    Note that THIS BINDING IS NOT INTENDED TO BE REVERSIBLE.  RFC ...

I added that in, too.

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Date: Wed, 28 Dec 2005 13:34:56 -0800
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 28 Dec 2005, at 7:28 AM, Ben Laurie wrote:

> Jon Callas wrote:
>> (1) I don't think the spec should change. The reason that I don't  
>> think
>> it should change is that we're in last call. We want to tidy this  
>> thing
>> up.
>
> That's a crazy argument. If we're in last call and changes are needed,
> then what that tells us is we shouldn't be in last call, not that we
> shouldn't make changes!
>
>

But, Ben, that's precisely my argument. When you're in last call, you  
should either make only small changes or blow the thing up, and go  
back to a non-last-call state.

There are no huge problems in clearsigning. It works. It's been  
deployed for 15 years now, if we include pre-OpenPGP.

> Which is not to say I care passionately about reversability. I would,
> however, like to remove the ambiguity.
>
> Can we say implementations SHOULD always add a newline, but they MAY
> omit it if the plaintext ends with a newline (for backwards
> compatibility)? That way nothing is broken, but future behaviour is  
> defined.

I'm happy to make that change. In fact, I just did.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: private key language
Date: Wed, 28 Dec 2005 13:30:44 -0800
To: "Daniel A. Nagy" <[email-masked]>
Sender: [email-masked]

Not as I understand it.

	Jon

Date: Wed, 28 Dec 2005 13:21:35 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: private key language
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Wed, 28 Dec 2005 18:33:18 +0100
To: [email-masked]
Subject: Re: private key language
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

-- 
Daniel

Date: Wed, 28 Dec 2005 12:11:23 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: private key language
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Wed, 28 Dec 2005 15:28:15 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Jon Callas wrote:
> (1) I don't think the spec should change. The reason that I don't think
> it should change is that we're in last call. We want to tidy this thing
> up.

That's a crazy argument. If we're in last call and changes are needed,
then what that tells us is we shouldn't be in last call, not that we
shouldn't make changes!

This argument was used in DNSSEC to squash changes that are now coming
back with a vengeance years later. All that invoking "last call so don't
touch it" did was introduce about 5 years delay into the process.

Which is not to say I care passionately about reversability. I would,
however, like to remove the ambiguity.

Can we say implementations SHOULD always add a newline, but they MAY
omit it if the plaintext ends with a newline (for backwards
compatibility)? That way nothing is broken, but future behaviour is defined.

Date: Wed, 28 Dec 2005 16:17:40 +0100
To: [email-masked]
Subject: Re: private key language
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

-- 
Daniel

Date: Wed, 28 Dec 2005 09:12:44 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: private key language
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Wed, 28 Dec 2005 12:59:35 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Jon Callas wrote:
> 
> I have some general opinions about this issue.
> 
> (1) I don't think the spec should change.

> Now, then, I am not opposed to having a clarification in the spec.

> (2) I don't see how in the general case clearsigning can be a  
> reversible operation.

> ... Clearsigning is human-readable and that's the  
> whole point.

> (3) I am firmly against any tweak to the spec, including commentary,  
> that requires any implementation that's got versions past 1.0.1 to  have 
> to make a code or behavior change. It's far, far too late for that.

OK.

Suggested change from this (1st para, chapter 7):

     It is desirable to sign a textual octet stream without ASCII
     armoring the stream itself, so the signed text is still readable
     without special software. In order to bind a signature to such a
     cleartext, this framework is used.  (Note that RFC 3156 defines
     another way to sign cleartext messages for environments that support
     MIME.)

To this (changes are in the parenthesized Note):

     It is desirable to sign a textual octet stream without ASCII
     armoring the stream itself, so the signed text is still readable
     without special software. In order to bind a signature to such a
     cleartext, this framework is used.  (Note that this binding is not
     intended to be reversible.  RFC 3156 defines another way to sign
     cleartext messages for environments that support MIME.)

Changes are in the parenthesized Note and amount to the insertion
of the following CAPS:

    Note that THIS BINDING IS NOT INTENDED TO BE REVERSIBLE.  RFC ...

iang

Date: Wed, 28 Dec 2005 11:43:34 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
Cc: "Daniel A. Nagy" <[email-masked]>, [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:
> I don't think it is reasonable to expect interchange here.

I'm also of that view, mildly.  The purpose of
cleartext signing is so that we can pass around
signed documents and have them survive as such,
with a human-reachable import.

In my time using this feature with contracts, I
have never come across a case where interchange
/ reversibility is needed.  In fact, to me, it
is a nuisance that verification of the signature
causes a stripped file to be produced.

I'm scratching my head here and I can't quite see
it.  Can anyone?

> p.s. Incidentally, speaking of clear signed data, there are
> differences in practice in what trailing whitespace is removed.  Some
> programs remove space and tab.  Some programs remove only space.
> Currently, a trailing tab in a clearsigned document is an effective
> way to break interoperability.

Right.  Also there is UTF.  That's why we banged the
drum a while ago and got this inserted:

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

The characters to be removed are specified precisely.
If something is not removing tabs, then that's a bug.
A victory against high stress levels in developers.

iang

Date: Wed, 28 Dec 2005 10:07:35 +0100
To: OpenPGP <[email-masked]>
Subject: private key language
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

-- 
Daniel

Date: Wed, 28 Dec 2005 10:02:41 +0100
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

In my opinion, the spec is clear enough about how to verify clearsigned
messages and that is all that must be specified. I agree with Jon that it is
ultimately up to the applications how they pre-process the text to be
signed, as long as the human-readable part does not change (you sign what
you see).

I don't want to standardize either behavior: in my implementation
(ePointPGP) cleartext signatures are reversible and it is actually
important. I don't want the standard to declare me wrong. I don't want the
standard to declare widely used implementations such as GPG wrong either. I
regard it primarily as a back-end, and if someone wants to make reversible
clearsigned documents and be sure about it, it's still possible with
detached text signatures and perhaps some trivial pre-processing. The end
result can be put together as a clearsigned document. The behavior won't
change if Werner decides to tweak clearsigning a bit further in a future
version of GPG.

-- 
Daniel

From: Jon Callas <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Date: Tue, 27 Dec 2005 23:20:26 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I have some general opinions about this issue.

(1) I don't think the spec should change. The reason that I don't  
think it should change is that we're in last call. We want to tidy  
this thing up. Changes to the spec are most likely going to get  
something that is "right" but causes a decade of interoperability  
twists that we will "resolve" by declaring old versions to be bogus  
and the new behavior that no one does to be right. Then a half-dozen  
years from now, we'll go back to whatever it says now.

If you don't believe me, this is *exactly* what happened with the  
whole blank-trimming thing.

Now, then, I am not opposed to having a clarification in the spec.  
I'll merely allude to my standard comment that OpenPGP Formats is not  
a How To Write An OpenPGP Application which everyone's heard at least  
once. And yes, I know there's a big fat fuzzy grey line between  
clarifications and telling people how to code.

(2) I don't see how in the general case clearsigning can be a  
reversible operation. There are several reasons for this. We have a  
way to sign data reversibly. That is binary-mode signing. Binary-mode  
signing is not clearsigning. We also have an higher-level  
abstraction, text-mode signing. Text-mode signing is not, in the  
general case, reversible. The reason is that OpenPGP takes this  
abstract text object and then translates it into the native text  
format of the receiver's system. If one of us is on a unix box, and  
one of us is on Windows, then it's very difficult for us to talk  
about what the heck reversibility is. Ambiguities about text-mode are  
not new to OpenPGP. They date back at least as far as FTP, and they  
are a good thing, not a bad thing.

Clearsigning is an abstraction built on top of text mode that further  
abstracts the signature. Text-mode signing is not human-readable. It  
still involves packets. Clearsigning is human-readable and that's the  
whole point.

I believe that good human interaction is a better virtue than  
reversibility. Let me give an example.

Consider these three text files:

"a"     (the file containing the letter 'a')
"a\n"   (the file containing an 'a' and followed by a line-end)
"a\n\n" (the same, but with two line-ends)

If the first two look the same when clearsigned, this is not a bug,  
it's a feature. The point of clearsigning is that it be a pleasant  
experience for the user who wants to read the text, while making it  
so that a signature can be verified. I expect the third one to have  
one more blank line than the second one. I don't care how many more  
it has than the first one.

I'm on a unix system and if I 'more' each of the first two, they come  
out the same on my terminal. If I 'cat' them, they do not, and I  
believe that this is braindamaged, even if it is "right" and even  
after you explain to me in detail that it's "right." It may be right,  
but it's still braindamaged.

Whatever GnuPG, PGP, etc. are doing are okay. I see lots of  
clearsigned messages and nothing ever rubs my aesthetics the wrong  
way. The purpose of clearsigning is to make it easy to read by  
humans. Abstract properties like reversibility are secondary; if you  
want the thing to be reversible, then use a detached signature, for  
Pete's sake!

If there is some application out there that were to compress a  
zillion newlines into some reasonable number like one, two, or three  
in the output of a clearsigned message, then more power to them!  
There's nothing in OpenPGP that says you can't do that.

(3) I am firmly against any tweak to the spec, including commentary,  
that requires any implementation that's got versions past 1.0.1 to  
have to make a code or behavior change. It's far, far too late for that.

Whatever is out there is good enough. If we can make life easier for  
the likes of Ben and Rachel and other people who are making new  
systems, we should. But this should not burden any existing system  
one iota.

	Jon

Date: Tue, 27 Dec 2005 18:59:06 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Dec 27, 2005 at 02:29:44PM -0500, David Shaw wrote:
> On Tue, Dec 27, 2005 at 09:38:05AM -0800, "Hal Finney" wrote:
> > 
> > I'd suggest that clearsigning is aimed more at applications which will
> > present the signed document to users as it was received "on the wire",
> > so that they can read it usefully even with the signature in place.
> > For that purpose the important thing is to know exactly how the signature
> > will be verified so that signers can create valid documents.  I think
> > we agree that the spec is adequate for this purpose.
> > 
> > For data interchange, you want to start with a document on one machine
> > and sign or encrypt it, send it to another machine and verify/decrypt,
> > getting back the same document.  For that purpose the binary formats
> > work well.
> > 
> > The problem arises if you want to clearsign but still get data
> > interchange.  The sender needs to know not only how the data will get
> > verified, but also how it will be stored if the signature is stripped
> > away.  We didn't spec this because it didn't seem to fit that well into
> > the clearsign model, which is oriented around presenting data with the
> > signatures in place.
> 
> I think the concern is not so much that we need the ability to data
> interchange, but that there is a point of ambiguity in the standard
> such that
> 
>   Un-Clearsign ( Clearsign ( A ) ) != A
> 
> in some cases, specifically around the lack or presence of a line
> ending on the final line of A.

Okay, obviously I didn't express that well.  I didn't mean to say that
we don't need data interchange, but yet we do need data interchange.

What I'm trying to say is that we don't need full data interchange,
but it might be nice to fix (or even just document?) this particular
issue.  Given different implementations of end of line at end of
document, verifying a clearsigned document across implementations can
add or subtract blank lines at the end.

David

Date: Tue, 27 Dec 2005 17:25:32 -0500
From: David Shaw <[email-masked]>
To: "Daniel A. Nagy" <[email-masked]>
Cc: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: "Daniel A. Nagy" <[email-masked]>, [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Dec 27, 2005 at 10:27:16PM +0100, Daniel A. Nagy wrote:
> 
> On Tue, Dec 27, 2005 at 02:29:44PM -0500, David Shaw wrote:
> 
> > > The problem arises if you want to clearsign but still get data
> > > interchange.  The sender needs to know not only how the data will get
> > > verified, but also how it will be stored if the signature is stripped
> > > away.  We didn't spec this because it didn't seem to fit that well into
> > > the clearsign model, which is oriented around presenting data with the
> > > signatures in place.
> > 
> > I think the concern is not so much that we need the ability to data
> > interchange, but that there is a point of ambiguity in the standard
> > such that
> > 
> >   Un-Clearsign ( Clearsign ( A ) ) != A
> > 
> > in some cases, specifically around the lack or presence of a line
> > ending on the final line of A.
> 
> I think, clearsigned and one-pass signed text documents should work the
> same way. Data interchange AND human-readability together are worth
> pursuing. I think, it is perfectly reasonable to expect that
> 
> Canonize ( Un-Clearsign ( Clearsign ( A ) ) ) == Canonize ( A )

That is a much larger task than the current final-line-ending
question.  Canonical text for a literal packet type 't' and canonical
text for clear signing are not the same.

In a 't', line endings are converted to CRLF.  In a clear signature,
line endings are converted to CRLF and trailing whitespace is removed.
Thus, you can convert a clear signature to a signed 0x01 document, but
not necessarily from a signed 0x01 to a clearsigned document.

I don't think it is reasonable to expect interchange here.  If text
interchange is desired, then there is a form for that (literal 't').
Clear signed is intended for different situations where trailing
whitespace may well not survive transport - clear text
canonicalization is a lossy format because of this.  The fact that a
clear signed document can be converted to a signed 0x01 document is an
interesting curiosity, but not much more than that.

I have a mild interest in fixing the clearsign end-of-document
ambiguity, but I don't want to start changing the canonicalization
rules for either 't' or clear text.

David

p.s. Incidentally, speaking of clear signed data, there are
differences in practice in what trailing whitespace is removed.  Some
programs remove space and tab.  Some programs remove only space.
Currently, a trailing tab in a clearsigned document is an effective
way to break interoperability.

Date: Tue, 27 Dec 2005 22:27:16 +0100
To: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Tue, Dec 27, 2005 at 02:29:44PM -0500, David Shaw wrote:

> > The problem arises if you want to clearsign but still get data
> > interchange.  The sender needs to know not only how the data will get
> > verified, but also how it will be stored if the signature is stripped
> > away.  We didn't spec this because it didn't seem to fit that well into
> > the clearsign model, which is oriented around presenting data with the
> > signatures in place.
> 
> I think the concern is not so much that we need the ability to data
> interchange, but that there is a point of ambiguity in the standard
> such that
> 
>   Un-Clearsign ( Clearsign ( A ) ) != A
> 
> in some cases, specifically around the lack or presence of a line
> ending on the final line of A.

I think, clearsigned and one-pass signed text documents should work the
same way. Data interchange AND human-readability together are worth
pursuing. I think, it is perfectly reasonable to expect that

Canonize ( Un-Clearsign ( Clearsign ( A ) ) ) == Canonize ( A )

-- 
Daniel

Date: Tue, 27 Dec 2005 14:29:44 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Dec 27, 2005 at 09:38:05AM -0800, "Hal Finney" wrote:
> 
> I'd suggest that clearsigning is aimed more at applications which will
> present the signed document to users as it was received "on the wire",
> so that they can read it usefully even with the signature in place.
> For that purpose the important thing is to know exactly how the signature
> will be verified so that signers can create valid documents.  I think
> we agree that the spec is adequate for this purpose.
> 
> For data interchange, you want to start with a document on one machine
> and sign or encrypt it, send it to another machine and verify/decrypt,
> getting back the same document.  For that purpose the binary formats
> work well.
> 
> The problem arises if you want to clearsign but still get data
> interchange.  The sender needs to know not only how the data will get
> verified, but also how it will be stored if the signature is stripped
> away.  We didn't spec this because it didn't seem to fit that well into
> the clearsign model, which is oriented around presenting data with the
> signatures in place.

I think the concern is not so much that we need the ability to data
interchange, but that there is a point of ambiguity in the standard
such that

  Un-Clearsign ( Clearsign ( A ) ) != A

in some cases, specifically around the lack or presence of a line
ending on the final line of A.

David

Date: Tue, 27 Dec 2005 18:25:07 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Hi Hal,

that is fine;  in which case I'd just suggest
that the spec have a simple one liner in there
that suggests that the cleartext format is not
required to be reversible / for data interchange:

   An implementation MAY produce a signature-stripped
   version of the document, but the format is not
   intended for data interchange, and there are
   some minor artifacts such as with the terminating
   newline.

(Or something hopefully shorter.)

I admit I couldn't think of a case where we wanted
to reverse / interchange.  Still, the spec is less
than clear on this point, and for programmers who
don't follow all the background, a note would be
useful.

Whichever.  I really don't mind which way it goes,
but the spec isn't helpful here.  Programmers will
and do expect the cleartext signing format to be
reversable, and it isn't.

iang

Hal Finney wrote:
> I'd suggest that clearsigning is aimed more at applications which will
> present the signed document to users as it was received "on the wire",
> so that they can read it usefully even with the signature in place.
> For that purpose the important thing is to know exactly how the signature
> will be verified so that signers can create valid documents.  I think
> we agree that the spec is adequate for this purpose.
> 
> For data interchange, you want to start with a document on one machine
> and sign or encrypt it, send it to another machine and verify/decrypt,
> getting back the same document.  For that purpose the binary formats
> work well.
> 
> The problem arises if you want to clearsign but still get data
> interchange.  The sender needs to know not only how the data will get
> verified, but also how it will be stored if the signature is stripped
> away.  We didn't spec this because it didn't seem to fit that well into
> the clearsign model, which is oriented around presenting data with the
> signatures in place.
> 
> So what are the rules for storing a clearsigned message, with signature
> stripped away?  Would we just want to store the byte stream that
> was hashed (the portion of it that was from the message and not the
> signature bytes)?  Or would we want to switch to native line terminators
> when we store?  Would we strip or keep trailing whitespace when we store?
> 
> If we did spec this, it would then by implication tell a sender how
> to at least approximate data interchange.  Problems might arise if line
> terminators are getting changed.  And if we strip trailing whitespace when
> we store, then it would be impossible to send a document with trailing
> whitespace and have it be received that way.  OTOH the reason we strip
> trailing whitespace for verification is because some mail systems corrupt
> that part, so retaining trailing whitespace on store will not guarantee
> data interchange either.
> 
> In short, clearsigning is not really appropriate for data interchange
> because of how many ways the message could be corrupted in transit.
> 
> But if we do spec it, I would definitely NOT then put in the spec that
> a sender was FORCED to offer a data interchange option!  That is far,
> far outside anything we should be imposing on an implementation, in a
> data format spec.
> 
> Hal Finney
> 
> 

Date: Tue, 27 Dec 2005 18:25:38 +0000
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Hal Finney wrote:
> I'd suggest that clearsigning is aimed more at applications which will
> present the signed document to users as it was received "on the wire",
> so that they can read it usefully even with the signature in place.
> For that purpose the important thing is to know exactly how the signature
> will be verified so that signers can create valid documents.  I think
> we agree that the spec is adequate for this purpose.
> 
> For data interchange, you want to start with a document on one machine
> and sign or encrypt it, send it to another machine and verify/decrypt,
> getting back the same document.  For that purpose the binary formats
> work well.

Not for text documents. It seems to me that it is a reasonable
expectation that if I clearsign a text document, I should be able to
recover the document from the clear signature. Currently that isn't
possible with certainty.

I do not see the harm in fixing this issue.

To: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Date: Tue, 27 Dec 2005 09:38:05 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I'd suggest that clearsigning is aimed more at applications which will
present the signed document to users as it was received "on the wire",
so that they can read it usefully even with the signature in place.
For that purpose the important thing is to know exactly how the signature
will be verified so that signers can create valid documents.  I think
we agree that the spec is adequate for this purpose.

For data interchange, you want to start with a document on one machine
and sign or encrypt it, send it to another machine and verify/decrypt,
getting back the same document.  For that purpose the binary formats
work well.

The problem arises if you want to clearsign but still get data
interchange.  The sender needs to know not only how the data will get
verified, but also how it will be stored if the signature is stripped
away.  We didn't spec this because it didn't seem to fit that well into
the clearsign model, which is oriented around presenting data with the
signatures in place.

So what are the rules for storing a clearsigned message, with signature
stripped away?  Would we just want to store the byte stream that
was hashed (the portion of it that was from the message and not the
signature bytes)?  Or would we want to switch to native line terminators
when we store?  Would we strip or keep trailing whitespace when we store?

If we did spec this, it would then by implication tell a sender how
to at least approximate data interchange.  Problems might arise if line
terminators are getting changed.  And if we strip trailing whitespace when
we store, then it would be impossible to send a document with trailing
whitespace and have it be received that way.  OTOH the reason we strip
trailing whitespace for verification is because some mail systems corrupt
that part, so retaining trailing whitespace on store will not guarantee
data interchange either.

In short, clearsigning is not really appropriate for data interchange
because of how many ways the message could be corrupted in transit.

But if we do spec it, I would definitely NOT then put in the spec that
a sender was FORCED to offer a data interchange option!  That is far,
far outside anything we should be imposing on an implementation, in a
data format spec.

Hal Finney

Date: Tue, 27 Dec 2005 10:56:52 +0100
To: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Tue, Dec 27, 2005 at 09:09:02AM +0000, Ian G wrote:

> My results do not agree.  If there is no terminating
> newline, GPG adds it (as it must).  If there is a
> terminating line, GPG does not add one.  I'm using
> FreeBSD and 1.4.2.

Same with 1.4.1. and 1.4.2 on Linux and Cygwin

-- 
Daniel

Date: Tue, 27 Dec 2005 09:09:02 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Cc: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

[email-masked] wrote:
> i really can't see any bug in gnupg about this
> 
> gnupg clearsigns exactly what the user gives it
> 
> if the user gives it text with no empty line after it,
> then the signature block begins right after the text
> 
> if the user wants a blank line and includes the line return, 
> then gnupg signs after the empty line
> 
> they are *not* identical or interchangeable
> 
> here are two, one with the empty line, 
> and one without:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
>  test
>  
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)

My results do not agree.  If there is no terminating
newline, GPG adds it (as it must).  If there is a
terminating line, GPG does not add one.  I'm using
FreeBSD and 1.4.2.

iang

galland$ echo "test" > test
galland$ cat test
test
galland$ gpg -ats -u DSS3 test
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information

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

galland$ cat test.asc

test
galland$ cat test
test
galland$ echo -n "test" > test
galland$ cat test
galland$ gpg -ats -u DSS3 test
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information

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

File `test.asc' exists. Overwrite? (y/N) y
galland$ cat test.asc

test

Date: Tue, 27 Dec 2005 06:04:46 +0000
From: Ben Laurie <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

[email-masked] wrote:
> On Mon, 26 Dec 2005 13:32:13 -0800 "Daniel A. Nagy" 
> <[email-masked]> wrote:
>> On Mon, Dec 26, 2005 at 05:03:59PM +0000, Ben Laurie wrote:
>>
>>> I have just tested GPG yet again, and cleartext signatures of 
>> two files,
>>> one without a newline at the end, and one with, look identical:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> test
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.2 (FreeBSD)
>> Yepp, that's a bug in GPG and it does not follow from the spec. My
>> implementation does not do that. In my opinion, the correct 
>> behavior would
>> be reversible.
>> The output of gpg --clearsign should be identical to that 
>> converted from the
>> output of gpg -ts.
> 
> i really can't see any bug in gnupg about this
> 
> gnupg clearsigns exactly what the user gives it
> 
> if the user gives it text with no empty line after it,
> then the signature block begins right after the text
> 
> if the user wants a blank line and includes the line return, 
> then gnupg signs after the empty line

Not the version I'm using, as I've already stated, and in any case, my
issue is with clarity in the I-D.

Date: Mon, 26 Dec 2005 15:05:37 -0800
To: <[email-masked]>
Cc: 
Subject: Re: Outstanding question - rule on cleartext signing last line
From: <[email-masked]>
Sender: [email-masked]

On Mon, 26 Dec 2005 13:32:13 -0800 "Daniel A. Nagy" 
<[email-masked]> wrote:
>On Mon, Dec 26, 2005 at 05:03:59PM +0000, Ben Laurie wrote:
>
>> I have just tested GPG yet again, and cleartext signatures of 
>two files,
>> one without a newline at the end, and one with, look identical:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> test
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2 (FreeBSD)
>
>Yepp, that's a bug in GPG and it does not follow from the spec. My
>implementation does not do that. In my opinion, the correct 
>behavior would
>be reversible.
>The output of gpg --clearsign should be identical to that 
>converted from the
>output of gpg -ts.

i really can't see any bug in gnupg about this

gnupg clearsigns exactly what the user gives it

if the user gives it text with no empty line after it,
then the signature block begins right after the text

if the user wants a blank line and includes the line return, 
then gnupg signs after the empty line

they are *not* identical or interchangeable

here are two, one with the empty line, 
and one without:

 test

test

addition or subtraction of the empty line, invalidates the signature

and this is also true of all commandline pgp versions

vedaal

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

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

Date: Mon, 26 Dec 2005 22:32:13 +0100
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Mon, Dec 26, 2005 at 05:03:59PM +0000, Ben Laurie wrote:

> I have just tested GPG yet again, and cleartext signatures of two files,
> one without a newline at the end, and one with, look identical:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> test
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (FreeBSD)

Yepp, that's a bug in GPG and it does not follow from the spec. My
implementation does not do that. In my opinion, the correct behavior would
be reversible.
The output of gpg --clearsign should be identical to that converted from the
output of gpg -ts.

-- 
Daniel 

Date: Mon, 26 Dec 2005 15:19:26 -0500
From: David Shaw <[email-masked]>
To: Ian G <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: Ian G <[email-masked]>, OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Dec 26, 2005 at 05:29:01PM +0000, Ian G wrote:
> 
> David Shaw wrote:
> >As far as I can see, the current system is quite reversible.  For
> >example, given a document reading "this is a test" (no line ending,
> >and the last character in the file is the second t from test), here's
> >a clear signature:
> 
> OK, I understand all that.  But you've added
> a new rule:  on signing, always add the extra
> line ending.
> 
> And that's what we want to clarify - I don't
> think the spec says that.  It simply says that
> the last newline is not part of the signature.

Ok, now we're cooking: we agree.  I don't think the spec says that
either.  I am just saying that that behavior is consistent with the
spec, and (I say) a good thing to do, and (to me) follows naturally
from what the spec does say.  That said, GPG doesn't do it, and PGP
(at least the version I have here) does.

Both PGP and GPG are compliant with the spec as written.  If you add
this extra rule to enforce reversibility, GPG will become noncompliant
(fixable, but annoying), and many GPG-created signatures will become
noncompliant (a little more worrisome).

> Can we put that in the spec?  Here's what it
> says:
> 
>     As with binary signatures on text documents, a cleartext signature
>     is calculated on the text using canonical <CR><LF> line endings.
>     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>     SIGNATURE-----' line that terminates the signed text is not
>     considered part of the signed text.
> 
>     When reversing dash-escaping, an implementation MUST strip the
>     string "- " if it occurs at the beginning of a line, and SHOULD warn
>     on "-" and any character other than a space at the beginning of a
>     line.
> 
>     Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>     the end of any line is removed when the cleartext signature is
>     generated.
> 
> Here's what I suggest (changes at ***):
> 
>     As with binary signatures on text documents, a cleartext signature
>     is calculated on the text using canonical <CR><LF> line endings.
>     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>     SIGNATURE-----' line that terminates the signed text is not
> *** part of the signed document and SHOULD be added by implementations. ***
> 
>     When reversing dash-escaping, an implementation MUST strip the
>     string "- " if it occurs at the beginning of a line, and SHOULD warn
>     on "-" and any character other than a space at the beginning of a
>     line.
> 
>     Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
>     the end of any line is removed when the cleartext signature is
>     generated.
> 
> How's that?

I have no objection to that.

David

Date: Mon, 26 Dec 2005 17:29:01 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:
> As far as I can see, the current system is quite reversible.  For
> example, given a document reading "this is a test" (no line ending,
> and the last character in the file is the second t from test), here's
> a clear signature:

OK, I understand all that.  But you've added
a new rule:  on signing, always add the extra
line ending.

And that's what we want to clarify - I don't
think the spec says that.  It simply says that
the last newline is not part of the signature.

By all means, if that's what we agree on, then
we should simply state that in the spec:  always
add a newline on signing, always take it off
on reversing (verifying and stripping sig).

I'm happy with that rule - even though I don't
think that's what all implementations do.

> The final CRLF is not part of the document.  If a user/implementation
> wants a final CRLF in there that is part of the document, they need to
> add one.
> 
> Think of the "BEGIN PGP SIGNATURE" string as actually being
> "CRLF-----BEGIN PGP SIGNATURE".  It's part of the message structure
> and not part of the signed text.

Right that all makes perfect sense - to me.
Can we put that in the spec?  Here's what it
says:

     As with binary signatures on text documents, a cleartext signature
     is calculated on the text using canonical <CR><LF> line endings.
     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text is not
     considered part of the signed text.

     When reversing dash-escaping, an implementation MUST strip the
     string "- " if it occurs at the beginning of a line, and SHOULD warn
     on "-" and any character other than a space at the beginning of a
     line.

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

Here's what I suggest (changes at ***):

     As with binary signatures on text documents, a cleartext signature
     is calculated on the text using canonical <CR><LF> line endings.
     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text is not
*** part of the signed document and SHOULD be added by implementations. ***

     When reversing dash-escaping, an implementation MUST strip the
     string "- " if it occurs at the beginning of a line, and SHOULD warn
     on "-" and any character other than a space at the beginning of a
     line.

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

How's that?

iang

Date: Mon, 26 Dec 2005 17:05:40 +0000
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:
> On Mon, Dec 26, 2005 at 04:20:28PM +0000, Ian G wrote:
>> David Shaw wrote:
>>
>>> Can you give an example of why you feel this is a bug?
>> I think it is a bug if we decide that the
>> process of cleartext signing is reversable.
> 
> Can you please give an example of how the current system is not
> reversible?
> 
> As far as I can see, the current system is quite reversible.  For
> example, given a document reading "this is a test" (no line ending,
> and the last character in the file is the second t from test), here's
> a clear signature:
> 
> test  <<-----  There is a CRLF here, but it is NOT PART OF THE SIG

> Now given a document reading "this is a test<LINEENDING>", here's a
> clear signature:

test  <<----- There is a CRLF here and it IS PART OF THE SIG
<<-----  There is a CRLF here, but it is NOT PART OF THE SIG
-----BEGIN PGP SIGNATURE-----

blah blah blah
-----END PGP SIGNATURE-----

> In what way is this not reversible?

>> So, if the process of verification creates
>> a file that is the pre-signed version, then
>> it has to decide whether the final CRLF has
>> to be preserved or stripped in the unsigned
>> output.

> The final CRLF is not part of the document.  If a user/implementation
> wants a final CRLF in there that is part of the document, they need to
> add one.

> Think of the "BEGIN PGP SIGNATURE" string as actually being
> "CRLF-----BEGIN PGP SIGNATURE".  It's part of the message structure
> and not part of the signed text.

If that were what happened, I'd be happy. But it isn't.

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

Date: Mon, 26 Dec 2005 17:04:30 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:
> On Mon, Dec 26, 2005 at 12:29:15PM +0000, Ben Laurie wrote:
>> David Shaw wrote:
>>> On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
>>>> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
>>>>
>>>>> But I think we need to hear from the PGP Inc and GPG
>>>>> architects on this?
>>>> I recall that we tweaked gpg's behaviour in this regard until all
>>>> users were satisfied.  Thus I'd say not to add new requirement to the
>>>> specs.
>>> I agree.  I think the spec is just fine in this regard: the final CRLF
>>> (the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
>>> the signature.  That allows for the GPG behavior to preserve the
>>> presence or lack of line ending on the last line.
>> However, it doesn't. This strikes me as a bug both in GPG and in the spec.
> 
> Can you give an example of why you feel this is a bug?

Because information about the final character is lost.

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

Date: Mon, 26 Dec 2005 17:03:59 +0000
From: Ben Laurie <[email-masked]>
To: "Daniel A. Nagy" <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Daniel A. Nagy wrote:
> On Mon, Dec 26, 2005 at 12:29:15PM +0000, Ben Laurie wrote:
>> David Shaw wrote:
>>> On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
>>>> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
>>>>
>>>>> But I think we need to hear from the PGP Inc and GPG
>>>>> architects on this?
>>>> I recall that we tweaked gpg's behaviour in this regard until all
>>>> users were satisfied.  Thus I'd say not to add new requirement to the
>>>> specs.
>>> I agree.  I think the spec is just fine in this regard: the final CRLF
>>> (the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
>>> the signature.  That allows for the GPG behavior to preserve the
>>> presence or lack of line ending on the last line.
>> However, it doesn't. This strikes me as a bug both in GPG and in the spec.
> 
> Yes it does. GPG behaves slightly differently with messages entered from the
> console, but that makes a lot of sense, too. I don't see any bugs in either
> the specs and GPG. I have coded up my own OpenPGP implementation based on
> the spec (http://pgp.epointsystem.org/tool) and it interoperates perfectly
> with GPG.

I have just tested GPG yet again, and cleartext signatures of two files,
one without a newline at the end, and one with, look identical:

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

Cheers,

Ben.

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

Date: Mon, 26 Dec 2005 11:48:43 -0500
From: David Shaw <[email-masked]>
To: Ian G <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: Ian G <[email-masked]>, OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Dec 26, 2005 at 04:20:28PM +0000, Ian G wrote:

> So, does this output as a line terminated
> string or as an unterminated string? :
> 
>  -----BEGIN PGP SIGNED MESSAGE-----
> 
>  my signed text
>  -----BEGIN PGP SIGNATURE-----
>  xxxxx
>  -----END PGP SIGNATURE-----

Sorry, I did not answer this in my earlier mail.  This is output as an
unterminated string.  If you wanted it to be output as a terminated
string, you'd have generated this:

>  -----BEGIN PGP SIGNED MESSAGE-----
> 
>  my signed text
> 
>  -----BEGIN PGP SIGNATURE-----
>  xxxxx
>  -----END PGP SIGNATURE-----

Note the blank line between "my signed text" and the BEGIN PGP
SIGNATURE.

David

Date: Mon, 26 Dec 2005 11:39:08 -0500
From: David Shaw <[email-masked]>
To: Ian G <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: Ian G <[email-masked]>, OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Dec 26, 2005 at 04:20:28PM +0000, Ian G wrote:
> David Shaw wrote:
> 
> > Can you give an example of why you feel this is a bug?
> 
> I think it is a bug if we decide that the
> process of cleartext signing is reversable.

Can you please give an example of how the current system is not
reversible?

As far as I can see, the current system is quite reversible.  For
example, given a document reading "this is a test" (no line ending,
and the last character in the file is the second t from test), here's
a clear signature:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  test  <<-----  There is a CRLF here, but it is NOT PART OF THE SIG
  -----BEGIN PGP SIGNATURE-----

  blah blah blah
  -----END PGP SIGNATURE-----

Now given a document reading "this is a test<LINEENDING>", here's a
clear signature:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
 
  test  <<----- There is a CRLF here and it IS PART OF THE SIG
  <<-----  There is a CRLF here, but it is NOT PART OF THE SIG
  -----BEGIN PGP SIGNATURE-----

  blah blah blah
  -----END PGP SIGNATURE-----

In what way is this not reversible?

> So, if the process of verification creates
> a file that is the pre-signed version, then
> it has to decide whether the final CRLF has
> to be preserved or stripped in the unsigned
> output.

The final CRLF is not part of the document.  If a user/implementation
wants a final CRLF in there that is part of the document, they need to
add one.

Think of the "BEGIN PGP SIGNATURE" string as actually being
"CRLF-----BEGIN PGP SIGNATURE".  It's part of the message structure
and not part of the signed text.

David

Date: Mon, 26 Dec 2005 16:20:28 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:

> Can you give an example of why you feel this is a bug?

I think it is a bug if we decide that the
process of cleartext signing is reversable.

So, if the process of verification creates
a file that is the pre-signed version, then
it has to decide whether the final CRLF has
to be preserved or stripped in the unsigned
output.

So, does this output as a line terminated
string or as an unterminated string? :

-----BEGIN PGP SIGNED MESSAGE-----

my signed text

Now, if we decide that the process of signing
is not one that is deterministically reversable,
it is not an issue.  In practice, verification
is possibly all we need - and we have that.

(I have been unable to convince myself that we
need reversibility - I can't think of a case
where I would want it... but that's just me!)

iang

Date: Mon, 26 Dec 2005 10:36:15 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Dec 26, 2005 at 12:29:15PM +0000, Ben Laurie wrote:
> 
> David Shaw wrote:
> > On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
> >> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
> >>
> >>> But I think we need to hear from the PGP Inc and GPG
> >>> architects on this?
> >> I recall that we tweaked gpg's behaviour in this regard until all
> >> users were satisfied.  Thus I'd say not to add new requirement to the
> >> specs.
> > 
> > I agree.  I think the spec is just fine in this regard: the final CRLF
> > (the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
> > the signature.  That allows for the GPG behavior to preserve the
> > presence or lack of line ending on the last line.
> 
> However, it doesn't. This strikes me as a bug both in GPG and in the spec.

Can you give an example of why you feel this is a bug?

David

Date: Mon, 26 Dec 2005 14:43:04 +0100
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Mon, Dec 26, 2005 at 12:29:15PM +0000, Ben Laurie wrote:
> 
> David Shaw wrote:
> > On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
> >> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
> >>
> >>> But I think we need to hear from the PGP Inc and GPG
> >>> architects on this?
> >> I recall that we tweaked gpg's behaviour in this regard until all
> >> users were satisfied.  Thus I'd say not to add new requirement to the
> >> specs.
> > 
> > I agree.  I think the spec is just fine in this regard: the final CRLF
> > (the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
> > the signature.  That allows for the GPG behavior to preserve the
> > presence or lack of line ending on the last line.
> 
> However, it doesn't. This strikes me as a bug both in GPG and in the spec.

Yes it does. GPG behaves slightly differently with messages entered from the
console, but that makes a lot of sense, too. I don't see any bugs in either
the specs and GPG. I have coded up my own OpenPGP implementation based on
the spec (http://pgp.epointsystem.org/tool) and it interoperates perfectly
with GPG.

-- 
Daniel

Date: Mon, 26 Dec 2005 12:29:15 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

David Shaw wrote:
> On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
>> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
>>
>>> But I think we need to hear from the PGP Inc and GPG
>>> architects on this?
>> I recall that we tweaked gpg's behaviour in this regard until all
>> users were satisfied.  Thus I'd say not to add new requirement to the
>> specs.
> 
> I agree.  I think the spec is just fine in this regard: the final CRLF
> (the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
> the signature.  That allows for the GPG behavior to preserve the
> presence or lack of line ending on the last line.

However, it doesn't. This strikes me as a bug both in GPG and in the spec.

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

Date: Wed, 14 Dec 2005 08:56:09 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Secret key transport
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Well into comically late in the game here, but a question recently
came up about the secret key transport format.  Namely, is there one?
2440bis has a public key transport format (the whole of section 10.1),
and the format of secret key and secret subkey packets is defined, but
there doesn't seem to be an analogue to section 10.1 for secret keys.

For example, I've seen secret keys in this format:

 - Secret key packet
 - User ID packet
 - Selfsig on user ID
 - Secret subkey packet
 - Selfsig on subkey

I've also seen secret keys in this format:

 - Secret key packet
 - User ID packet
 - Secret subkey packet

 (i.e. missing the selfsigs).

The first example strikes me as preferable as there is a mild benefit
to having the secret key format parallel the public key format in that
an implementation can extract the public key from the secret key
automatically.  The second example requires a public key to be sent in
addition to the secret key to get the selfsigs (while the selfsig on
the user ID is optional, the one on the subkey isn't).

Either way, though, 2440bis seems silent on this subject.  Is this
something that needs a line or two of text?

David

Date: Thu, 8 Dec 2005 09:52:05 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
> 
> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
> 
> > But I think we need to hear from the PGP Inc and GPG
> > architects on this?
> 
> I recall that we tweaked gpg's behaviour in this regard until all
> users were satisfied.  Thus I'd say not to add new requirement to the
> specs.

I agree.  I think the spec is just fine in this regard: the final CRLF
(the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
the signature.  That allows for the GPG behavior to preserve the
presence or lack of line ending on the last line.

David

Date: Thu, 8 Dec 2005 13:49:54 +0100
To: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Thu, Dec 08, 2005 at 01:23:01PM +0100, Werner Koch wrote:
> On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:
> 
> > But I think we need to hear from the PGP Inc and GPG
> > architects on this?
> 
> I recall that we tweaked gpg's behaviour in this regard until all
> users were satisfied.  Thus I'd say not to add new requirement to the
> specs.

I, for one, like the way GPG behaves in this respect very much. Any change
to the spec that would make gpg's current behavior non-compliant should be
considered harmful, IMHO.

-- 
Daniel

Date: Thu, 8 Dec 2005 13:43:35 +0100
To: Ian G <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Thu, Dec 08, 2005 at 11:43:48AM +0000, Ian G wrote:

> So, what you are proposing is that when
> an unterminated message is signed:
> 
> -----BEGIN SIGNED MESSAGE-----
> 
> this message was signed unterminated
> -----BEGIN PGP SIGNATURE-----
> b1ab1a
> -----END PGP SIGNATURE-----
> 
> It recovers as "this message was signed unterminated"
> as it went in?  And then this becomes:
> 
> 
> -----BEGIN SIGNED MESSAGE-----
> 
> this message was already terminated
> 
> -----BEGIN PGP SIGNATURE-----
> b1ab1a
> -----END PGP SIGNATURE-----
> 
> which extracts as "this message was already terminated
> " (i.e., preserving its one newline).

Exactly.

-- 
Daniel

From: Werner Koch <[email-masked]>
To: Ian G <[email-masked]>
Cc: "Daniel A. Nagy" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Outstanding question - rule on cleartext signing last line
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 08 Dec 2005 13:23:01 +0100
Sender: [email-masked]

On Thu, 08 Dec 2005 11:43:48 +0000, Ian G said:

> But I think we need to hear from the PGP Inc and GPG
> architects on this?

I recall that we tweaked gpg's behaviour in this regard until all
users were satisfied.  Thus I'd say not to add new requirement to the
specs.

Salam-Shalom,

   Werner

Date: Thu, 08 Dec 2005 11:43:48 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: "Daniel A. Nagy" <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Outstanding question - rule on cleartext signing last line
Sender: [email-masked]

Daniel A. Nagy wrote:
> On Thu, Dec 08, 2005 at 09:52:52AM +0000, Ian G wrote:
> 
> 
>>(I never did see a resolution to that question?
>>What then was the rule on the last newline?)
> 
> 
> In order for the cleartext signed message to verify, there is no need to add
> another newline; the standard allows for text messages where the last line
> is not terminated. GPG actually REMOVES the last newline, if the input comes
> from the console, in order to allow for cleartext messages with an
> unterminated last line. I like this feature a lot.
> 
> If terminating the last newline is not required, then one-pass signed and
> clearsigned text messages can be converted back-and-forth without access to
> the secret key (or any cryptography, for that matter). I think this feature
> is worth preserving.
> 
> Thus, I propose not requiring the termination of the last line (and not
> terminating it automagically).

So, what you are proposing is that when
an unterminated message is signed:

-----BEGIN SIGNED MESSAGE-----

this message was signed unterminated

It recovers as "this message was signed unterminated"
as it went in?  And then this becomes:

-----BEGIN SIGNED MESSAGE-----

this message was already terminated

which extracts as "this message was already terminated
" (i.e., preserving its one newline).

OK, I'd be happy with that.  As long as it is a solid
rule.

But I think we need to hear from the PGP Inc and GPG
architects on this?

iang

Date: Thu, 8 Dec 2005 11:41:50 +0100
To: Ian G <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: [Fwd: [PGP-USERS] Word Wrap Problems with PGP 9.0.3]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Thu, Dec 08, 2005 at 09:52:52AM +0000, Ian G wrote:

> (I never did see a resolution to that question?
> What then was the rule on the last newline?)

In order for the cleartext signed message to verify, there is no need to add
another newline; the standard allows for text messages where the last line
is not terminated. GPG actually REMOVES the last newline, if the input comes
from the console, in order to allow for cleartext messages with an
unterminated last line. I like this feature a lot.

If terminating the last newline is not required, then one-pass signed and
clearsigned text messages can be converted back-and-forth without access to
the secret key (or any cryptography, for that matter). I think this feature
is worth preserving.

Thus, I propose not requiring the termination of the last line (and not
terminating it automagically).

-- 
Daniel

Date: Thu, 08 Dec 2005 09:52:52 +0000
From: Ian G <[email-masked]>
Organization: http://iang.org/
To: OpenPGP <[email-masked]>
Subject: [Fwd: [PGP-USERS] Word Wrap Problems with PGP 9.0.3]
Sender: [email-masked]

As a fascinating comment on the trickiness that
is cleartext signing, the below just popped up
on a user list.

Obviously, the app offers the useful feature of
reformatting the text according to some metric.
Just as obviously this goes way beyond the
discussion of whether the whitespace should be
stripped from the end, or whether the last
newline is added or imputed or stripped or
ignored...  and the text is likely no longer
comparable canonically or otherwise.

(I never did see a resolution to that question?
What then was the rule on the last newline?)

iang

-------- Original Message --------
Subject: [PGP-USERS] Word Wrap Problems with PGP 9.0.3
Date: Wed, 07 Dec 2005 22:25:34 -0700
From: Nick Andriash
Reply-To: [email-masked]
To: [email-masked]

I just purchased PGP Desktop Pro and am finding that when I go to clearsign
a message, PGP is actually re-flowing and/or word wrapping the text. I use
BeckyMail which is as close to a WYSIWYG Editor as there is. When I finish
typing my message or editing my reply, I used to simply clearsign the
message and send it... there was no word wrapping before signing, except with this latest version of PGP.

Does anyone know if or where the setting for that word wrap may be?

-- 
    ~~Nick Andriash~~
Courtenay, B.C. Canada

__________________________________________________________
  the PGP-USERS mailing list
Home Pg: cryptorights.org/pgp-users
Charter: www.cryptorights.org/lists/pgp-users/charter.html

From: Werner Koch <[email-masked]>
To: Holger Sesterhenn <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Charset for embedded filename?
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 06 Dec 2005 19:50:58 +0100
Sender: [email-masked]

On Tue, 06 Dec 2005 16:42:34 +0100, Holger Sesterhenn said:

> Is this filename (string) treated as UTF-8?

Yes:

3.4. Text

    Unless otherwise specified, the character set for text is the UTF-8
    [RFC2279] encoding of Unicode [ISO10646].

Shalom-Salam,

   Werner

Date: Tue, 06 Dec 2005 16:42:34 +0100
From: Holger Sesterhenn <[email-masked]>
Organization: Utimaco Safeware AG, NL Aachen
To: OpenPGP <[email-masked]>
Subject:  Charset for embedded filename?
Sender: [email-masked]

Hi,

draft 15 says in chapter 5.9. "Literal Data Packet (Tag 11)"

[...]
- File name as a string (one-octet length, followed by a file
    name). This may be a zero-length string. Commonly, if the source
    of the encrypted data is a file, this will be the name of the
    encrypted file. An implementation MAY consider the file name in
    the literal packet to be a more authoritative name than the
    actual file name.

[...]

Is this filename (string) treated as UTF-8?

How to convert special chars (e.g. German umlauts) if its not UTF-8?

-- 
Best Regards,

Holger Sesterhenn
---
Internet   http://www.utimaco.com/smgw

Date: Tue, 06 Dec 2005 11:00:04 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>, Ben Laurie <[email-masked]>
Subject: Re: -15 still not clear on signatures
Sender: [email-masked]

David Shaw wrote:
> On Mon, Dec 05, 2005 at 06:03:17PM -0500, David Shaw wrote:
>> On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:
> 
>>> b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length
>>> of the encoded message, emLen. emLen is not specified in -15. By
>>> inspection of existing signatures, it seems to me it is one less than
>>> the size of the modulus (which strikes me as theoretically wrong, but if
>>> that's the way it is, I guess that's the way it is).
>> I was under the impression that emLen was equal to the size of the
>> modulus.  I'm a bit confused with the two different descriptions of
>> EMSA-PKCS1-v1_5 (one in rfc-2437, and one in rfc-3447).  The leading
>> zero seems to have been added outside of EMSA-PKCS1-v1_5 in 2437 and
>> within it in 3447.
> 
> I did some digging and I think I see the problem here.  2440 and 1991
> correctly describe the encoding.  The instructions in 2440bis will not
> work as EMSA-PKCS1-v1_5 (the RFC-2437 version) is only part of the
> correct encoding.  The encoding is effectively to calculate
> EMSA-PKCS1-v1_5-ENCODE (m, emLen - 1) and then prefix the resulting
> octet string with a zero octet.  There is a similar situation with
> leading zeroes for EME-PKCS1-v1_5 for the encrypted session key
> packets.
> 
> To make things more complicated, EMSA-PKCS1-v1_5-ENCODE and
> EME-PKCS1-v1_5-ENCODE in RFC-3447 *are* the correct encodings, leading
> zero and all.
> 
> Since 3447 obsoletes 2437 anyway, maybe the easiest fix is to use 3447
> and add a note along the lines of "Use 3447 and not 2437 - we really
> mean it".

Assuming you are right about 3447 (I haven't checked it), then definitely.

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

Date: Tue, 06 Dec 2005 10:53:03 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>, Ben Laurie <[email-masked]>
Subject: Re: -15 still not clear on signatures
Sender: [email-masked]

David Shaw wrote:
> On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:
>> I was working on my signing code and realised that some issues
>> previously discussed do not appear to be resolved in -15 (its possible
>> some of these are also new).
>>
>> a) V4 signatures don't mention how one actually calculates the signature
>> - the text only appears for V3 signatures.
> 
> I'm not exactly sure what you mean here.  Isn't this stated in 5.2.4,
> in the paragraph beginning "Once the data body is hashed" ?

No, that tells you how to calculate the hash, not what you do with it
once you have calculated it. That is, padding, encryption, etc.

Cheers,

Ben.

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

Date: Mon, 5 Dec 2005 22:28:27 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>, Ben Laurie <[email-masked]>
Subject: Re: -15 still not clear on signatures
Mail-Followup-To: OpenPGP <[email-masked]>, Ben Laurie <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Dec 05, 2005 at 06:03:17PM -0500, David Shaw wrote:
> On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:

> > b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length
> > of the encoded message, emLen. emLen is not specified in -15. By
> > inspection of existing signatures, it seems to me it is one less than
> > the size of the modulus (which strikes me as theoretically wrong, but if
> > that's the way it is, I guess that's the way it is).
> 
> I was under the impression that emLen was equal to the size of the
> modulus.  I'm a bit confused with the two different descriptions of
> EMSA-PKCS1-v1_5 (one in rfc-2437, and one in rfc-3447).  The leading
> zero seems to have been added outside of EMSA-PKCS1-v1_5 in 2437 and
> within it in 3447.

I did some digging and I think I see the problem here.  2440 and 1991
correctly describe the encoding.  The instructions in 2440bis will not
work as EMSA-PKCS1-v1_5 (the RFC-2437 version) is only part of the
correct encoding.  The encoding is effectively to calculate
EMSA-PKCS1-v1_5-ENCODE (m, emLen - 1) and then prefix the resulting
octet string with a zero octet.  There is a similar situation with
leading zeroes for EME-PKCS1-v1_5 for the encrypted session key
packets.

To make things more complicated, EMSA-PKCS1-v1_5-ENCODE and
EME-PKCS1-v1_5-ENCODE in RFC-3447 *are* the correct encodings, leading
zero and all.

Since 3447 obsoletes 2437 anyway, maybe the easiest fix is to use 3447
and add a note along the lines of "Use 3447 and not 2437 - we really
mean it".

David

Date: Mon, 5 Dec 2005 18:03:17 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Cc: Ben Laurie <[email-masked]>
Subject: Re: -15 still not clear on signatures
Mail-Followup-To: OpenPGP <[email-masked]>, Ben Laurie <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:
> 
> I was working on my signing code and realised that some issues
> previously discussed do not appear to be resolved in -15 (its possible
> some of these are also new).
> 
> a) V4 signatures don't mention how one actually calculates the signature
> - the text only appears for V3 signatures.

I'm not exactly sure what you mean here.  Isn't this stated in 5.2.4,
in the paragraph beginning "Once the data body is hashed" ?

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

I was under the impression that emLen was equal to the size of the
modulus.  I'm a bit confused with the two different descriptions of
EMSA-PKCS1-v1_5 (one in rfc-2437, and one in rfc-3447).  The leading
zero seems to have been added outside of EMSA-PKCS1-v1_5 in 2437 and
within it in 3447.

David

Date: Mon, 5 Dec 2005 14:50:16 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Other -15 comments
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

I recently did a read-over of -15.  I've already sent the minor text
nits in other mail.  These are comments that rise (marginally) above
simple wording questions.  Much apologies for the late submission.

*****

5.5.2. Public Key Packet Formats says "Third, there are minor
weaknesses in the MD5 hash algorithm that make developers prefer other
algorithms."  Suggest dropping the word "minor".

*****

Section 5.5.2. Public Key Packet Formats says:

  V3 keys are deprecated; an implementation SHOULD NOT generate a V3
  key, but MAY accept it.

but section 11.1. Key Structures says:

  V3 keys are deprecated. Implementations MUST NOT generate new V3
  keys, but MAY continue to use existing ones.

These can't both be correct.  I lean towards MUST NOT here,
personally.

*****

The first two paragraphs in section 6.4. Decoding Radix-64 contradict
each other.  The first says that all non-radix-64 characters must be
ignored.  The second says that non-radix-64 characters probably
indicate a transmission error, "about which a warning message or even
a message rejection might be appropriate under some circumstances".

Suggest going with the second.

*****

David

Date: Mon, 5 Dec 2005 14:32:18 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Some -15 text nits, part 2
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Here is the second half of a -15 proofreading.  As before, these are
just language nits, and should not have any functional significance.
I did note a few items that might be considered functional, but I'm
sending them in a different mail so as to not mix them up.  Many
apologies for the late submission of these.

*****

5.1. Public-Key Encrypted Session Key Packets says "Note that when an
implementation forms several PKESKs with one session key, forming a
message that can be decrypted by several keys, the implementation MUST
make new PKCS-1 encoding for each key."

This needs an "a", so as to read "...MUST make a new PKCS-1
encoding..."

*****

5.2.3.3. Notes on Self-Signatures says "If the key is located by key
ID, the algorithm of the primary User ID of the key provides the
default symmetric algorithm."  Suggest changing "default" to
"preferred", as preferred is the word used in all the other examples
there.

*****

5.2.3.7. Preferred symmetric algorithms says "Algorithm numbers in
section 9."  This should be "Algorithm numbers are in section 9."
(i.e. add an "are").

*****

5.2.3.15. Revocation key mentions "1 octet of algid" in the
definition.  Suggest "1 octet of PK algorithm ID" or similar as we
never define "algid" in the document.

*****

5.2.3.23. Reason for Revocation has a sentence "Such a revocation
SHOULD include an 0x20 subpacket."  Suggest changing this to "Such a
revocation SHOULD include an 0x20 code." or similar.  0x20 in this
case is not a subpacket, and the rest of this section refers to it as
a "code".

*****

5.3. Symmetric-Key Encrypted Session Key Packets has two small
formatting bugs.  The lines beginning "Zero or more Encrypted Session
Key packets" and "The decryption result consists" are both indented
an extra space.

*****

5.5.2. Public Key Packet Formats says:

   V2 keys are identical to the deprecated V3 keys except for the
   version number. An implementation MUST NOT generate them and may
   accept or reject them as it sees fit.

Suggest capitalizing the "may".

*****

5.5.3. Secret Key Packet Formats has the sentence "The reason for this
is that there are some attacks on the private key that can
undetectably modify the secret key".  That doesn't really parse well.
Suggest "The reason for this is that there are some attacks that
involve undetectably modifying the secret key".

*****

5.6. Compressed Data Packet (Tag 8) has a note about ZIP and ZLIB,
but not BZip2.  It might be good to add:

   BZip2-compressed packets are compressed using the BZip2 algorithm.

*****

6.6. Example of an ASCII Armored Message says "Note that this example
is indented by two spaces."  The example is, in fact, indented by
three spaces, but even so should probably be indented by four spaces
like the rest of the document.  (Hey, I did say these were nits).

*****

9.4. Hash Algorithms mentions MD5.  Suggest adding a reminder to this
section that MD5 is deprecated.

*****

10.1. Transferable Public Keys has a paragraph beginning "After the
User ID or Attribute packets there may be one or more Subkey packets."
This should be "zero or more" Subkey packets, as is correctly stated a
few paragraphs up from there.

In the same section, there is a paragraph beginning "Each Subkey
packet must be followed by one Signature packet", there is a sentence
"For subkeys that can issue signatures, the subkey binding signature
must contain an embedded signature subpacket with a primary key
binding signature (0x19) issued by the subkey on the top level key".
Suggest capitalizing the MUST.

*****

In section 10.2. OpenPGP Messages, the paragraph beginning "In
addition, decrypting a Symmetrically Encrypted Data Packet" has a
blank line in the middle of the paragraph.

*****

Section 11.1. Key Structures says "A subkey always has a single
signature after it that is issued using the primary key to tie the two
keys together.  This binding signature may be in either V3 or V4
format, but SHOULD be V4."  Suggest adding "Subkeys that can issue
signatures must have a V4 binding signature due to the REQUIRED
embedded primary key binding signature."

*****

12.1. Symmetric Algorithm Preferences says "Since it is found on a
self-signature, it is possible that a keyholder may have different
preferences." Suggest adding the word "multiple" as in "... multiple
different preferences."

In the same section, in the last paragraph, suggest removing the
parentheses around the Alice example.

*****

Section 13. Security Considerations says:

      * SHA384 requires the same work as SHA512. In general, there are
        few reasons to use it -- you need a situation where one needs
        more security than SHA256, but do not want to have the 512-bit
        data length.

"but do not want" should probably be "but does not want".

*****

14. Implementation Nits says:

      * PGP 2.6.X and 5.0 do not trim trailing whitespace from a
        "canonical text" signature. They only remove it from cleartext
        signatures. These signatures are not OpenPGP compliant --
        OpenPGP requires trimming the whitespace. If you wish to
        interoperate with PGP 2.6.X or PGP 5, you may wish to accept
        these non-compliant signatures.

This item is no longer needed as the draft no longer requires trimming
whitespace from canonical text signatures.

*****

In section 16. References (Normative), the reference to BZ2 points to
<http://sources.redhat.com/bzip2>.  This is no longer correct, and
should be <http://www.bzip.org/>.

*****

In section 17. References (Non-Normative), some of the references are
no longer referred to (BLEICHENBACHER, DONNERHACKE, RFC1983).  I'm not
sure if this is a problem or not, as they are not normative anyway.
Either way, I do suggest changing "Non-Normative" to "Informative" as
that is the current recommended wording on rfc-editor.org.

David

Date: Thu, 01 Dec 2005 10:39:43 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: Some -15 comments
Sender: [email-masked]

David Shaw wrote:
> On Wed, Nov 16, 2005 at 03:07:20AM +0100, Daniel A. Nagy wrote:
> 
> 
>>As for the subject of our discussion, I think that we all agree that the
>>spec for 0x80 should be stripped of "a note from one person to another..."
>>bit., because one major implementation does not treat it that way.

Yes.

>>The only disagreement seems to be whether "a note from one person to
>>another" should be retained as an interoperable feature or should it be
>>delegated to private notation namespace.
>>
>>The disadvantage of the  latter approach would be that various implementers
>>would (possibly) implement this same semantics with a host of different
>>notation names and won't interoperate.
>>
>>Now, I can see that implementing the former using a type flag also causes
>>problems. Maybe, it should be a common, ITEF-namespace notation? Or an
>>entirely separate subpacket type akin to "reason for revocation"?

My view - it has to be outside the spec.  "a note
from one person to another" is a very high level
thing and we'll never be able to nail down what
it means.  And if we do, we then have to add all
the other variants like "a note from one person
to two persons..." "a note from the program to a
person..." "a note in XML..."

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

Removing that part, yes, I would agree.

iang

PS: point of order here - as we are in last
call, what are we "permitted" to change?  Only
completely wrong things?  Or is this flexible?

iang