Subject: Re: version 3 header & USER ID packet

From: "Michael Young" <[email-masked]>
Date: Tue, 31 Oct 2000 11:15:54 -0500

>> > We have been reading a public key-ring and have noticed that the CTB for
>> > the user id is:
>> >
>> > 10110101 that says:
...
>This key-ring that was extracted is from any one of the key-servers located at:
>http://www.rediris.es/cert/index.en.html or:
>0xFC4CC190

The key I got back has 0xb4 (10110100) as the header byte for the user packet,
indicating a one-byte length.  The whole thing parsed just fine for me.

---

From: Erron Criddle <[email-masked]>
Date: Wed, 01 Nov 2000 09:47:27 +0800

>indicating a one-byte length.  The whole thing parsed just fine for me.

Funny enough, so did we when I got the programmer to look at it 
again...apparently he changed some code last night and now its producing 
the right result!!!

Sorry for the wasted bandwidth :)

Also Michael, thanks for re-analysis :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

Date: Wed, 01 Nov 2000 09:47:27 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: version 3 header & USER ID packet
Cc: "Michael Young" <[email-masked]>
Sender: [email-masked]

>indicating a one-byte length.  The whole thing parsed just fine for me.

Funny enough, so did we when I got the programmer to look at it 
again...apparently he changed some code last night and now its producing 
the right result!!!

Sorry for the wasted bandwidth :)

Also Michael, thanks for re-analysis :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: version 3 header & USER ID packet
Date: Tue, 31 Oct 2000 11:15:54 -0500
Sender: [email-masked]

...

Date: Tue, 31 Oct 2000 15:42:15 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: version 3 header & USER ID packet
Cc: [email-masked]
Sender: [email-masked]

At 10:22 AM 30/10/2000 -0800, [email-masked] wrote:

>Erron writes:
> > 10: Version 3 header
> > 1101: User ID packet
> > 01: 2 octet length
> > Now when I read the "File Formats Used by PGP 2.x", it says (under the 
> User
> > ID packet) that a User ID packet has a length of 1 octet.
>
>If the CTB says there is a two byte length, there better be a two byte
>length.  It doesn't matter what "File Formats used by PGP 2.x" says,
>after all, this CTB may not have been created by PGP 2.x.

not in this case.

>Was there in fact a two byte length in this userid packet?

no.

>   I.e. did the next two bytes look like a reasonable length field?  If 
> so, just use them.
>If not, then it's a bad keyring.

The version 3 CTB's  last 2 bits were 01, indicating a two byte length 
field, however there was only one length byte (this worked in with the 
length of the User ID field (39 octets)).

Has anyone else any comments on this?

http://math-www.uni-paderborn.de/pgp/  or:

http://keys.pgp.com:11371/     (the NAI server!)

using the keyword of:

0xFC4CC190

As many PGP key-servers contain this key-ring with a 2 byte length 
identifier in the CTB (see http://www.openpgp.net/pgpsrv.html) and a 1 byte 
length identifier for the actual User ID packet, what should we do? Should 
we accept it or have all the keyservers change their software so they check 
each transferred key-ring for mistakes like these? The latter seems a very 
large task.

Or is it easier to assume a 1 octet length indentifier for the User ID?

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

From: [email-masked]
Date: Mon, 30 Oct 2000 10:22:57 -0800
To: [email-masked], [email-masked]
Subject: Re: version 3 header & USER ID packet
Sender: [email-masked]

Erron writes:
> 10: Version 3 header
> 1101: User ID packet
> 01: 2 octet length
> Now when I read the "File Formats Used by PGP 2.x", it says (under the User 
> ID packet) that a User ID packet has a length of 1 octet.

If the CTB says there is a two byte length, there better be a two byte
length.  It doesn't matter what "File Formats used by PGP 2.x" says,
after all, this CTB may not have been created by PGP 2.x.

Was there in fact a two byte length in this userid packet?  I.e. did the
next two bytes look like a reasonable length field?  If so, just use them.
If not, then it's a bad keyring.

Hal

Date: Mon, 30 Oct 2000 16:40:26 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: version 3 header & USER ID packet
Sender: [email-masked]

To all,

10110101 that says:

10: Version 3 header
1101: User ID packet
01: 2 octet length

Now when I read the "File Formats Used by PGP 2.x", it says (under the User 
ID packet) that a User ID packet has a length of 1 octet.

 From this, either two things have happened:

a) The program that wrote the key-ring has used a default "two byte" length 
identifier when a CTB is created and when the User ID CTB has been created 
it simply leaves this as the User ID always uses a 1 octet length 
identifier with a version 3 header (as "File Formats used by PGP 2.x" 
indicates).

b) The public key-ring is bad.

Now, if b) should be followed then OK, however if a) should be followed, is 
there any other packets that follow this peculiar line?

I though that when a version 3 CTB is created for a User ID, it should read 
10110100, indicating a 1 octet length for the user ID, not 10110101???

TIA for the clarification...

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: MDC Usage
Date: Fri, 27 Oct 2000 11:51:12 -0400
Sender: [email-masked]

As the name suggests, an MDC helps detect modifications.  Without an MDC,
an attacker has a fair chance of changing the end of the file without it
being noticed.

