Subject: Moving forward

From: Werner Koch <[email-masked]>
Date: Tue, 12 Oct 1999 10:19:08 +0200

Hi,

the list is very quite for a long time now.  So I want to raise some
issues again which are still unsolved:

  - There is a problem with dash-escaped text 
    (see my mail from Sep 15th)

  - What happened to the MDC?
    Silently ignoring this issue is not good - we had a lot of
    discussion on this topic and some proposals.  If we don't
    come to a conclusion we should agree on a way to solve it.

  - Other issues like large signature packets, new packet types
    (non private ones) that PGP is now using should also be 
    discussed.

  - There are some open tasks from the last Oslo meeting.

  - Do we have a way to specify private extensions for the S2K
    (I am thinking about hardware tokens).

I see more and more demand for S/MIME applications.  To make OpenPGP
a success we should really agree on some topics and move forward to
get OpenPGP into draft standard state.

  Werner

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 12 Oct 1999 13:15:57 -0500

In <[email-masked]>, on 10/12/99 

>    (I am thinking about hardware tokens).

Any word on what's going on with PGP/MIME? Last I heard a couple of people
here were working on some issues but I haven't heard anything since then.

I am interested in seeing parallel signatures being added to the protocol.
I am not sure if this should be on the PGP/MIME level or the OpenPGP.

Another issue I would like to see addressed for a long time now is UserID
revocation. IMHO this is something that is much needed. 

>I see more and more demand for S/MIME applications.  To make OpenPGP a
>success we should really agree on some topics and move forward to get
>OpenPGP into draft standard state.

I have always been of the opinion that the way to get this done is for PGP
to be integrated into other protocol. Netscape & RSADSI are involved in
nearly every area where Inet security is involved and they are pushing
S/MIME X.509 protocols.

NAI has the resources to make just as big if not bigger push for the
OpenPGP protocols but they are not.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

---

From: Michael Elkins <[email-masked]>
Date: Wed, 13 Oct 1999 16:27:13 -0700

> I am not sure if this should be on the PGP/MIME level or the OpenPGP.

IMO, the parallel signature should be left out of PGP/MIME and OpenPGP.  Where
it belongs is in an update of RFC1847 (Security Multiparts) since this is a
generic encapsulation of multiple signatures.

That being said, an update of PGP/MIME would likely only reference the new
specification (RFC2440) instead of RFC1991.  Given that PGP/MIME only specifies
what you sign, not the format of the signature, it is fairly neutral with
respect to which spec you are talking about.

me

---

From: Dave Del Torto <[email-masked]>
Date: Fri, 15 Oct 1999 18:29:44 -0700

At 4:27 PM -0700 1999-10-13, Michael Elkins wrote:
>   >Any word on what's going on with PGP/MIME? Last I heard a couple of
>   >people here were working on some issues but I haven't heard anything
>   >since then.
>   >
>   >I am interested in seeing parallel signatures being added to the
>   >protocol. I am not sure if this should be on the PGP/MIME level or
>   >the OpenPGP.
>
>IMO, the parallel signature should be left out of PGP/MIME and
>OpenPGP. Where it belongs is in an update of RFC1847 (Security
>Multiparts) since this is a generic encapsulation of multiple
>signatures.
>
>That being said, an update of PGP/MIME would likely only reference
>the new specification (RFC2440) instead of RFC1991. Given that
>PGP/MIME only specifies what you sign, not the format of the
>signature, it is fairly neutral with respect to which spec you are
>talking about.

Sorry I've been so distracted by other things since Oslo... nice to 
hear from you, ME.

I'm trying hard to be unbiased about parallel sigs (having written 
it) but how about if we (Thomas & I, last I checked) split parallel 
sigs into a new, separate RFC and we also reference them in the new? 
OpenPGP/MIME RFC instead?

    dave

---

From: Jon Callas <[email-masked]>
Date: Sun, 17 Oct 1999 22:58:44 -0700

>issues again which are still unsolved:

I'm starting the task of updating 2440. I need to find an uninterrupted day
or two to do it properly. However, the main thing the working group really
needs to do is get implementations up to 2440-compliance. There's a part of
me that is loathe to rush on with mods to 2440 presently. I'd rather see
2440 become a standard than slow the whole process down by adding features,
as much as I like them, and believe that they're desirable. I would rather
see 2440 go to Standard   (or merely replace it with buffing of unclear
places) than see OpenPGP get bogged down in featuritis.

>    (see my mail from Sep 15th)

I've read through your mail, Werner, and have another suggestion for the
problem.

A summary of the problem is that that 2440 does not cover the case where a
clear-signed message does not end with a CRLF or is of length zero.

My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
just declare that that's bad? If a clear-signed message isn't
CRLF-terminated, add one. This also handles the zero-length case, because
that just becomes a single blank line.

I admit that it never occurred to me that you COULD have a clear-signed
message with no CRLF. This just strikes me as aesthetically bad that the
END header could dangle at the end of a line, and contrary to the intent of
cleartext, if not its stated or implied definition. This seems to me to
hinge on the definition of "canonical text-mode" text, and I always thought
that canonical text-mode text always ended with a line end. Am I wrong on
this?

>    come to a conclusion we should agree on a way to solve it.

Here's what has happened with it: many people seem to believe this is a
good idea. We've settled that out. However, the details of a design have
not been hashed out.

Remaining things to do are:

* One hash algorithm or many? My opinion is one, and that should be SHA-1.
We don't need the full capability of the hash algorithm the way signatures
do. SHA-1 is already required, and the contents of the hash are protected
by the cipher. Additionally, there are a number of subtle complexities that
get added if this is an option. We already have a hash-preferences packet,
but if there is an option on MDC packets, then the sender must not only
find a suitable cipher that the receivers speak, but also a suitable hash
algorithm. There's also the issue of what happens if an attacker attacks
the field that specifies the hash algorithm. I cannot help but believe that
all that will happen is that a lot of code will be executed that ends up
deciding to use SHA-1, the MUST-implement hash. I'll also note that even if
there's an option, the simplest thing for an implementation to do is just
plop down SHA-1 and not even give the user an option. I think I could even
write up an argument for why an implementation SHOULD just use SHA-1. I
think the correct thing to do is just plop 20 bytes of SHA-1 at the end of
the data.

* What cipher mode? I think we all agree that PGP-CFB mode is kinda hokey.
There is nothing wrong with it cryptographically, but no one else uses it.
There's a good argument that we should use standard CFB mode or even CBC
mode. However, I'm going to argue against that:

(1) CBC mode gives no more security than any of the other modes. It adds
complexity to the design, and complexity lowers security. There's a small
lure that possibly a CBC packet could be made to interoperate with S/MIME,
but the S/MIME people aren't interested in interoperating with us. We've
made several overtures to them to work together, and been rebuffed every
time. The last one required only that they change a MUST to a SHOULD on a
certificate specifier, and they refused. I have zero interest in lowering
our security by adding two code paths through the ciphers to interoperate
with people who don't want to interoperate with us. After all, it's in
*their* charter that they need to work with us, not ours.

(2) Regular CFB mode gives no more security than PGP-CFB mode. Adding in
another mode means more code, more things to review, more chances for an
error. If we have only one mode, there's only one thing to check out, and
all implementations are smaller. I'm mildly irked that PGP has to have its
own mode, but that's history. It works, it's secure. Eccentricity is not in
and of itself a bad thing. PGP-CFB mode is not there because the original
designers felt the need to be different, it's there because there was no
consensus at the time on how modes should be implemented, and PGP-CFB mode
has a genuine benefit -- it's easy to tell if you've used the wrong key on
a message, with errors at 2**-16. (And yes, yes, I know this sword has two
edges.)

Consequently, in spite of the fact that I have no particular love for
PGP-CFB mode, I say we just run with it, in the interests of simplicity and
speed.

