Subject: Re: [ISSUE] End-of-line whitespace in 0x01 sigs

From: [email-masked]
Date: Wed, 31 Mar 2004 20:51:57 +0100

[two slight preferences for "no trimming whitespace for 0x01 sigs"]

> David Shaw wrote:
> Okay, so here's a proposal.  In section 5.2.1, the text currently
> reads:
>
>     0x01: Signature of a canonical text document.
>         This means the signer owns it, created it, or certifies that it
>         has not been modified.  The signature is calculated over the
>         text data with its line endings converted to <CR><LF> and
>         trailing spaces (0x020) and tabs (0x09) removed.
>
> I suggest:
>
>     0x01: Signature of a canonical text document.
>         This means the signer owns it, created it, or certifies that it
>         has not been modified.  The signature is calculated over the
>         text data with its line endings converted to <CR><LF>.
>
> This is the same as before but trailing whitespace is not removed.

I suggest that if there is to be a change, then there
might need to be some note reflecting that change.
Something like:

     0x01: Signature of a canonical text document.
         This means the signer owns it, created it, or certifies that it
         has not been modified.  The signature is calculated over the
         text data with its line endings converted to <CR><LF>.

         Note. Some non-conforming implementations may calculate over 
         canonical lines with trailing whitespace removed (spaces
         and tabs).

Also, some clarification as to how to deal with  
the programs out there:

         On verification, an implementation MAY retry using this
         format but SHOULD NOT sign with it.

All negotiable comments!

> Note that I'm only talking about 0x01 signatures here.  Cleartext
> signatures, and the trimming therein, should be unchanged by this.

Understood.

> Rationale: there are good reasons to do whitespace trimming for
> cleartext signatures (mail mangling, cut and paste mangling, etc).
> These reasons do not apply to an 0x01 signature as it is not cleartext
> - it is protected inside the binary or ascii armor shell.  In general,
> if we have no good reason to tamper with user supplied input, I think
> we should keep hands off.

I repeat my weak vote (in the sense that I
don't use such signatures so I have no real
vested interest or experience).  We need to
see what others say on this I suspect, as 2  
slight leanings doesn't a consensus make!

Also, I'd like to hear from Jon and Derik on whether
they are still asking for text proposals, I saw that
all the text and consensus over the last month for
cleartext signatures did not get used, and did not
see why.

iang

slight leanings doesn't a consensus make!

Also, I'd like to hear from Jon and Derik on whether
they are still asking for text proposals, I saw that
all the text and consensus over the last month for
cleartext signatures did not get used, and did not
see why.

iang

---

From: David Shaw <[email-masked]>
Date: Wed, 31 Mar 2004 20:25:20 -0500

> might need to be some note reflecting that change.

[..]

>          canonical lines with trailing whitespace removed (spaces

Rather than putting this here in section 5.2.1, put it in the
implementation notes section at the end (section 14):

     * Historically there has been some variability in end of line
       whitespace removal from cleartext signatures.  Specifically,
       some implementations do not count the tab character (0x09) as
       whitespace at the end of the line.  These signatures are not
       OpenPGP compliant, but MAY be accepted.

     * Earlier versions of this standard required removing end of line
       whitespace from 0x01 canonical text signatures.  This is no
       longer true, and such signatures are not OpenPGP compliant, but
       MAY be accepted.

David

Date: Wed, 31 Mar 2004 20:25:20 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: [ISSUE] End-of-line whitespace in 0x01 sigs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> might need to be some note reflecting that change.

[..]

>          canonical lines with trailing whitespace removed (spaces

Rather than putting this here in section 5.2.1, put it in the
implementation notes section at the end (section 14):

     * Historically there has been some variability in end of line
       whitespace removal from cleartext signatures.  Specifically,
       some implementations do not count the tab character (0x09) as
       whitespace at the end of the line.  These signatures are not
       OpenPGP compliant, but MAY be accepted.

     * Earlier versions of this standard required removing end of line
       whitespace from 0x01 canonical text signatures.  This is no
       longer true, and such signatures are not OpenPGP compliant, but
       MAY be accepted.

David

Date: Wed, 31 Mar 2004 20:13:26 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: [ISSUE] Signing things that aren't obvious how to hash
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 31, 2004 at 01:09:33PM -0800, Hal Finney wrote:
> 
> David Shaw writes:
> > Section 5.2.4 says:
> >
> >     The signature data is simple to compute for document signatures
> >     (types 0x00 and 0x01), for which the document itself is the data.
> >
> > How about:
> >
> >     The signature data is simple to compute for document signatures
> >     (types 0x00 and 0x01), for which the document itself is the data.
> >     When the document is not represented as a Literal Message, the
> >     entire OpenPGP Message is the data.  See section 10.2 for the
> >     formal definition of Literal and OpenPGP messages.
> 
> One comment, after helping many people over the years implement OpenPGP
> compliant code, I suggest we take out any claims in the document that
> any part of it is "simple".

Good point. ;)

The original "problem" here is that the grammar defines a particular
packet arrangement that the draft doesn't explain how to generate:

  Signature Packet, OpenPGP Message

and

  One-Pass Signature Packet, OpenPGP Message, Corresponding Signature
  Packet

The draft only specifies how to handle these cases where the "OpenPGP
Message" in question is really a "Literal Message".

I was suggesting to fix it by defining how to hash the OpenPGP
Message.  Rather than do that, though, why not just change the grammar
to explicitly say Literal Message?

No new functionality, less complexity.  Less is more.

David

Date: Wed, 31 Mar 2004 13:09:33 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [ISSUE] Signing things that aren't obvious how to hash
Sender: [email-masked]

David Shaw writes:
> Section 5.2.4 says:
>
>     The signature data is simple to compute for document signatures
>     (types 0x00 and 0x01), for which the document itself is the data.
>
> How about:
>
>     The signature data is simple to compute for document signatures
>     (types 0x00 and 0x01), for which the document itself is the data.
>     When the document is not represented as a Literal Message, the
>     entire OpenPGP Message is the data.  See section 10.2 for the
>     formal definition of Literal and OpenPGP messages.

One comment, after helping many people over the years implement OpenPGP
compliant code, I suggest we take out any claims in the document that
any part of it is "simple".

Hal

Date: Wed, 31 Mar 2004 20:51:57 +0100
From: [email-masked]
To: [email-masked]
Subject: Re: [ISSUE] End-of-line whitespace in 0x01 sigs
Sender: [email-masked]

All negotiable comments!

Understood.

iang

iang

Date: Tue, 30 Mar 2004 18:19:16 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] Signing things that aren't obvious how to hash
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Back in July of last year, we discussed what the right way to hash
such constructions as

  SIGNATURE + COMPRESSED(LITERAL)

Thus raising the question whether the signature is on the literal
packet, or the compressed packet that holds the literal packet.  It
seems that some software actually generates this.

Anyway, the answer (you hash the compressed packet) seemed to be
fairly uncontroversial, and so I'd like to suggest some language to
say so in 2440bis.

Section 5.2.4 says:

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

How about:

    The signature data is simple to compute for document signatures
    (types 0x00 and 0x01), for which the document itself is the data.
    When the document is not represented as a Literal Message, the
    entire OpenPGP Message is the data.  See section 10.2 for the
    formal definition of Literal and OpenPGP messages.

Does this introduce a problem with detached signatures?

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: whitespace  //  the 'program'
Date: Tue, 30 Mar 2004 14:36:06 -0800
To: <[email-masked]>
Sender: [email-masked]

> the source code programs written this way, can always be signed with
> a detached signature of the file itself,
>

Or signed in binary mode.

> but, just in case one 'did' want to clearsign such a page of code,
> would it be possible under the new open pgp whitespace specs?
>

No, and this isn't a bug, it's a feature.

	Jon

Date: Tue, 30 Mar 2004 14:25:00 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] End-of-line whitespace in 0x01 sigs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> David Shaw wrote:

[ i == no trimming whitespace for 0x01 sigs
  ii == trimming whitespace for 0x01 sigs ]

> >I would be perfectly content with either solution, with perhaps a
> >slight leaning towards (i) due to a desire to not mess with user
> >supplied input unless we have to.
> 
> 
> Right now, I'm inclined towards (i) myself as
> a signing implementation could warn whether
> there are trailing spaces, and a verifying
> implemetation could try to trim spaces as
> a fallback technique.

 
I suggest:

David

Date: Tue, 30 Mar 2004 01:22:18 +0100
From: [email-masked]
To: [email-masked]
Subject: Re: whitespace // the program
Sender: [email-masked]

> http://compsoc.dur.ac.uk/whitespace/index.php
> 
> the source code programs written this way, can always be signed with
> a detached signature of the file itself,
> 
> but, just in case one 'did' want to clearsign such a page of code,
> would it be possible under the new open pgp whitespace specs?

As the code there is *trying* to be difficult, I wouldn't
be so fussed if we get some inconsistent results.  White-
space stripping is not really a total answer to all needs,
it's just a simple compromise to try and catch the common
gremlins in transport systems.

Having said that, it would seem that, if the program that
was there (from a brief look) had been signed in clear-
text, then the sig would have "not travelled," as the
whitespace would have been ignored by the signature.  In
this case, the whitespace appeared at end of line, and was
highly significant.

So, I'd say that was a 'no,' it wouldn't be efficacious to
sign such code with the cleartext signing format.

YMMV!  Cute language though...

iang

Date: Mon, 29 Mar 2004 06:54:11 -0800
To: [email-masked]
Cc: 
Subject: whitespace  //  the 'program'
From: <[email-masked]>
Sender: [email-masked]

here is an interesting site about programs written entirely
with only whitespace characters,
(was brought up on the gnupg users list)

http://compsoc.dur.ac.uk/whitespace/index.php

the source code programs written this way, can always be signed with
a detached signature of the file itself,

but, just in case one 'did' want to clearsign such a page of code,
would it be possible under the new open pgp whitespace specs?

vedaal

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

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

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From: Jon Callas <[email-masked]>
Subject: Re: UTF-8 and literal packets
Date: Wed, 24 Mar 2004 15:03:34 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I would rather have the description in the RFC say what it means, 
rather than what to do with it. There are a number of reasons for that, 
chief among them that we don't have all the answers.

I'm working now on an OS with native support for umpteen character sets 
and encodings, one of which is UTF-8. There's a "Text Encoding" menu so 
I can select one should things not be displayed correctly. In my case, 
my MUA has the option of setting a property on the window as to what 
character set it is, and then it's all magically handled.

Let's also not forget that while OpenPGP gets used a whole lot for 
mail, it is an object security standard, not a mail security standard.

I can conceive of instances where whatever agent handles the text, it 
may know it's not UTF-8, but have no idea what it is, nor how to 
canonicalize. In that case, it should do the best job it can. I can 
also conceive of applications that may not have a good way to 
canonicalize, either. In any event, we are not wise enough to tell the 
implementer what to do.

What it means simply is that when you get such a literal packet, you 
know the text is in UTF-8. Do the right thing with said text. If you 
have a blob of text and you know it's not in UTF-8, then canonicalize, 
or use the 't' flag, or even use the 'b' flag.

	Jon

Date: Wed, 24 Mar 2004 14:49:39 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: UTF-8 and literal packets
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 24, 2004 at 09:38:50AM -0800, Hal Finney wrote:
> 
> Jon Callas writes:
> > We would like to have a modification to the literal packet, where there 
> > is a type 'u' packet which is identical to the type 't' packet except 
> > that in this packet the implementation is saying, "By gum, I *know* 
> > this really, really contains UTF-8 in it. Trust me. Really."
> 
> So how would we define appropriate behavior with respect to the
> 't' and 'u' packets, on receipt and on creation?  Are we deprecating
> 't' on creation, and we SHOULD use a 'u' (and UTF-8 of course)?
> And then on receipt, what should (or SHOULD) we do?

The way I look at it is that the rule for 't' is to take text and
canonicalize the line endings.  The rule for 'u' is to take text and
canonicalize the line endings and the encoding.  When receiving a
message of either sort, you decanonicalize, doing whatever is
appropriate for your platform.

If possible, use 'u'.  If you can't, whether for lack of information
on the original character set, or even just a minimal implementation
that doesn't have character set recoding ability, then use 't'.  't'
should not be deprecated.

David

Date: Wed, 24 Mar 2004 11:43:38 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: UTF-8 and literal packets
Sender: [email-masked]

Werner writes:
> I'd say don't deprecate anything, the 'u' is merely a flag that the
> message is for sure utf-8 encoded.  It's up to the MUA[1] to create
> and display a message correctly, that flag might be helpful.  Maybe a
> "If it is definitely known that the message is utf-8 encoded, the 'u'
> flag SHOULD be used."

I'm concerned that it's going to be hard to clearly specify when 't'
should be used and when 'u' should be, and likewise how to distinguish
the handling of 't' from 'u'.  Should 't' prompt the recipient to try
to guess what character set it is, i.e. prompt the user to choose
a charset?  That's going to make things inconvenient for all the old
't' encrypted files around.

And what about the problem with 'u' causing CRLF's to be left in files
when decrypted by legacy versions?  That would suggest that in at
least some cases (like plain ASCII text) it would be better to use 't'.
This is true even though plain ASCII is legal UTF-8 and so the rule you
suggest would suggest to use 'u'.

It's not that this is a bad idea, it's just that it's hard to codify
the unfortunately messy situation that we are in now.

Hal

To: "Hal Finney" <[email-masked]>
Cc: [email-masked]
Subject: Re: UTF-8 and literal packets
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 24 Mar 2004 20:08:40 +0100
Sender: [email-masked]

On Wed, 24 Mar 2004 09:38:50 -0800, Hal Finney said:

> 't' and 'u' packets, on receipt and on creation?  Are we deprecating
> 't' on creation, and we SHOULD use a 'u' (and UTF-8 of course)?
> And then on receipt, what should (or SHOULD) we do?

I'd say don't deprecate anything, the 'u' is merely a flag that the
message is for sure utf-8 encoded.  It's up to the MUA[1] to create
and display a message correctly, that flag might be helpful.  Maybe a
"If it is definitely known that the message is utf-8 encoded, the 'u'
flag SHOULD be used."

  Werner

[1] or better up to the text editor or whatever OpenPGP aware
    application, as MUAs should use PGP/MIME

Date: Wed, 24 Mar 2004 09:38:50 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: UTF-8 and literal packets
Sender: [email-masked]

Jon Callas writes:
> We would like to have a modification to the literal packet, where there 
> is a type 'u' packet which is identical to the type 't' packet except 
> that in this packet the implementation is saying, "By gum, I *know* 
> this really, really contains UTF-8 in it. Trust me. Really."

So how would we define appropriate behavior with respect to the
't' and 'u' packets, on receipt and on creation?  Are we deprecating
't' on creation, and we SHOULD use a 'u' (and UTF-8 of course)?
And then on receipt, what should (or SHOULD) we do?

Hal

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] A collection of fussy language nits
Date: Tue, 23 Mar 2004 10:55:59 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 22 Mar, 2004, at 9:07 AM, David Shaw wrote:

>
> Here's a small collection of language and wording nits for bis-10.
> None of these should have any operational consequences.
>
> David
>
> ##############
>
> Section 2.5 (Signature-Only Applications) misspells "non-conformant"
> as "non-comformant".
>

Done.

> ##############
>
> Section 5.2.3.23 (Reason for Revocation) refers to a User ID in one
> spot as a "User id".  "id" should be capitalized like everywhere else
> in the document.
>

Done.

> ##############
>
> Section 5.2.4 (Computing Signatures), and section 10.1 (Transferable
> Public Keys) need the word "type" inside the parentheses with the
> number 0x19.  This is to be consistent with other examples.
>

Done.

> ##############
>
> Section 5.5.3 (Secret Key Packet Formats) in the sentence:
>
>       - [Optional] If secret data is encrypted (string-to-key usage
>         octet not zero), Initial Vector (IV) of the same length as the
>         cipher's block size.
>
> needs an "an" before "Initial Vector".
>

Done.

> ##############
>
> Throughout the document, the expansion of MPI is "multi-precision
> integer" around half the time, and "multiprecision integer" the other
> half (minus the hyphen).  Similarly, "Triple-DES" is occasionally
> "TripleDES".  I have no strong feeling which spelling is better, but
> we should be consistent.
>

I picked "multiprecision" and "TripleDES".