Suppose I change a byte in the last cipher-block of a "classic PGP" message.
Because PGP uses a CFB mode, this changes the corresponding byte of the
plaintext, and nothing else.  (It would completely change subsequent blocks,
but there aren't any more.)  If the plaintext is human-readable text, there is
a fair chance that this would change one word to another, such that the human
reader won't realize that tampering had occurred.  Worse, if the data has no
internal consistency check (raw binary data), this attack could be applied to
anything after the salt+2 check bytes.  If the message is encoded using the
indeterminate packet length feature, an attacker could also just truncate the
message.

The MDC itself is redundant data that can be used as a consistency check.
The variant on the symmetric data packet is necessary to ensure that
a receiver knows an MDC packet will appear, both so that it can hash
the plaintext as it goes and so that it can detect the MDC being cut off;
it uses a different CFB resync to make it harder to tweak this new packet
into an old one undetected (at which point the MDC could be stripped).

There was a lengthy discussion on the MDC proposal on the mailing list.
(I wasn't reading it at the time, but img.org maintains an archive.)

Date: Fri, 27 Oct 2000 16:47:22 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: 2 octet length determination
Sender: [email-masked]

To all,

After a lot of "wondering" about how to write a version 4 two octet length, 
I thought it would be nice to post this for a two octet length (192 to 8383 
octets):

let a  = (total data packet length) - 192

let bc = two octet representation of a

let d = b + 192

 From this, the two octet value to write is equal to dc.

Nice and easy :)

2440bis/4.2.2.2 tells you how to determine that packet length from a two 
octet length, however it does not tell you how to code the two octet length 
packet and it may be worth adding the above simplified formula for us dummies.

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

Date: Fri, 27 Oct 2000 10:39:00 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDC Usage
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 27 Oct 2000, Erron Criddle wrote:

> I was wondering where\why you would use the tag 18 and 19 packets?

To replace packet 9.

To avoid attacks like "A Choosen Ciphertext Attack Against Several
E-Mail Encryption Protocols" by Katz and Schneier, June 23rd, 2000
presented at the last [I am not sure] Crypto - you should be able to
find that paper at the Counterpane site.

  Werner

Date: Fri, 27 Oct 2000 14:37:54 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: MDC Usage
Sender: [email-masked]

To all,

I was wondering where\why you would use the tag 18 and 19 packets?

TIA.

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

Date: Mon, 23 Oct 2000 12:23:13 -0400
From: Tom Zerucha <[email-masked]>
To: Erron Criddle <[email-masked]>
Cc: [email-masked]
Subject: Re: the joys of public key-rings (NOT)
Sender: [email-masked]

On Mon, Oct 23, 2000 at 03:16:33PM +0800, Erron Criddle wrote:
> To all,
> 
> We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new 
> format (OpenPGP) header (0xC6) with a version 4 public key (new format 
> packet), we are getting an old format header (0x99) with a version 4 public 
> key (new format packet)!

This is withing spec.

> So, what to do for the transfer of public key-rings????
> 
> Do we use:
> 
> 1) old format headers with old format packets
> 2) old format headers with new format packets
> 3) new format headers with old format packets, or:
> 4) new format headers with new format packets???

Yes.  In that you should accept all formats.  The header/encapsulation
should be separate from the actual packet formats.

> Please help as we are just sitting here drinking lots and want to get back 
> to programming and testing...

If you want to be nice, you should encapsulate old format packets in
old format headers, and new in new.

From: "Michael Young" <[email-masked]>
To: "Erron Criddle" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: the joys of public key-rings (NOT)
Date: Mon, 23 Oct 2000 12:05:31 -0400
Sender: [email-masked]

Are you asking whether it's legal to use an old-style header (single byte for
tag + length) on a version-4 key?  Yes, it's legal to use old-style headers
whenever you are able.

Is it legal to use a new-style header on a version-3 key?  Sure, if you don't
care about PGP2 compatibility.

Is it legal to generate the same key value in both version-3 and version-4 forms?
Yes, but since signatures hash the whole key packet, they will refer to
only one version or the other, so you can't mix and match.  (You could
also have the same key value with different creation times, which would
all hash differently, and in v4 would generate different fingerprints.)

Are you asking what you should generate?  If you know in advance that you're
generating material that PGP2 won't understand, you might use a new-style packet
to catch the incompatibility right away.  If you don't know, you might use old-style.

Some other esoteric considerations (that you probably should ignore):
  If you get all excited about extra bytes, old-style encoding can be shorter.

  If you don't want to compute packet lengths up front, it would appear that an
  old-style indeterminate-length packet is legal for a single key in a file, but the
  new-style partial-body scheme is not.

Date: Mon, 23 Oct 2000 15:16:33 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: the joys of public key-rings (NOT)
Sender: [email-masked]

To all,

We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new 
format (OpenPGP) header (0xC6) with a version 4 public key (new format 
packet), we are getting an old format header (0x99) with a version 4 public 
key (new format packet)!

So, what to do for the transfer of public key-rings????

Do we use:

1) old format headers with old format packets
2) old format headers with new format packets
3) new format headers with old format packets, or:
4) new format headers with new format packets???

Please help as we are just sitting here drinking lots and want to get back 
to programming and testing...

TIA.

Date: Mon, 23 Oct 2000 13:41:10 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Public Key-Rings
Sender: [email-masked]

To all,

We have downloaded a PGP 5.0 Key from a key-server and, expecting a CTB as 
the first byte (ie 0xC6) of the public key-ring, we are getting 0x99...

Does anyone know WTF is going on?

Also, if we are reading some other format/version of a "transferable public 
key" other than OpenPGP, does anyone know of a key-server whereby we can 
obtain "transferable public key" data based on OpenPGP for testing purposes?