The best thing to do would be for someone to write a PGP-CFB mode wrapper
that could be applied to a number of ciphers. Ideally, this would be
open-sourced. And no, I don't mean GPLed. I mean true open source, where
anyone could do anything with it.

* We have to design an Optional Features Subpacket. This is a subpacket
that goes in a self-signature that states that the certholder would
understand an MDC message should one be sent to them. It's not really that
big a deal. I see it as a vector of bytes, each denoting a feature. Feature
1 is MDC. Reserve feature FF as a tag, in case (perish the thought) we need
more optional features.

Here's my opinion:

The MDC packet looks exactly like the encrypted data packet, but it has 20
bytes of SHA-1 at the end. I've described the feature subpacket above.

>    (non private ones) that PGP is now using should also be

To show that I'm an equal-opportunity ox-gorer in the name of simplicity,
do we need the large signature packet? Do we need it now? My opinion is
that we need it, but not now. It's far more important that we get
implementations to support 2440 than anything else. I'm willing to put it
on the back burner for post-standard revisions of OpenPGP. Does anyone
object?

>  - There are some open tasks from the last Oslo meeting.

What are they? I know we're supposed to move ourselves along, and come up
with a list of things that an implementation has to do, so we can show we
have at least two interoperable versions. I think we have two that are
close. Tom Zerucha's reference implementation, and GnuPG. The main thing I
can think of for us to do is to show that they implement 2440, and
interoperate.

>    (I am thinking about hardware tokens).
No, we do not. Do we need them? Do you want to suggest an architecture?
Should I issue a plea for simplicity?

	Jon

---

From: Tony Mione <[email-masked]>
Date: Mon, 18 Oct 1999 07:55:06 -0400 (EDT)

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

On Sun, 17 Oct 1999, Jon Callas wrote:

>...

Along these lines...

At the request of John Noerenberg, I had created a 'Laundry List' of
features to work on for OpenPGP (v1.1). The list was discussed in Orlando
and some items were dropped. I have not updated the list since its original
creation last year.

Now that we are talking about new features, etc. Is there a need to
maintain this web page? If so, I will get on with updating it based on what
I have seen on the list in the past couple of days. For anyone who is
interested, the list is at:

http://hardees.rutgers.edu/~mione/ietf/OpenPGPv11LaundryList.html

Please indicate if I should make an attempt to bring this up to date.

> 	Jon

Take care.

Tony Mione                          Phone: +1 732-445-0605 FAX: +1 732-445-2968
Manager, TD Network Services                 W3: http://noc.rutgers.edu/~mione/
RUCS Telecommunications Division        PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall ** Rom 10:9-11 **

---

From: Tom Zerucha <[email-masked]>
Date: Mon, 18 Oct 1999 23:09:42 -0400 (EDT)

> anyone could do anything with it.

my opgp has such a wrapper routine and has no usage restrictions (and the
only modification restriction is that it must be documented or
disassociated).

> bytes of SHA-1 at the end. I've described the feature subpacket above.

As long as the 20 bytes are appended to the packet (i.e. are outside), not
the data.

I want a virtual EOF when I come to the end of encrypted data.

Alternately, say these new packets MUST use the old format CTBs, so the
length is in the header, so I can subtract 20.

---

From: Werner Koch <[email-masked]>
Date: Tue, 19 Oct 1999 10:37:45 +0200

> length is in the header, so I can subtract 20.

No! Please don't even thing about this.  We would loose the ability to
encrypt a stream directly.

---

From: Werner Koch <[email-masked]>
Date: Tue, 19 Oct 1999 10:34:40 +0200

> or two to do it properly. However, the main thing the working group really

That is good news.  Hope you will find the time.

> 2440 become a standard than slow the whole process down by adding features,

So do I.

> just declare that that's bad? If a clear-signed message isn't

This is okay for me.  If it is in the standard I have an easy answer
to those bug reports.  A clear signed message is not intended to be
in the first place machine readable but for humans and they don´t care
about an appended blank line.