> ##############
>
> Section 4.2.3 (Packet Length Examples) has the following paragraph:
>
>     An implementation MAY use Partial Body Lengths for data packets,
>     be they literal, compressed, or encrypted. The first partial
>     length MUST be at least 512 octets long. Partial Body Lengths MUST
>     NOT be used for any other packet types.
>
> I believe this paragraph should be moved one section up to section
> 4.2.2.4 (Partial Body Lengths) as 4.2.2.4 is where partial body
> lengths are actually defined and 4.2.3 is just examples.
>
>

Done.

	Jon

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: UTF-8 and literal packets
Date: Tue, 23 Mar 2004 07:09:22 -0800
Sender: [email-masked]

[Editor hat off, representative of implementer hat on]

We at PGP have been talking with David Shaw about an issue we're having 
with UTF-8. The problem is that there are a number of times where 
someone takes text that is not UTF-8, but something like 8859-n, passes 
it into either GnuPG or PGP, sends it to the other, and then we end up 
displaying it wrong. Abstractly, this is not a problem that can be 
solved entirely. Heck, both my mailer and my web browser have menus 
where I can select what character set/encoding to assume something is 
in.

We would like to have a modification to the literal packet, where there 
is a type 'u' packet which is identical to the type 't' packet except 
that in this packet the implementation is saying, "By gum, I *know* 
this really, really contains UTF-8 in it. Trust me. Really."

We've already tested this and both GnuPG and PGP handle a literal 'u' 
packet like 'b', which only has the potential drawback of artifically 
CRLF endings. This gives us a way, however, to get proper layering in 
the sort of systems that we interact with.

Any objections?

	Jon

Date: Mon, 22 Mar 2004 12:07:04 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] A collection of fussy language nits
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Here's a small collection of language and wording nits for bis-10.
None of these should have any operational consequences.

David

##############

Section 2.5 (Signature-Only Applications) misspells "non-conformant"
as "non-comformant".

##############

Section 5.2.3.23 (Reason for Revocation) refers to a User ID in one
spot as a "User id".  "id" should be capitalized like everywhere else
in the document.

##############

Section 5.2.4 (Computing Signatures), and section 10.1 (Transferable
Public Keys) need the word "type" inside the parentheses with the
number 0x19.  This is to be consistent with other examples.

##############

Section 5.5.3 (Secret Key Packet Formats) in the sentence:

      - [Optional] If secret data is encrypted (string-to-key usage
        octet not zero), Initial Vector (IV) of the same length as the
        cipher's block size.

needs an "an" before "Initial Vector".

##############

Throughout the document, the expansion of MPI is "multi-precision
integer" around half the time, and "multiprecision integer" the other
half (minus the hyphen).  Similarly, "Triple-DES" is occasionally
"TripleDES".  I have no strong feeling which spelling is better, but
we should be consistent.

##############

Section 4.2.3 (Packet Length Examples) has the following paragraph:

    An implementation MAY use Partial Body Lengths for data packets,
    be they literal, compressed, or encrypted. The first partial
    length MUST be at least 512 octets long. Partial Body Lengths MUST
    NOT be used for any other packet types.

I believe this paragraph should be moved one section up to section
4.2.2.4 (Partial Body Lengths) as 4.2.2.4 is where partial body
lengths are actually defined and 4.2.3 is just examples.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] User attribute language problem
Date: Mon, 22 Mar 2004 08:43:29 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 19 Mar, 2004, at 5:58 PM, David Shaw wrote:

>
> Very minor problem here in section 5.12 (the User Attribute Packet).
> The first sentence in that section is:
>
>     The User Attribute packet is a variation of the User ID packet.
>     It is capable of storing more types of data than the User ID
>     packet which is (by convention) limited to text.
>
> The parenthetical "(by convention)" should be removed as it is no
> longer true.  User IDs are required to be text.
>
> David
>
>

Fixed in -11.

	Jon

Date: Fri, 19 Mar 2004 20:58:16 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] User attribute language problem
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Very minor problem here in section 5.12 (the User Attribute Packet).
The first sentence in that section is:

    The User Attribute packet is a variation of the User ID packet.
    It is capable of storing more types of data than the User ID
    packet which is (by convention) limited to text.

The parenthetical "(by convention)" should be removed as it is no
longer true.  User IDs are required to be text.

David

To: "Weins, Thorsten" <[email-masked]>
Cc: "Hal Finney" <[email-masked]>, <[email-masked]>
Subject: Re: AW: Loading FR in CFB mode
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 19 Mar 2004 10:59:05 +0100
Sender: [email-masked]

On Fri, 19 Mar 2004 09:19:37 +0100, Weins, Thorsten said:

> I have encountered this problem while trying to use a RSA-Key which has been created using PGP 8.0 with our OpenPGP implementation. The secret key is encrypted with AES256 and the IV which is part of the secret key packet is only 8 Bytes long. How can the problem be handled?

That might be a bug in PGP.  You need to explictly track the length of
the IV like:

	    switch( sk->protect.algo ) {
	      case 7: case 8: case 9: /* reserved for AES */
	      case 10: /* Twofish */
		sk->protect.ivlen = 16;
		break;
	      default:
		sk->protect.ivlen = 8;
	    }

IIRC, I once checked with Hal that Twofish worked for both GnuPG and
PGP.

  Werner

content-class: urn:content-classes:message
Subject: AW: Loading FR in CFB mode
Date: Fri, 19 Mar 2004 09:19:37 +0100
From: "Weins, Thorsten" <[email-masked]>
To: "Hal Finney" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I have encountered this problem while trying to use a RSA-Key which has been created using PGP 8.0 with our OpenPGP implementation. The secret key is encrypted with AES256 and the IV which is part of the secret key packet is only 8 Bytes long. How can the problem be handled?

Thorsten Weins

-----Ursprüngliche Nachricht-----
Von: Hal Finney [mailto:[email-masked]] 
Gesendet: Donnerstag, 18. März 2004 18:48
An: [email-masked]; Weins, Thorsten
Betreff: Re: Loading FR in CFB mode

Thorsten writes:
> can anybody tell me how to load the FR in CFB mode (not PGP CFB mode!) 
> when the BS is 16 Bytes (e.g. when using AES256) but the IV only 
> consists of 8 Bytes.

I assume this is not an OpenPGP question, right?

There is no right answer to this.  The IV should normally be the same size as the block size.  If you are using a non-standard, smaller IV then you must have an agreement among all participants about how you will handle it.

Hal Finney

Date: Thu, 18 Mar 2004 09:48:18 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Loading FR in CFB mode
Sender: [email-masked]

Thorsten writes:
> can anybody tell me how to load the FR in CFB mode (not PGP CFB mode!)
> when the BS is 16 Bytes (e.g. when using AES256) but the IV only
> consists of 8 Bytes.

I assume this is not an OpenPGP question, right?

There is no right answer to this.  The IV should normally be the same
size as the block size.  If you are using a non-standard, smaller IV
then you must have an agreement among all participants about how you
will handle it.

Hal Finney

Date: Thu, 18 Mar 2004 08:54:58 -0800
To: [email-masked]
Cc: 
Subject: suggested text for Public Subkey Packet section
From: <[email-masked]>
Sender: [email-masked]

in the just released draft,
the section about public subkeys reads as follows:

=================[ begin quote ]======================================

5.5.1.2. Public Subkey Packet (Tag 14)

    A Public Subkey packet (tag 14) has exactly the same format as a
    Public Key packet, but denotes a subkey. One or more subkeys may
be
    associated with a top-level key.  By convention, the top-level key
    provides signature services, and the subkeys provide encryption
    services.

==================[ end quote ]=======================================

suggested additional text:

"Implementations MAY generate subkeys that can sign only, can encrypt
only, or can both sign and encrypt. Implementations SHOULD recognize
signatures from a signing subkey."

Also, 
is this a good place to include the issue of signatures linking the subkey
to the master key and master key to the subkey?

with Respect,

vedaal

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

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

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

content-class: urn:content-classes:message
Subject: Loading FR in CFB mode
Date: Thu, 18 Mar 2004 17:49:14 +0100
From: "Weins, Thorsten" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hello,

can anybody tell me how to load the FR in CFB mode (not PGP CFB mode!)
when the BS is 16 Bytes (e.g. when using AES256) but the IV only
consists of 8 Bytes.

Thanks in advance,

Thorsten

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-10.txt
Date: Thu, 18 Mar 2004 09:48:22 -0500
Sender: [email-masked]

--NextPart

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

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-10.txt
	Pages		: 72
	Date		: 2004-3-17
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Packets sequences
Cc: [email-masked]
Date: Thu, 18 Mar 2004 19:00:17 +1300
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

>>If there's some reason for this, could the RFC include some text explaining
>>it or discourage people from using it?
>
>The background is in the archives here.

So that's the explanatory text for the RFC?

In any case the mail archive contents, "Error code 404 Access denied, or file
does not exist", aren't entirely illuminating about the reason for multiple
literal packets.  Posting the relevant text would be helpful.

Peter.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Packets sequences
Date: Wed, 17 Mar 2004 17:53:30 -0800
To: [email-masked] (Peter Gutmann)
Sender: [email-masked]

> That'd work, although there's still the current special-case of 
> allowing a
> string of literal packets.  Is there any reason for this?  My code 
> doesn't
> handle this, but that's because it never occurred to me that anyone 
> would ever
> construct a packet like that.  It seems to be a clunky way to do
> indeterminate-length packets (use a sequence of literal packets rather 
> than a
> single literal packet with indeterminate-length chunks).  If there's 
> some
> reason for this, could the RFC include some text explaining it or 
> discourage
> people from using it?
>

The background is in the archives here.

	Jon

Date: Wed, 17 Mar 2004 13:55:08 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
CC: David Shaw <[email-masked]>
Subject: Re: Let's resolve the end-of-line and whitespace question
Sender: [email-masked]

David Shaw wrote:
> On Wed, Mar 17, 2004 at 10:54:14AM -0500, Ian Grigg wrote:
> 
> [settling the end-of-line issue for 0x01 signatures]
> 
> 
>>Myself, I'm minded to say it should be either:
>>
>>    i.   there should be no trimming, as the binary
>>         (as opposed to cleartext) signature form
>>         implies careful handling (mime/zip) and
>>         thus special care is less needed,
>>
>>    OR
>>
>>    ii.  it should be the same as the cleartext
>>         signature method, for less confusion.
>>
>>(Unfortunately, both these require a compatibility
>>change.)
> 
> 
> I'm not sure that the change will hurt compatibility.  Given the way
> that PGP and GnuPG handle 0x01 signatures (by including their own
> variation of canonicalized text as part of the message), we could pick
> either of these with no significant problems.  Note that PGP currently
> does (i), and GnuPG currently does (ii), and they manage to
> interoperate most of the time.  (Not to say that there aren't other
> implementations out there).
> 
> I would be perfectly content with either solution, with perhaps a
> slight leaning towards (i) due to a desire to not mess with user
> supplied input unless we have to.

Right now, I'm inclined towards (i) myself as
a signing implementation could warn whether
there are trailing spaces, and a verifying
implemetation could try to trim spaces as
a fallback technique.

iang

Date: Wed, 17 Mar 2004 11:27:52 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Let's resolve the end-of-line and whitespace question
Sender: [email-masked]

David Shaw wrote (back in Feb):
...

> 1) 2440 says of the canonical text signature (sigclass 0x01):
> 
>         The signature is calculated over the text data with its line
> 	endings converted to <CR><LF> and trailing blanks removed.
> 
>    This is different than what every version of PGP though 8 does.
>    These implementations do the <CR><LF> line endings, but do not
>    remove trailing blanks (essentially PGP 2.x behavior).

We've discussed his issue 2) elsewhere.  Issue 1) remains,
if I'm not mistaken.  Any comments?

Myself, I'm minded to say it should be either:

     i.   there should be no trimming, as the binary
          (as opposed to cleartext) signature form
          implies careful handling (mime/zip) and
          thus special care is less needed,

     OR

     ii.  it should be the same as the cleartext
          signature method, for less confusion.

(Unfortunately, both these require a compatibility
change.)

I personally am not fussed, but I concur with David's
original request, that it be nailed down so that we
can move forward and have the implementations match.

iang

Date: Wed, 17 Mar 2004 11:22:06 -0500
From: David Shaw <[email-masked]>
To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Let's resolve the end-of-line and whitespace question
Mail-Followup-To: Ian Grigg <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Mar 17, 2004 at 10:54:14AM -0500, Ian Grigg wrote:

[settling the end-of-line issue for 0x01 signatures]

> Myself, I'm minded to say it should be either:
> 
>     i.   there should be no trimming, as the binary
>          (as opposed to cleartext) signature form
>          implies careful handling (mime/zip) and
>          thus special care is less needed,
> 
>     OR
> 
>     ii.  it should be the same as the cleartext
>          signature method, for less confusion.
> 
> (Unfortunately, both these require a compatibility
> change.)

I'm not sure that the change will hurt compatibility.  Given the way
that PGP and GnuPG handle 0x01 signatures (by including their own
variation of canonicalized text as part of the message), we could pick
either of these with no significant problems.  Note that PGP currently
does (i), and GnuPG currently does (ii), and they manage to
interoperate most of the time.  (Not to say that there aren't other
implementations out there).

I would be perfectly content with either solution, with perhaps a
slight leaning towards (i) due to a desire to not mess with user
supplied input unless we have to.

David

Date: Wed, 17 Mar 2004 10:54:14 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
CC: David Shaw <[email-masked]>
Subject: Re: Let's resolve the end-of-line and whitespace question
Sender: [email-masked]

David Shaw wrote (back in Feb):
...

> 1) 2440 says of the canonical text signature (sigclass 0x01):
> 
>         The signature is calculated over the text data with its line
> 	endings converted to <CR><LF> and trailing blanks removed.
> 
>    This is different than what every version of PGP though 8 does.
>    These implementations do the <CR><LF> line endings, but do not
>    remove trailing blanks (essentially PGP 2.x behavior).

We've discussed his issue 2) elsewhere.  Issue 1) remains,
if I'm not mistaken.  Any comments?

Myself, I'm minded to say it should be either:

     i.   there should be no trimming, as the binary
          (as opposed to cleartext) signature form
          implies careful handling (mime/zip) and
          thus special care is less needed,

     OR

     ii.  it should be the same as the cleartext
          signature method, for less confusion.

(Unfortunately, both these require a compatibility
change.)

I personally am not fussed, but I concur with David's
original request, that it be nailed down so that we
can move forward and have the implementations match.

iang

Subject: Re: Be careful with that axe, Eugene
From: [email-masked]
To: [email-masked]
Date: Wed, 17 Mar 2004 12:28:55 +0100
Sender: [email-masked]

At 9:11 AM -0800 3/16/04, Jon Callas wrote:
 >I put in this note in -11 in security considerations about PKCS1
 >padding:
 >
 > * PKCS1 has been found to be vulnerable to attacks in which a
 >   system reports that errors in padding differently from errors in
 >   decryption becomes a random oracle that can leak the private key
 >   in mere millions of queries. [...]

I assume that the 2 words "reports that" in the 2nd line should
be switched ("that reports"), otherwise the text does not make
sense to me.

- Wolfgang Redtenbacher

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Packets sequences
Date: Wed, 17 Mar 2004 19:12:41 +1300
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
>On 14 Mar, 2004, at 1:30 AM, Peter Gutmann wrote:
>> Explicitly allowing complex jumbles of packets seems to be just asking
>> for
>> trouble/interop problems, particularly when there hasn't been any
>> strong need
>> for them in the first 10 years or so of PGP's existence.
>
>How about if I leave it the way that it is? The BNF does not permit anything
>like a jumble of packets. Only literal packets can be in a stream.

That'd work, although there's still the current special-case of allowing a
string of literal packets.  Is there any reason for this?  My code doesn't
handle this, but that's because it never occurred to me that anyone would ever
construct a packet like that.  It seems to be a clunky way to do
indeterminate-length packets (use a sequence of literal packets rather than a
single literal packet with indeterminate-length chunks).  If there's some
reason for this, could the RFC include some text explaining it or discourage
people from using it?

(OK, I can dream up some imaginary scenarios for multiple literals where you
 want to communicate, say two files in one encrypted packet, but standard
 practice for that is to zip or tar/gzip them, not to use a multiple literal
 packets).

Peter.

Date: Tue, 16 Mar 2004 16:13:30 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: cleartext signatures - trailing white space - proposal
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Tue, Mar 16, 2004 at 09:36:57AM -0800, Jon Callas wrote:

> 5.2.1 is made more explicit thus:
> 

There is a definite reason why whitespace removal is needed for
cleartext signatures, but is there any need for any trailing
whitespace removal for 0x01 signatures (where the huge majority of the
time the file is protected inside a literal packet)?  I do like the
consistency of it.

