Subject: You Gota See!

From: "$ Mafiouso" <[email-masked]>
Date: Wed, 26 Apr 2000 05:21:07 +1000

$ Hey!

$ Check Out This:

http://mafiouso3.tripod.com

$ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will 
Find It Here, 

$ Want a HOT Christina Aguilera Background For Your PC
$ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER.

http://mafiouso3.tripod.com/Christina.jpg

:)  Remember It's Da A Hit!

$ Contact Mafiouso At:

$ ICQ   53709750
$ Email [email-masked]

From: "$ Mafiouso" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 26 Apr 2000 05:21:07 +1000
Subject: You Gota See!
Reply-To: [email-masked]
Organization: Mafiouso Inc.
Sender: [email-masked]

$ Hey!

$ Check Out This:

http://mafiouso3.tripod.com

$ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will 
Find It Here, 

$ Want a HOT Christina Aguilera Background For Your PC
$ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER.

http://mafiouso3.tripod.com/Christina.jpg

:)  Remember It's Da A Hit!

$ Contact Mafiouso At:

$ ICQ   53709750
$ Email [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-mime-01.txt
Date: Fri, 21 Apr 2000 06:39:22 -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		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-01.txt
	Pages		: 12
	Date		: 20-Apr-00
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at <http://www.imc.org/ietf-
openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-01.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-mime-01.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-mime-01.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-mime-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 10 Apr 2000 10:26:05 -0700
To: Jon Callas <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Two AES ciphers
Sender: [email-masked]

At 02:49 PM 4/9/00 -0700, Jon Callas wrote:
>I'd prefer to wait, myself.

As long as you are willing to simultaneously hold up progression of 
2440bis, that's good thinking. However, I didn't want to assume that timing.

>If NIST says there's going to be two AES ciphers, it's five minutes of work
>to add it in. I'm not sending out a revision next week, or the week after.
>In three to four weeks there may be another 2440bis, if we get the MDC
>hammered out. If a week after that I have to put out another draft, sure.
>There's just no reason to do it now. It's not like we might run out of
>algorithm numbers.

The problem is that NIST probably won't decide until September (or whenever 
they actually announce the winner/winners). They have explicitly said that 
they are going to take the one/two discussion that happens at the upcoming 
meeting as input for their decision. It would be nice if they say soon 
whether there will be one or two, but the last I heard they won't decide 
about one/two before they announce the winner/winners. If we don't get a 
firm commitment on one/two soon, then the OpenPGP WG needs to think about 
what we want to do about progressing 2440bis before the AES announcement.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Two AES ciphers
Reply-To: [email-masked]
Date: Tue, 11 Apr 2000 03:13:00 (NZST)
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
>At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote:
>>For the past few months, there has been much talk of the likelihood that
>>the AES process will come out with two ciphers, not one. This was talked
>>about at the SAAG meeting in Adelaide, and folks from NIST said that this
>>was indeed the current thinking.
>>
>>RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved
>>for AES with 128-bit key" and so on. It might be wise to allocate another
>>three and specify that the actual algorithms used for IDs 7, 8, and 9 (and
>>probably 11, 12, and 13) will be defined by a future RFC.
>
>I'm of two minds about this.

Since we're listing reasons for having two AES', here's mine.  At RSA2K, people
were making various bets (in some cases rather nontrivial ones) about the
eventual AES.  Eric Young and myself were both of the opinion that there'd be
two AES', the main one and a spare in case the other one breaks down.  Since
neither of us are betting types, I proposed that if I was wrong I'd wear a
t-shirt which said "Eric was wrong", whereupon he very graciously offered to
wear a shirt which said "Peter was wrong".  Because of this I'm rather banking
on there being two AES'.  This is a somewhat lesser reason than the ones which
Jon has offered, but it's valid nonetheless.

Peter.

Date: Mon, 10 Apr 2000 11:44:14 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Return to MDC packet discussion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, 9 Apr 2000, Jon Callas wrote:

> I have a question. Why not use one of the packet numbers reserved for
> experimental use? That's why they're there. This use is experimental.

I thought we agreed on the the MAC extension so why not use regular
packet numbers.  We did this for Twofish as well.

However it is fine for me to use the experimental numbers.  But then we
should add some magic numbers to those packets, so that we don't run
into problems when another implemenation uses them for another
purpose.

> If no one's going to use them, then why don't I just remove them from the
> standard?

Please, don't do that.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Düsseldorf                      http://www.openit.de

From: [email-masked]
Date: Sun, 9 Apr 2000 17:28:01 -0700
To: [email-masked], [email-masked]
Subject: Re: Return to MDC packet discussion
Sender: [email-masked]

Jon writes:
> I have a question. Why not use one of the packet numbers reserved for
> experimental use? That's why they're there. This use is experimental.
>
> If no one's going to use them, then why don't I just remove them from the
> standard?