Thanks for any info (and excuse me if I'm missing something :)

Date: Fri, 20 Oct 2000 07:56:26 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDC, gnupg 1.0.3,  and PGP7
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, 19 Oct 2000, Michael Young wrote:

> Do you still have the examples generated by PGP7 that you used for
> interoperability testing?

See Hal's mail.

> >The MDC packet is not listed due to a bug/implementation issue.
> 
> 
> Do you believe the bug is in the generation, or in the parsing?

No, it is due to the way it is implemented.  The MDC check is done
by the decryption fucntion.

> I believe that it's in the generation: the compressed data packet uses
> an old-style indeterminate length, leading your parser (and mine) to

I am not sure but I thing this is allowed.

   Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

From: [email-masked]
Date: Thu, 19 Oct 2000 15:26:57 -0700
To: [email-masked], [email-masked]
Subject: Re: MDC, gnupg 1.0.3,  and PGP7
Sender: [email-masked]

Here are two MDC test messages created by PGP 7.  The first uses Twofish,
the second 3DES.  The passphrase for each is "test".  I wanted to test
both to make sure we interoperate properly with both 64 bit and 128 bit
block ciphers.

Hal

-----BEGIN PGP MESSAGE-----
Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A
ll rights reserved.

qANQR1DDDQQKAwKbEffw1iOFWWDSagG2TUxTd8SWAFCCrwUfH+T0ENGoWmmL+R07
8ZD9CB3OnyBqz/zEVBi4aOrbuYPbJMCImPIt669wwIUx0XmaxwLQZufRCbnU/z1g
H/ElneG43J83HCFsHsFGtT7V6Uzq1nOjGaX9Dxpma8I=
=tXQ6
-----END PGP MESSAGE-----

-----BEGIN PGP MESSAGE-----
Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A
ll rights reserved.

qANQR1DDDQQCAwIQP0qEoEdt7WDSYgHJNchv5Om9R1y9QkMlDO0JPPCbVPcPLkhy
U8ynd+LiJeqx2CZjKtyZUIBv+Osj/ZOpMRju9lClQvLUiyjmJbYyN9+7mcT+r7aV
vBEXhpFtMQgWvQP0jp7KQGRQKTXeBRsr
=WKzv
-----END PGP MESSAGE-----

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: MDC, gnupg 1.0.3,  and PGP7
Date: Thu, 19 Oct 2000 14:15:57 -0400
Sender: [email-masked]

Thanks for the examples from 1.0.4a.

Do you still have the examples generated by PGP7 that you used for
interoperability testing?

>And here come the same thing with compression:
...
>The MDC packet is not listed due to a bug/implementation issue.

Do you believe the bug is in the generation, or in the parsing?
I believe that it's in the generation: the compressed data packet uses
an old-style indeterminate length, leading your parser (and mine) to
treat the MDC packet as contained within it.

Date: Thu, 19 Oct 2000 10:47:01 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: MDC, gnupg 1.0.3,  and PGP7
Sender: [email-masked]

In our last episode ("Re: MDC, gnupg 1.0.3,  and PGP7", shown on 10/19/00),
Werner Koch said:

>The MDC packet is not listed due to a bug/implementation issue.
>
>From packet.h:
>	PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */
>	PKT_MDC 	  =19, /* manipulaion detection code packet */
>

I only do what the voices in my head tell me to. This time, the voices told
me to use 15 and 16. :-) I'm changing them to 18 and 19.

Send me some more changes/additions, folks and they'll go in, too.
Otherwise, in a week or so, I'll just fling out another draft with this
correction.

	Jon

Date: Thu, 19 Oct 2000 17:53:09 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDC, gnupg 1.0.3,  and PGP7
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, 19 Oct 2000, Michael Young wrote:

> revision of June 15 is dead.  [That revision used tags 18 and 19, and

18 and 19 is right.

> I note that gnupg 1.0.3 uses tag 18.  As I started to write this, I noticed
> that 1.0.4 was release in source form yesterday -- does it use tag 15 again?

No.

> Werner Koch's recent reply suggests that PGP7 also uses tag 15.

I was wrong, it uses 18,19 and I did some interoperability tests.

> Would someone be willing to post a sample encryption from PGP7 that uses
> an MDC and Twofish?  (I'd also love to see a secret key packet encrypted

Passphrase "test"

Here are the packets:

symkey enc packet: version 4, cipher 10, s2k 3, hash 2
	salt 503a47a468e26509, count 96
:encrypted data packet:
	length: 137
	mdc_method: 2
:literal data packet:
	mode b, created 971969290, name="geheim",
	raw data: 83 bytes
:mdc packet: length=20

And here come the same thing with compression:

:symkey enc packet: version 4, cipher 10, s2k 3, hash 2
	salt f8c920d888fc458a, count 96
:encrypted data packet:
	length: 135
	mdc_method: 2
:compressed packet: algo=1
:literal data packet:
	mode b, created 971969488, name="geheim",
	raw data: 83 bytes

The MDC packet is not listed due to a bug/implementation issue.

>From packet.h:
	PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */
	PKT_MDC 	  =19, /* manipulaion detection code packet */

Hth,

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: MDC, gnupg 1.0.3,  and PGP7
Date: Thu, 19 Oct 2000 00:18:06 -0400
Sender: [email-masked]

I gather from Jon Callas's recent MDC spec message that his proposed
revision of June 15 is dead.  [That revision used tags 18 and 19, and
purported to have the hash include the block+2 salt bytes (but wasn't
changed consistently).]  Is that right?

I note that gnupg 1.0.3 uses tag 18.  As I started to write this, I noticed
that 1.0.4 was release in source form yesterday -- does it use tag 15 again?

Werner Koch's recent reply suggests that PGP7 also uses tag 15.
Would someone be willing to post a sample encryption from PGP7 that uses
an MDC and Twofish?  (I'd also love to see a secret key packet encrypted
with Twofish.)

My understanding of a reasonable packet sequence and proper containment
is as follows:
    zero or more PKE- or SKE- session-key packets
    Protected-SE-data packet (tag 15) {
        version "1";
        encrypted<
            block-size+2 random data (last two bytes repeated);
                % some packet(s?) { ... } -- typically a Compressed-data packet
                MDC packet (tag 16) % { 20-byte SHA hash result }
    }

where the hash occurs over the data between the two %-signs.

The gnupg 1.0.3 release generates roughly this format, but it uses an indeterminate
size for the Compressed-data packet.  An implementation that treats an indeterminate
size as that of the containing file or packet, as I think the spec implies, would consider
the MDC packet to be extraneous junk at the end of the Compressed-data packet.
Moreover, this approach won't work for the "uncompressed" algorithm, or for
a Literal-data or other packets in the payload.  Given that an MDC packet will follow, the
receiver must understand new-style packets, so a partial-body representation should
always be valid.  Does this sound reasonable?  [I apologize to Werner Koch for
asking about his implementation in public, but I thought others might have yet other
ideas on how this ought to work.]

Would it be reasonable to specify the encrypted payload more precisely, something like
"a sequence of OpenPGP packets, ending with an MDC packet"?  The MDC packet
section loosely implies this, but I think it would help to say so in the Protected-SE data
packet section explicitly.

Date: Mon, 16 Oct 2000 11:44:46 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: ElGamal & DSA Sample Keys
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 16 Oct 2000, Erron Criddle wrote:

> To all,
> 
> I know this may be a bit off track, however I am looking for 2048 bit 
> ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys.

$ gpg --gen-key

$ gpg --with-key-data --list-key my-new-key

See doc/DETAILS or g10/keylist.c for the format of the output.

Ciao,

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

Date: Mon, 16 Oct 2000 11:16:06 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: ElGamal & DSA Sample Keys
Sender: [email-masked]

To all,

I know this may be a bit off track, however I am looking for 2048 bit 
ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys.

If anyone knows where I can generate/obtain these from it would be much 
appreciated as we need to do some testing :)

TIA.

Date: Thu, 12 Oct 2000 11:40:02 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Another draft is going out
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 11 Oct 2000, Jon Callas wrote:

> I don't think that tying MDC and big blocks is a good idea -- in the spec.

The idea established at the time we introduced Twofish and talked
about MDC.  I suggested to wait with Twofish until we worked out the
MDC stuff.  Anyway, the specs are getting more and more complex, so
we better don't do what I suggested.

> If you want to limit use more, I have a suggestion: we put in a "feature"
> of 128-bit-block ciphers. That way you can declare whether you use them or

Too complicated.  We already have the preferences and issue a
warning when a received message is not encrypted by an algorithm
listed in the preferences.  So we can have the same effect by
setting up the preferences right and issue a warning when the MUST
algorithm 3DES has been used without MDC.

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

Date: Wed, 11 Oct 2000 11:59:53 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Another draft is going out
Sender: [email-masked]

At 11:25 AM +0200 10/11/00, Werner Koch wrote:

>Another point:
>
>If the use of the MDC packet is not required for at least the modern
>ciphers (w/o the feature packet), we should at least add a note that
>"An implementation SHOULD issue a warning if one of the new[1] cipher
>algorithms is used without the MDC packet".
>
>[1] new:  Either explictly list old algorithms or say that new
>algorithms are those with a blocklength other than 64 bit.
>

I don't think that tying MDC and big blocks is a good idea -- in the spec.

I think it is perfectly fine for you implementers to do that. The spec
gives you a lot of latitude, and if you want to only use a big block with
MDCs, that's fine. You need to *decrypt* one, but you don't ever have to
encrypt one. And you're perfectly within your rights to issue warning
messages if you think it's not a good idea.

If you want to limit use more, I have a suggestion: we put in a "feature"
of 128-bit-block ciphers. That way you can declare whether you use them or
not.

	Jon

Date: Wed, 11 Oct 2000 11:52:41 -0700
To: Thomas Roessler <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Another draft is going out
Sender: [email-masked]

At 12:27 PM +0200 10/11/00, Thomas Roessler wrote:
>On 2000-10-11 11:25:52 +0200, Werner Koch wrote:
>
>> I dropped IDEA because I don't see a reason to support that
>> patented algorithm anymore - now that there is another well
>> analyzed new algorithm available.
>
>We don't need to add still more interoperability nightmares with the
>old implementations which are still in use at some places.  The
>text-mode signature problems are bad enough already.
>

Sooner or later, we should start encouraging people away from PGP 2.

I like what Werner said -- he simply explicitly called out that IDEA is
needed for PGP 2 support.

The subtle, lovely thing about SHOULD is that SHOULD means "if you don't
understand the ramifications, do it." It allows anyone to say "I know what
I'm doing."

However, I like the idea of calling out that IDEA is there for backwards
compatibility. How about this paragraph:

---

Implementations MUST implement Triple-DES. Implementations SHOULD implement
AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or
earlier need to support IDEA, as that is the only symmetric cipher those
versions use. Implementations MAY implement any other algorithm.

---

	Jon

Date: Wed, 11 Oct 2000 12:27:39 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Another draft is going out
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On 2000-10-11 11:25:52 +0200, Werner Koch wrote:

> I dropped IDEA because I don't see a reason to support that
> patented algorithm anymore - now that there is another well
> analyzed new algorithm available.

We don't need to add still more interoperability nightmares with the
old implementations which are still in use at some places.  The
text-mode signature problems are bad enough already.

-- 
Thomas Roessler                         <[email-masked]>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-02.txt
Date: Wed, 11 Oct 2000 06:30:29 -0400
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-02.txt
	Pages		: 67
	Date		: 10-Oct-00
	
This document defines many tag values, yet it doesn't describe a
mechanism for adding new tags (for new features). Traditionally the
Internet Assigned Numbers Authority (IANA) handles the allocation of
new values for future expansion and RFCs usually define the
procedure to be used by the IANA.  However there are subtle (and not
so subtle) interactions that may occur in this protocol between new
features and existing features which result in a significant
reduction in over all security. Therefore this document does not
define an extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example) should be
forwarded to the IESG Security Area Directors for consideration or
forwarding to the appropriate IETF Working Group for consideration.

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 11 Oct 2000 11:25:52 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Another draft is going out
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

now that it has been decided on AES I suggest to change:

9.2. Symmetric Key Algorithms
[...] 
"Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.  Implementations MAY implement any other
algorithm."

by

"Implementations MUST implement Triple-DES. Implementations SHOULD
implement CAST5 and AES 128bit.  Implementations MAY implement any other
algorithm.  To allow backward compatibilty with PGP2 IDEA SHOULD be
implemented."

I dropped IDEA because I don't see a reason to support that patented
algorithm anymore - now that there is another well analyzed new
algorithm available.  

Another point:

If the use of the MDC packet is not required for at least the modern
ciphers (w/o the feature packet), we should at least add a note that
"An implementation SHOULD issue a warning if one of the new[1] cipher
algorithms is used without the MDC packet".  

[1] new:  Either explictly list old algorithms or say that new
algorithms are those with a blocklength other than 64 bit.

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

Date: Wed, 11 Oct 2000 00:07:43 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Another draft is going out
Sender: [email-masked]

I forgot to mention that there's also the notation data namespace thing in
there, too. Let me know what you think.

	Jon

Date: Mon, 9 Oct 2000 15:37:44 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Another draft is going out
Sender: [email-masked]

I have the MDC packets in and Ulf's comments (signature collisions and
PKCS1 leap to mind). I also added in a definition of a keyring. Like I said
before, I'm willing to put out a number of small drafts. This one is
particularly important because of the MDC packets, which required small
changes in a number of places. I also added in a "features" signature
subpacket. There are also AES references added and reservation notes
removed. I standardized some spelling.