> In 7.1, the confusing and arguably (I have argued this) silly text
> 
>    Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
>    any line is ignored when the cleartext signature is calculated.
> 
> is changed to
> 
>    Also, any trailing whitespace -- spaces (0x020) and tabs (0x09) --
>    at the end of any line is removed when the cleartext signature is
>    generated.

How about:

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

This matches what Werner and Ian proposed a few days ago.  I agree
that it is better to include CR and LF in the list.

David

Date: Tue, 16 Mar 2004 12:34:17 -0800
To: OpenPGP <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: Be careful with that axe, Eugene
Sender: [email-masked]

At 9:11 AM -0800 3/16/04, Jon Callas wrote:
>I put in this note in -11 in security considerations about PKCS1
>padding:

It might be good to also warn about timing attacks.  Here is a possible
paragraph (one sentence added):

      * PKCS1 has been found to be vulnerable to attacks in which a
        system reports that errors in padding differently from errors in
        decryption becomes a random oracle that can leak the private key
        in mere millions of queries. Implementations must be aware of
        this attack and prevent it from happening. The simplest solution
        is report a single error code for all variants of decryption
        errors so as not to leak information to an attacker.  It may
        be necessary to make the timing of responses the same for all
        cases as well.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | "There's nothing so clear as a | Periwinkle
(408)356-8506      | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble     | Los Gatos, CA 95032

Date: Tue, 16 Mar 2004 11:07:08 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

Jon Callas writes:
> > On Fri, 12 Mar 2004 09:23:44 -0800, Hal Finney said:
> >
> >> After signing this message, I've added a CR and 5 spaces to the above
> >> line, which will obscure the word DON'T on some systems.  The 
> >> signature
> >> will still verify if we strip CR with the whitespace, but a 
> >> superficial
> >> look at the message may produce the wrong impression.

> I think Hal gives a beautiful example of a thing that digital 
> signatures both can and can't solve. If someone signs a message that 
> has in it obscured meaning, it's not the signing program's fault the 
> meaning is obscured.
>
> And yet, a properly verifying signature shows that the signer was up to 
> no good, and whatever the outcome, the perfidy is there for anyone to 
> see.

I want to clarify that in this case, it was not the signer at fault.
I wrote a legitimate message which send DON'T SEND THE DATA TO ALICE
and clearsigned it.  Afterwards, an attacker (who happened to be me
in this case, because I didn't have a real attacker handy) modified my
clearsigned message by adding a CR and spaces to obscure the word DON'T.
This leaves the message apparently saying SEND THE DATA TO ALICE, the
opposite of what it is supposed to say.

The message still verified OK because we stripped off the CR and the
spaces for computing the hash, at the receiving end.  These characters
were not present at the sending end (because the attacker had not yet
intervened).  So both ends computed the same hash.

Now, the output of the clearsig verification includes a new copy of the
message, and that copy can (and should, and did, in my implementation)
have the trailing CR and spaces removed.  So that copy of the message
does include the word DON'T.  If the recipient only looks at the output of
the verification process, he won't be fooled, as long as the UI replaces
the message with the stripped version, or otherwise makes sure that the
user sees the version which is output by the verification process.

But if the recipient had read the initial message and gotten a sense
of its meaning, then did the sig verification and didn't closely look
for changes, he might have been fooled.

Or, more relevantly for our documentation purposes, if the OpenPGP
implementation had not replaced the input with the stripped version,
the verifier would also have been fooled.  (One reason an implementation
might not want to do this replacement is to preserve the ability to
re-verify the signature at some future time.)

There is a general rule in crypto signature UIs: sign what is seen (i.e.
"what you see is what you sign"), and see what is verified.  That is,
on the signing end, make sure that what your code signs corresponds to
what the user was seeing when he gave you the data.  Don't transform the
data before signing, and don't add stuff that he didn't see.  And on the
receiving end, make sure that the user sees what is actually verified,
and isn't confused into thinking that some other data was verified when
it actually was not.

We might want to include a reminder of these rules.  If they are followed,
I think that whitespace trimming issues will not introduce security
vulnerabilities.

Hal

From: Jon Callas <[email-masked]>
Subject: Re: cleartext signatures - trailing white space - proposal
Date: Tue, 16 Mar 2004 09:36:57 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 14 Mar, 2004, at 10:28 AM, Werner Koch wrote:

>
> On Fri, 12 Mar 2004 09:23:44 -0800, Hal Finney said:
>
>> After signing this message, I've added a CR and 5 spaces to the above
>> line, which will obscure the word DON'T on some systems.  The 
>> signature
>> will still verify if we strip CR with the whitespace, but a 
>> superficial
>> look at the message may produce the wrong impression.
>
> Right.  So better forget about cleartext and only use binary
> signatures; then another application is reponsible to take care of
> such things ;-)
>

I think Hal gives a beautiful example of a thing that digital 
signatures both can and can't solve. If someone signs a message that 
has in it obscured meaning, it's not the signing program's fault the 
meaning is obscured.

And yet, a properly verifying signature shows that the signer was up to 
no good, and whatever the outcome, the perfidy is there for anyone to 
see.

In the past, we have discussed other semantic attacks where an 
encrypted and signed message is decrypted and then publicly displayed 
for all the world to see, possibly to the consternation of the sender. 
I think that this "attack" is in this case the purest form of justice.

However, this doesn't get us any closer to what we should do.

I think the discussion has drifted away from what *trailing* 
characters, if any, we should have stripped. Remember, it's only 
trailing characters we should trim.

It is also interesting to discuss what happens in weird files -- ones 
that mix different types of line ends, but that's not strictly 
relevant. Even thought this is adding fuel to a fire I'm trying to 
squelch, I feel compelled to add in that there are some file systems 
that are record-oriented. In those a line-end is an out-of band thing. 
Deciding what a line-end is, and therefore what is trailing is an 
implementation-specific issue, anyway.

The argument I see against trimming anything <= 0x20 is that it makes 
it difficult or impossible to sign a file with a form feed or vertical 
tab. That the RFC/draft itself is such a file is an amusing irony. So 
there goes that proposal.

Here's another proposal, which I have edited in, and is thus now my 
default solution:

5.2.1 is made more explicit thus:

In 7.1, the confusing and arguably (I have argued this) silly text

    Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
    any line is ignored when the cleartext signature is calculated.

is changed to

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

Should this not be acceptable, here is a more radical suggestion:

How about if I remove any trimming requirments (since this is 
inconsistently done) and put in an implementation note that says that 
implementations might want to do text massaging on textmode signatures, 
and trimming trailing whitespace (for some suitable definition of 
whitespace) is a reasonable transformation that an implementation might 
want to do. I'm thinking I'd also put in that there are also other 
reasonable checks a signer could do, such as checking for overstriking, 
scanning tags for foreground and background colors being close, 
deceptive statements such as "This is a verified PGP message" and so 
on. I think I'll leave out that a complete scanner requires solving the 
halting problem.

I am happy to entertain even more solutions, especially the one where 
we just removed any text about trimming or ignoring trailing anything.

	Jon

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Be careful with that axe, Eugene
Date: Tue, 16 Mar 2004 09:11:56 -0800
Sender: [email-masked]

I put in this note in -11 in security considerations about PKCS1 
padding:

      * PKCS1 has been found to be vulnerable to attacks in which a
        system reports that errors in padding differently from errors in
        decryption becomes a random oracle that can leak the private key
        in mere millions of queries. Implementations must be aware of
        this attack and prevent it from happening. The simplest solution
        is report a single error code for all variants of decryption
        errors so as not to leak information to an attacker.

I don't want to beat this to death, given that the consensus seems to 
be that this is both an error to worry about, but an implementation 
error that is presently something smart coders should know about.

If there are small changes someone wants, feel free to write them up. I 
read the uPnP section that Carl mentioned. I think we are terser, but 
no less informative. I think the above lets someone who has a real 
reason not to take the suggested workaround a clue that they might want 
to start googling.

	Jon

Date: Tue, 16 Mar 2004 11:41:29 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Packets sequences
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 14, 2004 at 10:30:58PM +1300, Peter Gutmann wrote:

> I would like to see the RFC strongly discourage arbitrary jumbling
> and nesting of assorted packet types in favour of a single, clean
> canonical encoding.  So instead of:
> 
>   ENCRYPTED( COMPRESS, COMPRESSED, COMPRESSED )
> 
> or somesuch there should just be a straightforward:
> 
>   ENCRYPTED( COMPRESS )
> 
> Explicitly allowing complex jumbles of packets seems to be just
> asking for trouble/interop problems, particularly when there hasn't
> been any strong need for them in the first 10 years or so of PGP's
> existence.

I think this is a good idea.  I'm actually quite happy with the
grammar given in bis-09.  It's the same as the 2440 grammar with the
single change that you can have a run of literal packets.

Any implementation is of course free to be more liberal in what it
accepts, but I also see no need to explicitly allow arbitrary jumbling
and nesting especially since nobody has posted a reason why such
constructions are useful.

David

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Removing Elgamal Sigs
Date: Tue, 16 Mar 2004 08:35:43 -0800
Sender: [email-masked]

Since sending in -10, I have removed Elgamal signatures (it was the 
next thing on my list to do).

Section 9.1 now says:

        20         - Reserved (formerly Elgamal Encrypt or Sign)

I put this in 12.6, on reserved identifiers:

    Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
    with a public key identifier of 20. These are no longer permitted.
    An implementation MUST NOT generate such keys. An implementation
    MUST NOT generate Elgamal signatures.

(I also removed the reference to DES/SK in 12.6, this should have been 
done long ago.)

I thought about adding more text into 12.6 about what to do with an 
existing key or signature, but didn't add anything. The reason is that 
I think it should be just fine for an implementation to treat 20 the 
same way as any other illegal or reserved identifier, and also just 
fine for an implementation to migrate keys, verify signatures but alert 
that they're possibly forged, or any other reasonable thing. 
Consequently, the less said the better. Simplify, simplify.

	Jon

From: Jon Callas <[email-masked]>
Subject: Re: Packets sequences
Date: Tue, 16 Mar 2004 08:16:42 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 14 Mar, 2004, at 1:30 AM, Peter Gutmann wrote:

> Explicitly allowing complex jumbles of packets seems to be just asking 
> for
> trouble/interop problems, particularly when there hasn't been any 
> strong need
> for them in the first 10 years or so of PGP's existence.
>

How about if I leave it the way that it is? The BNF does not permit 
anything like a jumble of packets. Only literal packets can be in a 
stream.

	Jon

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: bis-10 sent in
Date: Tue, 16 Mar 2004 07:51:22 -0800
Sender: [email-masked]

I sent in what Derek and I did for bis-10, so we have something common 
to look at.

	Jon

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal (2)
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sun, 14 Mar 2004 19:37:00 +0100
Sender: [email-masked]

On Fri, 12 Mar 2004 14:10:47 -0500, Ian Grigg said:

> Combining comments from today, this is an updated proposal.  7.1
> should be unchanged.

Fine with me.

  Werner

To: "Hal Finney" <[email-masked]>
Cc: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sun, 14 Mar 2004 19:28:37 +0100
Sender: [email-masked]

On Fri, 12 Mar 2004 09:23:44 -0800, Hal Finney said:

> After signing this message, I've added a CR and 5 spaces to the above
> line, which will obscure the word DON'T on some systems.  The signature
> will still verify if we strip CR with the whitespace, but a superficial
> look at the message may produce the wrong impression.

Right.  So better forget about cleartext and only use binary
signatures; then another application is reponsible to take care of
such things ;-)

  Werner

Date: Sun, 14 Mar 2004 08:07:31 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: List of OpenPGP Issues
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 14, 2004 at 12:40:02AM -0800, Jon Callas wrote:
> 
> Derek and I sat down and folded in all the changes that have text 
> supplied. I could spend the extra 20 minutes needed to turn that into 
> -10 and just send it.

I think that is an excellent idea.  I know I find it easier to work
with the current document right in front of me.

David

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Packets sequences
Cc: [email-masked]
Date: Sun, 14 Mar 2004 22:30:58 +1300
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:

>So I believe it is legal to have the any of your suggested combinations, as
>well as multiple compressed packets, IFF you use the RFC2440 partial-packet
>length encodings instead of the RFC1991 indeterminate length encoding.
>
>I'm not sure offhand what the various implementations allow.  ISTR that the
>PGP 5/6/7/8 parser will happily accept this construction.
>
>Question to the audience:  Do we need any changes to the text to make this
>more clear?

I would like to see the RFC strongly discourage arbitrary jumbling and nesting
of assorted packet types in favour of a single, clean canonical encoding.  So
instead of:

  ENCRYPTED( COMPRESS, COMPRESSED, COMPRESSED )

or somesuch there should just be a straightforward:

  ENCRYPTED( COMPRESS )

Explicitly allowing complex jumbles of packets seems to be just asking for
trouble/interop problems, particularly when there hasn't been any strong need
for them in the first 10 years or so of PGP's existence.

Peter.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: List of OpenPGP Issues
Date: Sun, 14 Mar 2004 00:40:02 -0800
To: Derek Atkins <[email-masked]>
Sender: [email-masked]

Derek and I sat down and folded in all the changes that have text 
supplied. I could spend the extra 20 minutes needed to turn that into 
-10 and just send it.

We need to decide something about the remaining issues -- for example, 
it still doesn't sound like we have consensus on trailing whitespace -- 
but there's no reason why I can't send what I have now, and we do the 
others later.

	Jon

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: [ISSUE] Boilerplate gives wrong affiliation
Date: Sat, 13 Mar 2004 14:17:15 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Sat, 13 Mar 2004 14:17:15 +0000 (UTC)
Sender: [email-masked]

* Florian Weimer wrote:
> Network Working Group                                        Jon Callas
> Category: INTERNET-DRAFT                                PGP Corporation
> draft-ietf-openpgp-rfc2440bis-09.txt
> Expires Apr 2004                                       Lutz Donnerhacke
> October 2003                         IN-Root-CA Individual Network e.V.
>
> Obsoletes: 1991, 2440                                        Hal Finney
>                                                       Network Associates
>
>                                                            Rodney Thayer
>
> To my knowledge, Individual Network e.V. no longer exists.

Ack. You may even revome me from the author list.

Date: Sat, 13 Mar 2004 10:30:24 +0100
To: [email-masked]
Subject: [ISSUE] Boilerplate gives wrong affiliation
From: Florian Weimer <[email-masked]>
Sender: [email-masked]

Network Working Group                                        Jon Callas
Category: INTERNET-DRAFT                                PGP Corporation
draft-ietf-openpgp-rfc2440bis-09.txt
Expires Apr 2004                                       Lutz Donnerhacke
October 2003                         IN-Root-CA Individual Network e.V.

Obsoletes: 1991, 2440                                        Hal Finney
                                                      Network Associates

                                                           Rodney Thayer

To my knowledge, Individual Network e.V. no longer exists.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