Actually they are listed (at least in the RFC) as "private or experimental
values".  I view this as being an indication that these are OK for closed
systems where you want to pick a packet number you know won't ever be
used by the open implementations, for your own private or experimental
purposes.

As far as the MDC packet, I don't think it would be appropriate to put it
there as it is intended to be a permanent, public addition to the spec.

Hal

From: [email-masked]
Date: Sun, 9 Apr 2000 17:24:26 -0700
To: [email-masked]
Subject: Re: Two AES ciphers
Sender: [email-masked]

Jon writes:
> The third AES conference is next week. I hope this gets addressed there. If
> they say there that yes, definitely, there will be two algorithms, then so
> be it.

I wonder if rather than explicitly picking two, they might use the Miss
America strategy: name the winner, but remember the first runner up.
In the event the winner is unable to perform her duties (i.e. the
cipher is broken) then the runner up steps into her shoes.  Same idea
as president and vice president.

Of course it is a judgement call as to when a cipher is broken.
It's probably not going to snap like a brittle twig.  Rather, there may
be some attack found that makes people a bit uncomfortable.  Is that
enough to switch or not?  It may be a tough call.

All in all the two cipher approach seems problematic to me.

Hal

Date: Sun, 9 Apr 2000 14:49:10 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Two AES ciphers
Sender: [email-masked]

At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote:
>For the past few months, there has been much talk of the likelihood that
>the AES process will come out with two ciphers, not one. This was talked
>about at the SAAG meeting in Adelaide, and folks from NIST said that this
>was indeed the current thinking.
>
>RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved
>for AES with 128-bit key" and so on. It might be wise to allocate another
>three and specify that the actual algorithms used for IDs 7, 8, and 9 (and
>probably 11, 12, and 13) will be defined by a future RFC.
>

I'd prefer to wait, myself. There are a few reasons for it.

I'm of two minds about this. Last spring I came out against it in my
comments to NIST. There's been talk about it since the first AES
conference, but it's only been talk. In the past, the main rationale for
more than one AES was that the AES has many goals, and it wasn't clear that
one cipher could serve all of those goals.

However, the analysis shows that at least three of the five finalists are
usable in all contexts, from smart cards to high-performance systems.If the
main argument for more than one AES is concern about usability on smart
cards (or other limited system -- the 8051 is probably going to be with us
always) and big switches, that concern has been addressed.

To my mind, the other technical rationale is the "what if it breaks"
question. That's a completely different can of worms, though. I think this
is the only reasonable reason for more than one algorithm, but it raises a
number of algorithms. If you have one, there's no good backup plan. If you
have more than one, the odds that you'll have to deal with *some* broken
cipher is higher. Ironically, under this argument, I tend to side with
notion of redundancy, but I respect the opinions of people who want
simplicity, and see their point.

