Subject: Preparing a new draft...

From: Jon Callas <[email-masked]>
Date: Mon, 20 Aug 2001 12:09:04 -0700

I'm going through things needed to put in a new draft, and looking at the
last few months of comments to see what I should add.

I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
anyone disagree?

Do people here want to see diffs of my source before I submit the draft? (I
use a Perl formatting program that uses a RUNOFF/roff-like markup language
to produce the actual copy. Sending diffs of the final output is less fun
than it could be, but the source doesn't know page numbers or even section
numbers. On the other hand, it's pretty easy to see the actual changes.)

I'd like to get this one out ASAP, because I stupidly didn't get it out a
long time ago with the correct packet numbers for MDC, and I feel badly
about that. Producing actual drafts if a new one is needed is easy. It's
the figuring out what should go in it that's trouble.

	Jon

---

From: Werner Koch <[email-masked]>
Date: 20 Aug 2001 22:07:29 +0200

> I think we agreed that we should add in SHA256, SHA384, and SHA512. Does

Please mark them as optional.  We should also figure out the new DSA
parameters to be used with those hashes.  Ist there anything available
from NIST?  I didn't follow the development very closely.

> Do people here want to see diffs of my source before I submit the draft? (I

Pretty please.

> long time ago with the correct packet numbers for MDC, and I feel badly

Regarding MDC: PGP and GnuPG both implement MDC but without the use of
the features flag.  A long time ago I agreed with Hal to use MDC with
all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
our knowledge no other application did use one of those algorithms at
that time.   IMHO, it would be good to stress it even more that the
MDC packets should be used and that it can be expected that future
revisions of OpenPGP will make the use of MDC mandatory.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 20 Aug 2001 13:29:51 -0700

>last few months of comments to see what I should add.

Let's start thinking in terms of this draft as the one that will be 
submitted for DRAFT status of 2440.

---

From: Jon Callas <[email-masked]>
Date: Mon, 20 Aug 2001 14:15:13 -0700

>from NIST?  I didn't follow the development very closely.

Oh, yes, yes, yes. They are optional. The mandatory algorithms will not
change from 2440. They are, however, needed to balance with the newer
ciphers, or public keys bigger than 1024 bits.

>> Do people here want to see diffs of my source before I submit the draft? (I

Will do, then.

>revisions of OpenPGP will make the use of MDC mandatory.

Yeah, I know you did, and I still think it's a hack. A clever hack, but a
hack. But hey, that's the difference between a standard and an
implementation. You're perfectly free to do that.

I don't know, though, that will ever make the use of MDC mandatory. That
would break backwards compatibility with anything that's gone before you.
I'm still incredulous that there are people who steadfastly cling to 2.6!
At HAL2001, there were people who *still* adamantly insist that 2.6 is the
only trustworthy PGP version. I don't get it, but I respect it. And hey,
I'll admit that I'm still using PGP 6.5 when I'm on OS9, but GPG 1.0.6 on
OSX.

I agree with you that in a perfect world we'd make it mandatory, but people
would howl if we did. If we want to move to that as a goal, step one is to
deprecate 2.6.

	Jon

---

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 21 Aug 2001 07:16:54 +0200

>On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:
<snip>
>revisions of OpenPGP will make the use of MDC mandatory.
PGP does not generate MDC packets, it will however interpret them.

Since MDC's are too new, not mandatory, and may cause an application which
does not implement them to fail to decode, a responsible implementor
should not generate such packets unless otherwise instructed by the user.

Remember, the User Is King, the Implementor is not!

my 2c

---

From: Werner Koch <[email-masked]>
Date: 21 Aug 2001 12:40:53 +0200

> ciphers, or public keys bigger than 1024 bits.

Can you check that we don't have 1024 bit limit for DSA keys in
OpenPGP.

> implementation. You're perfectly free to do that.

Yeah.  And it is good that it is just a SHOULD rule ;-)

> would break backwards compatibility with anything that's gone before you.

Okay.  An implemenation can print a warning if a non MDC is used.

> only trustworthy PGP version. I don't get it, but I respect it. And hey,

I know and can't count the mails I wrote on the interoperability
problems due to no IDEA in GnuPG and to explain the advantages of
OpenPGP :-(

> would howl if we did. If we want to move to that as a goal, step one is to

And of equal importance is to use PGP/MIME.

  Werner

---

From: Florian Weimer <[email-masked]>
Date: 21 Aug 2001 17:54:28 +0200

> would howl if we did. If we want to move to that as a goal, step one is to

You could at least mark it 'obsolescent'. ;-)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: "Michael Young" <[email-masked]>
Date: Thu, 23 Aug 2001 10:23:16 -0400

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

On the subject of MDC packets, I'd like to note a peculiarity
in the GnuPG implementation, and ask whether others consider
it reasonable, in accordance with the specification.

Here (my perception of) the structure of a integrity-protected
packet sequence:

    SEIP-data packet {
        <version=1>
        encrypt-CFBn[key](
            <plaintext>
            MDC packet { SHA-1 hash }
        )
    }

The discussion of the SEIP-data packet doesn't say so explicitly,
but the <plaintext> would be an "OpenPGP message" in the
packet sequence grammar.  Is that required, or simply
a convention?

GnuPG encodes the <plaintext> using an old-style indeterminate
length packet.  This requires a parser to carve off the
MDC packet *from the end* in order to properly bound the
interpretation of that packet.  I can think of at least two
approaches to doing so, but neither is very satisfying:

    Use the bounds provided by the outer packet to limit the
    size of the <plaintext> region.  In a recursive filter-style
    parser, this is unnatural -- rather than consuming a generic
    input stream, the parser must also be given the bounds of
    that stream (and that bound must be carried through any
    layers that might reach another parsing step).  Moreover,
    there is no requirement that the outer packet be bounded;
    it could very reasonably use an old-style indeterminate or
    new-style partial-body encoding itself.

    Maintain a 22-byte lookahead buffer.  If the outer packet
    has indeterminate (*or partial-body*) length, and the
    <plaintext> has indeterminate length, this seems to be the
    only viable option.  (If the <plaintext> could be something
    other than a "OpenPGP message", then it is effectively
    indeterminate.  Partial-body encodings present no problem.)

So, my questions are:

    Is the <plaintext> *required* to be an "OpenPGP message"?

    Are indeterminate packets legal inside other indeterminate
    packets?  If not, are they legal inside strictly bounded
    packets?

Thanks in advance for your thoughts.

---

From: Werner Koch <[email-masked]>
Date: 23 Aug 2001 17:39:10 +0200

>             MDC packet { SHA-1 hash }

Correct, however the plaintyext is usually a compressed packet but can
be any other packet as allowed by the OpenPGP grammar.  That the MDC
has a form of a packet is probably due to my request because it can
make things easier.  However an implementation can ignore the fact
that this is a packet and handle it just like a checksum with a fixed
header.

> length packet.  This requires a parser to carve off the

Sure, there is no other way to do this when you don't know the length of
the text in advanced.  This is very common for Unix tools and that
feature is one of the great advantages of OpenPGP.

>     Is the <plaintext> *required* to be an "OpenPGP message"?

Yes.

>     packets?  If not, are they legal inside strictly bounded

Yes. 

There are only a few places where such packets are not allowed.  I
think this is the case for key packets but I am not sure what the
specs do say; GnuPG handles this automagically.

  Werner

---

From: Florian Weimer <[email-masked]>
Date: 23 Aug 2001 19:39:39 +0200

Werner Koch <[email-masked]> writes:

> the text in advanced.

You could use new packet lengths to create a stream of packets...

---

From: Werner Koch <[email-masked]>
Date: 23 Aug 2001 22:00:21 +0200

> You could use new packet lengths to create a stream of packets...

Well, this is actually done except when the packet is a compressed
one.  Then we use the old PGP 2.6 method which is a little bit
faster.  The RFC allows for this.

---

From: Derek Atkins <[email-masked]>
Date: 23 Aug 2001 17:17:12 -0400

Have you looked into why it is faster?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Michael Young" <[email-masked]>
Date: Thu, 23 Aug 2001 23:31:40 -0400

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

From: "Werner Koch" <[email-masked]>
> faster.  The RFC allows for this.

It's not clear to me what the RFC really allows.  (It is clear that
indeterminate encodings are not *recommended* at any time.)

The RFC first says:
    "If the packet is in a file, this means that the packet
     extends until the end of the file."

It then goes on to say "where the end of the data will be
clear from the context", which is a little more liberal.
I suppose you could interpret "in a file" as "is an
entire file".

In this context, the end is only clear because an *outer*
packet had a hard length.  Using a hard length there seems
inconsistent -- if you're generating output as you go,
you wouldn't know the outer size either.

> feature is one of the great advantages of OpenPGP.

I agree that the ability to structure as a "filter" is an advantage.
The partial-body packet encoding achieves this, without having to rely
on some external container (file, or an outer packet) bounding the
length.

If anything, having a truly indeterminate packet inside another packet
makes it harder to use a filter-like implementation for parsing.

> Have you looked into why it is faster?

A partial-body encoding requires a power-of-two sized buffer be
repeatedly filled (completely, or until end-of-input), and then copied
to the output stream.  An indeterminate encoding has no length
information whatsoever, and so requires no buffering or copying.

---

From: Florian Weimer <[email-masked]>
Date: 24 Aug 2001 15:45:27 +0200

> information whatsoever, and so requires no buffering or copying.

In conjunction with compression, the claim that this affects
performance is a bit peculiar because compression itself typically
requires such buffering, and adds much more overhead anyway.

---

From: Derek Atkins <[email-masked]>
Date: 24 Aug 2001 10:09:25 -0400

> requires such buffering, and adds much more overhead anyway.

That was my impression as well.  Considering that most modern Unix
systems have some amount of buffering ANYWAYS in the I/O system, I
can't see how doing extra buffering really affects anything.  It's not
like you can really do a copy-in-place because you need to prepend
PGP-packet headers before the transformed data.  And, as you say,
compression has to buffer data anyways.

When Colin and I were first working on this back in '95, we _did_
buffer the data, and quite honestly it seemed to work just fine; much
better than writing to a file like PGP 2.x did.  And yes, we'd
definitely try to reduce the number of memcpy() functions that had to
happen.  But it's just as easy to encrypt-in-place as it is to
encrypt-to-a-different-buffer.

-derek