Date: Sat, 13 Mar 2004 10:23:56 +0100
To: Jon Callas <[email-masked]>
Cc: Ian Grigg <[email-masked]>, [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: Florian Weimer <[email-masked]>
Sender: [email-masked]

Jon Callas wrote:

> The biggest flaw in PGP 2 is that it is not fatally flawed. If there 
> were some horrible bug in PGP 2, we could all demand that people give 
> up their V3 keys, and even just drop them. Alas, PGP 2 is indeed pretty 
> good, and therefore it is hard to get people who believe it to be 
> divine revealed wisdom to change their mind; we can only tease them 
> until they get tired of hearing it.

We could publicize more the user ID spoofing issue.  But it's probably
not extreme enough for most people to care.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

To: [email-masked]
Subject: List of OpenPGP Issues
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 18:32:07 -0500
Sender: [email-masked]

--=-=-=

Hi,

Here is the list of issues against the OpenPGP document, assuming that
Jon finishes the work he was left off to do this week.  This is the
status as of yesterday, and does not take into account the suggestions
made on the list today.

Hopefully we can close out all these issues in -10 or -11 and get to
WGLC.  When the list of open issues is emptied I intend to call a WGLC
on the document.

This list should be comprehensive of all outstanding issues (as of
yesterday).  If you think there is an outstanding issue that is not
listed in this document, please re-send it to the list and include the
string [ISSUE] in the subject.  Hopefully I wont need to set up a
formal process for issue submission, but we'll see.  The ADs would
like me to use RT to track the issues, but mapping the email threads
to an RT queue is seeming to be a lot more work than I'd like to do by
hand.  So, we'll see how it goes.

-derek

--=-=-=
Content-Disposition: attachment; filename=Issues
Content-Description: OpenPGP Issues

OpenPGP Document Issues (see rt.psg.com for numbered issues)

CLOSED ISSUES

* Clarification needed on compressed messages (fixed in -10)
* Non-textual User IDs (fixed in -10)
* Shamir's Discrete Log Hash (no consensus to include new algorithm)
* Comment Length and Format (fixed in -10)
* Signature woes and reconciliation (fixed in -10)
* Back-signatures from a signing subkey onto the primary key (fixed in -10)
* Remove Elgamal signatures (type 20 keys) (fixed in -10)
* Partial length chunks and 5-byte lengths (fixed in -10)
* "cleartext signatures" naming consistency (fixed in -10)
* MDC inconsistency in bis-9 (fixed in -10)
* Secret Key Packet Formats (fixed in -10)
#219 Obsolete 1991 (fixed in -10)
#220 3rd Party Signatures (fixed in -10)
#222 non-textual user IDs (fixed in -10)

OPEN ISSUES -- WAITING ON EDITOR

#221 IDEA v3 vs. v4 algo conflict

OPEN ISSUES -- NEED TEXT

#29 milestones (need to send text to ADs)
#235 Definition of "string"
#347 Trailing white space in clearsigned messages
#348 non-UTF8 in message body

--=-=-=

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

--=-=-=--

Date: Fri, 12 Mar 2004 17:47:24 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Packets sequences
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 10, 2004 at 08:23:03AM +0000, [email-masked] wrote:

>     ENCRYPTED( LITERAL )
>     ENCRYPTED( LITERAL, LITERAL, LITERAL )
>     ENCRYPTED( COMPRESSED( LITERAL ) )
>     ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )

I'd say all of those are pretty clearly legal as both "LITERAL" and
"LITERAL, LITERAL, LITERAL" are valid OpenPGP messages.

The original poster was asking about:
   ENCRYPTED( LITERAL, LITERAL, COMPRESSED( LITERAL, LITERAL ) )

Whether this one should be legal is a valid question, but as things
stand with the grammar in bis-09, I don't think it is currently legal.

David

To: [email-masked]
Subject: Re: OpenPGP WG minutes from IETF-59
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 17:38:58 -0500
Sender: [email-masked]

David Shaw <[email-masked]> writes:

> On Fri, Mar 12, 2004 at 04:36:44PM -0500, Derek Atkins wrote:
>
>> * 3rd party signatures in a one-pass signed message:  This issue is not
>> currently addressed in -09.  Text has been proposed to address this issue
>> and was accepted.
>
> Now that I look at this again - what exactly was accepted here?  I
> seem to recall more than one proposal coming out of that thread.

Yours.  Jon and I worked on this a couple days ago and your text should
be in -10.

> David

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

Date: Fri, 12 Mar 2004 17:21:18 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP WG minutes from IETF-59
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 12, 2004 at 04:36:44PM -0500, Derek Atkins wrote:

> * 3rd party signatures in a one-pass signed message:  This issue is not
> currently addressed in -09.  Text has been proposed to address this issue
> and was accepted.

Now that I look at this again - what exactly was accepted here?  I
seem to recall more than one proposal coming out of that thread.

David

Cc: [email-masked], Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: cleartext signatures - trailing white space - proposal
Date: Fri, 12 Mar 2004 14:07:56 -0800
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

On 12 Mar, 2004, at 5:31 AM, Ian Grigg wrote:

>
> I know we don't need it, but without an explicit
> mention of Unicode, I suspect there will be a
> an endless stream of questions, and also, people
> will start including their Unicode whitespace
> chars because there is no explicit guidance...
>

All OpenPGP text is Unicode, so there's no need for *another* explicit 
mention of this. The bottom 128 characters of Unicode are ASCII, and 
the bottom 256 character of Unicode are ISO Latin-1.

What we colloquially say that a space is 0x20, that also means 0x0020 
and 0x00000020 as well.

While I agree that the ability for people to ask exasperating questions 
knows no bounds, there's such a thing as too much explicitness.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Date: Fri, 12 Mar 2004 13:39:06 -0800
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

> I for one don't understand the joke - maybe I'm
> just a humourless old bastard,

The joke is that he offered, if we put in signature subkeys to stop 
using V3 keys, and I complied.

The joke is that I don't *really* expect him to give up his V3 key.

Ian, I think you're doing the right thing not supporting V3 keys.

The biggest flaw in PGP 2 is that it is not fatally flawed. If there 
were some horrible bug in PGP 2, we could all demand that people give 
up their V3 keys, and even just drop them. Alas, PGP 2 is indeed pretty 
good, and therefore it is hard to get people who believe it to be 
divine revealed wisdom to change their mind; we can only tease them 
until they get tired of hearing it.

Future protocol designers should learn from this experience and make 
sure that their early revisions have some massive security flaw so that 
it's easier to get people to upgrade to the revised version.

	Jon

To: [email-masked]
Cc: [email-masked]
Reply-To: Derek Atkins <[email-masked]>
Subject: OpenPGP WG minutes from IETF-59
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 16:36:44 -0500
Sender: [email-masked]

--=-=-=

Hi,

The final minutes of the OpenPGP WG meeting are attached.

Thanks.

-derek

--=-=-=
Content-Disposition: attachment; filename=ietf-59-minutes.txt
Content-Description: OpenPGP WG Minutes from IETF-59

OpenPGP, IETF-59
Seoul, South Korea
March 2, 2004
1300-1400

minutes by: Jim Schaad

Derek opened the meeting with agenda bashing and appointment of a meeting
secretary.

STATUS OF RFC 2440BIS:  The document has been around since 2001 and the
group needs to finish it.  The current draft is -09 with one update known to
be coming.  Derek presented the issues on the document since the editor was
not able to attend the IETF meeting.

Derek covered the set of closed issues on the document.  These issues are:

* Clarifications on the construction of compressed messages
* Non-Textual User IDs, they must now be UTF-8 strings only
* Addition of a discrete log hash, no strong support for doing this so it
  will not be done.
* Comment line length - no consensus for this issue developed on the mailing
  list so no changes are going to be made for this issue. 

Derek covered the set of open issues on the document.  (Titles of the items
correspond to the mail thread subject name.) These issues are:

* Signature woes & Reconciliation: Text has been proposed to resolve
this issue.  This was accepted without comment from the attendees.

* Trailing White Space: The issue is that some e-mail gateways strip
trailing white space on lines when processing mail messages.  This
cause signature validation failure at later date.  The question is
whether this is an issue that needs to be addressed.

One proposal is to strip EOL characters where the character <= 0x20.  From
the floor it was pointed out that this could cause problems from two things.
1) there are some control characters that may be part of the text stream
(such as page feeds) that should not be stripped and 2) for some languages
escape characters for local language processing might produce characters
that are in this character range and thus produce corruption of the text.

One suggestion was to do the standard MIME time canonicalization and ignore
the rest of the issues.  If the message is changed by stripping spaces in a
gateway, then the message correctly fails validation.

As no text has been proposed or was proposed from the floor the issue was
punted back to the authors to propose some text.

* IDEA in the v3-v4 algorithm conflict:  Major issue the question of what
support needs to be given to PGP 2 implementations.  No proposed text was
presented so issue was punted back to the author.

* 3rd party signatures in a one-pass signed message:  This issue is not
currently addressed in -09.  Text has been proposed to address this issue
and was accepted.

*Obsolete 1991:  Question is should rfc2440-bis obsolete RFC 1991 as well as
RFC 2440 when it progresses.  This was the consensus of the room.
 
* Back-signatures from a signing sub-key onto the primary key:  Text has
been supplied to address this issue by the author, the text was accepted by
the working group.

* Non UTF-8 Text in Message Body:  Should a charset on the armor header be
specified for non UTF-8 text?  No text has been proposed to address this
issue.  This has been punted back for proposed text by either Felix or the
authors.

* Remove Elgamal signatures (type 20):  Some security weaknesses have been
identified in the Elgamal signature scheme used.  The recommendation is to
remove it from the standard.  The group accepted this without comment.

* Partial length chucks and 5-byte lengths:  One reading of the text appears
to disallow 5-byte length items.  Authors have proposed a new text to deal
with this issue.  Text was accepted by the group.

* "cleartext signatures" naming convention:  This is just and editorial
issue.  The proposal is to move from several different ways of describing
the cleartext signature concept by a single string.  The list of locations
has been provided and the author is to make the changes.

* MDC Inconsistent in bis-09:  There are two places where this process is
described and they are inconsistent with each other.  Section 5.14 is the
one that does not match existing code so it will be modified to match the
other section.

* Secret Key Packet Formats:  This is just a set of editorial changes, and
were accepted by the group.

RECHARTERING OF THE GROUP.

Need to update the milestones to match current timeframe.  The current items
point to 2001.  Proposal is:
        - 2440bis to IESG: May 04 - Proposed
        - multiple sig draft - Remove this from the milestone list as it's
          purpose and authors are not known
        - Interop testing to start Aug 2004
        - Advance to draft about Feb 05.

--=-=-=

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

--=-=-=--

Date: Fri, 12 Mar 2004 14:10:47 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: cleartext signatures - trailing white space - proposal (2)
Sender: [email-masked]

Combining comments from today, this is an updated proposal.  7.1
should be unchanged.
=================================================================

7.1. Dash-Escaped Text

     The cleartext content of the message must also be dash-escaped.

     Dash escaped cleartext is the ordinary cleartext where every line
     starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
     (0x2D) and space ' ' (0x20). This prevents the parser from
     recognizing armor headers of the cleartext itself. An implementation
     MAY dash escape any line, SHOULD dash escape lines commencing
     "From " (note the space), and MUST dash escape any line commencing
     in a dash. The message digest is computed using the cleartext
     itself, not the dash escaped form.

     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.

7.2. Canonical Line Endings

     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.  See 6.2.

     When calculating a cleartext signature, trailing whitespace
     at the end of the line shall be removed (and replaced by the
     sequence <CR><LF> as above).  This protects against a failure
     of a valid signature due to conversions that may occur in text
     editing or in transport.

     Whitespace for cleartext signature end-trimming is defined to
     be the characters <SPACE> (0x20), <TAB> (0x09), <CR> (0x0D)
     and <LF> (0x0A).  No Unicode whitespace is defined.

     End-trimming whitespace may open a cleartext signed message to an
     attack of overstriking of key parts of text.  Display of cleartext
     signed messages should take care to strip whitespace before display
     (both before and after signing and verification).

8. ...
=================================================================

To: "Hasnain Mujtaba" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Packets sequences
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 13:41:48 -0500
Sender: [email-masked]

"Hasnain Mujtaba" <[email-masked]> writes:

> Derek,
>
> I think it would be helpful if the RFC made this more clear. 

ok, then suggest some text to make it more clear.  :)

-derek

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

content-class: urn:content-classes:message
Subject: RE: Packets sequences
Date: Fri, 12 Mar 2004 13:39:12 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Derek,

I think it would be helpful if the RFC made this more clear. 

Regards
Hasnain.

> <chair hat>
> Question to the audience:  Do we need any changes to the text
> to make this more clear?
> </chair hat>

Date: Fri, 12 Mar 2004 13:10:37 -0500
From: Ian Grigg <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

I've thought about this too, but I couldn't come to a
conclusion w.r.t., the line trimming issue.

It seems that an attack succeeds or fails no matter what
is done with the trailing whitespace, and the real issue
is whether the display system will be fooled or not.

If whitespace is not trimmed, then the attack is done
pre-signing, so the result is a signed/verified message
that says two different things depending on which system
it is displayed on.  And the original intent is lost.

If whitespace is trimmed, then the attack can be done
post-signing, and the two different meanings are again
presented depending on the display system.  But the
original intent is clear.

Which is better/worst is not clear to me, YMMV.

Perhaps the answer is to put a warning in the ID that
states to effect of:

     Trimming whitespace may open a cleartext signed
     message to an attack of overstriking of key parts
     of text.  Display of cleartext signed messages
     should take care to strip whitespace before display
     (both before and after signing and verification).

?

iang

Hal Finney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> There was a mention some time back of a possible attack on the proposed
> algorithm:
> 
> DON'T SEND THE DATA TO ALICE
>      
> 
> After signing this message, I've added a CR and 5 spaces to the above
> line, which will obscure the word DON'T on some systems.  The signature
> will still verify if we strip CR with the whitespace, but a superficial
> look at the message may produce the wrong impression.
> 
> Hal
> 
> -----BEGIN PGP SIGNATURE-----
> Version: McAfee E-Business Server v7.1.2 - Full License
> 
> iQA/AwUBQFHx3asSfKQ41E4qEQJpoACg917UqU5xQNrAiKWbW5b8bFqkfHoAnRZU
> myqu4AvEwpkH+kpl9+Axztg4
> =tCiJ
> -----END PGP SIGNATURE-----
> 

To: [email-masked]
Cc: [email-masked]
Subject: Re: Packets sequences
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 12:46:48 -0500
Sender: [email-masked]

Hi,

[email-masked] writes:

> The question seems to focus on whether 'a valid OpenPGP message' (above) means
> "one and only one OpenPGP message" or "only valid OpenPGP messages." For
> implementation purposes, I'm guessing that the first interpretation best
> describes what happens in practice:
>
>     ENCRYPTED( LITERAL )
>     ENCRYPTED( LITERAL, LITERAL, LITERAL )
>     ENCRYPTED( COMPRESSED( LITERAL ) )
>     ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )
>
> In other words, compressed messages don't share the same "level" with any other
> message (including another compressed message) and compressed messages "wrap"
> only a single message at a time (granting that a list of literal packets
> comprise a single literal message). FWIW, my implementation accepts a list of
> any sort of messages in the encrypted body (which could lead to really funky
> output) but will only create encrypted messages as ENC(CMP(MSG)) or
> ENC(MSG).

Part of the problem is the encoding of compressed messages.  RFC1991
claims that compressed packets have indefinite length, so there is no
way to know when the packet "ends".  As a result, the parser couldn't
differentiate between the end of a compressed packet and a subsequent
packet.  That meant it was necessarily illegal to have:

         ENCRYPTED ( COMPRESSED ( LITERAL ) | COMPRESED ( LITERAL ) )

because you oculdn't tell when the first compressed packet ended and
the second one began (because you've got a length-of-length of 11,
meaning indeterminate).

RFC2440 changed this to allow compressed packets to have a determined
indeterminate length, so you could tell when the packet ended without
knowing it's length a priori.  So, technically you COULD, using
RFC2440 syntax, implement the aforementioned encryption of two
compressed messages.

The key is being able to tell when the first packet ends and the
second one begins "above" the packet-type processor.  In other words,
just because gzip can tell you when the data has ended, that is not
sufficient for the PGP Packet Processor.

So I believe it is legal to have the any of your suggested
combinations, as well as multiple compressed packets, IFF you use the
RFC2440 partial-packet length encodings instead of the RFC1991
indeterminate length encoding.

I'm not sure offhand what the various implementations allow.  ISTR
that the PGP 5/6/7/8 parser will happily accept this construction.

<chair hat>

Question to the audience:  Do we need any changes to the text
to make this more clear?

</chair hat>

> Aloha,
> poiboy

-derek

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

To: <[email-masked]>
Cc: [email-masked]
Subject: Signing Subkeys (was Re: IDEA in v3-v4 conflict)
From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 12:30:07 -0500
Sender: [email-masked]

Hi,

If this is the case it is a bug in PGP and not necessarily a bug
in the OpenPGP spec.  If it's a bug in PGP then you should contact
PGP Corporation about it.  If the bug is due to inconsistencies in
the spec, then you should suggest text to clear up the amiguity.
Otherwise, this is the wrong forum to discuss the issue.

-derek

<[email-masked]> writes:

> On Thu, 11 Mar 2004 12:58:26 -0800 Derek Atkins <[email-masked]> wrote:
>
>>> but what about the difference in subkey production?
>>
>>What about them?
>>
>>> will PGP generate/allow addition of subkeys that can sign as well
>>as
>>> encrypt?
>>
>>Of course.
>>
>>> it might be necessary if the requirement is for the subkey to
>>sign the
>>> master, and the master to sign the subkey
>>
>>The requirement for a back-signature is only for signature keys.
>>Encrypt-only subkeys don't need it.
>
> the way things are now,
> is that PGP 'cannot' recognize a signature from a subkey
>
> (and to compound things, once GnuPG generates a signing subkey,
> it will, by default, preferentially use only the new subkey for signatures
> with that key.
> it will not use the master for signing unless the user specifically adds
> an over-ride '!' after the signing key id number,
> otherwise, a user entering the key id for signing, and forgetting that
> a new signing subkey was added,
> will find that the signature is from the subkey, with a different key
> id than the one entered)
>
> in any event,
> if PGP cannot recognize a signing subkey signature,
> then it won't recognize the subkey signing the master either,
>
>
> this has already been causing a considerable amount 
> user confusion for GnuPG -> PGP signed /signed and encrypted messages
>
>
> vedaal
>
>
>
> Concerned about your privacy? Follow this link to get
> FREE encrypted email: https://www.hushmail.com/?l=2
>
> Free, ultra-private instant messaging with Hush Messenger
> https://www.hushmail.com/services.php?subloc=messenger&l=434
>
> Promote security and make money with the Hushmail Affiliate Program: 
> https://www.hushmail.com/about.php?subloc=affiliate&l=427
>
>
>

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

Date: Fri, 12 Mar 2004 09:23:44 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

There was a mention some time back of a possible attack on the proposed
algorithm:

DON'T SEND THE DATA TO ALICE

After signing this message, I've added a CR and 5 spaces to the above
line, which will obscure the word DON'T on some systems.  The signature
will still verify if we strip CR with the whitespace, but a superficial
look at the message may produce the wrong impression.

Hal

Date: Fri, 12 Mar 2004 11:53:20 -0500
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

Werner Koch wrote:

>>    line<CR> <LF><CR><LF>
> 
> 
> It is easier for systems where the line ending is just one character
> ;-) In practise most systems do that and use LF (is it CR on Macs?).

Life would indeed be easier if everyone
just got the religion, yes.  Macs switched
to BSD for OSX, since about 2001, so they
now use LF for many things.  No doubt there
is some legacy CR Mac stuff floating around.

Java tries to use LF internally, but sometimes
there are messy conversions and assumptions
applied in some routines that interface with
the outside world.

>>coding up that sort of thing, I've adopted the strategy
>>of saying that any change in the nature of the line
>>endings is treated immediately as a panic (caller to
> 
> 
> However we are talking about what we need to hash and we explicitly
> want to convert the line for this purposes - that is what textmode is
> about.

Reflecting on this, it matters less how it is
defined in the ID on this particular point,
as there will be a signature verify failure
regardless if the recovery goes wrong.

So I withdraw my previous comments w.r.t.
CR/NL being in the list.

>>In sum, I'm not sure that we want to define whitespace
>>in this immediate context as including the legal line
>>ending characters...  Comments?
> 
> 
> 1. Determine the length of the line (according to the convention of
>    the system the application runs).

Which system?  The OS?  The language?  The
message delivery program?  How about this:

1.  Convert bytes into character stream
     (characters being Unicode).
2.  Determine the nature of the line endings
     (by reference to the system convention,
     to inspection:  CR, LF, CR/LF).
3.  Break into an array of lines, separating
     on the line ending in 2.
4.  Trim all trailing whitespace (sp,tab,cr,lf).
5.  Add cr/lf to every line except the last.
6.  Concatonate the array.
7.  Hash.

Mind you, we are now into implementation, which
goes beyond the ID unless people think an
explanatory psuedocode note would help.

iang

PS: btw, I just got a bounce of a mail sent to you
(and CC'd to the PGP users group) in 1997.  It came
from some german mail list at
[email-masked]
... what's happening over there?

Date: Fri, 12 Mar 2004 08:21:47 -0800
To: [email-masked]
Cc: 
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: <[email-masked]>
Sender: [email-masked]

On Thu, 11 Mar 2004 12:58:26 -0800 Derek Atkins <[email-masked]> wrote:

>> but what about the difference in subkey production?
>
>What about them?
>
>> will PGP generate/allow addition of subkeys that can sign as well
>as
>> encrypt?
>
>Of course.
>
>> it might be necessary if the requirement is for the subkey to
>sign the
>> master, and the master to sign the subkey
>
>The requirement for a back-signature is only for signature keys.
>Encrypt-only subkeys don't need it.

the way things are now,
is that PGP 'cannot' recognize a signature from a subkey

(and to compound things, once GnuPG generates a signing subkey,
it will, by default, preferentially use only the new subkey for signatures
with that key.
it will not use the master for signing unless the user specifically adds
an over-ride '!' after the signing key id number,
otherwise, a user entering the key id for signing, and forgetting that
a new signing subkey was added,
will find that the signature is from the subkey, with a different key
id than the one entered)

in any event,
if PGP cannot recognize a signing subkey signature,
then it won't recognize the subkey signing the master either,

this has already been causing a considerable amount 
user confusion for GnuPG -> PGP signed /signed and encrypted messages

vedaal

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

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

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Fri, 12 Mar 2004 10:37:54 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 12, 2004 at 03:56:50PM +0100, Werner Koch wrote:
> 
> On Fri, 12 Mar 2004 08:31:16 -0500, Ian Grigg said:

> > The issue comes when you get files that are garbled
> > in their line endings:
> 
> >     line< ><CR><CR><LF>
> 
> Our lineending is <CR><LF> and thus I would remove the space and the
> first <CR>.

[..]

> 1. Determine the length of the line (according to the convention of
>    the system the application runs).  
> 2. Trim trailing whitespace;  including CR and LF.
> 3. Append CR,LF
> 4. Hash the line

I strongly agree with this.  The whole point of trimming whitespace in
cleartext signatures is to protect the signature from accidental
whitespace damage via email and cut and paste and the like.  Leaving
any whitespace at the end of the line sort of defeats that point.

We can perhaps discuss what characters count as whitespace, but I
think that all of them should be removed.

David

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 12 Mar 2004 15:56:50 +0100
Sender: [email-masked]

On Fri, 12 Mar 2004 08:31:16 -0500, Ian Grigg said:

> I think there is a difference between whitespace and
> line endings, as far as OpenPGP cleartext signatures
> are concerned, at least.

Yes, but LF is also often used as a whitespace character.

> The issue comes when you get files that are garbled
> in their line endings:

>     line< ><CR><CR><LF>

Our lineending is <CR><LF> and thus I would remove the space and the
first <CR>.

> Or

>     line<CR> <LF><CR><LF>

It is easier for systems where the line ending is just one character
;-) In practise most systems do that and use LF (is it CR on Macs?).

> coding up that sort of thing, I've adopted the strategy
> of saying that any change in the nature of the line
> endings is treated immediately as a panic (caller to

However we are talking about what we need to hash and we explicitly
want to convert the line for this purposes - that is what textmode is
about.

> In sum, I'm not sure that we want to define whitespace
> in this immediate context as including the legal line
> ending characters...  Comments?

1. Determine the length of the line (according to the convention of
   the system the application runs).  
2. Trim trailing whitespace;  including CR and LF.
3. Append CR,LF
4. Hash the line

> these characters VT, FF, have defined meaning within
> the text than are likely to be added later by
> transmission gremlins.

Agreed.

> I know we don't need it, but without an explicit
> mention of Unicode, I suspect there will be a
> an endless stream of questions, and also, people

Okay, so lets add it.

  Werner

Date: Fri, 12 Mar 2004 13:54:04 +0000
From: Stuart A Yeates <[email-masked]>
To: Ian Grigg <[email-masked]>
CC: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

Ian Grigg wrote:

> Perl uses this definition of whitespace:
> 
>   \s      A whitespace character      [ \t\n\r\f]
> 
> which includes form feeds as 0x0c (I think).

Modern versions of perl also have a unicode compliant definition of 
whitespace (and other things) see:
http://perl.active-venture.com/pod/perlretut-morecharacter.html

> Java uses the java.lang.Character.isWhitespace()
> method, which probably depends on the character
> set!

java.lang.Character.isWhitespace() operates solely on chars, which are 
unicode.

> I don't know about Python, or Microsoft languages.

Modern versions of Python do unicode, I believe.

cheers
stuart

-- 
Stuart Yeates            [email-masked]
OSS Watch                                  http://www.oss-watch.ac.uk/
Oxford Text Archive                             http://ota.ahds.ac.uk/
Humbul Humanities Hub                         http://www.humbul.ac.uk/

Date: Fri, 12 Mar 2004 08:33:40 -0500
From: Ian Grigg <[email-masked]>
To: "Brian G. Peterson" <[email-masked]>
CC: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

Brian G. Peterson wrote:

> I would modify Werner's proposed text like so, for grammatical clarity:
> 
>        When calculating a cleartext signature, trailing whitespace
>        (defined as the characters <SPACE> (0x20), <TAB> (0x09),
>        <CR> (0x0D) and <LF> (0x0A)) at the end of any line shall be
>        removed and replaced by the sequence <CR><LF> for the purpose
>        of calculating the cleartext signature.  This protects against
>        a failure of a valid signature due to many conversions that may
>        occur in text editing tools or in transport.

( See comments to Werner - it's not so easy to
combine the "line ending" processing with the
"whitespace" processing. )

> I think it is important to clarify both the definition and a little of the
> reasoning behind this for readers and implementers of the RFC.

I agree;  this is one area where a little more
commentary can help solve a lot of little
annoying compatibility issues.

iang

Date: Fri, 12 Mar 2004 08:31:16 -0500
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

Werner Koch wrote:
> On Thu, 11 Mar 2004 20:40:56 -0500, Ian Grigg said:
> 
> 
>>     Also, any trailing whitespace (characters <= 0x20) at the
> 
> 
> Please don't define whitespace this way.  I know software using
> control characters to separate fields (e.g. STX (0x02) or FS (0x1c))
> in a line. Ignoring them in a signature (at the end of a line) might
> very well change the content of the message (even if those fields are
> empty).  

OK, that makes for two votes for an explicit short
list of whitespace characters.

> SPACE, LF, CR and TAB are the whitespace characters we have always
> used in PGP and so should it be - that is also what most
> programmers[1] understand under whitespace (cf. K&R).

I think there is a difference between whitespace and
line endings, as far as OpenPGP cleartext signatures
are concerned, at least.

The issue comes when you get files that are garbled
in their line endings:

    line< ><CR><CR><LF>

Or

    line<CR> <LF><CR><LF>

and various other combinations.  In the past, when
coding up that sort of thing, I've adopted the strategy
of saying that any change in the nature of the line
endings is treated immediately as a panic (caller to
fix).  E.g., there is at least one manifest error, and
trying to determine the error as being either a line
ending error or a whitespace error makes for too many
complications in the code.

In sum, I'm not sure that we want to define whitespace
in this immediate context as including the legal line
ending characters...  Comments?

 > VT and FF would
> also belong to them, but given that we did not used them in PGP, I's
> feel better not to add them now.

If we are going for a list of characters, the shorter
the better, in general.  It seems more likely that
these characters VT, FF, have defined meaning within
the text than are likely to be added later by
transmission gremlins.

>>Note 4.  And, to clarify Unicode, I suggest adding:
> 
> 
> 
>>     No exception for Unicode whitespace is defined,
>>     and all Unicode characters SHOULD NOT be ignored.
> 
> 
> With a list of white space caracters along with their encoding values,
> we won't need that.

I know we don't need it, but without an explicit
mention of Unicode, I suspect there will be a
an endless stream of questions, and also, people
will start including their Unicode whitespace
chars because there is no explicit guidance...

> [1] Well, speaking of C programmers; don't know about Java.

Perl uses this definition of whitespace:

   \s      A whitespace character      [ \t\n\r\f]

which includes form feeds as 0x0c (I think).

Java uses the java.lang.Character.isWhitespace()
method, which probably depends on the character
set!

I don't know about Python, or Microsoft languages.

This underscores is that the ID should NOT rely
on any languague's definition of whitespace, and
should seek to define explicitly what is meant.

iang

Date: Fri, 12 Mar 2004 06:44:44 -0600 (CST)
Subject: Re: cleartext signatures - trailing white space - proposal
From: "Brian G. Peterson" <[email-masked]>
To: "Werner Koch" <[email-masked]>
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]

Werner Koch said:
> 7.2. Canonical Line Endings
>
>      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.
>
>      Also, any trailing whitespace (the characters <SPACE> (0x20),
>      <TAB> (0x09), <CR> (0x0D) and <LF> (0x0A)) at the end of any line
>      is removed and replaced by the sequence <CR><LF> for the purpose
>      of cleartext signature calculation.

I would modify Werner's proposed text like so, for grammatical clarity:

       When calculating a cleartext signature, trailing whitespace
       (defined as the characters <SPACE> (0x20), <TAB> (0x09),
       <CR> (0x0D) and <LF> (0x0A)) at the end of any line shall be
       removed and replaced by the sequence <CR><LF> for the purpose
       of calculating the cleartext signature.  This protects against
       a failure of a valid signature due to many conversions that may
       occur in text editing tools or in transport.

I think it is important to clarify both the definition and a little of the
reasoning behind this for readers and implementers of the RFC.

Regards,

    - Brian

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 12 Mar 2004 11:23:34 +0100
Sender: [email-masked]

On Thu, 11 Mar 2004 20:40:56 -0500, Ian Grigg said:

>      Also, any trailing whitespace (characters <= 0x20) at the

Please don't define whitespace this way.  I know software using
control characters to separate fields (e.g. STX (0x02) or FS (0x1c))
in a line. Ignoring them in a signature (at the end of a line) might
very well change the content of the message (even if those fields are
empty).  

SPACE, LF, CR and TAB are the whitespace characters we have always
used in PGP and so should it be - that is also what most
programmers[1] understand under whitespace (cf. K&R).  VT and FF would
also belong to them, but given that we did not used them in PGP, I's
feel better not to add them now.

> Note 1.  I'd like "space" defined as a 0x20 to remove the possibility
> of Unicode spaces.

Agreed.

> Note 4.  And, to clarify Unicode, I suggest adding:

>      No exception for Unicode whitespace is defined,
>      and all Unicode characters SHOULD NOT be ignored.

With a list of white space caracters along with their encoding values,
we won't need that.

> 7.2. Canonical Line Endings

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

>      Also, any trailing whitespace (characters <= 0x20) at the
>      end of any line is ignored when the cleartext signature is
>      calculated.  No exception for Unicode whitespace is defined,
>      and all Unicode characters SHOULD NOT be ignored.

     Also, any trailing whitespace (the characters <SPACE> (0x20),
     <TAB> (0x09), <CR> (0x0D) and <LF> (0x0A)) at the end of any line
     is removed and replaced by the sequence <CR><LF> for the purpose
     of cleartext signature calculation.

  Werner

[1] Well, speaking of C programmers; don't know about Java.

Date: Thu, 11 Mar 2004 20:40:56 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signatures - trailing white space - proposal
Sender: [email-masked]

 > As no text has been proposed or was proposed from the floor the issue was
 > punted back to the authors to propose some text.

The issue was more that consesnus hadn't been achieved,
and that text which was proposed was indicative only.

But here goes: it comes down to, as I see it, one of
two choices (full example at end):

     Also, any trailing whitespace (characters <= 0x20) at the
     end of any line is ignored when the cleartext signature is
     calculated.

OR:

     Also, any trailing whitespace (0x20, 0x09) at the
     end of any line is ignored when the cleartext signature is
     calculated.

Note 1.  I'd like "space" defined as a 0x20 to remove the possibility
of Unicode spaces.

Note 2.  Before it said (spaces, and tabs, 0x09) which is odd, as
tabs are 0x09, unless I have it crossed.  Where vertTabs (0x0B)
supposed to be in there?

Note 3.  I'm ambivalant on the choice.

Note 4.  And, to clarify Unicode, I suggest adding:

     No exception for Unicode whitespace is defined,
     and all Unicode characters SHOULD NOT be ignored.

iang

PS: while we're at it, it might be better if a new
section is added, 7.2, and the paras re-ordered as
below.  Just a thought...  I also took the liberty
of joining the "From " on one line, para 2, line 6.

7.1. Dash-Escaped Text

     The cleartext content of the message must also be dash-escaped.

     Dash escaped cleartext is the ordinary cleartext where every line
     starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
     (0x2D) and space ' ' (0x20). This prevents the parser from
     recognizing armor headers of the cleartext itself. An implementation
     MAY dash escape any line, SHOULD dash escape lines commencing
     "From " (note the space), and MUST dash escape any line commencing
     in a dash. The message digest is computed using the cleartext
     itself, not the dash escaped form.

     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.

7.2. Canonical Line Endings

     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.

     Also, any trailing whitespace (characters <= 0x20) at the
     end of any line is ignored when the cleartext signature is
     calculated.  No exception for Unicode whitespace is defined,
     and all Unicode characters SHOULD NOT be ignored.

8. ...

Date: Thu, 11 Mar 2004 20:34:04 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signatures - trailing white space - comments
Sender: [email-masked]

Comments on some areas, below, assuming continued
debate.  Proposals in next email.

> ===================== Hal Finney, 2004.02.20
> {comprehensive list of unicode spaces, elided}
> 
> Therefore I think all of these should be hashed
> even if they do occur at the end of a line.
> 
> ...
> 
> The only one left is IDEOGRAPHIC SPACE, which I suspect is the default
> space character in ideographic languages (although it's possible they use
> ordinary SPACE).  I could imagine it being put at the end of a line by
> accident, by a Chinese typist or poorly designed word processing program,
> so I'd suggest that it should be stripped before hashing.
> 
> This is the only one I would suggest adding, along with SPACE.

My view on this is that a) Hal's summary is
very good, but not necessarily complete, and
b) I'm not sure we have the wherewithall to
be able to predict even the characters that
are there.