(There's a third reason, and that's political. Let's suppose that the
technical favorite in NIST were Rijndael. Beyond the amusement value of
having a US standard cipher being written by people outside the US, that's
pretty much the icing on the cake for the argument that US governmental
controls on crypto have merely helped export crypto knowledge. It would
therefore behoove them to pick a second AES that they could slap a "Made in
USA" sicker on. But I digress.)

The third AES conference is next week. I hope this gets addressed there. If
they say there that yes, definitely, there will be two algorithms, then so
be it.

Until NIST says something official, the issue of whether there should be
more than one AES is under debate. As you can see, I have mix emotions
about the issue. I think it would be high-handed for me to act as if I know
what NIST is going to do before they've done it. It short-circuits the
debate.

If NIST says there's going to be two AES ciphers, it's five minutes of work
to add it in. I'm not sending out a revision next week, or the week after.
In three to four weeks there may be another 2440bis, if we get the MDC
hammered out. If a week after that I have to put out another draft, sure.
There's just no reason to do it now. It's not like we might run out of
algorithm numbers.

	Jon

Date: Sun, 9 Apr 2000 14:22:04 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Return to MDC packet discussion
Sender: [email-masked]

I have a question. Why not use one of the packet numbers reserved for
experimental use? That's why they're there. This use is experimental.

If no one's going to use them, then why don't I just remove them from the
standard?

	Jon

Date: Sat, 08 Apr 2000 19:34:22 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Two AES ciphers
Sender: [email-masked]

For the past few months, there has been much talk of the likelihood that 
the AES process will come out with two ciphers, not one. This was talked 
about at the SAAG meeting in Adelaide, and folks from NIST said that this 
was indeed the current thinking.

RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved 
for AES with 128-bit key" and so on. It might be wise to allocate another 
three and specify that the actual algorithms used for IDs 7, 8, and 9 (and 
probably 11, 12, and 13) will be defined by a future RFC.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 5 Apr 2000 15:41:49 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: 5.2.3.16. Key server preferences
Sender: [email-masked]

On Wed, 5 Apr 2000, Werner Koch wrote:

> Good point.  We should allow for this but I don't see a reason to
> change the specs.  The keyserver admin can do this (using automated
> tools of course).
> 
>   Werner

Actually, Werner, that thought occured to me about 20 minutes after I sent
in the post. Technically any automated action by the keyserver would be an
action performed by the keyserver admin, so retaining signature
revocations would not violate the RFC.

- --Len.

__

L. Sassaman

System Administrator                |  "All of the chaos
Technology Consultant               |   Makes perfect sense..."
icq.. 10735603                      |
pgp.. finger://ns.quickie.net/rabbi |              --Joe Diffie

From: [email-masked]
Date: Wed, 5 Apr 2000 10:13:16 -0700
To: [email-masked]
Subject: Re: 5.2.3.16. Key server preferences
Sender: [email-masked]

Another thing the keyservers should allow is importing a key revocation
packet even if the sender is not able to authenticate himself as knowing
the private key.  We used to recommend making a key revocation packet at
creation time so that the key could be revoked even if the passphrase
is forgotten.  It would be important for the server to accept the key
revocation in this circumstance.

(You could argue that since the key revocation packet is signed by the
key, that is proof that it comes from the key holder and hence should
be accepted under a straighforward reading of the rfc.  But then that
would imply that all self-sigs from the key holder should be added,
and that might not always be his intention.)

Hal

Date: Wed, 5 Apr 2000 16:45:21 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: 5.2.3.16. Key server preferences
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 5 Apr 2000, L. Sassaman wrote:

> longer trust that key. There could be cases where the owner of the key
> does not wish me to revoke said signature. I should still be able to
> revoke it; in this case the wishes of the signer outweigh the wishes of

Good point.  We should allow for this but I don't see a reason to
change the specs.  The keyserver admin can do this (using automated
tools of course).

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel   +49 211 465357
Birkenstr. 12                           email [email-masked]
D-40233 Düsseldorf                      http://www.openit.de

Date: Wed, 5 Apr 2000 16:39:16 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Return to MDC packet discussion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, 4 Apr 2000, [email-masked] wrote:

> Due to our long corporate lead times for testing and quality assurance I
> would like to incorporate this feature on at least a read-only basis for
> the next release of PGP, which will be in mid to late summer.  By making

Okay, I'll implement the read-write in GnuPG within the next few weeks. 

> numbers 18 and 19 for the integrity protected encrypted packet, and the

No problem.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel   +49 211 465357
Birkenstr. 12                           email [email-masked]
D-40233 Düsseldorf                      http://www.openit.de

Date: Wed, 5 Apr 2000 00:43:51 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: 5.2.3.16. Key server preferences
Sender: [email-masked]

On Wed, 5 Apr 2000, Jon Callas wrote:

> 
> What are the obvious reasons? And what's the obvious abuse?
> 
> The purpose of this packet is so that a key can say, "Here's where you can
> get the most up-to-date version of me." Or perhaps if you prefer, the key's

No, that's what "5.2.3.18.Preferred key server" (in the current
draft; 5.2.3.17 in the RFC) is for.

What I am talking about is subpacket 23:

5.2.3.17. Key server preferences

   (N octets of flags)

   This is a list of flags that indicate preferences that the key
   holder has about how the key is handled on a key server. All
   undefined flags MUST be zero.

   First octet: 0x80 = No-modify
       the key holder requests that this key only be modified or
       updated by the key holder or an administrator of the key server.

   This is found only on a self-signature.

- --

If I wish to revoke a signature on a key, I am doing so because I no
longer trust that key. There could be cases where the owner of the key
does not wish me to revoke said signature. I should still be able to
revoke it; in this case the wishes of the signer outweigh the wishes of
the key owner, in my opinion. If someone has set me as a trusted
introducer, I would not want them to treat keys on which I have revoked my
signature as valid. That would defeat the point of the revocation (since
the revocation would not be present without consent of the key owner, in
the current draft).

- --Len.

__

L. Sassaman

System Administrator                |  "All of the chaos
Technology Consultant               |   Makes perfect sense..."
icq.. 10735603                      |
pgp.. finger://ns.quickie.net/rabbi |              --Joe Diffie

Date: Wed, 5 Apr 2000 00:07:17 -0700
To: "L. Sassaman" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: 5.2.3.16. Key server preferences
Sender: [email-masked]

At 11:02 PM -0700 4/4/00, L. Sassaman wrote:

>While reading over the description of the Key server preferences signature
>subpacket (5.2.3.17 in the current draft), a possible abuse of this option
>occurred to me. I would like to suggest that the wording in the draft be
>modified to say:
>
>"When valid revocations of signatures made on a key are submitted to a key
>server, implementations that honor subpacket 23 MUST allow the signature to
>be revoked, regardless of the value of this packet"
>
>Or something to that effect... the reasons here are obvious.
>