I'm sure I missed someone's something. Just send me mail. In a week or two,
I'll do another.

	Jon

From: [email-masked]
Date: Mon, 9 Oct 2000 06:10:20 +0800
To: [email-masked]
Subject: At last, HERBAL V the all natural alternative!
Sender: [email-masked]

Herbal V: An Incredible All-Natural Healthy Alternative 

  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.

Available N o w ! 

Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!

Herbal V... Bringing Back the Magic!

1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.

Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 

Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.

Step 1: Place a check by your desired quanity.

______ 1 Bottle of Herbal V  $24

______ 2 Bottles of Herbal V $44

______ 3 Bottles of Herbal V $59

Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]

Step 2: Place a check by your desired payment method 
and complete fields if necessary.

_____Check or CHECK-BY-FAX [details below]

_____Money Order 

_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____

Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.

Name ___________________________________________________ 

Address _________________________________________________

City ____________________________________________________ 

State ___________________________________________________ 

Zip _____________________________________________________ 

E-mail __________________________________________________ 

Signature _________________________________________________
[ required for check and credit card orders]

             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                

        ______________________________________________________

*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW

              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From: [email-masked]
To: <>
Subject: WOW!!! Highest Payouts Around!!!!!!!!
Date: Sun, 08 Oct 2000 12:52:08 -0400
Sender: [email-masked]

Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html.

If you would like to be removed from these mailings in the future please mailto:[email-masked]?subject=remove