So, I would say that any Unicode whitespace
that are encounted SHOULD NOT be treated as
whitespace, in this context.

Later implementations may divine more
clearly what to do here, in which case
they might be encouraged to create an Armor
Header that states how to treat.  Otherwise,
the default is that Unicode characters have
no special treatment, for simplicity, IMHO.

> ===================== Derik Atkins, 2004.03.08
> * Trailing White Space: The issue is that some e-mail gateways strip
> trailing white space on lines when processing mail messages.  This
> cause signature validation failure at later date.  The question is
> whether this is an issue that needs to be addressed.
> 
> One proposal is to strip EOL characters where the character <= 0x20.  From
> the floor it was pointed out that this could cause problems from two 
> things.
> 1) there are some control characters that may be part of the text stream
> (such as page feeds) that should not be stripped and

I'm unsure what to make of this - any comments?

If page feeds shouldn't be stripped, then maybe
backspaces shouldn't be stripped, and we are
back to space/tabs being stripped?

 > 2) for some languages
> escape characters for local language processing might produce characters
> that are in this character range and thus produce corruption of the text.

The way I see this is:

If a character set outside Unicode is being used,
then that should be indicated in the Armor Headers,
and then interpreted properly such that corruption
is not present.  If not, it will also muck up on
line endings CR/NL.

Elsewise it is in Unicode, and the rules apply.

> One suggestion was to do the standard MIME time canonicalization and ignore
> the rest of the issues.  If the message is changed by stripping spaces in a
> gateway, then the message correctly fails validation.

I'm not quite sure how MIME canonicalization works,
but the issue is wider than mail, things like
cut&paste are widely used for cleartext signed
documents, and these tools tend to add spaces
on the end.

iang (proposal to follow)

Date: Thu, 11 Mar 2004 19:40:30 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: cleartext signatures - trailing white space - recap
Sender: [email-masked]

I think the *key* email extracts are below on this issue,
but this is my choice, and I've been harsh in stripping
things out, to concentrate.  I also may have missed some
mails, and left out a couple that seemed to have no traction.
(Apologies to those!  Please repost if necessary.)

David Shaw introduced the issue, as well as the issue of
space-stripping in text-mode, which has received relatively
little attention.  It may be that if we can crack the nut
of cleartext signature canonicalization, then the text-mode
sig falls out easily.

iang

===================== David Shaw, 2004.02.11
2) 2440 says of the cleartext signature:

         Also, any trailing whitespace (spaces, and tabs, 0x09) at the
	end of any line is ignored when the cleartext signature is
	calculated.

    Again, PGP through 8 implements this differently than 2440 says,
    where trailing spaces are removed, but trailing tabs are not
    (again, PGP 2.x behavior).

===================== Jon Callas, 2004.02.20
  How about if we remove any whitespace things, and just
  canonicalize line ends? It sounds like Unicode
  whitespace may be a huge can of worms. Alternatively,
  we could just say trim anything that's <= 0x20, which
  is a simple enough thing that solves some obvious
  attacks with backspacing and bare CRs to overstrike.

===================== Ian Grigg 2004.02.20
My vote would be to trim whitespace and normalise
line endines to CR/NL, where whitespace is <=0x20:

     Also, any trailing whitespace (characters <= 0x20) at the
     end of any line is ignored when the cleartext signature is
     calculated.

I think there should be a comment in there that
indicates what to do with Unicode, just to show
we thought about it, and not waste people's time
asking the question when they are implementing.
Something like:

     Unicode whitespace, where defined, SHOULD NOT be ignored.

Or,

     No Unicode whitespace characters are defined.

Leaving open the possibility of defining them in
an update?

===================== Hal Finney, 2004.02.20
{comprehensive list of unicode spaces, elided}

Therefore I think all of these should be hashed
even if they do occur at the end of a line.

...

The only one left is IDEOGRAPHIC SPACE, which I suspect is the default
space character in ideographic languages (although it's possible they use
ordinary SPACE).  I could imagine it being put at the end of a line by
accident, by a Chinese typist or poorly designed word processing program,
so I'd suggest that it should be stripped before hashing.

This is the only one I would suggest adding, along with SPACE.

===================== Derik Atkins, 2004.03.08
* Trailing White Space: The issue is that some e-mail gateways strip
trailing white space on lines when processing mail messages.  This
cause signature validation failure at later date.  The question is
whether this is an issue that needs to be addressed.

One proposal is to strip EOL characters where the character <= 0x20.  From
the floor it was pointed out that this could cause problems from two things.
1) there are some control characters that may be part of the text stream
(such as page feeds) that should not be stripped and 2) for some languages
escape characters for local language processing might produce characters
that are in this character range and thus produce corruption of the text.

One suggestion was to do the standard MIME time canonicalization and ignore
the rest of the issues.  If the message is changed by stripping spaces in a
gateway, then the message correctly fails validation.

As no text has been proposed or was proposed from the floor the issue was
punted back to the authors to propose some text.

=====================

To: <[email-masked]>
Cc: [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: Derek Atkins <[email-masked]>
Date: Thu, 11 Mar 2004 15:58:26 -0500
Sender: [email-masked]

<[email-masked]> writes:

> great!
>
> but what about the difference in subkey production?

What about them?

> will PGP generate/allow addition of subkeys that can sign as well as
> encrypt?

Of course.

> it might be necessary if the requirement is for the subkey to sign the
> master, and the master to sign the subkey

The requirement for a back-signature is only for signature keys.
Encrypt-only subkeys don't need it.

<chair hat>

Version -10 of the document should be out soon.  In the meantime I'll
send out the list of issues (both open and closed) soon.  My hope is
that we can get all the issues closed and then move to last call.  My
intention is to initiate a WGLC when the list of open issues is
emptied.

Note to people opening issues:  Please supply text!  If you do not
supply text when bringing up an issue with the document then we have
nothing specific to discuss, which makes it harder to focus the
discussions on the endgame: a finished document.  So, when you
find an issue please give the document section(s), the existing
text, and your suggested changes to the text.

Thank you!

</chair hat>

-derek

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

Date: Thu, 11 Mar 2004 08:42:31 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Sender: [email-masked]

Jon Callas wrote:

> Does this mean you think I should strip out all V3 keys now? I'd be 
> happy to put out an interim draft RSN to just put a nail in V3 keys as 
> you suggest. :-)
> 
>     Jon
> 
> (In case it's not clear, I really am joking)

I for one don't understand the joke - maybe I'm
just a humourless old bastard, or, maybe our Java
implementation, which is a bit stuck at "nearly
done," for lack of funds.  Cryptix OpenPGP lacks
PGP 2 support, and will probably always lack PGP 2
support, because there just isn't any real economic
sense in it.

Dropping support in the standard for old stuff would
seem to be a boon to all future implementations.
Those that wanted to support the old ways still can,
there is no suggestion that they have to drop
support, nobody ever said you can't over do the
support aspects.

Still, standards are meant to be used by developers,
not the other way around.  If the RFC calls for V3
support, it's easy enough to ignore that part and
not achieve conformity.

iang

Date: Wed, 10 Mar 2004 15:57:55 -0800
To: [email-masked]
Cc: 
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: <[email-masked]>
Sender: [email-masked]

On Wed, 10 Mar 2004 14:44:04 -0800 Jon Callas <[email-masked]> wrote:
>> {that said, many of us are still holding on to our v3 keys,
>> at least till all the subkey signing issues are resolved ;-) }
>>
>
>Be careful what you ask for, you might get it.
>
>Derek and I went through the issues from Seoul this afternoon, and
>>
>that's resolved now. A draft should come out soon -- he's going to
>post 
>some things about the remaining open issues where there's no text.

great!

but what about the difference in subkey production?

will PGP generate/allow addition of subkeys that can sign as well as
encrypt?

it might be necessary if the requirement is for the subkey to sign the
master, and the master to sign the subkey

>Does this mean you think I should strip out all V3 keys now? I'd
>be 
>happy to put out an interim draft RSN to just put a nail in V3 keys
>as 
>you suggest. :-)
>
>	Jon
>
>(In case it's not clear, I really am joking)

{it is clear ;-) }

but the truth is, 
it probably wouldn't matter,

the hardline v3 users don't rely primarily on servers for key exchange

vedaal

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

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

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: paper of interest to be presented at EuroCrypt
Date: Wed, 10 Mar 2004 15:11:36 -0800
To: [email-masked] (Peter Gutmann)
Sender: [email-masked]

On 9 Mar, 2004, at 11:43 PM, Peter Gutmann wrote:

> "Do not custom-configure your MTA to act as an oracle for an attacker 
> and then
> let it run unattended for six months" ought to do it.
>

I'm happy to put this in as a security consideration. Should I also put 
in one about not looking into a laser with your remaining eye?

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Date: Wed, 10 Mar 2004 14:44:04 -0800
To: <[email-masked]>
Sender: [email-masked]

> {that said, many of us are still holding on to our v3 keys,
> at least till all the subkey signing issues are resolved ;-) }
>

Be careful what you ask for, you might get it.

Derek and I went through the issues from Seoul this afternoon, and 
that's resolved now. A draft should come out soon -- he's going to post 
some things about the remaining open issues where there's no text.

Does this mean you think I should strip out all V3 keys now? I'd be 
happy to put out an interim draft RSN to just put a nail in V3 keys as 
you suggest. :-)

	Jon