> that canonical text-mode text always ended with a line end. Am I wrong on

No. 

> We don't need the full capability of the hash algorithm the way signatures

Go ahead and specify SHA-1 as the only one hash algorithm to be used.

I even give up on my request to add a version number to the new
packet.  The only thing I'd really like is to have the hash prefixed
with some bytes which can be interpreted as a packet (new type or
a signature packet of version 0) and the length of the encrypted 
packet given without this hash.  This way an implementor can choose
between:

  a) assume this is one packet (simply adding the fixed size of
     the hash packet to the length given in the header or reading
     these additional bytes in case of a partial length header).

  b) handle them as 2 packets with no need to defer the hashing of
     the encrypted packet by the length of the hash.

> PGP-CFB mode, I say we just run with it, in the interests of simplicity and

I agree.

> that could be applied to a number of ciphers. Ideally, this would be

I am not sure whether I understand this correct:  Do you mean a thing
to decrypt PGP-CFB and encrypt it using standard CFB?

> understand an MDC message should one be sent to them. It's not really that

Should it go as a hashed subpacket?  This would put a burden on the user to
update his self-signature - no big issue but it can't be automatized
by a new version of an implementation.  So in addition to this feature
subpacket (which is a good idea), what about a requirement (we already
discussed this) that for cipher algorithms with a blocksize other than
64 bit the use of the new MDC packet is a SHOULD (or MUST).  This will
be a good thing for the AES algorithm and Twofish.  It won't do any
harm.

> do we need the large signature packet? Do we need it now? My opinion is

No we don't need them.  I still don't thing that huge signatures are a
good thing - it makes a lot of trouble to handle them the same way as
usual signatures; the signed stuff should better go into a literal
data packet.  And yes, I know that there is the PGP ticket project but
we shouldn't discuss this now.

> implementations to support 2440 than anything else. I'm willing to put it

Another thing for the optional feature packet ;-)

> can think of for us to do is to show that they implement 2440, and

How can we do this?  Do we need to meet physically and if, does it need to
happen in the U.S. (due to export control rules)?  Is someone still
working on a check list?

> Should I issue a plea for simplicity?

I think it is a good idea to reserve some IDs for experiments, as we
did for ciphers etc. - In case such experimental packets have leaked
out and later revisions of the standard use the same IDs for another
purpose a user has not a good chance to identify this problem.

So I'd suggest to add just this:

3.6.1.4. Reserved S2K Identifiers

   Identifiers with a first octet in the range [0x64, 0x64] are
   reserved for private/experimental S2K algorithms.  

  Werner

---

From: Dave Del Torto <[email-masked]>
Date: Mon, 18 Oct 1999 18:41:17 -0700

At 10:58 PM -0700 1999-10-17, Jon Callas wrote:
>[...]
>A summary of the problem is that that 2440 does not cover the case where
>a clear-signed message does not end with a CRLF or is of length zero.
>
>message with no CRLF.

My memory may be faulty, but I believe that both RFC 1991 and our
OpenPGP/MIME draft simply implicitly assume that you can't have a
length-zero message, because it makes no sense to provide a digital
signature on _nothing_. You can't even use such a zero-length message
to verify someone's ownership of a _key_, which you could do with a
one-byte (i.e. one char) clearsigned message.
>This just strikes me as aesthetically bad that the END header could
>dangle at the end of a line, and contrary to the intent of
>cleartext, if not its stated or implied definition. This seems to me
>to hinge on the definition of "canonical text-mode" text, and I
>always thought that canonical text-mode text always ended with a
>line end. Am I wrong on this?             [...]

No, the armoured footer line should (always) be preceded by a CRLF.
You're right that it's an imperative for implementors to ensure this.

    dave

___________________________________________________________________________
The Shortest Correspondence on Record, sent by a 19th C. writer on vacation
via telegraph to his Publisher, inquiring about sales of his new novel: "?"
The answer came back shortly, also by Morse Code: "!"

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 19 Oct 1999 12:03:37 +0200