Date: Thu, 5 Oct 2000 20:52:40 -0700
To: Ulf =?iso-8859-1?Q?M=F6ller?=  <[email-masked]>, "Peter J . Holzer" <[email-masked]>, Lars Hecking <[email-masked]>, [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility?
Sender: [email-masked]

At 8:13 PM -0400 10/5/00, Ulf Möller wrote:
>Sometimes I have the impression that most of my comments on the
>OpenPGP drafts fall in the "gone unnoticed" category (I first pointed
>it out on September 16th, 1998, again on October 13th -- RFC 2440 was
>published in November --, once more on February 10th, 1999, and again
>on December 23rd after a cryptic note on the subject appeared in
>2440bis-00); but we actually have the following text in the latest
>draft:
>
>     * PGP 2.6.X and 5.0 do not trim trailing whitespace from a
>       "canonical text" signature. They only remove it from cleartext
>       signatures. These signatures are not OpenPGP compliant --
>       OpenPGP requires trimming the whitespace. If you wish to
>       interoperate with PGP 2.6.X or PGP 5, you may wish to accept
>       these non-compliant signatures.

You're welcome.

I've said this a number of times, and I think it bears repeating.

If I get a request about OpenPGP that is vague, I may not do what the
requester intends. The ways in which I can fall down include putting the
wrong thing in the draft, but they are also likely to be that I'll do
nothing when you wanted something.

There are a couple of reasons I might do nothing. The usual one is that I
don't know what you want me to do. OpenPGP has small quantities of
sub-optimal things in it. Usually, those things are there because of
backwards compatibility.

However, at the start of this working group, we decided that backwards
compatibility is important and desirable, but not essential. So there are
things we can, and have, broken because it makes a better standard moving
forward.

So sometimes I interpret someone's complaint as a complaint, not as a
suggestion for a change in the document.

I know that in your case, I've made a number of errors of this sort. I am
truly sorry for this, and I've been trying to make a special effort to pay
closer attention to what you want.

However, it makes it *much* easier for me if you tell me what you want. The
best thing is something like:

Please change XXX to YYY.

For example, I am presently working on getting the PKCS1 updates done.
Thank you for you help. But changing them correctly means that I have to go
dredge out the PKCS1 draft, read it, interpret it, and figure out what to
do. This will take a couple of hours, most likely. In the last few days
I've had several ten minute opportunities to edit. I've had a couple
hour-long ones. I haven't yet had that much time.

If you know what you want text to be, tell me. If I have to do research not
only will I do it slower, but there's a chance I may decide that the best
thing to do is nothing.

In short -- if you make me think, I may end up concluding something other
than you want.

Again, though, I'm sorry I've screwed up. It isn't that I'm ignoring you.

	Jon

Date: Thu, 5 Oct 2000 20:13:06 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: "Peter J . Holzer" <[email-masked]>, Lars Hecking <[email-masked]>, [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility?
Sender: [email-masked]

On Wed, Oct 04, 2000 at 12:36:38PM +0200, Thomas Roessler wrote:

> This smells like a discrepancy between RFC 2440 and the classical
> PGP implementation has crept in, and gone unnoticed for quite some
> time.

Sometimes I have the impression that most of my comments on the
OpenPGP drafts fall in the "gone unnoticed" category (I first pointed
it out on September 16th, 1998, again on October 13th -- RFC 2440 was
published in November --, once more on February 10th, 1999, and again
on December 23rd after a cryptic note on the subject appeared in
2440bis-00); but we actually have the following text in the latest
draft:

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

Date: Wed, 4 Oct 2000 13:25:46 +0100
From: Lars Hecking <[email-masked]>
To: "Peter J . Holzer" <[email-masked]>
Cc: [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility?
Sender: [email-masked]

Peter J . Holzer writes:
> On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote:
> > Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing
> > about all this?  Are they compatible:
> > 
> > - to each other?
> > - to PGP 2.6?
> 
> I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG)
> couldn't verify a message (signed with PGP 2.6) I sent to him in a
> tarred and compressed folder (to avoid any corruption in transit). I'll
> try PGP 6.5 (which I have installed at home) this evening.
 
 Just re-tried with pgp 2.6.3i, and yes, this time it works.

 -l

-- 
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.

Date: Wed, 4 Oct 2000 14:20:01 +0200
From: "Peter J . Holzer" <[email-masked]>
To: Lars Hecking <[email-masked]>, [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility?
Sender: [email-masked]

--pfTAc8Cvt8L6I27a
Content-Type: text/plain; charset=us-ascii

On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote:
> Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing
> about all this?  Are they compatible:
> 
> - to each other?
> - to PGP 2.6?

I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG)
couldn't verify a message (signed with PGP 2.6) I sent to him in a
tarred and compressed folder (to avoid any corruption in transit). I'll
try PGP 6.5 (which I have installed at home) this evening.

	hp

-- 
   _  | Peter J. Holzer      | Any setuid root program that does an
|_|_) | Sysadmin WSR / LUGA  | exec() somewhere is just a less
| |   | [email-masked]        | user friendly version of su.
__/   | http://www.hjp.at/   |    -- Olaf Kirch on bugtraq 2000-08-07

--pfTAc8Cvt8L6I27a
Content-Type: application/pgp-signature

--pfTAc8Cvt8L6I27a--

Date: Wed, 4 Oct 2000 12:36:38 +0200
From: Thomas Roessler <[email-masked]>
To: "Peter J . Holzer" <[email-masked]>
Cc: Lars Hecking <[email-masked]>, [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
Subject: Text canonicalization in RFC 2440 - backwards compatibility?
Mail-Followup-To: "Peter J . Holzer" <[email-masked]>, Lars Hecking <[email-masked]>, [email-masked], "ietf-openpgp @ imc . org" <[email-masked]>
Sender: [email-masked]

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[This thread got started since PGP signatures on the bugtraq list
did not verify correctly.  However, these signatures are (1)
text-mode, and (2) the modification apparently concerns trailing
whitespace.]

This smells like a discrepancy between RFC 2440 and the classical
PGP implementation has crept in, and gone unnoticed for quite some
time.

Essentially, RFC 2440 says that we shouldn't observe the problems
occuring on bugtraq: Peter is generating "canonical text"
signatures.  RFC 2440 says:

   0x01: Signature of a canonical text document.
            Typically, 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 blanks removed.

However, when experimenting with PGP 2.6.3in, I'm observing that
canonical text signatures _do_ take trailing whitespace into
account.

Now, let's look at the older docs: RFC 1991 doesn't seem to define
canonical text mode at all.  pgpdoc2.txt from the PGP 2
distribution, however, just says this: "Canonical text has a
carriage return and a linefeed at the end of each line of text."

This is a precise description of the behaviour, and actually matches
the expectation which seems to have been implicit to RFC 2015, which
only deals with line-end canonicalization, but not with the
signature mode to be used.

To make things worse, the "clearsign" signatures of pgp2 _do_
correspond with what RFC 2440 says about canonical text documents in
general.

Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing
about all this?  Are they compatible:

- to each other?
- to PGP 2.6?

Or am I just confused?

On 2000-10-04 11:55:29 +0200, Peter J . Holzer wrote:
> Date: Wed, 4 Oct 2000 11:55:29 +0200
> From: "Peter J . Holzer" <[email-masked]>
> To: Lars Hecking <[email-masked]>
> Cc: Thomas Roessler <[email-masked]>,
> 	[email-masked]
> Subject: Re: rcp file transfer hole (was: scp file transfer hole)
> X-Mailer: Mutt 0.95.3i
>=20
> [I have included Elias in the Cc, because I think he might want to know
> about this "feature" of his mailing-list software]
>=20
>=20
> On 2000-10-04 10:06:34 +0100, Lars Hecking wrote:
> >  Any idea why half the signatures on bugtraq don't check out? Do you
> >  have an fcc copy of your posting that you can compare with the posted
> >  message?
>=20
> Yes.
>=20
> Looks like Bugtraq strips trailing spaces from each line. This will
> garble the signature separator ("-- ") and therefore the pgp signature
> won't check out any more.=20
>=20
> I guess I should add=20
>=20
> send-hook '~t [email-masked]' 'set pgp_strict_enc'
>=20
> to my .muttrc.
>=20
> For people which don't use PGP signatures, but want their normal
> signatures to be separated correctly, it would be nice if mutt could be
> forced to use quoted printable even for ascii messages. Thomas?
>=20
> 	hp
>=20
> --=20
>    _  | Peter J. Holzer      | Any setuid root program that does an
> |_|_) | Sysadmin WSR / LUGA  | exec() somewhere is just a less
> | |   | [email-masked]        | user friendly version of su.
> __/   | http://www.hjp.at/   |    -- Olaf Kirch on bugtraq 2000-08-07

--=20
Thomas Roessler                         <[email-masked]>

--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline

--6TrnltStXW4iwmi0--

Date: Wed, 4 Oct 2000 01:20:56 -0700
To: Erron Criddle <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PKCS1 update excerpts
Sender: [email-masked]

I'm trying to clarify and get the references proper. So perhaps, if other
people think it helps.

	Jon

Date: Wed, 4 Oct 2000 10:55:49 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDC Excerpts
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 2 Oct 2000, Jon Callas wrote:

> 5.2.3.24. Features
> 
>    (array of one-octet values)

We need a number for this signature sub packet.

>        1 - Modification Detection (packets 15 and 16)
> 
>    If an implementation implements any of the defined features, it
>    SHOULD implement the features subpacket, too.

I have a problem with this.  Currently PGP 7 and GnuPG 1.0.2
implement this feature and use packets 15 and 16 when Twofish is
used.  A year back or so we had a long discussion about this MDC
packets and the use of Twofish.  I suggested that we should wait
with using Twofish until we had figured out how to do this MDC and
the require implementations to use the MDC packet if they use a
cipher with a blocklength not equal to 64 bits.

Requiring to use the MDC only if the feature packet is present
makes the code more complicated because an implementation has to
check the cipher preferences and the MDC feature.

The feature packet is a good thing because it enables us to use the
MDC even with with CAST5 or 3DES.  It should however say that this
feature is implictly assumed when a symmetrical cipher algorithm
with ablocklength different from 64 bits is used (or explitly
enumerate algorithms). I'd also appreciate if we can say that the
use of the MDC is a SHOULD for such algorithms.

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

Date: Wed, 04 Oct 2000 15:40:27 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: PKCS1 update excerpts
Cc: Jon Callas <[email-masked]>
Sender: [email-masked]

Jon,

Does this info help:

The m value is calculated as follows:

boundary        0x00            The boundary value
identifier      0x02            The block type identifier
random  n octets                n octets of non zero PRNG data to make 
len(m) = modulus of the
                                                              length of the 
primary key p
boundary        0x00            The boundary value
algorithm id    1 octet         The ID of the symmetrical algorithm used 
with the session key
session key     n bits          This is the n bit session key to encrypt 
the data
checksum        2 bytes         Is the 16 bit checksum of the session key, 
MOD 65536

At 03:15 PM 3/10/2000 -0700, you wrote:
>Please let me know if this is adequate:
>
>5.1:
>
>    The value "m" in the above formulas is derived from the session key
>    as follows.  First the session key is prefixed with a one-octet
>    algorithm identifier that specifies the symmetric encryption
>    algorithm used to encrypt the following Symmetrically Encrypted Data
>    Packet.  Then a two-octet checksum is appended which is equal to the
>    sum of the preceding session key octets, not including the algorithm
>    identifier, modulo 65536.  This value is then encoded as described
>    in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m"
>    value used in the formulas above.
>
>    Note that when an implementation forms several PKESKs with one
>    session key, forming a message that can be decrypted by several
>    keys, the implementation MUST make new PKCS-1 encoding for each key.
>
>and
>
>5.2.2:
>
>    With RSA signatures, the hash value is encoded as described in
>    PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of
>    type DigestInfo, and then encoded using PKCS-1 encoding type
>    EMSA-PKCS1-v1_5 [RFC2437].  This requires inserting the hash value
>    as an octet string into an ASN.1 structure. The object identifier
>    for the type of hash being used is included in the structure.  The
>    hexadecimal representations for the currently defined hash
>    algorithms are:

Date: Tue, 3 Oct 2000 21:57:15 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

On Tue, Oct 03, 2000 at 04:11:09PM -0700, Jon Callas wrote:

> I added the following two paragraphs to Security Considerations that
> address this issue:

Thanks.

Date: Tue, 3 Oct 2000 16:11:09 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

I added the following two paragraphs to Security Considerations that
address this issue:

There is a potential security problem in signatures. If an attacker can
find a message that hashes to the same hash with a different algorithm, a
bogus signature structure can be constructed that evaluates correctly.

For example, suppose Alice DSA signs message M using hash algorithm H.
Suppose that Mallet finds a message M' that has the same hash value as M
with H'. Mallet can then construct a signature block that verifies as
Alice's signature of M' with H'. However, this would also constitute a
weakness in either H or H' or both. Should this ever occur, a revision will
have to be made to this document to revise the allowed hash algorithms.

From: [email-masked]
Date: Tue, 3 Oct 2000 15:52:54 -0700
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

Ulf Möller wrote:

>The security notes still don't mention that there is a cryptographic
>flaw in v4 signatures.  This needs to be fixed, or if there are good
>reasons for not fixing it, it must at least be explained in the
>document.

The problem is that we currently allow a choice of hash algorithms with
DSA signatures.  Because there is no room in the DSA inputs to specify
the hash algorithm, it is possible to do a hash substitution attack.
This is why the DSS specifies that the hash must be SHA-1.

We allow other hashes with a size of 160 bits, as described in section
5.2.2:

   DSA signatures MUST use hashes with a size of 160 bits, to match q,
   the size of the group generated by the DSA key's generator value.
   The hash function result is treated as a 160 bit number and used
   directly in the DSA signature algorithm.

The only other hashes listed in RFC 2440 which have this size are
RIPEMD-160 and HAVAL.  These are thought to be strong hashes, like SHA-1,
hence there is no actual cryptographic weakness in RFC-2440.

This issue is discussed in section 13, Security Considerations:

   The DSA algorithm will work with any 160-bit hash, but it is
   sensitive to the quality of the hash algorithm, if the hash algorithm
   is broken, it can leak the secret key. The Digital Signature Standard
   (DSS) specifies that DSA be used with SHA-1.  RIPEMD-160 is
   considered by many cryptographers to be as strong. An implementation
   should take care which hash algorithms are used with DSA, as a weak
   hash can not only allow a signature to be forged, but could leak the
   secret key. These same considerations about the quality of the hash
   algorithm apply to Elgamal signatures.

In my opinion this does address the issue raised above.

Hal

Date: Tue, 3 Oct 2000 15:15:19 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: PKCS1 update excerpts
Sender: [email-masked]

Please let me know if this is adequate:

5.1:

   The value "m" in the above formulas is derived from the session key
   as follows.  First the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then encoded as described
   in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m"
   value used in the formulas above.

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

and

5.2.2:

   With RSA signatures, the hash value is encoded as described in
   PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of
   type DigestInfo, and then encoded using PKCS-1 encoding type
   EMSA-PKCS1-v1_5 [RFC2437].  This requires inserting the hash value
   as an octet string into an ASN.1 structure. The object identifier
   for the type of hash being used is included in the structure.  The
   hexadecimal representations for the currently defined hash
   algorithms are:

Date: Tue, 3 Oct 2000 14:56:29 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

In our last episode ("Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt",
shown on 10/2/00), Ulf Möller said:

>The security notes still don't mention that there is a cryptographic
>flaw in v4 signatures.  This needs to be fixed, or if there are good
>reasons for not fixing it, it must at least be explained in the
>document.
>

Should we start killing hash algorithms, then?

	Jon

Date: Tue, 3 Oct 2000 10:47:30 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

This draft still does not say anything about name spaces for
notation data tags, making notation data essentially useless.

Suggestion:

   The present document defines two name spaces for notation data
   names: The IETF name space and the user name space.
   
   Notation data names in the IETF name space consist of an
   arbitrary string of UTF-8 encoded characters, with the exception
   that the character "@" ("at") MUST NOT occur in such a name.
   
   XXX - describe IANA registration procedures.
   
   Notation data names in the user name space consist of a tag,
   followed by the "@" character, followed by a DNS domain name.
   The tag may be an arbitrary string of UTF-8 encoded characters,
   with the exception that the character "@" MUST NOT occur in such
   a name.  The DNS domain name must be under the exclusive control
   of the person or entity which introduces the notation data name
   in question.
   
   For example, if The Example Corporation wishes to introduce
   sample notation data, the appropriate notation data name could be
   "[email-masked]".

-- 
Thomas Roessler                         <[email-masked]>

Date: Mon, 2 Oct 2000 23:21:35 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

The security notes still don't mention that there is a cryptographic
flaw in v4 signatures.  This needs to be fixed, or if there are good
reasons for not fixing it, it must at least be explained in the
document.

As I explained on January 19th:

| > I think I'm confused here. Suppose I have an implementation that does DSA
| > with SHA-1. Let us also suppose that Tiger gets broken. How does this
| > affect my DSA/SHA signature?
| 
| Then if I want to forge a signature, I find a message for which the
| Tiger hash value is identical to your original SHA-1 hash.  Unless
| your original signature was a v3 RSA signature, nothing in OpenPGP
| prevents me from setting the hash algorithm identifier for that
| message to Tiger.  That's why the RSA value in PKCS #1 contains a
| DigestInfo, and why the DSS specifies SHA-1 as the only signature
| algorithm.  Putting the hash algorithm identifier in the data
| protected by that very hash algorithm is pointless.
| 
| That clearly is a cryptographic weakness in the protocol, so it has to
| be mentioned in the RFC.

Most of the other issues I raised haven't been addressed either, but
as things are it looks like it would be pointless to invest a lot of
time in OpenPGP.

Date: Mon, 2 Oct 2000 15:36:23 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: MDC Excerpts
Sender: [email-masked]

5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15)

   The Symmetrically Encrypted Integrity Protected Data Packet is a
   variant of the Symmetrically Encrypted Data Packet. It is a new
   feature created for OpenPGP that addresses the problem of detecting
   a modification to encrypted data. It is used in combination with a
   Modification Detection Code Packet.

   There is a corresponding feature in the features signature subpacket
   that denotes that an implementation can properly use this packet
   type. An implementation SHOULD NOT use this packet when encrypting
   to a recipient that does not state it can use this packet, and
   SHOULD prefer this to older Symmetrically Encrypted Data Packet when
   possible.

   This packet contains data encrypted with a symmetric-key algorithm
   and protected against modification by the SHA-1 hash algorithm. When
   it has been decrypted, it will typically contain other packets
   (often literal data packets or compressed data packets).  The last
   decrypted packet in this packet's payload MUST be a Modification
   Detection Code packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is
       1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data Packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes an octet string
   to the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the
   cipher, are random; the last two octets are each copies of their 2nd
   preceding octet.  For example, with a cipher whose block size is 128
   bits or 16 octets, the prefix data will contain 16 random octets,
   then two more octets, which are copies of the 15th and 16th octets,
   respectivelly. Unlike the Symmetrically Encrypted Data Packet, no
   special CFB resynchronization is done after encrypting this prefix
   data.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key is
   incorrect.

   The plaintext of the data to be encrypted is passed through the
   SHA-1 hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  Specifically,
   the input to the hash function does not include the prefix data
   described above; it includes all of the plaintext, and then also
   includes two octets of values 0xD0, 0x14.  These represent the
   encoding of a Modification Detection Code packet tag and length
   field of 20 octets.

   The resulting hash value is stored in a Modification Detection Code
   packet which MUST use the two octet encoding just given to represent
   its tag and length field.  The body of the MDC packet is the 20
   octet output of the SHA-1 hash.

   The Modification Detection Code packet is appended to the plaintext
   and encrypted along with the plaintext using the same CFB context.

   During decryption, the plaintext data should be hashed with SHA-1,
   not including the prefix data but including the packet tag and
   length field of the Modification Detection Code packet.  The body of
   the MDC packet, upon decryption, is compared with the result of the
   SHA-1 hash.  Any difference in hash values is an indication that the
   message has been modified and SHOULD be reported to the user.
   Likewise, the absence of an MDC packet, or an MDC packet in any
   position other than the end of the plaintext, also represent message
   modifications and SHOULD also be reported.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.