(In case it's not clear, I really am joking)

Date: Wed, 10 Mar 2004 09:58:38 -0800
To: [email-masked]
Cc: 
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: <[email-masked]>
Sender: [email-masked]

On Wed, 10 Mar 2004 08:59:52 -0800 Ian Grigg <[email-masked]> wrote:

>Florian Weimer wrote:

>> I'm all in favor of ignoring PGP 2 completely.
>
>
>Gets my vote as well.
>
>
>> Keep in mind that PGP 2 is unsupported software with known security
>> flaws and rather unclear licensing conditions.
>
>
>Also, small user base, and rather
>expensive development ramifications.
>
>PGP 2 was good when it was good, but
>I think it's time to move on.

even as a long-time dedicated pgp 2 user,
i sort-of have to agree with all of you here ;-(

those of us who still want/insist on using pgp 2, 
will continue to do so,
(and not as small a group as you imagine,
especially if you count all the remailers),
and don't really care about any of the open-pgp specs,
as it doesn't affect pgp 2 to pgp 2 usage

(i recently had an experience where i sent a signed and encrypted pgp
message to someone
{a fairly well known academic cryptographer who uses *only* pgp2.x, }
who sent my message back, unread, because the version line was later
than 2.x, with a note to re-send it in 2.x, even though the message was
*completely* 2.x compatible )

it is unfair to have Open-PGP standardizers and developers, bend over
backwards to accommodate pgp 2.x for users who don't really need or appreciate
it, 
and whose crypto usage will remain largely un-affected,
while hindering advancements that might benefit everyone else ...

{that said, many of us are still holding on to our v3 keys,
at least till all the subkey signing issues are resolved ;-) }

vedaal

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

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

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Wed, 10 Mar 2004 11:59:52 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Sender: [email-masked]

Florian Weimer wrote:
> David Shaw wrote:
> 
> 
>>I'd also be fine with dropping the paragraph altogether if there is
>>not much interest in supporting PGP 2.
> 
> 
> I'm all in favor of ignoring PGP 2 completely.

Gets my vote as well.

> Keep in mind that PGP 2 is unsupported software with known security
> flaws and rather unclear licensing conditions.

Also, small user base, and rather
expensive development ramifications.

PGP 2 was good when it was good, but
I think it's time to move on.

iang

Date: Wed, 10 Mar 2004 17:00:44 +0100
To: [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
From: Florian Weimer <[email-masked]>
Sender: [email-masked]

David Shaw wrote:

> I'd also be fine with dropping the paragraph altogether if there is
> not much interest in supporting PGP 2.

I'm all in favor of ignoring PGP 2 completely.

Keep in mind that PGP 2 is unsupported software with known security
flaws and rather unclear licensing conditions.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

Subject: Re: Packets sequences
Date: Wed, 10 Mar 2004 08:23:03 +0000
From: [email-masked]
To: 
CC: [email-masked]
Sender: [email-masked]

-------- Original Message --------
From: poiboy
To: [email-masked]
Subject: Re: Packets sequences
Date: Wed, 10 Mar 2004 03:34:15 +0000

> Just to be sure that I understand this properly, does this mean that an
> encrypted message can contain a variable length sequence of literal data
> packets and/or compressed data packets, e.g, is this sequence possible?
> 
> Encrypted data packet = {literal data packet1, compressed data packet1,
> literal data packet2}, where the compressed data packet1 can itself hold
> a sequence of literal data packets. 

I think the answer leans toward "no" - but take this with a grain of salt since
I'm not qualified to comment on the intent of the draft.

>From 10.2.:

    OpenPGP Message :- Encrypted Message | Signed Message |
                       Compressed Message | Literal Message.

    Compressed Message :- Compressed Data Packet.

    Literal Message :- Literal Data Packet |
                      Literal Message, Literal Data Packet.

    In addition, decrypting a Symmetrically Encrypted Data Packet or a
    Symmetrically Encrypted Integrity Protected Data Packet as well as
    decompressing a Compressed Data packet must yield **a valid OpenPGP
    Message**. (emphasis added)

The question seems to focus on whether 'a valid OpenPGP message' (above) means
"one and only one OpenPGP message" or "only valid OpenPGP messages." For
implementation purposes, I'm guessing that the first interpretation best
describes what happens in practice:

    ENCRYPTED( LITERAL )
    ENCRYPTED( LITERAL, LITERAL, LITERAL )
    ENCRYPTED( COMPRESSED( LITERAL ) )
    ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )

In other words, compressed messages don't share the same "level" with any other
message (including another compressed message) and compressed messages "wrap"
only a single message at a time (granting that a list of literal packets
comprise a single literal message). FWIW, my implementation accepts a list of
any sort of messages in the encrypted body (which could lead to really funky
output) but will only create encrypted messages as ENC(CMP(MSG)) or
ENC(MSG).

Aloha,
poiboy

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: paper of interest to be presented at EuroCrypt
Cc: [email-masked], [email-masked]
Date: Wed, 10 Mar 2004 20:43:41 +1300
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

>>As already mentioned in Section 2, GPG implements RSA encryption as defined
>>by PKCS#1 v1.5.  This is not state-of-the-art cryptography: like with
>>ElGamel, Bleichenbacker's chosen-ciphertext [4] can decrypt any ciphertext.
>
>Any comments?

This came up on the S/MIME group some time ago, I did a back-of-the-envelope
calculation and came up with some figure like 6 months continuous hammering of
a mail server *specifically configured to act as an oracle* to decrypt a
message (that's not the exact figure, it may have been 8 months or something
similar, I'd have to go back and dig up the notes).  My conclusion was that in
terms of things to worry about it was at about the same level as being hit by
a freak meteor.

(And before someone leaps in with "I can dream up an artificial scenario where
 ...", I'm quite sure you can, but it's really a "don't do that, then" issue
 and not any real-world threat).

There was a brief attempt to force S/MIME to go to OAEP, but the response was
something akin to a general yawn from implementors (see "The Crypto Gardening
Guide and Planting Tips" at
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt for more on this).

>My question here would be more along the lines of whether a warning comment
>should be placed in the draft document?

"Do not custom-configure your MTA to act as an oracle for an attacker and then
let it run unattended for six months" ought to do it.

Peter.

From: "Carl Ellison" <[email-masked]>
To: "'Steven M. Bellovin'" <[email-masked]>, "'Ian Grigg'" <[email-masked]>
Cc: "'Mike Markowitz'" <[email-masked]>, "'Hal Finney'" <[email-masked]>, <[email-masked]>
Subject: RE: paper of interest to be presented at EuroCrypt 
Date: Tue, 9 Mar 2004 23:25:36 -0800
Sender: [email-masked]

In UPnP Security, we started out with a better encoding mechanism, that
provably avoids the attack on PKCS#1v1.5. However, we were forced by our
developers to go back to PKCS.  The crypto libraries some of these folks
were using did PKCS#1 and nothing else.

So, we added instructions to the developers and convinced ourselves that
this made PKCS#1 safe.

http://www.upnp.org/standardizeddcps/security.asp

See p.49 of DeviceSecurity for those instructions.

 - Carl

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Steven 
> M. Bellovin
> Sent: Tuesday, March 09, 2004 2:41 PM
> To: Ian Grigg
> Cc: Mike Markowitz; Hal Finney; [email-masked]
> Subject: Re: paper of interest to be presented at EuroCrypt 
> 
> 
> In message <[email-masked]>, Ian Grigg writes:
> 
> >The paper also makes some comments concerning
> >OpenPGP weaknesses (sans exploits) of PKCS#1 v1.5
> >RSA encryption and signatures (section 4.2, 4.3).
> >
> >    4.2 Encryption
> >
> >    As already mentioned in Section 2, GPG implements
> >    RSA encryption as defined by PKCS#1 v1.5.  This is
> >    not state-of-the-art cryptography: like with
> >    ElGamel, Bleichenbacker's chosen-ciphertext [4]
> >    can decrypt any ciphertext.  But, as mentioned
> >    in 3.3, the relevance of such attacks to the email
> >    world is debatable, in part because of the high
> >    number of oracle calls.  We hope that future
> >    versions of the OpenPGP standard, will recommend
> >    better RSA encryption standards (see for instance
> >    PKCS#1 v2.1 [20] or NESSIE [8]).
> >
> >Any comments?
> >
> >Presumably it is way too late in the piece to
> >change these methods.  My question here would be
> >more along the lines of whether a warning comment
> >should be placed in the draft document?
> >
> 
> Adding a warning in the Security Considerations section 
> would, I think, 
> be necessary here.  It's a known weakness that could have serious 
> consequences if, for example, the OpenPGP message format was used for 
> some sort of programmatic interface, rather than for email.
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 

Date: Tue, 9 Mar 2004 21:43:59 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Packets sequences
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Mar 09, 2004 at 07:58:18PM -0500, Hasnain Mujtaba wrote:
> 
> Hi all, 
> 
> RFC 2440 states:
> 
>    5.7. Symmetrically Encrypted Data Packet (Tag 9)   
>    The Symmetrically Encrypted Data packet contains data encrypted with
>    a symmetric-key algorithm. When it has been decrypted, it will
>    typically contain other packets (often literal data packets or
>    compressed data packets).
> 
> Just to be sure that I understand this properly, does this mean that an
> encrypted message can contain a variable length sequence of literal data
> packets and/or compressed data packets, e.g, is this sequence possible?
> 
> Encrypted data packet = {literal data packet1, compressed data packet1,
> literal data packet2}, where the compressed data packet1 can itself hold
> a sequence of literal data packets. 

You know, I don't think it is.  Encrypted(literal1, literal2) is
legal, and Encrypted(compressed(literal1, literal2)) is legal, but
mixing the literals and compressed packets at the same "level" of
encapsulation isn't.  Anyone read the grammar otherwise?

Legal or not, I suspect most parsers would handle it.

David

content-class: urn:content-classes:message
Subject: Packets sequences
Date: Tue, 9 Mar 2004 19:58:18 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi all, 

RFC 2440 states:

   5.7. Symmetrically Encrypted Data Packet (Tag 9)   
   The Symmetrically Encrypted Data packet contains data encrypted with
   a symmetric-key algorithm. When it has been decrypted, it will
   typically contain other packets (often literal data packets or
   compressed data packets).

Just to be sure that I understand this properly, does this mean that an
encrypted message can contain a variable length sequence of literal data
packets and/or compressed data packets, e.g, is this sequence possible?

Encrypted data packet = {literal data packet1, compressed data packet1,
literal data packet2}, where the compressed data packet1 can itself hold
a sequence of literal data packets. 

Thanks
Hasnain. 

From: "Steven M. Bellovin" <[email-masked]>
To: Ian Grigg <[email-masked]>
Cc: Mike Markowitz <[email-masked]>, Hal Finney <[email-masked]>, [email-masked]
Subject: Re: paper of interest to be presented at EuroCrypt 
Date: Tue, 09 Mar 2004 17:40:43 -0500
Sender: [email-masked]

In message <[email-masked]>, Ian Grigg writes:

>The paper also makes some comments concerning
>OpenPGP weaknesses (sans exploits) of PKCS#1 v1.5
>RSA encryption and signatures (section 4.2, 4.3).
>
>    4.2 Encryption
>
>    As already mentioned in Section 2, GPG implements
>    RSA encryption as defined by PKCS#1 v1.5.  This is
>    not state-of-the-art cryptography: like with
>    ElGamel, Bleichenbacker's chosen-ciphertext [4]
>    can decrypt any ciphertext.  But, as mentioned
>    in 3.3, the relevance of such attacks to the email
>    world is debatable, in part because of the high
>    number of oracle calls.  We hope that future
>    versions of the OpenPGP standard, will recommend
>    better RSA encryption standards (see for instance
>    PKCS#1 v2.1 [20] or NESSIE [8]).
>
>Any comments?
>
>Presumably it is way too late in the piece to
>change these methods.  My question here would be
>more along the lines of whether a warning comment
>should be placed in the draft document?
>

Adding a warning in the Security Considerations section would, I think, 
be necessary here.  It's a known weakness that could have serious 
consequences if, for example, the OpenPGP message format was used for 
some sort of programmatic interface, rather than for email.

		--Steve Bellovin, http://www.research.att.com/~smb

Date: Tue, 09 Mar 2004 16:42:15 -0500
From: Ian Grigg <[email-masked]>
To: Mike Markowitz <[email-masked]>
CC: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: paper of interest to be presented at EuroCrypt
Sender: [email-masked]

Mike Markowitz wrote:
> Folks:
> 
> Since Hal just pointed to an RSA Conference paper, I thought I'd bring attention
> to an OpenPGP-related paper to be presented by Phong Nguyen at EuroCrypt in May.

A goodly post, although the paper worries
me somewhat on two points, the second of
which may be germane to OpenPGP, further
below.

> The abstract sounds like old news, but perhaps list subscribers will be interested
> anyway:
> 
> http://www.di.ens.fr/~pnguyen/pub.html#Ng04
> 
>     Abstract: More and more software use cryptography. But how can one know if
>     what is implemented is good cryptography? For proprietary software, one
>     cannot say much unless one proceeds to reverse-engineering, and history
>     tends to show that bad cryptography is much more frequent than good
>     cryptography there. Open source software thus sounds like a good solution,
>     but the fact that a source code can be read does not imply that it is
>     actually read, especially by cryptography experts. In this paper, we
>     illustrate this point by

Having read the paper here:

     ftp://ftp.di.ens.fr/pub/users/pnguyen/Eurocrypt04.ps

(at least the non heavy-crypto parts), I
think the above half-abstract is unsupported,
and probably disproven by the existence of
the paper itself.

As the paper presents no information on
anything about "good/bad cryptography"
and/or "open source" and/or "proprietary
software" and/or "reverse engineering",
it seems an out of place comment?

(As is the first paragraph of the paper
proper.)

In essence, the existence of GPG as an
open source crypto system has permitted
the author to examine the software and
find some potentially useful flaws.  That
would seem to be evidence to the contrary
of the point claimed above?

 >     examining the case of a basic Internet application
>     of cryptography: secure email. We analyze parts of the source code of the
>     latest version of GNU Privacy Guard (GnuPG or GPG), a free open source
>     alternative to the famous PGP software, compliant with the OpenPGP standard,
>     and included in most GNU/Linux distributions such as Debian, MandrakeSoft,
>     Red Hat and SuSE. We observe several cryptographic flaws in GPG v1.2.3. The
>     most serious flaw has been present in GPG for almost four years: we show
>     that as soon as one (GPG-generated) ElGamal signature of an arbitrary
>     message is released, one can recover the signer's private key in less than a
>     second on a PC. As a consequence, ElGamal signatures and the so-called
>     ElGamal sign+encrypt keys have recently been removed from GPG. Fortunately,
>     ElGamal was not GPG's default option for signing keys.

This part and the paper proper looks useful!
I recall the ElGamal signing keys are already
deprecated.

The paper also makes some comments concerning
OpenPGP weaknesses (sans exploits) of PKCS#1 v1.5
RSA encryption and signatures (section 4.2, 4.3).

    4.2 Encryption

    As already mentioned in Section 2, GPG implements
    RSA encryption as defined by PKCS#1 v1.5.  This is
    not state-of-the-art cryptography: like with
    ElGamel, Bleichenbacker's chosen-ciphertext [4]
    can decrypt any ciphertext.  But, as mentioned
    in 3.3, the relevance of such attacks to the email
    world is debatable, in part because of the high
    number of oracle calls.  We hope that future
    versions of the OpenPGP standard, will recommend
    better RSA encryption standards (see for instance
    PKCS#1 v2.1 [20] or NESSIE [8]).

Any comments?

Presumably it is way too late in the piece to
change these methods.  My question here would be
more along the lines of whether a warning comment
should be placed in the draft document?

(Apologies for not proposing the text for that!)

iang

PS: definately worth posting though.

[4] D. Bleichenbacker.  Generating ElGamal signatures
without knowing the secret key. In _Proc. of Eurocrypt
'96_, volume 1070 of LNCS, pages 10-18.  IACR, Springer-
Verlag, 1996.

Date: Tue, 9 Mar 2004 11:07:12 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: RSA conf paper on PGP web of trust
Sender: [email-masked]

Brian Peterson writes:
> The paper says:
> "We assume in this work that each user legitimately has exactly one,
> unique true (or valid) identity. An identity which does not belong to a
> real user is a false identity. We further assume each user can have, or be
> associated with, one or more public keys."
>
> This is all fine.  I think that the logical fallacy in the paper is
> assuming that signing the same public key with two of your signing keys is
> a malicious act, and should lower the trustworthiness of all your
> signatures.

I don't think they assume this, at least that is not how I understood
their model.  You can have multiple public keys but you are supposed
to make it clear that the all belong to the same person.  The main new
result in the paper is how to analyze the web of trust in that situation.

Here is an example to show why this can be complicated.  Suppose Charlie
has two keys, an RSA and a DSA key.  Alice certifies Charlie's RSA key
and Bob certifies Charlie's DSA key.  Now Charlie signs Doris's key with
his RSA key and Ellen's key with his DSA key.  In some respects the sigs
on Doris and Ellen have a common failure mode, namely that Charlie is
bad; but in other respects they have independent failure modes, that
one of Alice or Bob was bad and made up a fake Charlie key.

Dealing with these complexities in general is, according to the paper,
NP complete.  They provide some heuristics.  However I think a better
solution is to require users with multiple keys to fully cross certify
them, each key directly or indirectly signing all the others.  Then you
can assume that either all the keys belong to that user, or none of
them do.  This allows you to collapse the WoT graph by treating all the
keys belonging to a user as just one "virtual" key.

The main problem I see with their model is that they assume that you can
put a limit to the number of colluding bad users.  If you assume that
there are only n bad users, then if you can find n+1 separate validation
paths to a given key, you can conclude that it is good (factoring in
the multiple-keys-per-user issue).

The two problems with this requirement are, first, that it is hard to
come up with a reasonable n value without making it very large; and
secondly, their algorithm's performance appears to deteriorate quickly
with increasing n.  Their table 1 was based on a PGP keyring and as
n went from 1 to 2, the number of valid keys fell from 9992 to 77!
The lesson is that in practice there just aren't that many parallel,
independent certification paths.

Now, having said that, I must admit that all other trust models that I
am aware of have weaknesses of their own.  It seems that you can't have
both security against targeted attacks, and also a trust model which
makes a large percentage of valid keys be known to be valid.

> As this applies to implications for the OpenPGP Trust specification, I
> think it would be reasonable to specify that multiple signatures from
> different keys by the same partially trusted individual (identified by
> email adreess or possibly name) would be counted as only one valid
> partially trusted signature for the purposes of calculated trust.

Yes, I think that is a reasonable heuristic as part of the trust model.

Hal Finney

Date: Tue, 9 Mar 2004 09:34:46 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Mar 09, 2004 at 09:10:24AM -0500, David Shaw wrote:

> Without going into all the messy details, a V3 program is going to
> reject any message that doesn't use only RFC-1991 packets and packet
> constructions, the IDEA cipher, a session key from a RSA key that is
> less than 2112 bits, etc.
> 
> Proposed text to fix this is to add to the end of the paragraph:
> 
>   Note that when assembling a backwards compatible message, there may
>   be other issues that be resolved in addition to using the IDEA
>   cipher.
> 
> I'd also be fine with dropping the paragraph altogether if there is
> not much interest in supporting PGP 2.

Or, it should be said - I'm also fine with doing nothing.  2440bis is
not a programming guide, and this is hardly a world-shatteringly
important issue.

David

Date: Tue, 9 Mar 2004 09:10:24 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: IDEA in v3-v4 conflict (was Re: OpenPGP at IETF-59 Draft Minutes #1)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 08, 2004 at 09:16:10PM -0500, Derek Atkins wrote:

> * IDEA in the v3-v4 algorithm conflict:  Major issue the question of what
> support needs to be given to PGP 2 implementations.  No proposed text was
> presented so issue was punted back to the author.

This one was mine.  The problem I had was the draft suggests using
IDEA when encrypting to a mix of V3 and V4 keys.

Section 12.1 of the draft says:

   An implementation that is striving for backward compatibility MAY
   consider a V3 key with a V3 self-signature to be an implicit
   preference for IDEA, and no ability to do TripleDES. This is
   technically non-compliant, but an implementation MAY violate the
   above rule in this case only and use IDEA to encrypt the message,
   provided that the message creator is warned. Ideally, though, the
   implementation would follow the rule by actually generating two
   messages, because it is possible that the OpenPGP user's
   implementation does not have IDEA, and thus could not read the
   message. Consequently, an implementation MAY, but SHOULD NOT use
   IDEA in an algorithm conflict with a V3 key.

It's a reasonable suggestion on the face of it, but it is insufficient
in practice.

Without going into all the messy details, a V3 program is going to
reject any message that doesn't use only RFC-1991 packets and packet
constructions, the IDEA cipher, a session key from a RSA key that is
less than 2112 bits, etc.

Proposed text to fix this is to add to the end of the paragraph:

  Note that when assembling a backwards compatible message, there may
  be other issues that be resolved in addition to using the IDEA
  cipher.

I'd also be fine with dropping the paragraph altogether if there is
not much interest in supporting PGP 2.

David

Date: Tue, 09 Mar 2004 12:23:26 +0000
From: Ben Laurie <[email-masked]>
To: Bill Frantz <[email-masked]>
Cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: RSA conf paper on PGP web of trust
Sender: [email-masked]

Bill Frantz wrote:

> At 10:51 AM -0800 3/5/04, Hal Finney wrote:
> 
>>I just noticed that a paper was published at the RSA conference with
>>concepts that might be relevant to the PGP web of trust.
>>
>>http://discovery.csc.ncsu.edu/~pning/pubs/robust-keyrings.pdf
>>
>>...
>>
>>The new paper does not use a probabilistic model, but rather assumes
>>that users are either malicious or reliable.  It attempts to distinguish
>>the two by detecting conflicts, where the same identity is bound to
>>two different keys.  It takes such a conflict as evidence of malicious
>>behavior and uses graph theory to try to figure out which keys are the
>>malicious ones.  These can then be eliminated from the WoT and then the
>>resulting signatures are taken to be correct.
> 
> 
> Wouldn't this be a common situation if someone replaces a key for hygiene
> reasons, but does not revoke the previous key (on the basis that the old
> key hasn't been proven bad, and some people may not have the new one)?

Or, like me, where I have an RSA key and a DSA key...

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Mon, 8 Mar 2004 20:26:37 -0800
To: "Hal Finney" <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: RSA conf paper on PGP web of trust
Sender: [email-masked]

At 10:51 AM -0800 3/5/04, Hal Finney wrote:
>I just noticed that a paper was published at the RSA conference with
>concepts that might be relevant to the PGP web of trust.
>
>http://discovery.csc.ncsu.edu/~pning/pubs/robust-keyrings.pdf
>
>...
>
>The new paper does not use a probabilistic model, but rather assumes
>that users are either malicious or reliable.  It attempts to distinguish
>the two by detecting conflicts, where the same identity is bound to
>two different keys.  It takes such a conflict as evidence of malicious
>behavior and uses graph theory to try to figure out which keys are the
>malicious ones.  These can then be eliminated from the WoT and then the
>resulting signatures are taken to be correct.

Wouldn't this be a common situation if someone replaces a key for hygiene
reasons, but does not revoke the previous key (on the basis that the old
key hasn't been proven bad, and some people may not have the new one)?

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | "There's nothing so clear as a | Periwinkle
(408)356-8506      | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble     | Los Gatos, CA 95032

To: [email-masked]
Subject: OpenPGP at IETF-59 Draft Minutes #1
From: Derek Atkins <[email-masked]>
Date: Mon, 08 Mar 2004 21:16:10 -0500
Sender: [email-masked]

--=-=-=

Enclosed please find the the draft minutes of the OpenPGP meeting at
IETF-59.  Please comment if there are any errors or ommisions.

-derek

--=-=-=
Content-Disposition: attachment; filename=ietf-59-minutes.txt
Content-Description: IETF-59 OpenPGP Minutes

OpenPGP, IETF-59
Seoul, South Korea
March 2, 2004
1300-1400

minutes by: Jim Schaad

Derek opened the meeting with agenda bashing and appointment of a meeting
secretary.

STATUS OF RFC 2440BIS:  The document has been around since 2001 and the
group needs to finish it.  The current draft is -09 with one update known to
be coming.  Derek presented the issues on the document since the editor was
not able to attend the IETF meeting.

Derek covered the set of closed issues on the document.  These issues are:

* Clarifications on the construction of compressed messages
* Non-Textual User IDs, they must now be UTF-8 strings only
* Addition of a discrete log hash, no strong support for doing this so it
  will not be done.
* Comment line length - no consensus for this issue developed on the mailing
  list so no changes are going to be made for this issue. 

Derek covered the set of open issues on the document.  (Titles of the items
correspond to the mail thread subject name.) These issues are:

* Signature woes & Reconciliation: Text has been proposed to resolve
this issue.  This was accepted without comment from the attendees.

* Trailing White Space: The issue is that some e-mail gateways strip
trailing white space on lines when processing mail messages.  This
cause signature validation failure at later date.  The question is
whether this is an issue that needs to be addressed.

One proposal is to strip EOL characters where the character <= 0x20.  From
the floor it was pointed out that this could cause problems from two things.
1) there are some control characters that may be part of the text stream
(such as page feeds) that should not be stripped and 2) for some languages
escape characters for local language processing might produce characters
that are in this character range and thus produce corruption of the text.

One suggestion was to do the standard MIME time canonicalization and ignore
the rest of the issues.  If the message is changed by stripping spaces in a
gateway, then the message correctly fails validation.

As no text has been proposed or was proposed from the floor the issue was
punted back to the authors to propose some text.

* IDEA in the v3-v4 algorithm conflict:  Major issue the question of what
support needs to be given to PGP 2 implementations.  No proposed text was
presented so issue was punted back to the author.

* 3rd party signatures in a one-pass signed message:  This issue is not
currently addressed in -09.  Text has been proposed to address this issue
and was accepted.

*Obsolete 1991:  Question is should rfc2440-bis obsolete RFC 1991 as well as
RFC 2440 when it progresses.  This was the consensus of the room.
 
* Back-signatures from a signing sub-key onto the primary key:  Text has
been supplied to address this issue by the author, the text was accepted by
the working group.

* Non UTF-8 Text in Message Body:  Should a charset on the armor header be
specified for non UTF-8 text?  No text has been proposed to address this
issue.  This has been punted back for proposed text by either Felix or the
authors.

* Remove Elgamal signatures (type 20):  Some security weaknesses have been
identified in the Elgamal signature scheme used.  The recommendation is to
remove it from the standard.  The group accepted this without comment.

* Partial length chucks and 5-byte lengths:  One reading of the text appears
to disallow 5-byte length items.  Authors have proposed a new text to deal
with this issue.  Text was accepted by the group.

* "cleartext signatures" naming convention:  This is just and editorial
issue.  The proposal is to move from several different ways of describing
the cleartext signature concept by a single string.  The list of locations
has been provided and the author is to make the changes.

* MDC Inconsistent in bis-09:  There are two places where this process is
described and they are inconsistent with each other.  Section 5.14 is the
one that does not match existing code so it will be modified to match the
other section.

* Secret Key Packet Formats:  This is just a set of editorial changes, and
were accepted by the group.

RECHARTERING OF THE GROUP.

Need to update the milestones to match current timeframe.  The current items
point to 2001.  Proposal is:
        - 2440bis to IESG: May 04 - Proposed
        - multiple sig draft - Remove this from the milestone list as it's
          purpose and authors are not known
        - Interop testing to start Aug 2004
        - Advance to draft about Feb 05.

--=-=-=

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

--=-=-=--

Date: Mon, 08 Mar 2004 16:48:31 -0600
To: "Hal Finney" <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: paper of interest to be presented at EuroCrypt
Cc: [email-masked]
Sender: [email-masked]

<html>
<body>
Folks:<br><br>
Since Hal just pointed to an RSA Conference paper, I thought I'd bring
attention <br>
to an OpenPGP-related paper to be presented by Phong Nguyen at EuroCrypt
in May.<br>
The abstract sounds like old news, but perhaps list subscribers will be
interested<br>
anyway:<br><br>
<a href="http://www.di.ens.fr/~pnguyen/pub.html#Ng04" eudora="autourl">http://www.di.ens.fr/~pnguyen/pub.html#Ng04<br><br>
</a>
<dl>
<dd>Abstract:</b> More and more software use cryptography. But how can
one know if what is implemented is good cryptography? For proprietary
software, one cannot say much unless one proceeds to reverse-engineering,
and history tends to show that bad cryptography is much more frequent
than good cryptography there. Open source software thus sounds like a
good solution, but the fact that a source code can be read does not imply
that it is actually read, especially by cryptography experts. In this
paper, we illustrate this point by examining the case of a basic Internet
application of cryptography: secure email. We analyze parts of the source
code of the latest version of GNU Privacy Guard (GnuPG or GPG), a free
open source alternative to the famous PGP software, compliant with the
OpenPGP standard, and included in most GNU/Linux distributions such as
Debian, MandrakeSoft, Red Hat and SuSE. We observe several cryptographic
flaws in GPG v1.2.3. The most serious flaw has been present in GPG for
almost four years: we show that as soon as one (GPG-generated) ElGamal
signature of an arbitrary message is released, one can recover the
signer's private key in less than a second on a PC. As a consequence,
ElGamal signatures and the so-called ElGamal sign+encrypt keys have
recently been removed from GPG. Fortunately, ElGamal was not GPG's
default option for signing keys. <br><br>
<br><br>

</dl>-mjm<br><br>
<x-sigsep><p></x-sigsep>
==========<br>
Michael J. Markowitz, Ph.D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Email: [email-masked]<br>
Vice President
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Voice: 708-445-1704 (Oak Park)<br>
Information Security
Corporation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
847-405-0500 (Deerfield)<br>
1011 Lake Street, Suite 212&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; 708-445-9705<br>
Oak Park, IL&nbsp;
60301&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
WWW:&nbsp;&nbsp;
<a href="http://www.infoseccorp.com/" eudora="autourl">http://www.infoseccorp.com</a>&nbsp;&nbsp;
</body>
</html>

Date: Fri, 5 Mar 2004 10:51:24 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: RSA conf paper on PGP web of trust
Sender: [email-masked]

I just noticed that a paper was published at the RSA conference with
concepts that might be relevant to the PGP web of trust.

http://discovery.csc.ncsu.edu/~pning/pubs/robust-keyrings.pdf

Improving Robustness of PGP Keyrings by Conflict Detection, by Q Jiang
et al of North Carolina State University.

One concept they discuss is the use of redundancy in the WoT.  This idea
goes back to PGP 2; you can mark introducers as partially trusted,
and then if you have two chains of trust leading to the same key, both
partial, this can add up to full validity.  We extended this internally
in later versions of PGP to support full probabilistic calculation based
on a paper by Ueli Maurer.

However a problem with this is that if a user has two keys, both marked
as partially trusted, and both sign a third key, that key can end up
as fully valid, even though only one user signed it.  Internally at
PGP.com we discussed this years ago and thought about providing a way
to indicate that one or more keys were controlled by the same user,
but the UI would be so complex that we gave up on it.  (Ironically,
the sample keyring we distributed at one point had two keys on it by the
same person, with both keys signing other keys on the keyring, so we were
setting up a situation which practically begged for this flaw to show up.)

The new paper does not use a probabilistic model, but rather assumes
that users are either malicious or reliable.  It attempts to distinguish
the two by detecting conflicts, where the same identity is bound to
two different keys.  It takes such a conflict as evidence of malicious
behavior and uses graph theory to try to figure out which keys are the
malicious ones.  These can then be eliminated from the WoT and then the
resulting signatures are taken to be correct.

There is a large literature on trust issues in WoT-like structures.
I'll see if I can find an up-to-date bibliography on the subject, or
perhaps someone here knows of one.

Hal Finney

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: OpenPGP Meeting Summary
From: Derek Atkins <[email-masked]>
Date: Thu, 04 Mar 2004 00:44:23 -0500
Sender: [email-masked]

The following is a short summary of what transpired at the OpenPGP
meeting on March 2nd.  Full minutes will be forthcoming.

-derek

OpenPGP met for about 30 minutes on Tuesday.  We discussed status of
2440bis, the list of document issues, and the wg milestones.

STATUS OF RFC 2440BIS:  The document has been opened since 2001 and the
group needs to finish it.  The current draft is -09 with one update known to
be coming.

2440BIS ISSUES: We went through the list of issues.  Many of them were
accepted without comment from the audience.  Issues without proposed
text will be sent back to the originator.  There was some discussion
about end-of-line whitespace canonicalization issues, but again it was
decided to push back to the creator of the issue to actually propose
some text.

MILESTONES: We decided on the the following updated milestones:
        - 2440bis to IESG: May 04 - Proposed
        - multiple sig draft - Remove this from the milestone list aa it's
                               purpose and authors are not known
        - Interop testing to start Aug 2004
        - Advance to draft about Feb 05.

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

Date: Tue, 2 Mar 2004 10:54:53 +0100
To: Len Sassaman <[email-masked]>
Cc: Ian Grigg <[email-masked]>, "Weins, Thorsten" <[email-masked]>, [email-masked]
Subject: Re: Trust Packets
From: Florian Weimer <[email-masked]>
Sender: [email-masked]

Len Sassaman wrote:

> I wouldn't say that they didn't define trust. PGP has internal trust
> calculation algorithms, which happen not to be documented within the IETF.
> I have always thought this unfortunate. I agree that trust calculation
> should be orthogonal to the OpenPGP message format specification, but I do
> wish that it were documented.

Well, right now, the format specification already specifies some parts
of the trust model (issues surrounding revocation, for instance).  This
should probably removed from the format spec, to preserve orthogonality.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: OpenPGP Trust Algorithm
From: Derek Atkins <[email-masked]>
Date: Mon, 01 Mar 2004 19:12:52 -0500
Sender: [email-masked]

Len Sassaman <[email-masked]> writes:

> I wouldn't say that they didn't define trust. PGP has internal trust
> calculation algorithms, which happen not to be documented within the IETF.
> I have always thought this unfortunate. I agree that trust calculation
> should be orthogonal to the OpenPGP message format specification, but I do
> wish that it were documented.

You are welcome to write an I-D that describes this algorithm
and present it to the working group.  I think this would be in-scope,
and if not we could recharter to include it.

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
From: Derek Atkins <[email-masked]>
Date: Mon, 01 Mar 2004 17:49:42 -0500
Sender: [email-masked]

Sorry for the delay in responding to this thread.

It does appear that there is no consensus to make a change to the text
on this matter.  You are correct that PGP goes to some lengths to try
to protect itself from transmission errors or corruptions.  However it
still makes some assumptions about the transmission medium and what it
will do to its messages.

You are correct that OpenPGP is designed for more than just email.
However other transmission mediums tend to have even fewer restrictions
than email, so changes do not appear to be warranted.

Security programs are built with some basic assumptions.  For example,
you assume that TCP will actually deliver your packets (OpenPGP certainly
does not worry about TCP DoS attacks).  Following that logic, it is
reasonable to make some basic assumptions about lower-layer behavior.

Also I'll keep in point that the comment is also (generally)
user-settable, so users can always shoot themselves in the foot.

-derek

Ian Grigg <[email-masked]> writes:

> [email-masked] wrote:
>> 
>> On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote:
>> >
>> > Such as:
>> >
>> > Version: 1.0.0 non-commercial, upgrade to
>> > Version: 2.0.0-commercial
>> >
>> > When the line slicing behaviour is set to (about) column 42.
>> 
>> If I have to set my line width to 42, your mail system is so broken
>> that I don't need to talk to it. 72 is reasonable, and and one should
>> expect lines exceeding 80 characters to be wrapped. Anything under 68 is
>> unreasonably small. I, for example, am using 72 character lines in my
>> editor (vim).
>
>
> It does appear to be the consensus that there
> is no need or desire to change the ID on this
> issue.  However, I'm not seeing a lot of real
> consideration of the real points here.  So  I'm
> unclear here whether to keep kicking this dying
> horse, or perhaps Derik could rule on closing
> it?
>
> ?  I disagree with the above logic on the
> following grounds:
>
>    OpenPGP is not only used for mail, and in
>    fact takes great care to be more universally
>    useful (scan the ID for the word "mail", I
>    just did!).  We here should also strive to
>    move from the particular to the general, when
>    looking at examples, and back again.
>
>    Security standards are not built on such
>    considerations of "yours is broken because
>    I don't like your numbers."  Bad software
>    is certainly built with those sorts of
>    criteria, but bad software is not what we
>    are about here.  This is about security,
>    so detail is important.
>
>    The offending number chosen was related to
>    the example;  the point remains with an
>    example of a different number.  You pick.
>
>    Notwithstanding many peoples' desires to
>    impose their views of how mail works on
>    the rest of the world, there are other
>    mail considerations in the future:  PDAs
>    and phones have smaller screens, for example.
>    Web mailers and hush-style mailers can be
>    very unkind to formatters.  Chat is replacing
>    email....  the list goes on - if OpenPGP is
>    to be based on the email view of the past,
>    then, we should all stop work on it right
>    now.
>
> The greatest success comes when multiple
> competing implementations communicate with
> ease, and without games.  Here we have a case
> where it is apparently easy to legally create
> a correct message that gets turned into a
> recipient message of indeterminate legality
> by transport.
>
> Fixing this costs nobody much at all [1].
>
>
>> if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ')
>>         exit(1);
>
>
> Please make sure you read the entire example.
>
> That doesn't decide which line of the two lines
> in the previous text, post-slicing, goes on to
> become the dominating one.
>
> The game to play in security programming is to see
> if a) we can confuse the other party, and b) we can
> create a security breach out of a confusion.
>
> We've shown a).  I grant b) is a little harder, as
> optional headers aren't supposed to be "used" for
> such things.  But, who knows what adventurous souls
> have in their minds for the future... [2]
>
>
> iang
>
>
> [1] I just thought late last night how to breach
> b)...  Imagine you are a company selling a device
> that filters on the headers.  Imagine that you
> make commercial decisions on the basis of those
> headers.  (Because that's all you can read.)  Then,
> an enterprising young chap realises that all he
> has to do is to slice the headers, and they are
> still human-readable, but they bypass the filtering
> of the proxy that handles incoming messages.
>
> marketing reference: NY AG v. WS == 1.3 bn.
>
> [2]  the guys
> over at PGP Inc might want to rewrite their
> comment to be a bit shorter than the ASCII-
> Armoured data lines - rule of thumb - and to
> change the extra ": " to some other symbol.
>
> If they haven't already done these steps,
> I'd be very surprised!  Also, they should
> reject sliced headers, or suggest we change
> the ID on that point.  But, no real cost.
>
> GPG might want to detect and warn that the
> headers appear corrupted and can be fixed
> easily with an editor, rather than silently
> bailing on ID strictness.
>
>

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