What are the obvious reasons? And what's the obvious abuse?

The purpose of this packet is so that a key can say, "Here's where you can
get the most up-to-date version of me." Or perhaps if you prefer, the key's
owner is saying "here's where you can get the most up-to-date version of
this key." There are other reasonable uses, like including it in a
signature so you can find the key that signed it. Like all signed
statements, you shouldn't automatically treat them like gospel -- remember,
any idiot can sign anything. But that's the abuse?

	Jon

Date: Tue, 4 Apr 2000 23:02:51 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: [email-masked]
Subject: 5.2.3.16. Key server preferences
Sender: [email-masked]

Hi folks,

While reading over the description of the Key server preferences signature
subpacket (5.2.3.17 in the current draft), a possible abuse of this option
occurred to me. I would like to suggest that the wording in the draft be
modified to say:

"When valid revocations of signatures made on a key are submitted to a key
server, implementations that honor subpacket 23 MUST allow the signature to
be revoked, regardless of the value of this packet"

Or something to that effect... the reasons here are obvious.

- --Len.

__

L. Sassaman

System Administrator                |  "All of the chaos
Technology Consultant               |   Makes perfect sense..."
icq.. 10735603                      |
pgp.. finger://ns.quickie.net/rabbi |              --Joe Diffie

From: [email-masked]
Date: Tue, 4 Apr 2000 11:29:13 -0700
To: [email-masked], [email-masked]
Subject: Re: Return to MDC packet discussion
Sender: [email-masked]

Werner Koch wrote:
> > 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)
>
> >    Unlike the Symmetrically Encrypted Data Packet, no special CFB
> >    resynchronization is done after encrypting this prefix data.
>
> Good.
>
> This proposal is fine with me.  To implement this we have to add
> feature flags to the public keys or choose an implicit way to decide
> when a tag-15 packet should be used or is expected.  Using cipher
> algorithms with a blocklength other the 64 bit should still work 
> as an implicit criteria.

Due to our long corporate lead times for testing and quality assurance I
would like to incorporate this feature on at least a read-only basis for
the next release of PGP, which will be in mid to late summer.  By making
sure we can read the integrity protected packets in our next version,
which will be v7.0, we will be able to start using them that much sooner.

In implementing this I realized that the proposed tag numbers were already
being used in earlier versions of PGP.  I would like to use packet tag
numbers 18 and 19 for the integrity protected encrypted packet, and the
MDC packet, respectively.  The suggested draft language below is the
same as in my previous message, but with the tag numbers updated.

Hal Finney
PGP.COM

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

5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18)

   The Symmetrically Encrypted Integrity Protected Data 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 such decrypted packet 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, should be 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.Y Modification Detection Code Packet (Tag 19)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used in the context of 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.  (These requirements are already imposed by the
   rules for tag and length encoding.)

Date: Mon, 3 Apr 2000 11:02:53 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Sender: [email-masked]

On Sat, 1 Apr 2000, Thomas Roessler <[email-masked]> wrote:
>On 2000-03-31 15:47:56 -0800, Jon Callas wrote:
>
>> So, popping back to your questions, no, we have to have
>> binary mode signatures, or else PGP/MIME can't sign a
>> binary file cross-platform.
>
>Beg your pardon?  What PGP/MIME does is converting binary
>data to a canonical text representation which matches
>MIME's and OpenPGP's idea of canonical text.  That is,
>with PGP/MIME (or any other signature standard based on
>RFC 1847), all you have to look at are signatures of
>textual data.  MIME does the conversion for you.

Yes, and unless there are absolutely no inter-operability problems 
arising from the different modes of signing MIME messages, the 
openPGP/MIME draft should say "MUST use text-mode signatures", not 
"SHOULD NOT use binary-mode signatures" as I previously suggested.

-- 
Ian Bell                                           T U R N P I K E  Ltd

Date: Sat, 1 Apr 2000 11:14:54 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Ian Bell <[email-masked]>, [email-masked]
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Mail-Followup-To: Jon Callas <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2000-03-31 15:47:56 -0800, Jon Callas wrote:

> So, popping back to your questions, no, we have to have
> binary mode signatures, or else PGP/MIME can't sign a
> binary file cross-platform.

Beg your pardon?  What PGP/MIME does is converting binary
data to a canonical text representation which matches
MIME's and OpenPGP's idea of canonical text.  That is,
with PGP/MIME (or any other signature standard based on
RFC 1847), all you have to look at are signatures of
textual data.  MIME does the conversion for you.

> If all parties are using the same rules of what text
> is, then it doesn't matter what mode you use, as long
> as you use the same mode. If you want to cross a
> text-rule boundary, you have to use the right mode.

Right.

-- 
http://www.guug.de/~roessler/