5.13. Modification Detection Code Packet (Tag 16)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used with a Symmetrically Encrypted Integrity Protected Data
   packet.  The Modification Detection Code packet MUST be the last
   packet in the plaintext data which is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST appear in no
   other place.

   A Modification Detection Code packet MUST have a length of 20
   octets.

   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet, not
       including prefix data but including the tag and length byte of
       the Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new-format encoding of the packet tag, and a one-octet encoding of
   the packet length. The reason for this is that the hashing rules for
   modification detection include a one-octet tag and one-octet length
   in the data hash. While this is a bit restrictive, it reduces
   complexity.

[...]
[Yes, I know this is earlier in the document.]

5.2.3.24. Features

   (array of one-octet values)

   The features subpacket denotes which advanced OpenPGP features a
   user's implementation supports. This is so that as features are
   added to OpenPGP that cannot be backwards-compatible, a user can
   state that they can use that feature.

   This subpacket is similar to a preferences subpacket, and only
   appears in a self-signature.

   An implementation SHOULD NOT use a feature listed when sending to a
   user who does not state that they can use it.

   Defined features are:

       1 - Modification Detection (packets 15 and 16)

   If an implementation implements any of the defined features, it
   SHOULD implement the features subpacket, too.

Date: Mon, 2 Oct 2000 15:27:21 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt
Sender: [email-masked]

At 2:15 PM +0200 9/29/00, Werner Koch wrote:
>Thanks for updating the draft Jon.
>
>I think we should add the section on the new MDC packets.  Those are
>implemented in PGP 7 and GnuPG 1.0.3.  Hal: Can you post this
>proposed section again?
>

I've added in the MDC packets, editing the text from Hal's submission. I
also added in a "features" subpacket to state that you speak MDC. Excerpts
will be forthcoming. I made a few other edits surrounding MDC use (for
example in the BNF). I also put in a reminder in the packet header
description that you have to use a new-format packet for tags of 16 and
greater.

>Assuming that AES will be announced quite soon, we could issue a new
>draft right after this event.
>

What changes need to be made for that? We've already reserved constants for
the AES. Do I need to do anything other than remove the word "reserved"?
Hmmm. A Rijndael reference. That seems to be it to me, though.

	Jon