> >a clear-signed message does not end with a CRLF or is of length zero.

As I read the text, it does (RFC 2440, 7.1):

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

Actually, the construction is analogous to what MIME does with
multipart separator lines, see RFC 2046 section 5.1.1:

|   NOTE: The CRLF preceding the boundary delimiter line is
|   conceptually attached to the boundary so that it is possible to
|   have a part that does not end with a CRLF (line break).  Body
|   parts that must be considered to end with line breaks, therefore,
|   must have two CRLFs preceding the boundary delimiter line, the
|   first of which is part of the preceding body part, and the second
|   of which is part of the encapsulation boundary.

That is, OpenPGP implementations MUST add

		  <cr><lf><delimiter line><cr><lf>

when creating cleartext signatures, and MUST calculate the signature
over the text PRECEDING the <cr><lf> sequence which starts the
separator.

Thus, a "-----BEGIN PGP SIGNATURE-----" delimiter without a
preceding CRLF is just nonsense, and possibly part of signed text.

A quick test with pgp 2.6.3in, gpg 0.9.8a-snap1999-06-30, and pgp5
("PGP for Personal Privacy Version: unix50i1b") indicates that at
least these implementations actually seem to be working the way
suggested by the text and the analogy with MIME.

More precisely, I generated a simple text file which lacked the
final new line character.  I clearsigned it with pgp 2.6.3in.  The
signature was correctly verified by pgp2, gpg, and pgp5.  Then, I
added another new line in front of the delimiter line, and all
implementations correctly warned me that this was a bad signature.

> signature on _nothing_.

In the PGP/MIME draft, we don't really have to deal with this, since
we just take what MIME gives us, make sure MIME line endings are
correct (namely CRLF), and pass the rest to PGP.  

Additionally, with PGP/MIME, there is always at least one CRLF to be
signed: A multipart/signed MIME body MUST have two subparts, the
first of arbitrary type, the second of type
application/pgp-signature.  Since the signature is calculated over
the MIME representation of the first body part, our worst case is an
empty text/plain body part, including headers.  This can (worst case
again) be represented by one empty line which terminates
the (empty) MIME header.

Example:

| From: Thomas Roessler <[email-masked]>
| To: Thomas Roessler <[email-masked]>
| Subject: stupid test message
| Message-ID: <[email-masked]>
| Mime-Version: 1.0
| Content-Type: multipart/signed; micalg=pgp-md5;
| 	protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q"
|
| 
| --Q68bSM7Ycu6FN28Q
| 
| 
| --Q68bSM7Ycu6FN28Q
| Content-Type: application/pgp-signature
| 
| -----BEGIN PGP MESSAGE-----
| Version: 2.6.3in
| 
| iQEVAwUBOAxAbNImKUTOasbBAQGcxQf+KhjjzhxUo2RTCauKm+5znAXFWOtZAyVe
| 3mxuRJvJPDTjocEo/aDwHzekhqssLhPI0LD62R96LvKHM6nbYRJyG4pByf8VH2lI
| C2bWpSw7QFqBjJgBC8Z6+qD/hAdvdNbduNJ2kUPiX8npuVdj8RyWNDJ3xyk+TPQh
| vTbnGjwAeIgnygstZpKW8feBMFLi3SZ57qlc1Gen5r1srruNPYykPUoqpmjROe9j
| r6U4P17V1aKUzJts/b4RF+MKiO3ebQf5NbplWkMVvqdR0VNOYpddDZiqzYMkoIYb
| 3TcMUAzGcp1iRetd5mIezcJKJ6bIgPwdaZyvbuAW8lQ8LhZkn5uqqg==
| =37F7
| -----END PGP MESSAGE-----
| 
| --Q68bSM7Ycu6FN28Q--

---

From: Dave Del Torto <[email-masked]>
Date: Mon, 18 Oct 1999 18:41:12 -0700

dave