Subject: Re: Obvious (?) question about interoperability
From: Jon Callas <[email-masked]>
To: [email-masked]
Date: Tue, 31 Mar 1998 22:28:11 -0800

At 6:11 PM -0800 3/31/98, [email-masked] wrote:

   Having just regrouped my PGP 2.6.x support stuff, I need to ask what
   versions of what types we need to support.

   One stalling point is that although there are V4 packets for thinks like
   key material, 2.6.2 will only like RSA keys in V3 packets.

   Generally PGP 5.0 will interoperate, except any secret keyrings won't be
   decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being
   replaced by type 4).  It will also cause problems for conventionally
   encrypted packets.

We're going back to the type 3 iterated-salted s2ks. Simplicity is a
virtue, but not when it makes things harder.

   So I have to pause and ask, How backward compatible need we be, and with
   what versions?  Should 2.6.x be a mode, or something which prevades every
   portion of the spec where "We do X every time, except we also need to
   leave Y in".

The charter calls for "limited" backwards compatibility. I think for your
purposes it depends on how much you want to do. Our predecessor, RFC 1991,
recommended backwards compatibility to one previous version. That would
mean you could ignore 2.6. That wouldn't particularly nice, though. There
are a number of things you can do that are easy to make things work with
2.6.

I am planning on putting in the algorithm notes that a V3 key with a V3
self signature MAY be considered to have an implicit preference for IDEA
alone. This would mean that a considerate OpenPGP implementation can freely
interoperate with 2.6, but a minimal one doesn't have to.

For you, do as much as you want above what is required. If you want your
implementation to be widely used and interoperable with old versions, you
can do a lot. Otherwise, you can leave the annoying stuff to someone else.

   ------------------

   Another problem I have is with the new CTB, at least for intrinsically
   short packets like keys, signatures, P/SKESK headers, etc.
   If these are normalized (Monolithic if overall length is <4096 bytes), I
   can use ordinary libc calls (fread, fwrite).  Otherwise I need a
   normalization pass.  I think implementations SHOULD store anything except
   compressed, literal, or conventionally encrypted packets in normalized
   form.  Further, the conventionally encrypted packets should not divide the
   first 10 bytes (actually 11) of the stream.

There has been a suggestion for a new-format length that would use the
length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a
marker for a four-octet length that follows. So you would see:

	<CTB><0xFF><four-octet-length><packet-body>

as a packet form. That lets someone bring in the whole packet without the
streaming mechanism. People sounded supportive of that, and my slides for
tomorrow have that on there as a feature I want to have in the next draft.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 31 Mar 1998 21:16:05 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Obvious (?) question about interoperability
Sender: [email-masked]

[email-masked] writes:
> Having just regrouped my PGP 2.6.x support stuff, I need to ask what
> versions of what types we need to support.
>
> One stalling point is that although there are V4 packets for thinks like
> key material, 2.6.2 will only like RSA keys in V3 packets.
>
> Generally PGP 5.0 will interoperate, except any secret keyrings won't be
> decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being
> replaced by type 4).  It will also cause problems for conventionally
> encrypted packets.
>
> So I have to pause and ask, How backward compatible need we be, and with
> what versions?  Should 2.6.x be a mode, or something which prevades every
> portion of the spec where "We do X every time, except we also need to
> leave Y in".

Things like secret keyrings are largely beyond the scope of the spec
because it describes interchange formats.  We do describe secret keys
since those could be exchanged, as when someone brings his secret key
from work to his home.

There are many places in the spec where backwards compatibility
considerations are called out.  In some places we have a SHOULD behavior
which breaks backwards compatibility, with an associated MAY behavior
to retain backwards compatibility.

Ultimately it is for the implementor to decide how important backwards
compatibility is with PGP 2.X.

> Another problem I have is with the new CTB, at least for intrinsically
> short packets like keys, signatures, P/SKESK headers, etc.
> If these are normalized (Monolithic if overall length is <4096 bytes), I
> can use ordinary libc calls (fread, fwrite).  Otherwise I need a
> normalization pass.  I think implementations SHOULD store anything except
> compressed, literal, or conventionally encrypted packets in normalized
> form.  Further, the conventionally encrypted packets should not divide the
> first 10 bytes (actually 11) of the stream.

By "normalization" do you mean the problem of assembling packets which use
partial-length fields?  If so, it was for this reason that I recommended
adopting a four-byte length field option.  I understand this will be
discussed at the OpenPGP meeting tomorrow.

> For all the complaints about bit-twiddling, I don't understand why no one
> doesn't think there is any problem creating an entire I/O abstraction
> layer, i.e. a pgpfopen, pgpfread, etc. which is what the spec requires (if
> you don't want to add it as a filter).

I agree that the bit-twiddling which has called so much attention to
itself is a tiny fraction of the work you must do to implement the spec.

> I would make all of these MUSTs, but embedded applications may have
> reasons not to, and I can normalize the stream myself.

What exactly would you make MUSTs?  Do you mean you would disallow the
partial-length packets?

> Since I introduced the term normalized, I should define it -
>
> packet :- oldCTB-len, datachunk... | newCTB len-stream
>
> len-stream :- nontermlen, datachunk, len-stream | termlen, datachunk
>
> The len-stream is normal if it does not contain any nontermlen entries
> indicating the following datachunk is less than 4096 bytes.

I don't understand the significance of this definition.  What is it about
normal vs non-normal streams which requires them to be treated differently?
I could see a distinction between packets which have the length at the
beginning vs packets whose length is not known until you have read the
whole thing.  But I don't understand why the issue is whether the
partial length packets are less than 4096 bytes.

Hal

Date: Tue, 31 Mar 1998 21:23:16 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Why one pass sigs?
Sender: [email-masked]

[email-masked] writes:
> Actually I would dump 1-pass signatures.
>
> The way I would implement multiple signatures is to use one of the
> subpackets to indicate nesting in the existing signature structure.

The purpose of the 1-pass signature packets is not primarily to provide
multiple signature capability.  The main purpose is to allow the signer
to process the entire message in one pass.

With old-style signatures, the signature has to go at the front of
the message.  But the signer can't create the signature until he has
processed the whole message.  So he then has to go back and stick the
signature back at the front of the message, which requires some buffering
and re-scanning of the data.

With the 1-pass signature, the signer puts the 1-pass packet at the
front to tell the verifier what hash to use, then comes the message,
and then comes the signature.  This is a much more natural flow for all
parties.

PGP 2.X creates many temp files to deal with the buffering needed by the
signature structure, and the need to know all packet lengths in advance.
The one-pass signature packets and partial packet length specifiers are
designed to allow processing messages without any temporary files, which
enhances security and performance.

Hal

Date: Tue, 31 Mar 1998 23:27:29 -0500
From: [email-masked]
To: [email-masked]
Subject: Why one pass sigs?
Sender: [email-masked]

Actually I would dump 1-pass signatures.

The way I would implement multiple signatures is to use one of the
subpackets to indicate nesting in the existing signature structure.

How large is a signature packet?  The largest you can think of.  3K
with a 8K RSA key and lots of subpackets?  Most hash contexts are a
significant fraction of that size, and you will need to create them to
hash streams which is why they are there in the first place.

So I would do something like:

PacketParse(hashctx) {
...
switch (packettype)
...
Sigparse:
numsigs=0
do {
  read sig header
  malloc buffer[numsigs]
  read sig into buffer
  extract hashalg and antinest
  setup hashcontext[numsigs]

  numsigs++;
} while antinest

/* will use sigparse case recursively for nested sigs */
PacketParse(hashcontext,numsigs)

while( numsigs > 0 ) {
  finish hashing and verify signature using buffer[numsigs]
  dealloc buffer[numsigs]
  numsigs--;
}

}

or you can have PacketParse not hash sig packets if they have the antinest
flag set, but hash all others and it would be a purely recursive
implementation and the buffer and hashcontext need not be arrays. 

Even for true 1pass sigs, you have to set up a lot of structure.

Is adding the half parsed signature packet really going to bloat things
that much over what you have to do (much less what you actually do) with
normal sig packets?

Dumping 1 pass sigs would make things uniform and by changing the topology
of the implementation it could still handle signatures as streams.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 31 Mar 1998 21:11:53 -0500
From: [email-masked]
To: [email-masked]
Subject: Obvious (?) question about interoperability
Sender: [email-masked]

Having just regrouped my PGP 2.6.x support stuff, I need to ask what
versions of what types we need to support.

One stalling point is that although there are V4 packets for thinks like
key material, 2.6.2 will only like RSA keys in V3 packets.

Generally PGP 5.0 will interoperate, except any secret keyrings won't be
decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being
replaced by type 4).  It will also cause problems for conventionally
encrypted packets.

So I have to pause and ask, How backward compatible need we be, and with
what versions?  Should 2.6.x be a mode, or something which prevades every
portion of the spec where "We do X every time, except we also need to
leave Y in".

------------------

Another problem I have is with the new CTB, at least for intrinsically
short packets like keys, signatures, P/SKESK headers, etc.
If these are normalized (Monolithic if overall length is <4096 bytes), I
can use ordinary libc calls (fread, fwrite).  Otherwise I need a
normalization pass.  I think implementations SHOULD store anything except
compressed, literal, or conventionally encrypted packets in normalized
form.  Further, the conventionally encrypted packets should not divide the
first 10 bytes (actually 11) of the stream.

For all the complaints about bit-twiddling, I don't understand why no one
doesn't think there is any problem creating an entire I/O abstraction
layer, i.e. a pgpfopen, pgpfread, etc. which is what the spec requires (if
you don't want to add it as a filter).

I would make all of these MUSTs, but embedded applications may have
reasons not to, and I can normalize the stream myself.

Since I introduced the term normalized, I should define it -

packet :- oldCTB-len, datachunk... | newCTB len-stream

len-stream :- nontermlen, datachunk, len-stream | termlen, datachunk

The len-stream is normal if it does not contain any nontermlen entries
indicating the following datachunk is less than 4096 bytes.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 31 Mar 1998 09:51:41 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: 3DES Weakness
Sender: [email-masked]

I wrote:
> The disadvantage
> is that the block size is then only 64 bits, so if you encrypt a
> substantial fraction of 2^64 blocks (2^67 bytes) using a given key,
> there is a chance that duplicate blocks will occur by accident, which
> will reveal some plaintext.

This is incorrect; having duplicate blocks occur is a "birthday paradox"
problem and you need only about 2^32 blocks before you have a substantial
chance of getting a duplicate.  This is 32 GBytes of data, which might be
approached in some applications, especially in the future.

Hal

Date: Tue, 31 Mar 1998 08:41:11 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: 3DES Weakness
Sender: [email-masked]

> NYT-Markoff reports today on Biham and Knudsen's paper
> on 3DES weakness, "Cryptanalysis of the ANSI X9.52 
> CBCM Mode," noted here a few days ago.

This mode of operation is not used in OpenPGP.  It was a special mode
created by Don Coppersmith et al to thwart a series of attacks devised
by Eli Biham against 3DES modes which use inner feedback to effectivelly
increase block size.  (Inner feedback means that you bring in data from
other blocks between the three DES operations.)  In the last few years,
Biham has shown that adding inner feedback is dangerous and often helps
an attacker.  Coppersmith came up with a special way of doing it which
was supposed to be immune to Biham's methods, which is the CBCM mode.
Now Biham has shown that this mode, as well, is vulnerable to his attack.

OpenPGP uses only "outer" feedback, in CFB mode.  We operate on each block
using three full DES operations, without trying to bring in any extra
feedback between the three DES transformations.  The advantage is that
without inner feedback, Biham's attacks don't apply.  The disadvantage
is that the block size is then only 64 bits, so if you encrypt a
substantial fraction of 2^64 blocks (2^67 bytes) using a given key,
there is a chance that duplicate blocks will occur by accident, which
will reveal some plaintext.  However this is an extremely large amount
of data, and since OpenPGP usually uses randomly generated session keys,
it is not a problem in practice.

Hal Finney

Date: Tue, 31 Mar 1998 11:10:39 -0500
From: [email-masked]
To: [email-masked]
Subject: Preannounce: opgp92.tgz
Sender: [email-masked]

On Mon, 30 Mar 1998, Hal Finney wrote:

> This is a remarkable accomplishment!  OpenPGP compatible encryption,
> decryption, and signatures in under 6000 lines of C code, making use of
> standard libraries like SSLeay.

I just checked - it is actually shorter since 2000 lines are simply the
implementations for RIPEMD-160, HAVAL, and SAFER/SK128 which I included
instead of patches and/or URLs.  Counting just my *.[ch] files, it is
around 3750.

I also have left in lots of lines for demonstration (e.g. how to add RC2
as algorithm 100), and limited the line length.

I am verifying 0.92 (Found some problems with S2K algs 0 and 1, but now
they interoperate with PGP 5) - it should be up on www.cryptography.org
this afternoon after I complete some testing.

The README in the pgplib directory lists my notes for the OpenPGP
specification (what I do, don't, or deviate from).

--- reply to tzeruch - at - ceddec - dot - com ---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 31 Mar 98 08:39:50 -0600
To: [email-masked]
Subject: Re: 3DES Weakness
Sender: [email-masked]

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

- -------------------------------------------------------------------------
The following message is forwarded to you by "William H. Geiger III"
<[email-masked]> (listed as the From user of this message).  The
original sender (see the header, below) was John Young <[email-masked]>
and has been set as the "Reply-To" field of this message.
- -------------------------------------------------------------------------
>Date: Tue, 31 Mar 1998 07:44:49 -0500
>To: [email-masked]
>From: John Young <[email-masked]>
>Subject: 3DES Weakness
>Sender: [email-masked]
>Reply-To: John Young <[email-masked]>

NYT-Markoff reports today on Biham and Knudsen's paper
on 3DES weakness, "Cryptanalysis of the ANSI X9.52 
CBCM Mode," noted here a few days ago.

The ANSI X9.F1 committee has held up implementing its
standard as a result, and may have to wait for AES. 
Credit is given to the worldwide DES crack.

   http://www.nytimes.com

See a mirror:

   http://jya.com/3des-weak.htm

Get the Biham/Knudsen paper:

  http://www.cs.technion.ac.il/%7Ebiham/publications.html

- -----------------------------------------------------
 -- End of forwarded message
- -----------------------------------------------------
- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: Don't be held back by yesterday's DOS!  Try today's OS/2!

Date: Tue, 31 Mar 1998 00:33:58 -0500
From: [email-masked]
To: [email-masked]
Subject: Testcases and opgp91f.tgz
Sender: [email-masked]

The first is at the execpc.com location.  I added the PGP tag on
conventional encryption which seems to unconfuse PGP5.x

The source which produced it is on www.cryptography.org, as usual.
Now version f (a pre-0.92).

I still have to verify it on DEC Alpha, FreeBSD, maybe SPARC, and verify
the mungability.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 23:42:59 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Sender: [email-masked]

On Mon, 30 Mar 1998, Hal Finney wrote:

> PGP 5.X puts a marker packet at the beginning of any binary message which
> includes new-style packet tag octets (ones with bit 6 set).  This
> causes PGP 2.X to recognize that the message is a PGP message which
> requires a newer version of PGP.  Without the marker packet, PGP 2.X
> thinks it is not a PGP message.
> 
> The binary parser for PGP 5.X also looks for an old-style tag octet at
> the beginning of the message.  This is in pgpFileTypePGP in the
> pgpFileType.c module.
> 
> In order for PGP 5.X to recognize that a binary message which uses
> new-format tags is a PGP message, you should put a marker packet at
> the front.  That's why it is not reading the SKESK example properly.

So, that is what the 0xa8 0x03 'P' 'G' 'P' is for?  I shut it off for
conventionals.
(line 157 of pgp5cryp.c)

Oh well, version 0.91e tomorrow...

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 19:37:46 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Conventional works, but pgpv needs armor
Cc: [email-masked]
Sender: [email-masked]

At 11:52 AM -0500 3/29/98, [email-masked] wrote to
[email-masked]:
>the passphrase is "testpass", the first is S2KEK, the second is S2K only.
>

I was able to decrypt the S2K example with PGP 5.0 on my Mac.  The S2KEK
example didn't work.  I didn't try removing the blank line.
john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  The decriminalization of slang, sloganeering, huckstering and
  doublespeak masquerading as intelligible communication has lobotomized
  the culture.  What are left ae sound bites, parodies and paralysis.
  -- Russell Sherman, "Piano Pieces", 1997
  ----------------------------------------------------------------------

Date: Mon, 30 Mar 1998 23:39:25 -0500
From: [email-masked]
Reply-To: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: opgp91 uploaded - version d :)
Sender: [email-masked]

On Mon, 30 Mar 1998, Hal Finney wrote:

> This is a remarkable accomplishment!  OpenPGP compatible encryption,
> decryption, and signatures in under 6000 lines of C code, making use of
> standard libraries like SSLeay.  Those who are reluctant to wade through
> the 100000+ lines of PGP 5.X may find this implementation easier to
> digest.  I want to congratulate tzeruch for producing this implementation
> so quickly, and thank him for his interoperability testing with PGP 5.X.
> 
> Hal Finney

Not so fast, now 0.91d (a pre 0.92) is there.  Our T1 went down, and I
found a few small problems, but have full V4 signatures in one pass form
(I merged routines so it is smaller too).  There is always 1 more bug.
But it is easier to find in fewer lines and usually something stupid I did
recently.  But my TODO list has no more features (unless the spec
changes), and there isn't too much more to clean up.

A fixed test suite will be up tomorrow (My 75Mhz 486 laptop is fast enough
for development, but not to generate the test cases, and I don't want to
upload using a modem).

It also wasn't that quickly - I already had a 2.6.2 lib (my minipgp
directory originally). The first version actually predated the scanned
code (I has all but S2K for the things that were turned on, and bought the
5 volumes which now have post-it notes every few pages when the scanning 
effort seemed stopped at 95%).

Also remember I am leaving it to pgpk to handle keyrings and trust, and I
don't do packet parsing.  Someone else can do a shell script or GUI or
something else as a wrapper.  I use the routines as a general crypto
library, but it is nice to be compatible with an application.  But for PGP
internals, I think it is a good reference.  Now that it works.

After the scanned code was available, I could more easily turn things on,
so I could verify more things ( f(f**-1(x))=x, f and f**-1 being different
implemntations if possible).

Now that I have a real (or sometimes surreal) spec, it is easier.

But part of the effort was to produce a cleaner reference source - the
S2Ks get/put for example are mirror images, and except for the hashing,
monolithic.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 23:15:27 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Test Suite - and S2K Detail missing from the spec
Sender: [email-masked]

On Mon, 30 Mar 1998, Hal Finney wrote:

> > I programmed up a script to encrypt/sign one of my README files with all
> > possible combinations of algorithms I support.
> >
> > I included ElGamal signatures and the .tgz file is just over 1Mb, so I
> > don't know of anyone else would want to try.
> 
> As we have discussed in the past, ElGamal signatures are not secure
> with the DSS keys generated by PGP.  It is necessary to change
> the keygen algorithm so that generators other than 2 are used.
> See http://www.bell-labs.com/user/bleichen/bib.html.

Been there, fixed that

1. I use a Generator of 5

2. I insure there is no small gcd

3. I use DH key material, not DSS.

4. If I get an insecure key I print a warning and treat it as an error.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 16:12:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: opgp91 uploaded
Sender: [email-masked]

This is a remarkable accomplishment!  OpenPGP compatible encryption,
decryption, and signatures in under 6000 lines of C code, making use of
standard libraries like SSLeay.  Those who are reluctant to wade through
the 100000+ lines of PGP 5.X may find this implementation easier to
digest.  I want to congratulate tzeruch for producing this implementation
so quickly, and thank him for his interoperability testing with PGP 5.X.

Hal Finney

Date: Mon, 30 Mar 1998 16:01:41 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Cc: [email-masked]
Sender: [email-masked]

PGP 5.X puts a marker packet at the beginning of any binary message which
includes new-style packet tag octets (ones with bit 6 set).  This
causes PGP 2.X to recognize that the message is a PGP message which
requires a newer version of PGP.  Without the marker packet, PGP 2.X
thinks it is not a PGP message.

The binary parser for PGP 5.X also looks for an old-style tag octet at
the beginning of the message.  This is in pgpFileTypePGP in the
pgpFileType.c module.

In order for PGP 5.X to recognize that a binary message which uses
new-format tags is a PGP message, you should put a marker packet at
the front.  That's why it is not reading the SKESK example properly.

Hal Finney
[email-masked]
[email-masked]

Date: Mon, 30 Mar 1998 15:47:55 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Test Suite - and S2K Detail missing from the spec
Cc: [email-masked]
Sender: [email-masked]

> I programmed up a script to encrypt/sign one of my README files with all
> possible combinations of algorithms I support.
>
> I included ElGamal signatures and the .tgz file is just over 1Mb, so I
> don't know of anyone else would want to try.

As we have discussed in the past, ElGamal signatures are not secure
with the DSS keys generated by PGP.  It is necessary to change
the keygen algorithm so that generators other than 2 are used.
See http://www.bell-labs.com/user/bleichen/bib.html.

Hal Finney
[email-masked]
[email-masked]

Date: Mon, 30 Mar 1998 15:39:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Test Suite - and S2K Detail missing from the spec
Cc: [email-masked]
Sender: [email-masked]

[email-masked] writes:
> Which is mainly the way it works, but there is a quirk in pgp5.0 that the
> cipher length of the S2K cipher must equal the cipher length of the ESK: 
> [...]
> If 3DES encrypts a CAST key, or vice versa, the test will fail, but if
> IDEA encrypts CAST or CAST encrypts IDEA, it will work (and PGP can't be
> requiring both to use identical ciphers).

Yes, that's a bug, thanks for pointing it out.

Hal

Date: Mon, 30 Mar 1998 18:36:48 -0500
From: [email-masked]
To: [email-masked]
Subject: Test Case set and opgp91a
Sender: [email-masked]

I found a bug in my V4 sigs, and now have 1 pass V4 working.
Still needs some cleaning.

I updated the test cases which should be 1215595 bytes
(www.execpc.com/~tz/asctest.tgz)

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 17:42:41 -0500
From: [email-masked]
To: [email-masked]
Subject: Test Case set
Sender: [email-masked]

www.execpc.com/~tz/asctest.tgz

About 1.2 Meg, with 360+ test cases.  No warranties, especially not that
they comply with the spec since that is what I am trying to figure out.

Start with pubring.asc and secring.asc (and set PGPPATH=. if you don't
want to mess up your keyrings).

The passphrase for all conventional encryptions is:
testpass

README is the encrypted file, not a real README.

Files are named by the algorithms applied:

c-[conv].asc
	Conventional, just S2K (using [conv]).
ce-[s2k]-[esk].asc
	Conventional using [esk], ESK encrypted using [s2k]
e-[pk]-[conv]-[sig]-[hash][-4].asc
	Public key encrypted ESK using pk
	Conventional algorithm conv
	Signature alg sig (includes ElGamal, and works w/PGP5 if enabled)
	Hash using hash
	if extra -4, the sig is in v4 format (AFAIK).
s-[sig]-[hash][-4].asc
	Detached sig as above (on README)

PGP5.0 seems to work (after fixing the S2K conventional keysize problem,
bypassing SHA1 only for DSA, and enabling ElGamal and RSA)  on all
combinations that use only supported algorithms, but does not handle V4
signatures.  But I include Conventional 0,4,5,6, and Hash 4.

This may disappear or be updated depending on conditions

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 15:34:44 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: opgp91 uploaded
Sender: [email-masked]

again to www.cryptography.org, should be in libraries shortly

This fixes a bug (and a bug the first fix introduced) in the ascii
armoring.  S2K and conventionally encrypted messages are supported. 
Detached (or extracted) V4 signatures are supported.  Much has been
cleaned up and/or reorganized.

I still don't have one-pass V4 signature support.

This release caused a few questions on some subtle points in the OpenPGP
spec, which are also implemented as I thought they should be.

I also did a munge-oriented reformat (tabs are only in Makefiles and one
shell script, testnp.sh where I missed them at the bottom).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 13:57:44 -0500
From: [email-masked]
To: [email-masked]
cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Test Suite - and S2K Detail missing from the spec
Sender: [email-masked]

On Mon, 30 Mar 1998 [email-masked] wrote:

> Initially, one or more hash contexts are set up as with the other S2K
> algorithms, depending on how many octets of key data are needed.
> 
> MD5 yields 16 bytes, SHA1 yields 20 bytes, DES needs 24.  How do I
> generate the extra material needed by longer algorithms?

I figured this out.  The problem is that it is under each individual S2K
description when technically it applys everywhere (maybe a 3.6.3.?
Keylength Issues Common to all S2K algorithms).

In 5.3

If the encrypted session key is present, the result of applying the S2K
algorithm to the passphrase is used to decrypt just that encrypted
session key field, using CFB mode with an IV of all zeros.  The
decryption result consists of a one-octet algorithm identifier that
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
specifies the conventional encryption algorithm used to encrypt the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^->
following Symmetrically Encrypted Data Packet, followed by the session
key octets themselves.

Nothing says that the conventional algorithm used to encrypt the ESK need
be the same as that used to encrypt the SEDP.

Which is mainly the way it works, but there is a quirk in pgp5.0 that the
cipher length of the S2K cipher must equal the cipher length of the ESK: 

eskConvkeyValidate (byte const *buf, size_t len)
...
        c = pgpCipherByNumber (buf[1]);
This is the cipher used to encrypt the ESK, not the ultimate message.
        ret = pgpS2Kdecode (NULL, NULL, buf+2, len-2);
...
        len -= 2+ret;
...
        if (len < c->keysize+1)
                return PGPERR_ESK_TOOSHORT;
        if (len > c->keysize+1)
                return PGPERR_ESK_TOOLONG;

If 3DES encrypts a CAST key, or vice versa, the test will fail, but if
IDEA encrypts CAST or CAST encrypts IDEA, it will work (and PGP can't be
requiring both to use identical ciphers).

You would need to decrypt the ESK to find the new cipher number, and then
the keysize test would work (and probably where the test belongs).

#if 0-ing the test out made PGP work fine.

Note that this may be an issue depending on how "preferred ciphers" are
implemented.  If the ultimate user prefers CAST for the session key, I
might want to add a conventional key using 3DES to encrypt the session
key to someone else.  This won't work now.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 30 Mar 1998 15:41:37 -0300
To: [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: On my HAVAL implementation
Sender: [email-masked]

Greetings.

I've been informed that some people are having trouble to use my public
domain implementation of the HAVAL hashing function.

I'd like to point out that:

1. Though my implementation is indeed public domain, the very algorithm is
*not*, as Dr. Yuliang Zheng clearly states in his HAVAL page.  However,
he's very liberal in conceding "licenses" (in fact, absolutely no fee is
due; Dr. Zheng only wants to keep track of where HAVAL is being used).

2. When compiling on Intel machines, it is necessary to #define
LITTLE_ENDIAN, or else -DLITTLE_ENDIAN for the code to behave properly.  A
new release is due to be soon available online that automatically does that
on some known platforms.  Please check
<http://www.nw.com.br/users/pbarreto/crypto_page.html> in a few days (a
week at most; I'm still waiting for some feedback from some  contributors).

3. I was not able to test the code on George Barwood's page on big-endian
machines (nor under Borland C++ compiler).  I have recently received bug
reports and corrections from Mr. Tines; these have been merged into the new
release, which seems to be OK on those platforms.

If anyone needs the corrected implementation right now, I'll gladly post it
by e-mail.  For reference, I can be reached at <[email-masked]>, at
<[email-masked]>, and at <[email-masked]>, but no
longer at <[email-masked]>

Finally (and for completeness), I'd like to point out that a Java
implementation of HAVAL is available as part of the Cryptix cryptographic
library (together with a whole lot of other cryptographic algorithms).

Cheers,

Paulo Barreto.

Date: Mon, 30 Mar 1998 11:30:19 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Test Suite - and S2K Detail missing from the spec
Sender: [email-masked]

I programmed up a script to encrypt/sign one of my README files with all
possible combinations of algorithms I support.

I included ElGamal signatures and the .tgz file is just over 1Mb, so I
don't know of anyone else would want to try.

I did have problems with conventional encryption with pgpv if the ESK used
3DES, but IDEA and CAST worked.  Also if you just use the salted S2K
value, pgpv ignores the cipher type byte in the ESK (only using the one in
the key).  pgpv also removes the trailing linefeed of the S2K only.  It
kept asking for a passphrase for S2K-only-3DES.

Which leads me to the lacuna in the S2K description:

Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.

MD5 yields 16 bytes, SHA1 yields 20 bytes, DES needs 24.  How do I
generate the extra material needed by longer algorithms?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 29 Mar 1998 18:17:31 -0500
From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Sender: [email-masked]

On Sun, 29 Mar 1998, William H. Geiger III wrote:

> On the first message there was an extra blank line inbetween the last line
> of radix-64 and the checksum. One must remove this line for decryption to
> work.

My dearmor rejects whitespace (including redundant linefeeds).

But that was a bug in my armor.c routine (if the line prior to the CRC was
exactly 64 chars).  Fixed.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 29 Mar 1998 18:13:14 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: 10.2 grammar (naked encrypted packets?)
Sender: [email-masked]

On Sun, 29 Mar 1998, Hal Finney wrote:

> > Noting the grammar says:
> >
> > OP Message :- Encrypted Message
> >
> > Encrypted Message :- Symmetrically Encrypted Data Packet
> >
> > So, a SEDP without any info how to decrypt it is a valid OP message?
> 
> Yes, that's the format PGP 2.X uses for a conventionally encrypted
> message.  If there are no ESKs the SEDP is assumed to be encrypted with
> IDEA, using the Simple rules to convert passphrase to key (i.e. hash
> the passphrase with MD5).

I think it would be clearer to say something like IDEA/MD5S2K SEDP (for
those who don't like V3 or PGP2) since SEDP | ESK,SEDP sort of implies the
isolated SEDP has an identical definition, when it actually is narrower. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 29 Mar 1998 11:59:19 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: 10.2 grammar (naked encrypted packets?)
Sender: [email-masked]

> Noting the grammar says:
>
> OP Message :- Encrypted Message
>
> Encrypted Message :- Symmetrically Encrypted Data Packet
>
> So, a SEDP without any info how to decrypt it is a valid OP message?

Yes, that's the format PGP 2.X uses for a conventionally encrypted
message.  If there are no ESKs the SEDP is assumed to be encrypted with
IDEA, using the Simple rules to convert passphrase to key (i.e. hash
the passphrase with MD5).

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 29 Mar 98 12:59:54 -0600
To: [email-masked]
Cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Sender: [email-masked]

This is a MIME encapsulated message

--==_011D2_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/29/98 
   at 11:52 AM, [email-masked] said:

>Well, it did work, and I originally had this ready to post until pgpv
>managed to decrypt it.

>the passphrase is "testpass", the first is S2KEK, the second is S2K only.

>Maybe some others would contribute test case messages (or pointers
>to).

I can confirm that both messages decrypted with my OS/2 port of PGP 5.0i
and as with the unix version it only works if the message is
ascii-armored.

On the first message there was an extra blank line inbetween the last line
of radix-64 and the checksum. One must remove this line for decryption to
work.

I'll have to fire up the NT box (shudder,shudder) and see how 5.5 handles
it.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: The best way to accelerate Windows is at escape velocity.

--==_011D2_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_011D2_===--

Date: Sun, 29 Mar 1998 13:09:57 -0500
From: [email-masked]
To: [email-masked]
Subject: 10.2 grammar (naked encrypted packets?)
Sender: [email-masked]

Noting the grammar says:

OP Message :- Encrypted Message

Encrypted Message :- Symmetrically Encrypted Data Packet

So, a SEDP without any info how to decrypt it is a valid OP message?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 29 Mar 1998 11:52:21 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Sender: [email-masked]

On Sat, 28 Mar 1998, Hal Finney wrote:

> [email-masked] writes:
> > I managed to get conventional SKESKs working, and pgpv 5.0 even understand
> > them, but I must ascii armor the file, or it says opening /dev/null and
> > does nothing.  I tried both s2k alone and s2k encrypted key.
> 
> I don't remember how much support is in the 5.0 Unix version.  Why don't
> you post a SKESK conventional message to the list, tell us what the
> passphrase is, and people can try decrypting it with different versions of
> PGP.

Well, it did work, and I originally had this ready to post until pgpv
managed to decrypt it.

the passphrase is "testpass", the first is S2KEK, the second is S2K only.

Maybe some others would contribute test case messages (or pointers to).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 28 Mar 1998 14:40:25 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Conventional works, but pgpv needs armor
Cc: [email-masked]
Sender: [email-masked]

[email-masked] writes:
> I managed to get conventional SKESKs working, and pgpv 5.0 even understand
> them, but I must ascii armor the file, or it says opening /dev/null and
> does nothing.  I tried both s2k alone and s2k encrypted key.

I don't remember how much support is in the 5.0 Unix version.  Why don't
you post a SKESK conventional message to the list, tell us what the
passphrase is, and people can try decrypting it with different versions of
PGP.

Hal

Date: Sat, 28 Mar 1998 13:23:58 -0500
From: [email-masked]
To: [email-masked]
Subject: Suggested addition
Sender: [email-masked]

Add signature subpacket types 100-110 as internal or user defined.

If I want to add my own tag to a PGP signature it would be nice to have a
place.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 28 Mar 1998 11:34:02 -0500
From: [email-masked]
To: [email-masked]
Subject: Signature packets without keyid?
Sender: [email-masked]

One pass signature packets contain a keyid, but there is no MUST to
require the keyid within the signature packet itself (that I can find,
i.e. in the subpacket definitions).

I would add MUST include a keyid subpacket (unhashed, MAY hash), and
SHOULD include the creation time in the hashed area, which would
correspond to what V3 signatures provide.

Otherwise there MUST be a 1 pass signature packet, and this would require
all implementations to prestore the keyid.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 27 Mar 1998 22:42:35 -0500
From: [email-masked]
To: [email-masked]
Subject: opgp90a uploaded
Sender: [email-masked]

www.cryptography.org, should be in libraries shortly

This is a pre-91 release (I still need to clean a few things), but if
anyone wants to take a look...

It now can support V4 signatures (unverified) and conventional encryption 
(only single ESK packets for now, but the code works and can be extended).

I think I have something for all parts of the spec (I am not doing key WOT
stuff - the V4 sig create has a quick V3 info mode or will take a
preformatted buffer).  And a few additions (e.g. El Gamal).

opgp91 should appear early next week after I clean things up.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 27 Mar 1998 19:04:07 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

At 11:27 AM 3/26/98 -0800, Jon Callas wrote:
>In this particular case, I think there's merit in *suggesting* but not
>mandating that the message id be a function of the message. 
>There's nothing wrong in suggesting that a hash be used, 
>but there are plenty of other suitable ways to do it, including 
>just taking a slice of funtional slice cyphertext, which is mathematically 
>"random" and cannot leak any information. Cyphertext is always sent 
>in the clear, as it were.
>
>I also think there's merit in not mandating how it's done, as long as it's
>deterministic. However, I'm willing to listen to anyone who wants to argue
>that that MUST on determinism be a SHOULD.

There are at least three problems with Message-ID
- Is the implementation secretly leaking data through it?
- Is the implementation leaking data due to bugs or bad design?
- Does the message-ID increase traceability of the message?

The latter's been argued enough times, and we'll assume for the
moment the non-existence of bugs :-)  
The problem with making it only a SHOULD is that the recipient,
and possibly the sender, can't verify whether it's leaking data or not.
If you make documentation of the algorithm a MUST, and the algorithm is
deterministic, then the sender can verify it, but the recipient doesn't
have access to the sender's documentation anyway.  If you make
one or one-of-small-n algorithms mandatory, both the sender and
recipient can check.  I lean towards "SHA1 or MD5 of the cyphertext",
ignoring any armor that might be present or whitespace-munged.

I suppose the same problem exists with initialization vectors and 
session keys, and you can argue that 
- if you _are_ paranoid, you shouldn't be using software without
	reading the source code yourself first
- the sender could also be sending copies of the message to kgbvax
	without sneaking it out through the IV or Message-ID.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 27 Mar 1998 21:23:12 -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Conventional works, but pgpv needs armor
Sender: [email-masked]

I managed to get conventional SKESKs working, and pgpv 5.0 even understand
them, but I must ascii armor the file, or it says opening /dev/null and
does nothing.  I tried both s2k alone and s2k encrypted key.

Even when ascii armoring, when I use the s2k encrypted key, pgpv gives

Message is encrypted.
Enter pass phrase:
Opening file "cvtv.two" type binary.
Opening file "/dev/null" type text.

but otherwise works.

Is this just 5.0?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 27 Mar 1998 21:10:50 -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: Hashed signature material
Sender: [email-masked]

On Fri, 27 Mar 1998 [email-masked] wrote:

> How do I get 5.0 to generate one of these beasts?  pgps keeps generating a
> v3 signature.
> 
> I now can make and verify some v4 sigs (or v3), but not correctly (My
> check says my generationis correct).  pgpv when I point at one I generate
> simply says:
> 
> This signature applies to another message
> None of the signatures were understood; can't check
> 
> Received signal 11.

After a little probing, pgp 5.0 doesn't like this for data (e.g. detached
sigs), and will see the 4 but act like a 3.

Anyone have a pubkey and a V4 signed file?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 27 Mar 1998 20:16:01 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Hashed signature material
Sender: [email-masked]

On Sat, 14 Mar 1998, Hal Finney wrote:

> Werner is correct.  In the case of V4 signature packets, 6 more bytes
> are added at the end, for technical reasons to prevent some signature
> aliasing attacks.  The contents are:
> 
> 	byte 0 - Version of signature packet, in this case 4
> 	byte 1 - 0xff
> 	bytes 2-5 - Length of hashed data from sig packet (not including
> 		these last 6 bytes), bigendian
> 
> We added the hashing information to the draft at the final stages, and
> it was an oversight on my part in not getting this information to Jon
> correctly.

How do I get 5.0 to generate one of these beasts?  pgps keeps generating a
v3 signature.

I now can make and verify some v4 sigs (or v3), but not correctly (My
check says my generationis correct).  pgpv when I point at one I generate
simply says:

This signature applies to another message
None of the signatures were understood; can't check

Received signal 11.

--- reply to tzeruch - at - ceddec - dot - com ---

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 27 Mar 98 14:52:30 -0600
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: UserID Revocation
Sender: [email-masked]

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

In <[email-masked]>, on 03/27/98 
   at 09:56 AM, [email-masked] (Lutz Donnerhacke) said:

>* Christopher Creutzig wrote:
>>On 11 Mar 1998, Lutz Donnerhacke wrote:
>>
>>-> >think that there are some more pressing issues like the ability to revoke
>>-> >userID's if modifying the format is still open game.
>>-> 
>>-> No. It's already solved an implemented since about than a year.
>>
>> I haven't seen it in the spec yet. Your reference implementation does not
>>define anything, it *only* implements the spec and serves as something
>>people can check their programs for interoperability with. It had been
>>solved with the old key format, though...

>It is a feature of PGP2.6.3(i)n since months.

Yes but that does not replace the need for it to be outlined in the spec.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: The sad thing about Windows bashing is it's all true.

Date: Fri, 27 Mar 1998 12:04:06 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: 5.2.2 clarification
Sender: [email-masked]

At 02:15 PM 3/27/98 -0500, [email-masked] wrote:
   "The data being signed is hashed, and then the signature data from the
   version number through..." 
                 ^
             inclusive ?
   
Inclusive. I added the word. This is redundant with the new section on
constructing a signature. I've left it in on the grounds that more
information is better. If it's really confusing, let me know and I can
replace it with a reference to the new section.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 27 Mar 1998 14:15:39 -0500
From: [email-masked]
To: [email-masked]
Subject: 5.2.2 clarification
Sender: [email-masked]

"The data being signed is hashed, and then the signature data from the
version number through..." 
              ^
          inclusive ?

--- reply to tzeruch - at - ceddec - dot - com ---

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: UserID Revocation
Date: 27 Mar 1998 09:56:49 GMT
Organization: IKS GmbH Jena
Lines: 14
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Christopher Creutzig wrote:
>On 11 Mar 1998, Lutz Donnerhacke wrote:
>
>-> >think that there are some more pressing issues like the ability to revoke
>-> >userID's if modifying the format is still open game.
>-> 
>-> No. It's already solved an implemented since about than a year.
>
> I haven't seen it in the spec yet. Your reference implementation does not
>define anything, it *only* implements the spec and serves as something
>people can check their programs for interoperability with. It had been
>solved with the old key format, though...

It is a feature of PGP2.6.3(i)n since months.

Date: Fri, 27 Mar 1998 00:15:16 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3 - more notes
Sender: [email-masked]

On Thu, 26 Mar 1998, Hal Finney wrote:

> [email-masked] writes:
> > 1. There are actually two forms of the SKESK.  The first is when the key
> > is derived from the passphrase (old style) described by the paragraph "If
> > the encrypted session key is not present...".  If this type is present, it
> > should be the only SKESK present (and no PKESK).
> 
> Yes, this is true.

Technically you could have a single one of these and use the result to
create SKESK and PKESK blocks, but this is only for backwards
compatibility.

> > 2. The S2K structure also contains a byte describing a symmetric
> > algorithm.  For form in 1. above, it MUST be the same as what is used to
> > encrypt the message.  This should also match the second octet in the
> > SKESK body.
> 
> No, it doesn't.  The S2K object has a hash algorithm but no encryption
> algorithm specifier.  So there is no matching involved here.

OOPS, When I wrote the routine (long before the spec, and before the
source to PGP5.0 was finished scanning), I had the cipher type byte just
before the salt and hash type.  When I was figuring out the structure I
always assumed the cipher type was prepended.  And it is in this case, but
isn't part of the S2K.  But it keeps sticking in my mind as if it is. 
Apologies. 

> There are two "layers" of encryption being used in this case.  The
> message is encrypted with a (random) SK, using a conventional encryption
> algorithm.  Then the SK is concatenated with the algorithm ID, encrypted
> with the hashed passphrase and stored at the end of the SKESK block.
> That second layer of encryption can use a different encryption algorithm.
> 
> The algorithm for that second layer is in the SKESK block, 2nd octet.
> The algorithm for the message encryption is then revealed when the SK
> is decrypted.

OK, that makes sense.  It seemed that it might work this way (but I had
trouble with my stuck memory as I explained above).

> > 5. For form 2, the only check is the match between the 2nd octet of the
> > SKESK body and the first of the decrypted session key.  Multiple SKESKs
> > can produce multiple possible keys and each will have to be tried to see
> > if the 10 byte check will work (since there is no checksum).
> 
> There is no match check.  You have to try the passphrase against each
> SKESK, and then do a test decryption of the first 10 bytes of the message
> to see if it works.  You are right that a checksum would help here,
> although it causes me backwards compatibility problems if we change it.
> (If we do change it, we should add an IV for the SK encryption layer.)

Lots of things can cause backwards compatibility problems, but maybe not
this format extension.  If the cipher type is known (the first byte), the
length of the key material is also known, so if the packet ends at the
right point there is no checksum (and depending on how you wrote the code
the checksum should be discarded since only the first N bytes are plugged
into the key routine - this is how my code reacts - you can send it 1000
bytes of key material, but it will only use 16 for IDEA and CAST, and 24
for 3DES - it isn't passed the array size). 

If PGP 5.x ignores trailing bytes after the used key material, you could
add a checksum (or CRC - the one for the ascii armor is hanging around, or
something else).

So Opgp might be able to add a few check bytes to discard bad SKESKs,
while PGP 5.x would simply still try each one.

> > 6. Do I scan the PKESKs first, and if one works ignore the SKESKs, or do I
> > ask for a passphrase anytime I encounter a SKESK?  If there was a rule of
> > the form "PKESKs MUST come before SKESKs"  this would be easier. 
> 
> You have the same problem if there are multiple PKESKs and you have the
> private key for more than one of them.  We scan them all.

Maybe, but with all the checksumming and other verification going on, it
is 99.99% likely that the first successful PKESK will contain a correct
key.  And then you don't need to check the rest.

> > 7. Without padding or something similar just checksums aren't really that
> > good since N random bytes will tend to coalesce around 127.5*N.  With
> > padding, the first zero byte must occur N+3 bytes before the end, the
> > following byte must be the valid ciphertype, and the checksum much match. 
> 
> Yes, when we redo this from scratch it would probably be better to do
> something better than a simple checksum.

Which is what the PKESKs have (and I check for all this - that is what I
describe in #7, and reject anything failing), and what the SKESKs don't
have, so I must try each such key in the lock to see if it turns. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 23:53:57 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Nesting different signatures
Sender: [email-masked]

On Thu, 26 Mar 1998, Hal Finney wrote:

> [email-masked] writes:
> 
> We may want to add a note to the One-Pass Signed Message grammar in
> 10.2 to clarify that the end signature must be by the same key as the
> one-pass packet.  That will insure that they can be paired up properly.

That is what is needed.  It isn't clear that the real sig relates to the
prefix.

There are other parsing rules, but most are of the form
prefix(message)
so conventional signatures would be
sigp(message)
and nested sig packets would always parse as
sigp(sigp(sigp(message)))

The grammar is a bit confusing for the 1pass since it is like a C
do{}while(); construct, i.e.
1ps(message)sigp

so parsing such messages should be unambiguous.

The very inside must be a conventionally encrypted, compressed or literal
packet.  ESKs and Signatures act as structure starts (like while(){}), and
1 pass signatures like structure pre-and-posts (like do{}while()).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 17:21:41 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3 - more notes
Sender: [email-masked]

[email-masked] writes:
> 1. There are actually two forms of the SKESK.  The first is when the key
> is derived from the passphrase (old style) described by the paragraph "If
> the encrypted session key is not present...".  If this type is present, it
> should be the only SKESK present (and no PKESK).

Yes, this is true.

> 2. The S2K structure also contains a byte describing a symmetric
> algorithm.  For form in 1. above, it MUST be the same as what is used to
> encrypt the message.  This should also match the second octet in the
> SKESK body.

No, it doesn't.  The S2K object has a hash algorithm but no encryption
algorithm specifier.  So there is no matching involved here.

> 3. For the other form, you can have multiple PKE packets and multiple
> SKESK packets, apparently in any order.  You need at least one, but there
> is no strict upper limit.

That sounds correct.

> 4. For form 2, the S2K cipher type byte must be the algorithm used to
> decrypt the session key for the message.  When that is decrypted, the
> first octet must match the 2nd octet of the SKESK body and the algorithm
> used to encrypt the message.

There is no S2K cipher type byte.  See section 3.6.1.  So there is no
need to match here.

There are two "layers" of encryption being used in this case.  The
message is encrypted with a (random) SK, using a conventional encryption
algorithm.  Then the SK is concatenated with the algorithm ID, encrypted
with the hashed passphrase and stored at the end of the SKESK block.
That second layer of encryption can use a different encryption algorithm.

The algorithm for that second layer is in the SKESK block, 2nd octet.
The algorithm for the message encryption is then revealed when the SK
is decrypted.

> 5. For form 2, the only check is the match between the 2nd octet of the
> SKESK body and the first of the decrypted session key.  Multiple SKESKs
> can produce multiple possible keys and each will have to be tried to see
> if the 10 byte check will work (since there is no checksum).

There is no match check.  You have to try the passphrase against each
SKESK, and then do a test decryption of the first 10 bytes of the message
to see if it works.  You are right that a checksum would help here,
although it causes me backwards compatibility problems if we change it.
(If we do change it, we should add an IV for the SK encryption layer.)

> 6. Do I scan the PKESKs first, and if one works ignore the SKESKs, or do I
> ask for a passphrase anytime I encounter a SKESK?  If there was a rule of
> the form "PKESKs MUST come before SKESKs"  this would be easier. 

You have the same problem if there are multiple PKESKs and you have the
private key for more than one of them.  We scan them all.

> 7. Without padding or something similar just checksums aren't really that
> good since N random bytes will tend to coalesce around 127.5*N.  With
> padding, the first zero byte must occur N+3 bytes before the end, the
> following byte must be the valid ciphertype, and the checksum much match. 

Yes, when we redo this from scratch it would probably be better to do
something better than a simple checksum.

Hal

Date: Thu, 26 Mar 1998 18:29:59 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Conventional Encryption Keys, 5.3 - more notes
Sender: [email-masked]

1. There are actually two forms of the SKESK.  The first is when the key
is derived from the passphrase (old style) described by the paragraph "If
the encrypted session key is not present...".  If this type is present, it
should be the only SKESK present (and no PKESK).

2. The S2K structure also contains a byte describing a symmetric
algorithm.  For form in 1. above, it MUST be the same as what is used to
encrypt the message.  This should also match the second octet in the
SKESK body.

3. For the other form, you can have multiple PKE packets and multiple
SKESK packets, apparently in any order.  You need at least one, but there
is no strict upper limit.

4. For form 2, the S2K cipher type byte must be the algorithm used to
decrypt the session key for the message.  When that is decrypted, the
first octet must match the 2nd octet of the SKESK body and the algorithm
used to encrypt the message.

5. For form 2, the only check is the match between the 2nd octet of the
SKESK body and the first of the decrypted session key.  Multiple SKESKs
can produce multiple possible keys and each will have to be tried to see
if the 10 byte check will work (since there is no checksum).

6. Do I scan the PKESKs first, and if one works ignore the SKESKs, or do I
ask for a passphrase anytime I encounter a SKESK?  If there was a rule of
the form "PKESKs MUST come before SKESKs"  this would be easier. 

7. Without padding or something similar just checksums aren't really that
good since N random bytes will tend to coalesce around 127.5*N.  With
padding, the first zero byte must occur N+3 bytes before the end, the
following byte must be the valid ciphertype, and the checksum much match. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 15:09:02 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Nesting different signatures
Sender: [email-masked]

[email-masked] writes:
> On Thu, 26 Mar 1998, Hal Finney wrote:
> > This is not a legal OP message, according to the grammar in section 10.2.
> > Signatures can only go at the end if there is a 1psig packet at the
> > beginning, and there cannot be two OP messages between the 1psig and sig,
> > only one.
>
> But it also says
>
> OPSM := OPSK, opM, SP
>
> Abbreviations for: One Pass Signature Message pacKet. oPENpGP
>
> The implication is that the SP is over the opM.  When nesting this would
> not be true, the signature can be over something inside the opM.

Actually, it is more complicated than this, and we need to clarify how
this works in the spec.  What it says now, in section 5.2.4, is:

   The signature data is simple to compute for document signatures (types
   0x00 and 0x01), for which the document itself is the data.  For
   standalone signatures, this is a null string.

While this is true, "the document itself" is not clearly defined in the
context of the OP grammar.

What actually happens is that the signed portion consists of an OP
message, as described in section 10.2.  The data which is actually hashed
depends on the nature of the signed OP message.

There are two steps: first identifying what OP message is signed, and
then determining what part of that OP message is hashed.

In a One-Pass Signed Message, if the nested flag is set in the One-Pass
Signature Packet, then the OP message which is sandwiched between the
one-pass packet and the signature packet is what is signed.  If the
nested flag is not set, the sandwiched OP message MUST be another
One-Pass Signed Message.  In that case the signed data of the outer
OPSM is the same as the signed data of the inner OPSM.

[We could change the grammar in 10.2 to distinguish between the two
kinds of OPSM packets, nested and non-nested, in order to clarify what
is legal here.]

In a regular Signed Message, the signed data is the OP message which
follows the signature packet.

Once we have identified the signed OP message, the hashing rules are
as follows.  If the signed portion is anything but a Literal Message,
then the entire signed OP message is hashed, including packet headers.
However, if the signed portion is a Literal Message, only the "literal
data" portion of the literal packet body is hashed.  The literal packet
headers are not hashed, nor are the formatting octet, filename, and
creation time fields within the literal packet body.

The part about one-pass packets is new to PGP 5.X, but the special
behavior with respect to hashing literal messages goes back to PGP 2.X.

> I didn't understand the correct sense of the "nest" flag until now.

Actually, I had it backwards in my earlier message.  If the nest flag
is set in the one-pass packet, that means the signed portion starts with
the very next packet.  If the flag is not set, the next packet must be
another one-pass packet, and the outer signature's signed portion is
the same as that of the inner signature.

> Setting the nest byte means that you *DON'T* want the signature to be on
> the whole following message which I would describe as NOT nesting.

No, setting the nest byte means you DO want the signature to be on the
whole following message.  I agree though that the terminology is a bit
confusing.

> Another point which I see here, but couldn't find stated clearly is that
> things should (must?) be positionally nested, i.e. 1psigs in order of
> ABCDE would have sigs at the end in EDCBA order. 

This is implied by the grammar in 10.2.  Each one-pass packet is paired
with a signature packet.  Constructing more elaborate messages using
this rule will cause ABCDE one-pass packets to automatically have EDCBA
sig packets at the end.

> My interest here is to prevent a complex interpretation of what is part or
> not part of what is being signed.  There should be no combinations of nest
> and nonest that are ambiguous.  And I can see there can be if the end sigs
> were not in reverse order of the 1pass sigs.
>
> Assuming reverse order, any adjacent pair must be one of the following:
>
> BeginSig(A);BeginSig(B);{data};EndSig(B);EndSig(A);
>
> or
>
> BeginSig(A);{BeginSig(B);{data};EndSig(B);};EndSig(A);
>
> Something like BS(A){BS(B);{data};ES(A) [or ES[X]!] is a nightmare.

We may want to add a note to the One-Pass Signed Message grammar in
10.2 to clarify that the end signature must be by the same key as the
one-pass packet.  That will insure that they can be paired up properly.

> Another fun, but maybe legal is mixing normal and 1 pass signatures.
>
> 1PS(A);S(B);literal;S(A) - syntactically legal if I understand.
> 1PS(A,SHA);S(A,MD5);literal;S(A,SHA) - also legal but more fun,
> or even:
> 1PS(A,SHA);(S(A,SHA on literal);literal);S(A,SHA on first S and literal)
> 	Signed Message = OP message, Signed
> 	Signed message is a valid OP Message.
> 	OPSM = 1PSP, OP Message, SP;
>
> Someone should say NO to these types of things.

As long as the grammar is unambiguous there should not be problems.
I think all the cases you have given here are legal and handled by
PGP 5.X.

Hal

Date: Thu, 26 Mar 1998 17:47:21 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3
Sender: [email-masked]

On Thu, 26 Mar 1998, Hal Finney wrote:

> I may not have been clear.  The symmetric-key ESK packet does not have
> a 10 byte prefix for the encrypted SK.  It is the next packet, the
> symmetrically encrypted data packet (section 5.7), which has the prefix.
> That prefix allows you to know if the passphrase is good, so there is no
> need for a checksum in the ESK packets.
> 
> It is true that the public key ESK packet has a checksum anyway, but it
> is not strictly necessary since the SK gets checked in the very next step
> when we decrypt the message proper.

But you can have *multiple* SKESK entries, one for each of several
passphrases, much like you can have multiple PKE packets.  So do you
rewind and check each one, or do you store the values in an array since
you don't know which of the several is the correct one until you try them
on the actual encrypted message.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 13:53:47 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3
Sender: [email-masked]

[email-masked] wrote:

> On Thu, 26 Mar 1998, Hal Finney wrote:
> > The purpose of a checksum is to tell you whether you've entered the
> > right passphrase.  That's not necessary here because after decrypting the
> > session key (SK) it will immediately use that SK to decrypt the message,
> > and there is a check which is done in the first 10 bytes of the message
> > to see if the SK is correct.
>
> It also says CFB mode with an IV of all zeros.  I didn't know the 10 byte
> with cfb reset (if the algorithm has a block size of 8 or less) was
> supposed to be there (see next).

I may not have been clear.  The symmetric-key ESK packet does not have
a 10 byte prefix for the encrypted SK.  It is the next packet, the
symmetrically encrypted data packet (section 5.7), which has the prefix.
That prefix allows you to know if the passphrase is good, so there is no
need for a checksum in the ESK packets.

It is true that the public key ESK packet has a checksum anyway, but it
is not strictly necessary since the SK gets checked in the very next step
when we decrypt the message proper.

> > It is true that the public key ESK packets do have this checksum, so you
> > are correct that it would be more consistent to have them for the symmetric
> > ESK as well, but functionally they are not needed.
>
> The ESK packets DO NOT have the 10 byte prefix but "is done in CFB
> mode..."  And there are resets between the secret values in RSA keys. 

ESK packets do not have the 10 byte prefix, that is correct.  Neither
does the symmetric ESK, as I hope I have made clear above.  The 10 byte
prefix is only used in the symmetrically encrypted data packet (tag 9).

I'm not sure what the relevance is of the resets between secret values
in RSA keys.  That only occurs within secret key packets, while we have
been discussing encrypted messages.

> Wouldn't it be better to use both the key and iv from the S2K and add the
> checksum instead of creating yet another mode?

S2K objects do not have IVs.  They know how to convert passphrases into
keys, that's it.  We do get the key from the S2K object and the passphrase,
but there is no IV there.

> Has anyone else implemented this yet?  (PGP5.0ib8 doesn't).

PGP 5.0 does not create such packets, but it does read and handle them.
PGP 5.5 creates conventionally encrypted messages using these packet
formats.

Hal

Date: Thu, 26 Mar 1998 17:15:47 -0500
From: [email-masked]
To: [email-masked]
Subject: Which is the preferred preference?
Sender: [email-masked]

I think a "Preferred algorithms should only appear in a self-signed X" 
would be good, and simply regenerating the signature would allow an update
since the times could be compared.  From what I read of the spec, it
should be in the self-signature containing the UserID.

In general, there should be something saying which subpacket types are
allowed to appear in which signature types.  Lots of things are web of
trust management, and maybe the next specification should be proper WoT
handling in full detail.  Reserving the values for such purposes is
probably good.  Defining every subpacket type and implying that all are
allowed on timestamps isn't. 

In fact a Subpacket Type / Signature Type table with Not/may/Should/Must
for each intersection would help greatly.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 13:48:19 -0800
To: Hal Finney <[email-masked]>, [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Conventional Encryption Keys, 5.3
Sender: [email-masked]

At 12:27 PM 3/26/98 -0800, Hal Finney wrote:

   [BTW, Jon, I notice that the wording in section 5.3 still uses the old
   term Conventional Encrypted Session Key in a few places.]
   
Thank you.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 26 Mar 1998 16:08:56 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3
Sender: [email-masked]

On Thu, 26 Mar 1998, Hal Finney wrote:

> > In the section beginning:
> >
> > "The decryption result consists of a one-octet algorithm..."
> >
> > Shouldn't there also be a two-octet checksum after the random key material
> > (to be identical to what is public-key encrypted)? 
> 
> The purpose of a checksum is to tell you whether you've entered the
> right passphrase.  That's not necessary here because after decrypting the
> session key (SK) it will immediately use that SK to decrypt the message,
> and there is a check which is done in the first 10 bytes of the message
> to see if the SK is correct.

It also says CFB mode with an IV of all zeros.  I didn't know the 10 byte
with cfb reset (if the algorithm has a block size of 8 or less) was
supposed to be there (see next).

> It is true that the public key ESK packets do have this checksum, so you
> are correct that it would be more consistent to have them for the symmetric
> ESK as well, but functionally they are not needed.

The ESK packets DO NOT have the 10 byte prefix but "is done in CFB
mode..."  And there are resets between the secret values in RSA keys. 

Wouldn't it be better to use both the key and iv from the S2K and add the
checksum instead of creating yet another mode?

Has anyone else implemented this yet?  (PGP5.0ib8 doesn't).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 15:53:36 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Nesting different signatures
Sender: [email-masked]

On Thu, 26 Mar 1998, Hal Finney wrote:

> [email-masked] writes:
> 
> This is not a legal OP message, according to the grammar in section 10.2.
> Signatures can only go at the end if there is a 1psig packet at the
> beginning, and there cannot be two OP messages between the 1psig and sig,
> only one.

But it also says

OPSM := OPSK, opM, SP

Abbreviations for: One Pass Signature Message pacKet. oPENpGP

The implication is that the SP is over the opM.  When nesting this would
not be true, the signature can be over something inside the opM.

> Generalizing this to the one pass signatures, we allow any legal PGP
> message to be signed by putting a 1pass packet in front of it and a
> signature packet behind it.
> 
> However at the same time the "nested" flag was introduced in the 1pass
> packet.  This is intended to allow multiple signatures to be on the
> same data.  You could not do that with the old PGP 2.X format, as each
> signature packet applied to the entire following message.
> 
> If you have a case like:
> 
>   1psig(k1,nest),1psig(k2,nonest),literal,sig(k2),sig(k1)
> 
> then both the signatures by k1 and k2 are on the literal data, or more
> generally, on whatever OP message lies between the last 1psig and the
> matching sig packet.  With the opposite setting for the nest flag:
> 
>   1psig(k1,nonest),1psig(k2,nonest),literal,sig(k2),sig(k1)
> 
> then the signature by k1 is on the three-packet signed message by k2.
> (Note that I reversed the order of the sig packets from your example,
> so that they are paired appropriately.)

I didn't understand the correct sense of the "nest" flag until now.

Setting the nest byte means that you *DON'T* want the signature to be on
the whole following message which I would describe as NOT nesting.

Another point which I see here, but couldn't find stated clearly is that
things should (must?) be positionally nested, i.e. 1psigs in order of
ABCDE would have sigs at the end in EDCBA order. 

My interest here is to prevent a complex interpretation of what is part or
not part of what is being signed.  There should be no combinations of nest
and nonest that are ambiguous.  And I can see there can be if the end sigs
were not in reverse order of the 1pass sigs.

Assuming reverse order, any adjacent pair must be one of the following:

BeginSig(A);BeginSig(B);{data};EndSig(B);EndSig(A);

or

BeginSig(A);{BeginSig(B);{data};EndSig(B);};EndSig(A);

Something like BS(A){BS(B);{data};ES(A) [or ES[X]!] is a nightmare.

Another fun, but maybe legal is mixing normal and 1 pass signatures.

1PS(A);S(B);literal;S(A) - syntactically legal if I understand.
1PS(A,SHA);S(A,MD5);literal;S(A,SHA) - also legal but more fun,
or even:
1PS(A,SHA);(S(A,SHA on literal);literal);S(A,SHA on first S and literal)
	Signed Message = OP message, Signed
	Signed message is a valid OP Message.
	OPSM = 1PSP, OP Message, SP;

Someone should say NO to these types of things.

> I believe you are suggesting eliminating the nest flag and assuming that
> we always use the first interpretation, where multiple 1psig packets
> all apply to the same signed data.  Then, when we want to express the
> second, we would do:
> 
>   1psig(k1), literal( 1psig(k2),literal,sig(k2) ), sig(k1)
> 
> wrapping the signed message by k2 in a literal packet.

Yes,

> The main problem I see is that the unwrapping process described above
> would not work smoothly.  We would either stop when we see the literal
> packet, and not report the k2 signature, or else we would have to have
> a policy of always peeking inside literal packets and seeing if the data
> looks like PGP data, and perhaps proceeding to decode it.  The literal
> packets then lose their useful function as a known stopping point.

Or the nesting flag belongs in the literal packet (you already define text
and binary and have 254 other values to choose from, maybe 'p').

> Derek Atkins was the designer of the one-pass signature packets, back
> before PGP, Inc. existed.  He told me that he was not completely satisfied
> with the design, that he thought the grammar still had some ambiguities,
> and that a three state nesting flag was necessary to cover all possible
> cases.  I have never gone back and looked into this area thoroughly.

Before finishing the official Open PGP spec, this should be done.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 12:27:27 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Conventional Encryption Keys, 5.3
Sender: [email-masked]

> I can create a conventional encryption key using S2K by itself on a
> passphrase, but I can also encrypt a conventional key using a S2K on a
> passphrase.

Yes, the second mode allows a message to be encrypted with a session
key, with multiple ESK packets preceding it which provide that session
key in different ways.  The session key can be public-key encrypted
to various keys, and/or the session key can be secret-key encrypted to
various passphrases.

If it is simply a conventionally encrypted message, this level of
indirection is not required and you can use the S2K hash of the passphrase
as the session key directly, which is the first mode.

> In the section beginning:
>
> "The decryption result consists of a one-octet algorithm..."
>
> Shouldn't there also be a two-octet checksum after the random key material
> (to be identical to what is public-key encrypted)? 

The purpose of a checksum is to tell you whether you've entered the
right passphrase.  That's not necessary here because after decrypting the
session key (SK) it will immediately use that SK to decrypt the message,
and there is a check which is done in the first 10 bytes of the message
to see if the SK is correct.

It is true that the public key ESK packets do have this checksum, so you
are correct that it would be more consistent to have them for the symmetric
ESK as well, but functionally they are not needed.

[BTW, Jon, I notice that the wording in section 5.3 still uses the old
term Conventional Encrypted Session Key in a few places.]

Hal

Date: Thu, 26 Mar 1998 15:15:21 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: More spec-ulations
Sender: [email-masked]

On Thu, 26 Mar 1998, Jon Callas wrote:

> At 11:41 PM 3/25/98 -0500, [email-masked] wrote:
>    1. If we are going to have a lame cipher for conventional encryption, why
>    not also have one for the PK algorithms, e.g. DH, RSA, and the
>    conventional key material plaintext as an MPI integer (for exportable
>    samples).  Would we need this for hashes and/or signatures too?  Any weak
>    (ROT-N like) alternatives?
> 
> Or we just remove the lame algorithms? There are places where it makes
> sense to have unencrypted secret keys, and these were the only places
> algorithm 0 has actually been used. I'm planning on noting such in the spec
> and striking the lame algorithms.

Yes and no.  The string to key has to use conventional encryption
algorithms, and no current implementation I know of really sets this,
rather it is left to default to IDEA/SHA1 (I use unpublished globals
preset to these).  This also creates interesting problems moving secrings
between implementations.

Maybe some additional text somewhere:

Conventional Algorithm Byte:  For secret keys 0 means unencrypted.  It is
invalid in any other usage.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 12:10:39 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: More spec-ulations - update
Sender: [email-masked]

[email-masked] writes:
> > 3. Are multiple signatures allowed similar to multiple recipient keys?
> > (The spec is at work and I am not right now)  E.g. 1psig(k1) 1psig(k2)...
> > signed text ... sig(k1) sig(k2) ... And would the order be important?
>
> I read about the nested signature bits.  Which presents a problem.
>
> if I have
> 1psig(k1,nest),1psig(k2,nonest),literal,sig(k1),sig(k2)
> And I want to alter the text, I can get:
> 1psig(k1,nonest),1psig(k2,nonest),literal,sig(k1),sig(k2)
> where I alter the second 1psig until my altered literal has the same hash
> value.

To do this you would need to create two different byte sequences which
both hash to the same value.  This is assumed to be impossible with the
cryptographically strong hash functions which we use.  We do not attempt
to defend against attacks which require breaking the hash function.

> But to isolate the problem: I didn't see any clear definition of what a
> data signature packet is supposed to be hashing.  I would think "only the
> immediately preceeding compressed, literal, or encrypted data packet" with
> a note that multiple signature packets must be concatenated.
>
> For example, a message of the form: (literal)(literal)(signature) - what
> would the hash for the signature be over?  Both literal packets or just
> the final one?

This is not a legal OP message, according to the grammar in section 10.2.
Signatures can only go at the end if there is a 1psig packet at the
beginning, and there cannot be two OP messages between the 1psig and sig,
only one.

> I would also prefer ignoring the nest/nonest octet; any signature packet
> to be signed can be encapsulated in a literal packet.  The 1-pass sig
> packets would then fire up the hash algorithms (optionally only if the
> corresponding keyids were available) as a convienience for any signature
> packet that would happen to occur after the literal.

The historical evolution of signatures has resulted in a rather complicated
set of conventions.  We could consider simplifying them, but it would
impair compatibility with the installed PGP 2.X base.

PGP 2.X normally signs files by wrapping them in a literal packet, and then
putting a signature packet in front.  However, it was also allowed for
any legal PGP messge to be signed by putting a signature packet in front
of it.

With PGP 2.X, you could sign a (binary) PGP encrypted file, and it would
say, "this looks like a PGP file, should I assume that it is?"  If you
said yes, it would not wrap the file in a literal packet but would just
stick the signature packet in front.  You could sign an encrypted file
in this way.  (Signing an encrypted file is a somewhat questionable
thing to do, but in some circumstances it may be appropriate.)

The main advantage of this is that it allows easy "unwrapping" of a
message which may be multiply signed and encrypted.  The unwrapping
stops when it comes to a literal packet.  PGP 2.X, if decrypting the
file above, would first say that it had found a signature, then that
it had found encrypted data, then it would proceed to describe what
it found within the encrypted portion.

Generalizing this to the one pass signatures, we allow any legal PGP
message to be signed by putting a 1pass packet in front of it and a
signature packet behind it.

However at the same time the "nested" flag was introduced in the 1pass
packet.  This is intended to allow multiple signatures to be on the
same data.  You could not do that with the old PGP 2.X format, as each
signature packet applied to the entire following message.

If you have a case like:

  1psig(k1,nest),1psig(k2,nonest),literal,sig(k2),sig(k1)

then both the signatures by k1 and k2 are on the literal data, or more
generally, on whatever OP message lies between the last 1psig and the
matching sig packet.  With the opposite setting for the nest flag:

  1psig(k1,nonest),1psig(k2,nonest),literal,sig(k2),sig(k1)

then the signature by k1 is on the three-packet signed message by k2.
(Note that I reversed the order of the sig packets from your example,
so that they are paired appropriately.)

I believe you are suggesting eliminating the nest flag and assuming that
we always use the first interpretation, where multiple 1psig packets
all apply to the same signed data.  Then, when we want to express the
second, we would do:

  1psig(k1), literal( 1psig(k2),literal,sig(k2) ), sig(k1)

wrapping the signed message by k2 in a literal packet.

The main problem I see is that the unwrapping process described above
would not work smoothly.  We would either stop when we see the literal
packet, and not report the k2 signature, or else we would have to have
a policy of always peeking inside literal packets and seeing if the data
looks like PGP data, and perhaps proceeding to decode it.  The literal
packets then lose their useful function as a known stopping point.

Derek Atkins was the designer of the one-pass signature packets, back
before PGP, Inc. existed.  He told me that he was not completely satisfied
with the design, that he thought the grammar still had some ambiguities,
and that a three state nesting flag was necessary to cover all possible
cases.  I have never gone back and looked into this area thoroughly.
PGP 5.X will parse and verify these various signature forms, but does not
create them.

Hal

Date: Thu, 26 Mar 1998 14:59:44 -0500
From: [email-masked]
To: [email-masked]
Subject: Conventional Encryption Keys, 5.3
Sender: [email-masked]

I can create a conventional encryption key using S2K by itself on a
passphrase, but I can also encrypt a conventional key using a S2K on a
passphrase.

In the section beginning:

"The decryption result consists of a one-octet algorithm..."

Shouldn't there also be a two-octet checksum after the random key material
(to be identical to what is public-key encrypted)? 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 11:27:12 -0800
To: Thomas Roessler <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

At 07:26 AM 3/26/98 +0100, Thomas Roessler wrote:

   I completely agree.  But those parts of the spec which are
   already trying to shut down such channels should be
   written in a more thorough fashion.  I'd be quite happy
   with _random_ Message IDs - if an implementation has a bad
   random generator, you are in trouble anyways.
   
If you're dissatisfied with the wording, feel free to reword them.

In this particular case, I think there's merit in *suggesting* but not
mandating that the message id be a function of the message. There's nothing
wrong in suggesting that a hash be used, but there are plenty of other
suitable ways to do it, including just taking a slice of funtional slice
cyphertext, which is mathematically "random" and cannot leak any
information. Cyphertext is always sent in the clear, as it were.

I also think there's merit in not mandating how it's done, as long as it's
deterministic. However, I'm willing to listen to anyone who wants to argue
that that MUST on determinism be a SHOULD.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 26 Mar 1998 11:14:26 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: More spec-ulations
Sender: [email-masked]

At 11:41 PM 3/25/98 -0500, [email-masked] wrote:
   1. If we are going to have a lame cipher for conventional encryption, why
   not also have one for the PK algorithms, e.g. DH, RSA, and the
   conventional key material plaintext as an MPI integer (for exportable
   samples).  Would we need this for hashes and/or signatures too?  Any weak
   (ROT-N like) alternatives?

Or we just remove the lame algorithms? There are places where it makes
sense to have unencrypted secret keys, and these were the only places
algorithm 0 has actually been used. I'm planning on noting such in the spec
and striking the lame algorithms.

	Jon

   

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 26 Mar 1998 14:11:42 -0500
From: [email-masked]
To: [email-masked]
Subject: More spec-ulations - update
Sender: [email-masked]

> 3. Are multiple signatures allowed similar to multiple recipient keys?
> (The spec is at work and I am not right now)  E.g. 1psig(k1) 1psig(k2)...
> signed text ... sig(k1) sig(k2) ... And would the order be important?

I read about the nested signature bits.  Which presents a problem.

if I have
1psig(k1,nest),1psig(k2,nonest),literal,sig(k1),sig(k2)
And I want to alter the text, I can get:
1psig(k1,nonest),1psig(k2,nonest),literal,sig(k1),sig(k2)
where I alter the second 1psig until my altered literal has the same hash
value.

But to isolate the problem: I didn't see any clear definition of what a
data signature packet is supposed to be hashing.  I would think "only the
immediately preceeding compressed, literal, or encrypted data packet" with
a note that multiple signature packets must be concatenated.

For example, a message of the form: (literal)(literal)(signature) - what
would the hash for the signature be over?  Both literal packets or just
the final one?

I would also prefer ignoring the nest/nonest octet; any signature packet
to be signed can be encapsulated in a literal packet.  The 1-pass sig
packets would then fire up the hash algorithms (optionally only if the
corresponding keyids were available) as a convienience for any signature
packet that would happen to occur after the literal.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 11:46:35 -0500
From: [email-masked]
To: [email-masked]
Subject: Multiple ASCII hash key?
Sender: [email-masked]

Section 7 says I can specify multiple hashes for clearsigned text,
i.e.

text to be signed

-----BEGIN PGP SIGNATURE-----

ascii armored signature(s)
-----END...

If I specify multiple hashes, I assume I specify multiple signature
packets, each being a signature using one of the hashes specified in the
"Hash: ..." term?

The text reads "If more than one message digest is used in the signature,"
and signature is singular not plural.

And can I have multiple signers (like a petition)?  What if they use
different hashes?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 26 Mar 1998 07:26:52 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: MessageID wording paranoia
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 25, 1998 at 07:26:16PM -0800, William Lewis wrote:

> I may be missing something here, but it seems to me that
> attempting to write this specification to completely
> disallow subliminal/covert channels is a fool's errand.
> It's already necessary that the PGP implementation be
> trusted. Adding requirements such as this one (specifying
> that the MessageID be externally verifiable) makes the
> spec more complicated and more difficult to implement, but
> doesn't actually increase security at all.

I completely agree.  But those parts of the spec which are
already trying to shut down such channels should be
written in a more thorough fashion.  I'd be quite happy
with _random_ Message IDs - if an implementation has a bad
random generator, you are in trouble anyways.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Wed, 25 Mar 1998 23:41:43 -0500
From: [email-masked]
To: [email-masked]
Subject: More spec-ulations
Sender: [email-masked]

1. If we are going to have a lame cipher for conventional encryption, why
not also have one for the PK algorithms, e.g. DH, RSA, and the
conventional key material plaintext as an MPI integer (for exportable
samples).  Would we need this for hashes and/or signatures too?  Any weak
(ROT-N like) alternatives?

2. There should be a table of key material lengths indexed by the
conventional algorithm number, e.g.  IDEA/3DES/CAST is 16/24/16.  I assume
the PKCSwhatever padding is specified too.  I have plaintext as zero (will
this break the PK algorithm to send a length of zero?), Blowfish as 16,
ROT-N as 8 (maybe should be 1?), and Safer/SK128 as 16.

3. Are multiple signatures allowed similar to multiple recipient keys?
(The spec is at work and I am not right now)  E.g. 1psig(k1) 1psig(k2)...
signed text ... sig(k1) sig(k2) ... And would the order be important?

This would be hard to implement, but it sounds like this would be legal.

--- reply to tzeruch - at - ceddec - dot - com ---

From: William Lewis <[email-masked]>
Date: Wed, 25 Mar 98 19:26:16 -0800
To: "William H. Geiger III" <[email-masked]>
Subject: Re: MessageID wording paranoia
Cc: Jon Callas <[email-masked]>, Thomas Roessler <[email-masked]>, [email-masked]
Sender: [email-masked]

William H. Geiger III <[email-masked]> writes:
> I had not thought of leaking key data this way. If the group feels this is
> a real concern couldn't the same type of "leaking" be done with the
> "boundary" in the MIME headers?

Or with the session key or IV, or the padding of the key to the RSA modulus  
size, or the 'k' parameter of a DSS signature, or probably any number of  
subtler ways. Fields which by their nature must *not* be generated in an  
externally predictable way.

I may be missing something here, but it seems to me that attempting to write  
this specification to completely disallow subliminal/covert channels is a  
fool's errand. It's already necessary that the PGP implementation be trusted.  
Adding requirements such as this one (specifying that the MessageID be  
externally verifiable) makes the spec more complicated and more difficult to  
implement, but doesn't actually increase security at all.

Wim Lewis / [email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 25 Mar 98 20:06:04 -0600
To: Jon Callas <[email-masked]>
Cc: Jon Callas <[email-masked]>, Thomas Roessler <[email-masked]>, [email-masked]
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

This is a MIME encapsulated message

--==_00594_===
Content-Type: text/plain

In <[email-masked]>, on 03/25/98 
   at 05:26 PM, Jon Callas <[email-masked]> said:

>It could, but there comes a point where we have to admit that some things
>are beyond our control.

>I don't see that this is an issue for OpenPGP-FORMATS, regardless. Even
>there, though, I don't know what we'd say, and I don't think it's so
>serious a problem that the spec should be held up for finding a
>solution.

This isn't somthing I was looking for the group to address just an
observation for contemplation. :)

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: This is a TAG-O-Matic
             Multi-line Sample
             Tag 

--==_00594_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00594_===--

Date: Wed, 25 Mar 1998 17:26:35 -0800
To: "William H. Geiger III" <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: MessageID wording paranoia
Cc: Thomas Roessler <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:18 PM 3/25/98 -0600, William H. Geiger III wrote:
   
   I had not thought of leaking key data this way. If the group feels this is
   a real concern couldn't the same type of "leaking" be done with the
   "boundary" in the MIME headers?
   
It could, but there comes a point where we have to admit that some things
are beyond our control.

I don't see that this is an issue for OpenPGP-FORMATS, regardless. Even
there, though, I don't know what we'd say, and I don't think it's so
serious a problem that the spec should be held up for finding a solution.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 25 Mar 98 19:18:04 -0600
To: Jon Callas <[email-masked]>
Cc: Thomas Roessler <[email-masked]>, [email-masked]
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

This is a MIME encapsulated message

--==_005B5_===
Content-Type: text/plain

In <[email-masked]>, on 03/25/98 
   at 04:58 PM, Jon Callas <[email-masked]> said:

>An excellent point -- there needs to be clarification there. I've added
>text that says, "...it MUST be computed from the finished (encrypted,
>signed, etc.) message in a deterministic fashion..."

>How's that?

I had not thought of leaking key data this way. If the group feels this is
a real concern couldn't the same type of "leaking" be done with the
"boundary" in the MIME headers?

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: You said Windows was a Power Tool???

--==_005B5_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_005B5_===--

Date: Wed, 25 Mar 1998 13:58:01 -0800
To: Thomas Roessler <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

At 03:45 PM 3/25/98 +0100, Thomas Roessler wrote:

   As a solution, I'd suggest to mandate the use of a certain
   hash (sha1?) of the armored text, i.e., the _encrypted_
   message. (Most probably it's meant that way, but let's
   make the text unambiguous.)
   
An excellent point -- there needs to be clarification there. I've added
text that says, "...it MUST be computed from the finished (encrypted,
signed, etc.) message in a deterministic fashion..."

How's that?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 25 Mar 1998 10:43:33 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: MessageID wording paranoia
Sender: [email-masked]

Thomas Roessler, <[email-masked]>, writes:
> The current draft states the following on the generation
> of Message-IDs:
>
> >    The MessageID should not appear unless it is in a
> >    multi-part message. If it appears at all, it MUST be
> >    computed from the message in a deterministic fashion,
> >    rather than contain a purely random value.  This is to
> >    allow anyone to determine that the MessageID cannot serve
> >    as a covert means of leaking cryptographic key
> >    information.
>
> I consider this to be a dangerous approach, since it may
> let _plaintext_ information leak to the public: Consider
> some (broken) implementation using an SHA1 hash of the
> message - to "prove" that some suspected plaintext is
> actually the one you have, you only need to have a look at
> the Message ID.

What it is trying to say is that any third party should be able to verify
the MessageID as a function of the message, so that nothing can be leaked.
This means that it can only be based on a deterministic function of the
armored data (or, equivalently, of the binary data which is armored).
Perhaps the wording could be clarified.

Hal

Date: Wed, 25 Mar 1998 15:45:03 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: MessageID wording paranoia
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The current draft states the following on the generation
of Message-IDs:

>    - "MessageID", a 32-character string of printable
>    characters.  The string must be the same for all parts of
>    a multi-part message that uses the "PART X" Armor Header.
>    MessageID strings should be unique enough that the
>    recipient of the mail can associate all the parts of a
>    message with each other.  A good checksum or cryptographic
>    hash function is sufficent.

>    The MessageID should not appear unless it is in a
>    multi-part message. If it appears at all, it MUST be
>    computed from the message in a deterministic fashion,
>    rather than contain a purely random value.  This is to
>    allow anyone to determine that the MessageID cannot serve
>    as a covert means of leaking cryptographic key
>    information.

I consider this to be a dangerous approach, since it may
let _plaintext_ information leak to the public: Consider
some (broken) implementation using an SHA1 hash of the
message - to "prove" that some suspected plaintext is
actually the one you have, you only need to have a look at
the Message ID.

Even worse, an implementation which uses some part of the
plain text, encrypted with a symmetric algorithm, could
use this stuff to leak known plaintext while still being
compliant to the standard, while an implementation using
random values would _not_ comply.

As a solution, I'd suggest to mandate the use of a certain
hash (sha1?) of the armored text, i.e., the _encrypted_
message. (Most probably it's meant that way, but let's
make the text unambiguous.)

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Tue, 24 Mar 1998 16:36:56 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

On Thu, 19 Mar 1998, Anonymous wrote:

> I think the answer must depend on why we want symmetric algorithm 0.
> At some level it might be a security risk to have it there: if an
> attacker can get the naive user's configuration file to specify that
> algorithm as the default encryption algorithm and the CFB/IV system
> were used as tzeruch and Section 5.7 suggest, there would be no easy
> way for the user casually looking at an encrypted file to know that
> it was unprotected.  This would also be true if an Algorithm 0 packet
> were left clear (i.e. without random IV and CFB) but compressed.
> 
> Is Algorithm 0 specified for debugging?  If so, do we need to say it
> MUST NOT be enabled outside of debugging environments?

I ended up implementing it without the CFB (though with the 10 byte reset
IV), so I could use less or od -a to see the not-really-encrypted text.

> The same question still holds for Algorithm 5, ROT-N: should we
> make that "MUST NOT be enabled outside of debugging environments"?

I did this without CFB, So every space maps to the same character, etc. 
So the structure of what you encrypt is visible.  I also added a cfb
ROT-8-n variant which does mess things up a bit more. 

Beyond debugging, it creates a diagnostic mode, but you are right that
these should be disabled in such a way that it is very hard for a user to
enable them.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 24 Mar 1998 10:15:49 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

On Mon, 23 Mar 1998, Jon Callas wrote:

> The question came up in the last stream of what happens if 3DES gets
> broken. The answer is that we're in trouble. Any protocol that has a single
> MUST algorithm has a single point of failure. Realistically, if that does
> happen, on this list (or some other) there will be a flurry of discussion,
> and then we'll pick one to be the new MUST algorithm. This would be
> painful, but it wouldn't be much more painful than excising out CAST5 or
> IDEA. Probably less than IDEA.

The problem is a conflict that some faction wants to minimize the MUST
list (Either for implementation reasons, e.g. PDAs, or because they don't
like or trust BlowFish, CAST5, or SAFER/SK128 - all I think are
unencumbered). 

If we have a single MUST, then that singleton is the default and has the
problems you mention.  If we add a second MUST, the conventional cipher
code innards double in size.

But I would also note that the same thing happens with RSA v.s. DH.  Or
even the various hash algorithms - MD5 has been superceeded by SHA1 - but
isn't that vulnerable too?  Part of the idea is to move ahead so that what
gets implemented by this spec will superceed both pgp 2.6.2 and pgp 5.x.
leaving a single "standard"  with a universal MUST subset. 

At the same time, where capable, every implementation should include the
SHOULDs to avoid the above problems.  SHOULD is not simply another way of
saying "MAY".

Though I still have problems with defaulting to 3DES if there is no
preferred cipher listed.  I should be able to encrypt using any SHOULD
algorithm and get a reply stating "I can't decrypt it, please use X" if
they published the key without a preference.  If there *is* a prefered
cipher, and it is 3DES, I must use 3DES.  If there is a list not including
3DES, but I don't implement any of them, I should use 3DES.

One note is that when generating the key for publication, what if I start
on my desktop with a full implementation, but then move to my PDA which
only has 3DES - I need a key update cert.  Or I should be asked what the
preferred cipher set is when I generate the key with a note that if I plan
to move the key to other implementations, I should use only 3DES as the
preferred cipher.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 23 Mar 1998 17:23:38 -0800
To: [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

At 15:33 3/23/98 , Jon Callas wrote:

>If the protocols allow someone to use [an unsafe encryption algorithm]
>and send it around, then you have the same exposure [as if they merely 
>neglected to encrypt at all].

Not quite: in the latter case, it's apparent to the recipient that the
sender blew it.  If that one message has all the secrets of the universe,
and a big red flag to attract Satan's attention, then the jig is up.  If
not, then a scathing rebuke in the (encrypted, no doubt) reply could
prevent further disclosures.  But if the message is encrypted, the
recipient may merely notice that decryption was necessary and was performed.

That distinction actually argues for your position (that the preferences
are binding upon the sender), but I still hold that the code and keyrings
have a necessarily incomplete knowledge, which the humans (who are, after
all the ones at risk here!) must be able to override.

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

Date: Mon, 23 Mar 1998 15:33:45 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

The question came up in the last stream of what happens if 3DES gets
broken. The answer is that we're in trouble. Any protocol that has a single
MUST algorithm has a single point of failure. Realistically, if that does
happen, on this list (or some other) there will be a flurry of discussion,
and then we'll pick one to be the new MUST algorithm. This would be
painful, but it wouldn't be much more painful than excising out CAST5 or
IDEA. Probably less than IDEA.

I do not believe that we are trying to solve the problem of a bad (or
stupid) person using a bad algorithm and sending you incriminating mail.
There are also algorithm identifiers reserved for experimental and private
algorithms. (And personally, I think the biggest danger is in sending
cleartext mail. The braindead mistake I make at least once a month is to
reply to encrypted mail and not hit the encrypt button -- but that's an
implementation flaw.) If the protocols allow someone to use anything as one
of those and send it around, then you have the same exposure. This is why I
believe that the interpretation of the algorithm preferences that I gave
before is the correct one; it simply makes all of these issues go away. 

Now, Bill Geiger's comments are good ones. Any message is a transaction
between the sender and the receiver(s). The protocol needs to address the
sender's desires, and Bill's expressions of them are very close to
arguments that PhilZ has given on this very issue. However, I think that it
is even *more* important to put some control in the hands of the receiver.
The sender has the option of not sending a message if the algorithm
negotiation fails (which would only happen if the sender wants never to use
3DES). As much as the option to use the phone is cold comfort, it is
nonetheless a real option. The receiver has no such option. If the receiver
(irrationally) hates algorithm X yet cannot specify this opinion, there
will inevitably be times when a message encrypted with X will appear in
their inbox. When this happens, the receiver is left in the same position
as Yosemite Sam after a lit stick of dynamite is dropped through the
mailslot. All they can do is snarl, "Ooooooooo! Ya stoopid idjit rabbit, I
told you never to use IDEA!"

The OpenPGP protocol solves the conflicts by declaring that everyone finds
3DES acceptable. Maybe not preferred, but acceptable. To answer Adam Back's
comments, if 3DES is one of your preferred algorithms, you list it to
indicate you like it more than some other algorithm. The question arises as
to whether you'd put it as your *last* algorithm, as it is implicit that
3DES is your least preferred acceptable algorithm. I believe that it is a
good idea to state it. In the previous draft, I asked the question of
whether it is worth having a negative preference on algorithms. No one
seemed to think so. If there were negative preferences, it would be
possible for someone to state a dislike for 3DES, which it is not possible
to do now. If someone were to make a TinyPGP system that used some other
algorithm other than 3DES, then a negative preference could allow it to
interoperate with some OpenPGP implementations. (I'm not advocating that we
do this at all, I'm just nothing that the issue could be solved if we
wanted to solve it.)

I believe that good design of a security protocol means that we should
declare the algorithm prefs to be as I described previously, and that it is
non-conforming to encrypt something to someone using an algorithm not in
their vector. This means that someone who does not implement the
preferences is implicitly commiting to using only 3DES, since it is always
acceptable. If we don't do this, then it is inevitable that a conforming
application will send a message to another conforming application that it
can't decode. And this is a Bad Thing.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 23 Mar 1998 15:30:34 -0800
To: [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

At 07:16 3/23/98 , [email-masked] wrote:

>But this is different.  If you don't want encrypted mail, then you should
>publish only the DSS key.  That would be the easiest way, though I don't
>know if there is a method of doing so in the spec.

Not if you've already published the key when the rules change (war breaks
out, and receiving encrypted mail becomes de fact treason).  At that point,
you need actually to rescind the implicit permission to encrypt ... key
revocation (or revocation of only the encrypt half) might do it.

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

Date: Mon, 23 Mar 1998 15:17:12 -0800
To: [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

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

At 06:14 3/21/98 , William H. Geiger III wrote:

>User x generates keys using WimpyPGP(tm) that only supports the bare
>minimum of algorithms. He now goes and updates to SuperPGP(tm) that has
>every algorithm under the sun. Before anyone can send him any messages
>encrypted with the one of the "new" algorithms he must update his keys and
>re-distribute it.

I don't believe anyone has responded to the issues raised in this example.
Concretely: the list of algorithms on the key does not necessarily
represent the list of algorithms the user('s programs) can or will accept,
because users can change their applications and preferences faster than
they can update the cosmic keyring.  This alone makes a hard-line send
limitation questionable.  The real world is just a little more complex and
dynamic than the code or standard can touch; the users - at both ends, by
common agreement - need the ability to override.

I'm not willing to go quite as far as whgiii, in saying that the sender
alone has complete right to choose the algorithm: there's little value to
sending a message that the recipient actually can not decrypt - except,
maybe, to rub his nose in it?  But there's a real question as to whether
the copy of the key that's on the sender's ring accurately reflects
reality.  In such a case, the "conservative on send" policy is to allow the
user some kind of override.

I grant the legitimate need and right of the recipient to forcibly refuse
certain algorithms, in order to protect his own privacy.  But this indirect
algorithm choice must always first of all be expressed by noncryptographic
means ("when you send stuff to me, be sure to encrypt it"); adding "... and
never use 3DES" doesn't seem too great an imposition.

Can this standard (which is, after all, about bits and bytes, not about UI)
say something like "the implementation MUST NOT encrypt with an unlisted
algorithm without dire warnings to the sender"?

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

Date: Mon, 23 Mar 1998 11:30:59 -0500
From: [email-masked]
To: Jim Gillogly <[email-masked]>
cc: [email-masked]
Subject: Re: HAVAL - But which variant (and what OID?)
Sender: [email-masked]

On Mon, 23 Mar 1998, Jim Gillogly wrote:

> Hal Finney writes:
> 
> > I can't find an OID assignment for HAVAL.  Peter Gutmann has a long list
> > of known security related OIDs in his dumpasn1.cfg file, but it does not
> > list HAVAL.  You might direct email to the author and ask if he knows
> > of an OID assignment.  I suspect we would need a family of OIDs, one for
> > each length/passes combination.
> 
> I wrote to the author -- he's interested but unfamiliar with the OID
> process.  Is it the case that one of us can simply define and declare
> a set of HAVAL variants that meets our needs?

The problem is that Hash Algorithm 4 is "HAVAL", but it has to mean a
specific variant.  I am setting it for 5 pass/160 bit.  128 bit might also
be good, or even 256 bit (for non-DSA).  But I would rather new has
algorithm *numbers* be assigned, e.g. HAVAL-5/160, HAVAL-3/128, etc.

> tzeruch asks:
> > And is there an implementation without copyright or patent problems?
> 
> Yes, Paulo Barreto has written a public domain implementation of HAVAL.
> It's at http://ds.dial.pipex.com/george.barwood/crypto.htm
> and is apparently correct, since the author, Yuliang Zheng, acknowledges
> that Barreto found and reported an error in the reference
> implementation.

I tried it, but I am having some problems getting it to pass its
self-test.  I also wrote the author - his page,
http://pscit-www.fcit.monash.edu.au/~yuliang/src/
gives liberal copyright terms.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 23 Mar 1998 10:16:58 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

On Sat, 21 Mar 1998, Christopher Creutzig wrote:

> On Fri, 20 Mar 1998, Anonymous wrote:
>  
> -> symmetrically-encrypted data packets (Sec. 5.7).  The clear-signed mode
> -> you refer to is disjoint from these (Sec. 7) and is not affected by choice
> -> of encryption algorithms.  If one of the warriors to whom you refer thought
> -> she was sending an encrypted message, but it was encrypted with one of
> -> these two algorithms (Plaintext or Rot-N), she would be in deep trouble.
> 
>  Right you are. I just wanted to point out that there should be a method of
> specifying 'no encrypted mail, please'. Granted, just use a sign-only key
> with no encryption sub key should solve the issue, so it's probably not
> worth too much bothering.

which is what the messages of the form:

 --BEGIN PGP SIGNED MESSAGE...

plaintext

 --BEGIN PGP SIGNATURE...

(ascii armored sig block)

 --END...

are for.

But this is different.  If you don't want encrypted mail, then you should
publish only the DSS key.  That would be the easiest way, though I don't
know if there is a method of doing so in the spec.

And "Unencrypted" can have a very different meaning than "Encrypted using
the conventional algorithm 'Plaintext'".

Unencrypted should probably be a literal encapsulation of plaintext
followed by a signature packet if desired.  Compression and armoring are
also possible.

Plaintext encryption would have all the headers and other structure of an
encrypted PGP message, but the essential section of the message would be
unencrypted.

But the matter of compression comes up - I remember the FCC did not want
packet radio to transmit even unencrypted .zip files because they weren't
immediately understandable.  If the idea is an open envelope, only the
attach signature format above is likely to work.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 22 Mar 1998 23:32:04 -0800
From: Jim Gillogly <[email-masked]>
Organization: Banzai Institute
To: [email-masked]
Subject: Re: HAVAL - But which variant (and what OID?)
Sender: [email-masked]

Hal Finney writes:

> I can't find an OID assignment for HAVAL.  Peter Gutmann has a long list
> of known security related OIDs in his dumpasn1.cfg file, but it does not
> list HAVAL.  You might direct email to the author and ask if he knows
> of an OID assignment.  I suspect we would need a family of OIDs, one for
> each length/passes combination.

I wrote to the author -- he's interested but unfamiliar with the OID
process.  Is it the case that one of us can simply define and declare
a set of HAVAL variants that meets our needs?

tzeruch asks:
> And is there an implementation without copyright or patent problems?

Yes, Paulo Barreto has written a public domain implementation of HAVAL.
It's at http://ds.dial.pipex.com/george.barwood/crypto.htm
and is apparently correct, since the author, Yuliang Zheng, acknowledges
that Barreto found and reported an error in the reference
implementation.

-- 
	Jim Gillogly
	Sterday, 1 Astron S.R. 1998, 07:18
	12.19.5.0.10, 9 Oc 8 Cumku, First Lord of Night

To: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: mail failed, returning to sender (fwd)
Date: Sat, 21 Mar 1998 10:08:04 +0100 (MET)
Sender: [email-masked]

On Thu, 19 Mar 1998, Anonymous wrote:
 
-> Is Algorithm 0 specified for debugging?  If so, do we need to say it
-> MUST NOT be enabled outside of debugging environments?

 In that case, please mention in the spec that it is legal to specify *no*
encryption algorithm at all and that this should denote that the recipient
wishes to receive unencrypted mail only. That's highly important for people
in areas of war. (Letters to and from the red cross in those areas are
always transported in open envelopes, for good reason. 'Treason' is no
accusement to be taken lightly. There are situations where people get shot
simply for receiving encrypted mail. Signing should be ok, however.)

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873

CC: [email-masked]
To: Anonymous <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Date: Sat, 21 Mar 1998 10:11:25 +0100 (MET)
Sender: [email-masked]

On Fri, 20 Mar 1998, Anonymous wrote:
 
-> We should probably keep this on the OpenPGP mailing list, so as not

 Sure. Just a typo on my part. I did forward my mail to the OpenPGP list
after sending it to you -- alas, I made a typo in the address, so I resent
it a couple of minutes ago.

-> symmetrically-encrypted data packets (Sec. 5.7).  The clear-signed mode
-> you refer to is disjoint from these (Sec. 7) and is not affected by choice
-> of encryption algorithms.  If one of the warriors to whom you refer thought
-> she was sending an encrypted message, but it was encrypted with one of
-> these two algorithms (Plaintext or Rot-N), she would be in deep trouble.

 Right you are. I just wanted to point out that there should be a method of
specifying 'no encrypted mail, please'. Granted, just use a sign-only key
with no encryption sub key should solve the issue, so it's probably not
worth too much bothering.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873

Date: Sun, 22 Mar 1998 12:36:02 -0800
To: "William H. Geiger III" <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Algorithms and specifiers
Cc: [email-masked]
Sender: [email-masked]

At 06:31 PM 3/21/98 -0600, William H. Geiger III wrote:
>This may be part of our misunderstanding here:
>I do not accept that the algorithm *preferences* should be a complete
>listing of all algorithms that the user is capable of using. IMHO it
>should just be what the name implies: a list of prefered algorithms,
>nothing more.

I assumed that was your position.  The problem is that there _does_
need to be some mechanism for indicating which algorithms the user
is capable of accepting, so it either needs a separate syntax for 
indicating it, or else it needs to be combined with the preference list.

I'd guess that the people who came up with the current scheme decided
that there was very little practical need to keep them separate, 
so they combined the two functions, and I agree with them.

PGP will probably end up in two main forms
- Commercial PGP from NAI and fellow travellers,
	which will support a wide range of algorithms
	including licensed IDEA and RSA
- Freeware PGP and OpenPGP, which will probably
	not include IDEA for patent-license reasons,
	but will support a lot of other algorithms;
	some will support RSA and some won't.
- Specialized applications for firewalls, smartcards, etc.,
	which will support one or two symmetric algorithms,
	3DES for official standards compatibility and 
	something small and fast that they'll actually use, 
	and they may even skip the 3DES to save space.

Especially in the latter case, if you don't know what 
algorithms someone can accept, you can't successfully send them mail
unless you default to 3DES.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sun, 22 Mar 1998 14:22:41 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Algorithms and specifiers
To: [email-masked]
Sender: [email-masked]

Bill rote:
>It is my position that algorithm preference is just that, a preference,
>and the final desision of what algorithms to use should be the sole
>decision of the owner of the document (ie the sender).
 
I must respectfully disagree but then I have gotten rather deep into
autoexecution of mobile code (anyone looked real close at the VBScript
capability of OUTLOOK98 beta 2 ?).

Agree that the decision of what to use should be the sender's, at the 
same time, what to *receive* should be that of the recipient. Currently,
I have all 40 bit algorithms turned off in Netscape and that is *my*
decision.

Would suggest that there be three choices: accept always, accept with 
warning & OK, never accept.

Now that presupposes that the sender does not know what algoritms the
recipient will accept but also expect that that information might be 
contained in some future certificate (though having to revoke simply
to add CAST-128 seems a bit extreeme).

However am convinced that in the near future, simple blind opening of
E-Mail with concurrent identification will no longer be acceptable.

					Warmly,
						Padgett

Date: Sun, 22 Mar 1998 13:54:14 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: X.509 is not a product (was S/MIME winz)
To: [email-masked]
Sender: [email-masked]

Bill rote:
>X.509 is NOT a hierarchical PKI.
>It's a syntax for one key certifying another key.

Exactly (and the rest of the posing is worth reading also). If you look back
to my original post, you will see I was referring to *operational* systems, 
not vapourware.

PGP is essentially a stand-alone product with its own hierarchy and the 
products are available. It is not an end-state but most of the pieces
are there.

Algoritms are trivial to change. Certificate generation/acceptance is also
easy to incorporate once agreed upon. The only problem arises if a required
element must be licensed and in that case nobody wins.

The infrastructure to change from an essentially personal product to one that 
is both global and ubiquitous is the hard part. I estimate it will take
two years - pressures are there, needs are there, is mostly a matter of doing
it.

Since S/MIME is now public, I expect that it will be come the ICD of choice.
ASCII-Armour had its place as did UUEncode but will need to settle for a 
nitch in the future, a BASE-64 future.

What we need now are standards. X.500 is one and by extension X.509 but just
as LDAP is producing a modified X.500, so is X.509 going to be modified. Not
a big thing.

Biggest question in my mind today is whether we will have single certificates
with extensible attributes and multiple signatures or just multiple attached
certificates. Suspect will be the latter but cannot tell yet.

In the mean time we are going to have to deal with a transition period of
maintaining connectivity with less-than-universal certificate use (the two
years I mentioned) and multiple platforms. Thusfar PGP seems to be filling
that need but the question remains whether it will be able to transition.

Today, security is an add-on/add-in. Tomorrow it will be pervasive. How to 
get from A to B is what we are dealing with now.

				 Warmly,
					Padgett

Date: Sat, 21 Mar 1998 20:26:34 -0800
To: "William H. Geiger III" <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Algorithms and specifiers
Cc: [email-masked]
Sender: [email-masked]

>>It is a matter of principle.  If the recipient can't read it,  sending it
>>has no value, so there should be a common algorithm available. If the
>>recipient doesn't trust anything but 3DES, why should you annoy him by
>>sending him messages he can't read?
...
>You seem to be missing the point here. 

I'm not missing your point, I'm just disagreeing with it :-)

>Why should the recipiant mandate how I encrypt my messages? 
>It is *my* message! These are *preferences* not mandates. 
>The owner of a key may chose not to put any algorithm
>*preferences* in his key should all communications to this user then be
>forced to use 3DES dispite the fact he is capable of decrypting other
>algorithms??
If your objective is to communicate with the recipient,
you need to send it in a form the recipient can understand.
If the recipient doesn't understand CAST5, it doesn't matter
how enthusiatic you are about CAST5 being the One True Algorithm,
because he won't be able to decrypt it.

The algorithm preferences serve a dual function - 
- indicating which algorithms the recipient understands, and
- indicating which algorithms the recipient would prefer to use.
Ignoring the recipient's preferred order is fine;
ignoring the list of acceptable algorithms is not.
If the recipient gives you a list of preferences listing
	BASS-O-MATIC, 3DES, ROT-13, RC4-40, FEAL-8, CAST5
then he's told you he can read CAST5, even though he'd rather
use anything else he supports, but there's no indication that
he can read IDEA, which is a strong implication that he can't.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sun, 22 Mar 1998 00:09:19 -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

On Fri, 20 Mar 1998, Jon Callas wrote:

> The most important is what the symmetric algorithm preference is. It's a
> list of symmetric algorithms that the keyholder accepts. If an algorithm is
> not in the list, then the keyholder doesn't speak it, and consequently an
> implementation MUST NOT use an algorithm absent from that list. If that
> packet is absent, then it is implicitly stating a preference for 3DES, and
> all keys implicitly accept 3DES even if unstated.

If 3DES is a MUST, even if it is not listed it should be usable (assume
the preference states Blowfish, and MyPGP doesn't do Blowfish). 

Much of this is implementation, so how different preferences are handled
should be up to the implementor, and not in the spec.

The way I would implement the selection logic (in order):

1. Sender Overrides (command line, config, environment) with a list of
   never, try to avoid (warn), prefer, force entries.

   Force will leave a single entry.  Otherwise start with the full list
   the sender supports, delete the NEVERS, then create 3 lists: prefered,
   neutral, avoid.  A Force will equal a single neutral entry.

2. Recipient Preference.  This is the list in the key | 3DES

   Take this list, and find the first common cipher on the senders
   preferred list, and if none exists, on the neutral list, and if there
   is none there, use the avoid list (and print a warning).

If I don't want to send 3DES, I put it in my never send list.  If I don't
want to receive 3DES, then I can't be running something that interoperates
with OpenPGP by definition.  If I am the receiver, and don't want 3DES, I
should be able to specify a warning message (e.g. a never list on the
receiver side).  I can still decrypt the message, but get warnings saying 
that it uses something I don't want it to be using.

> I'm planning on a few other things in the algorithm section. Among them, I
> plan some notes on Elgamal, particularly notes explaining the restriction
> on an Elgamal key that is going to be used for signatures. I always thought
> that "plaintext" means plaintext, with no CFB stuff, but after reading
> tzeruch's comments, it seems that having 10 bytes of reset data is more
> correct. Arguably, this is a way to satisfy the desire for a debugging
> algorithm without grossing out the people who don't like the idea. Comments?

I thought ROT-N was supposed to satisfy the desire for a debugging
algorithm.

10 bytes of reset data: I assume the bytes number 7==9 and 8==10, like all
other cfb variants, but the first 8 bytes are still random?

And more importantly, there would be a full conventional key header with
all the fields, just that the algorithm would be zero, so none of the
stuff would be used (except maybe the IV to do the 1st 10 bytes).

So the CFB routine won't even do the XOR operation with the previous 8
byte block?  (or can we define the blocksize > 8 so dispense with the
reset that way?).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 21 Mar 1998 23:35:16 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Free toolkit?
Sender: [email-masked]

On Fri, 20 Mar 1998, Jon Callas wrote:

> Is anyone planning a free OpenPGP toolkit?

Technically, mine is (not counting patents and other various external
legal restrictions - I only say if you cripple it call it something else.
I use SSLeay which can use a number of RSA software variants with
different license policies, and a few other libs which have copyright
notices on them which I leave pointers to in the READMEs and patches as
necessary). 

Actually I reworked the calls so the names make more sense and am doing a
major clean-up and verification this weekend.  It also munges cleanly ;),
but I don't have a publisher. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 21 Mar 1998 17:24:56 -0800
To: Adam Back <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: Algorithms and specifiers
Cc: [email-masked]
Sender: [email-masked]

At 11:26 AM -0800 3/21/98, Adam Back wrote:
>So by capabilities it means that if my client specifies no
>capabilities this implies 3DES capability.  (It has to as 3DES is a
>must algorithm, and we need one MUST algorithm).  If my client
>specifies CAST5, followed by 3DES, it means that I can decrypt both
>CAST5 and 3DES but the order indicates that I prefer CAST5, if the
>sender has this capability.
>
>As an aside I think it would be probably sensible to never list 3DES
>as a capability explicitly as it is by definition there as a MUST.
>What does the current spec imply on this?

If the list is only to specify supported algorithms, then none of the MUST
algorithms (3DES) need be specified.  If the list is to specify an ordered
list of preferences, then the MUST algorithms must be specified so their
preference order can be determined.

I think there is a problem with having one list for both functions, but I
don't think it is serious.  Let us say I support a 40 bit algorithm.  I
don't think it is worth shit, but I have it.  Do I include it in the list
(as least preferred) or do I leave it off?

-------------------------------------------------------------------------
Bill Frantz       | If hate must be my prison  | Periwinkle -- Consulting
(408)356-8506     | lock, then love must be    | 16345 Englewood Ave.
[email-masked] | the key.     - Phil Ochs   | Los Gatos, CA 95032, USA

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 21 Mar 98 18:31:31 -0600
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

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

In <[email-masked]>, on 03/21/98 
   at 07:26 PM, Adam Back <[email-masked]> said:

>If I understand correctly the algorithm preferences serve two functions
>at the same time:

> 1) the designature capabilities (a statement of what algorithms this
>    client is capable of handling)

> 2) they indicate the key owners preferences amongst of those
>    algorithms his client supports

This may be part of our misunderstanding here:

I do not accept that the algorithm *preferences* should be a complete
listing of all algorithms that the user is capable of using. IMHO it
should just be what the name implies: a list of prefered algorithms,
nothing more.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Your brain.  Windows: Your brain on drugs.

Date: Sat, 21 Mar 98 16:02:21 PST
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

I tried (regarding 3DES as a MUST):
> > However, doesn't this mean "client MUST implement" rather than
> > "recipient MUST accept"?

Adam Back <[email-masked]> responded:
> `Accepting' 3DES whilst not implementing it sounds strange -- you
> accept it and drop it in /dev/null?  Perhaps I am not understanding
> what you are saying.

Perhaps I'm misunderstanding.  I draw a distinction between what my
program (the client, possibly not written by me) understands, and what
I (the user) am willing to accept.  If Rot-N and Plaintext are left as
legitimate entries in Section 9.2 and I receive them, I not only want
to drop them in /dev/null, but also to hunt down and exterminate the
system that sent them.  OK, maybe too strong.  But if they're going
to send insecure messages to me, let them send them in the clear so
everybody is aware precisely what the level of protection is.  If it's
Rot-N or Plaintext with CFB XORed with an IV, it'll look secure until
somebody pokes at it with the right tool.

Try this: next year Kwan totally destroys 3DES by finding a gate
reduction to under 100 for 1DES combined rounds 2-15 when they're
considered as a unit.  Finney, you, and the NSA have all received
preprints of his Crypto '99 paper.  What do you do when you know the
algorithm's broken?  Historically algorithms <have> been broken, and we
can expect at least one of the algorithms on our list may run into
trouble if not an outright break.  Should you as the key owner be able
to expect cooperation from senders?
 
> > He also suggests that the list of preferred algorithms is all the
> > algorithms the client supports, ordered by preference of user.
> 
> OK, what about algorithms you specifically don't want to receive you
> don't list.  Except you are not allowed to drop 3DES, so either 3DES
> always has to be there, or if it is not listed it is assumed to be
> there but at lowest preference level.

Not listing algorithms you don't want to receive is fine with me.
I'm not as comfortable with not being able to drop 3DES, but am
willing to go along with it if this is viewed as too paranoid.

> Yes I agree.  In fact I'd go further I don't want Rot-13 (or Rot-N) to
> be defined at all!

Works for me.  Also Plaintext as a symmetric cipher type (9.2).

> Is there such a concept as plaintext encrypted messages?  This would
> be like cipher NULL with SSL to stand as a place holder for messages
> which are signed only.  NULL meaning `no confidentiality' is much

Our equivalent is cleartext signed messages, which is covered
separately from 9.2 (i.e. in Sec. 7).  I think we also don't need
Plaintext (9.2).

> Another approach to conflicting sender and recipient algorithm choices
> is to use both -- super-encrypt in the case of cipher algorithm
> choice.  Or use some other (to be decided) mechanism to combine
> ciphers such that we are confident that the result is as strong as the
> strongest of the two ciphers used.

Super-encrypting sounds good to me.  I think there are few cases
where doubling up modern algorithms weakens one.

> For conflicting signature preferences sign with both algorithms if
> both parties able to understand them (where signature includes both
> hash choice and signature algorithm).

Sounds good.

Looking back on the discussion, I think I may have the wrong approach
to the design process.  I'm suggesting design constraints that will let
me exercise my own preferences, but we should probably be concentrating
on ways to protect the even more naive user.  Lucky us when they
intersect, as in dumping Plaintext and Rot-N.

	Jim Gillogly
	Highday, 30 Rethe s.R. 1998, 00:01
	12.19.5.0.9, 8 Muluc 7 Cumku, Ninth Lord of Night

Date: Sat, 21 Mar 1998 23:20:00 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

Jim Gillogly <[email-masked]> writes:
> Perhaps we should consider some scenarios about why a recipient or
> a sender would have a preference.
> 
> - Example: I normally use this key/username to get gigabyte files of
>   satellite data dumped to my machine.  If they send it in 3DES
>   my scruffy P1 can't keep up.  I need it to use CAST or Blowfish.
>   If the sender overrides this and sends me 3DES, my machine chokes.
> 
> Note that in this latter case the user chooses not to accept the
> MUST algorithm for good (though uncommon) reasons -- should this
> be OK?

It seems valid to be able to say you don't want to receive messages
encrypted with 3DES (by leaving it off the list of capabilites).
However I think this equates roughly to putting 3DES last on your list
of accepted ciphers, because as 3DES is a MUST algorithm, everyone
knows you can actually read it, and may choose to send you it against
your wishes.  Indeed some people may have no other choice if they are
using a minimal implementation.  There wouldn't be much point ignoring
the data encrypted with 3DES after you've received it, and because of
users of minimal implementations your client would need to accept it
to claim compliance as 3DES is a MUST.  I think this leads to the
conclusion that you SHOULD NOT be able to disable 3DES, though putting
it lowest on your list of preferred algorithms should be fair enough.

> Adam Back suggests that 3DES need not be listed, since it's a MUST.

My reason for saying this was I thought that perhaps it was redundant
to list it, but on further reflection I retract that: you will have to
list 3DES in order to specify your relative preference for it over
other ciphers you choose to accept if you want to give it other than
default preference.

> However, doesn't this mean "client MUST implement" rather than
> "recipient MUST accept"?

`Accepting' 3DES whilst not implementing it sounds strange -- you
accept it and drop it in /dev/null?  Perhaps I am not understanding
what you are saying.

> He also suggests that the list of preferred algorithms is all the
> algorithms the client supports, ordered by preference of user.

OK, what about algorithms you specifically don't want to receive you
don't list.  Except you are not allowed to drop 3DES, so either 3DES
always has to be there, or if it is not listed it is assumed to be
there but at lowest preference level.

> I strongly object to this -- I do not want to accept Rot-N or
> Plaintext encrypted messages, whether or not my client knows what to
> do with them, since I trust my own guesses about security of
> algorithms more than I trust most people sending messages to me.

Yes I agree.  In fact I'd go further I don't want Rot-13 (or Rot-N) to
be defined at all!

If I remember rightly the sequence of events that led to ROT-N being
listed was that I made a reductio ad adsurdum (sp) argument giving
ROT-n as the example of why you should not implement something which I
viewed to have weak security, and Jon promptly added the ROT-N as a
joke.  Please remove it!  It is a security risk.

Is there such a concept as plaintext encrypted messages?  This would
be like cipher NULL with SSL to stand as a place holder for messages
which are signed only.  NULL meaning `no confidentiality' is much
preferable to Rot-13 meaning `no confidentiality' because it will
confuse people.  Rot-13 is redundant anyway if there is a NULL cipher.

> What are some scenarios that would make ignoring the recipient's
> preference the correct decision?

I am the sender, I am control what algorithms get used on sending.  If
the recipient says he would prefer CAST5, but I prefer IDEA and his
capabilities say that he can accept IDEA but prefers CAST5, well I
will send it to him as IDEA if I want to.

I as sender have a right to over-ride recipients algorithm preferences
up to but not beyond the point of using ciphers which he claims to not
be capable of decrypting.  I also have a `right' to send stuff
encrypted to him which I know he won't be able to read, however, I
don't think a conforming implementation should assist me in doing
this.

Another approach to conflicting sender and recipient algorithm choices
is to use both -- super-encrypt in the case of cipher algorithm
choice.  Or use some other (to be decided) mechanism to combine
ciphers such that we are confident that the result is as strong as the
strongest of the two ciphers used.

For conflicting signature preferences sign with both algorithms if
both parties able to understand them (where signature includes both
hash choice and signature algorithm).

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Sat, 21 Mar 1998 14:12:45 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

One case to consider is where there are multiple recipients.  PGP 5.X
tries to select an encryption algorithm which is acceptable to all.
If there is more than one acceptable one, it chooses the algorithm with
the earliest average position in each recipient's preference list.

However it may be that there are no algorithms which are both acceptable
to all recipients and acceptable to (or even implemented by) the sender.
This can actually happen pretty easily since the code assumes that
unpreferenced RSA keys are from PGP 2.X users who can only accept IDEA.

In 5.0, we aborted with an error in that case, and the user was informed
that he could not encrypt to those recipients.  However Phil Zimmermann
did not like that failure mode, so in 5.5 we changed it so that in that
case we go ahead and encrypt anyway, even though not all recipients may
be able to read the message.

Hal

Date: Sat, 21 Mar 1998 15:17:36 -0600
To: [email-masked]
From: Black Unicorn <[email-masked]>
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

At 08:13 PM 3/20/98 , William H. Geiger III wrote:

>It is my position that algorithm preference is just that, a preference,
>and the final desision of what algorithms to use should be the sole
>decision of the owner of the document (ie the sender).

I think in a way one can have the best of both worlds.  It's going to be a
question of user interface really.

Binding a list of accepted algorithms to one's public key is a "Good
Thing"(tm).  What is a "Bad Thing"(tm) is having PGP on the sender's side
go through some required automated process in conventional cipher
selection.  Ideally PGP should have a preference section which permits a
sender to be warned when encrypting to a key that does not have as its #1
preference the senders cipher of choice.

I look at this just like CMR keys.  I have the option of being warned
before encrypting to one (presumably so I can decide NOT to encrypt to it
if I find it distasteful).  If I find the cipher distasteful why should I
not be similarly warned?

"Warning:  The holder of this public key has specified CAST as its
preferred cipher.  CAST does not appear in your preferred cipher list.  The
recipient also permits the use of 3DES, encrypt with this cipher instead?"

Caller ID was done much the same way.  A call can be made with or without
sending caller ID info to the recipient, but the recipient has the option
of refusing to receive any calls which have first been *67'd.

This also begs for an interface which allows PGP to inform the user which
cipher received messages were encrypted with.  I'm not aware that this is
possible now, and the interface by which I select which ciphers my key
accepts (you have to make the selections in a general preferences section
and then create a new key to impose those preferences).

I'm not sure this is spec stuff, but it seems to suggest that these issues
can be partly if not fully solved by user interface.

I suppose it would be nice to require more detailed sender notification of
the recipients cipher list.

Date: Sat, 21 Mar 98 11:44:03 PST
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

Bill Stewart:
> >If you're paranoid enough that you insist that your messages be encrypted
> >with CAST5, do that, add a note saying it's encrypted with CAST5, and
> >encrypt that with the 3DES the recipient wants.

William H. Geiger III:
> You seem to be missing the point here. Why should the recipiant mandate
> how I encrypt my messages? It is *my* message! These are *preferences* not
> mandates. The owner of a key may chose not to put any algorithm
> *preferences* in his key should all communications to this user then be
> forced to use 3DES dispite the fact he is capable of decrypting other
> algorithms??

Uh, yes.  It's not a no-brainer decision though.

Perhaps we should consider some scenarios about why a recipient or
a sender would have a preference.

- Example: I'm involved in a conspiracy, and I don't want any of my
  clueless or government-stooge co-conspirators using Rot-N or
  Plaintext as their preferred cipher, since I suspect these ciphers
  may provide less protection than I feel my conspiracy is worth.
  If I can't specify that I refuse to accept crackable incriminating
  messages, then I'll have a lot of explaining to do in court.

- Example: I want to send a private message to someone, but know
  their only accepted cipher (IDEA) has recently been broken.  I
  can choose not to send the message, or else to send them a message
  telling them I can't send them secure mail and asking them to pick
  another algorithm.

- Example: I normally use this key/username to get gigabyte files of
  satellite data dumped to my machine.  If they send it in 3DES
  my scruffy P1 can't keep up.  I need it to use CAST or Blowfish.
  If the sender overrides this and sends me 3DES, my machine chokes.

Note that in this latter case the user chooses not to accept the
MUST algorithm for good (though uncommon) reasons -- should this
be OK?

Adam Back suggests that 3DES need not be listed, since it's a MUST.
However, doesn't this mean "client MUST implement" rather than
"recipient MUST accept"?  He also suggests that the list of
preferred algorithms is all the algorithms the client supports,
ordered by preference of user.  I strongly object to this -- I do
not want to accept Rot-N or Plaintext encrypted messages, whether
or not my client knows what to do with them, since I trust my own
guesses about security of algorithms more than I trust most people
sending messages to me.

What are some scenarios that would make ignoring the recipient's
preference the correct decision?

	Jim Gillogly
	Mersday, 29 Rethe S.R. 1998, 19:34
	12.19.5.0.9, 8 Muluc 7 Cumku, Ninth Lord of Night

Date: Sat, 21 Mar 1998 19:26:01 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

William Geiger <[email-masked]> writes:
> Bill Stewart <[email-masked]> writes:
> >If you don't trust RSA, and always want send out your messages using 
> >ElGamal public keys, why should you be prevented from doing so?   Don't
> >let the mere fact that the recipient doesn't have an ElGamal  key bother
> >you :-)
> 
> You seem to be missing the point here. Why should the recipiant mandate
> how I encrypt my messages? It is *my* message! These are *preferences* not
> mandates. 

If I understand correctly the algorithm preferences serve two
functions at the same time:

 1) the designature capabilities (a statement of what algorithms this
    client is capable of handling)

 2) they indicate the key owners preferences amongst of those
    algorithms his client supports

So by capabilities it means that if my client specifies no
capabilities this implies 3DES capability.  (It has to as 3DES is a
must algorithm, and we need one MUST algorithm).  If my client
specifies CAST5, followed by 3DES, it means that I can decrypt both
CAST5 and 3DES but the order indicates that I prefer CAST5, if the
sender has this capability.

As an aside I think it would be probably sensible to never list 3DES
as a capability explicitly as it is by definition there as a MUST.
What does the current spec imply on this?

> The owner of a key may chose not to put any algorithm *preferences*
> in his key should all communications to this user then be forced to
> use 3DES dispite the fact he is capable of decrypting other
> algorithms??

If he is capable of decrypting other algorithms, then he should
indicate this with the capability mechanism.

> This really seems like artifical restrictions in the spec that are not
> needed.

They are needed because otherwise people can not talk to each other.

If I read your comments correctly you are objecting that it is the
senders choice as to what algorithm he uses.  Well it is by
definition, *but* if the person you are sending to has stated using
the mechanism for stating capabilities that he *can not* cope with say
CAST5, sending him messages encrypted with CAST5 is bad.  So bad in
fact that we should call implementatiosn which do this non-conforming.

Your other point seems to be that perhaps it is a privacy leak to have
to leak which ciphers you prefer?  In that this would for instance
narrow down the implementation you were using.

I think this is getting towards PGP stealth functionality, and that we
could discuss this as a separate debate.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 21 Mar 98 12:49:25 -0500
To: Bill Stewart <[email-masked]>
Cc: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

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

In <[email-masked]>, on 03/21/98 
   at 10:34 AM, Bill Stewart <[email-masked]> said:

>It is a matter of principle.  If the recipient can't read it,  sending it
>has no value, so there should be a common algorithm available. If the
>recipient doesn't trust anything but 3DES, why should you annoy him by
>sending him messages he can't read?

>If you don't trust RSA, and always want send out your messages using 
>ElGamal public keys, why should you be prevented from doing so?   Don't
>let the mere fact that the recipient doesn't have an ElGamal  key bother
>you :-)

>If you're paranoid enough that you insist that your messages be encrypted
>with CAST5, do that, add a note saying it's encrypted with CAST5, and
>encrypt that with the 3DES the recipient wants.

You seem to be missing the point here. Why should the recipiant mandate
how I encrypt my messages? It is *my* message! These are *preferences* not
mandates. The owner of a key may chose not to put any algorithm
*preferences* in his key should all communications to this user then be
forced to use 3DES dispite the fact he is capable of decrypting other
algorithms??

This really seems like artifical restrictions in the spec that are not
needed.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: You're throwing it all out the Windows!

Date: Sat, 21 Mar 1998 10:34:45 -0800
To: "William H. Geiger III" <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Algorithms and specifiers
Cc: [email-masked]
Sender: [email-masked]

At 09:14 AM 3/21/98 -0500, William H. Geiger III wrote:
>Another example may be that user x has SuperPGP(tm) at home and
>WimpyPGP(tm) at work. User x has only one key. What preferences should be
>on his key?

Why should he only have one key?  
But if he does, it should be the 3DES supported by WimpyPGP,
so he can read it at both places.

>My biggest objection is a matter of principle. It's *my* message. 
>If I do not trust the "security" of 3DES and wish to send all 
>my messages out using CAST5 why should I be prevented in doing so?

It is a matter of principle.  If the recipient can't read it, 
sending it has no value, so there should be a common algorithm available.
If the recipient doesn't trust anything but 3DES, why should you
annoy him by sending him messages he can't read?

If you don't trust RSA, and always want send out your messages using 
ElGamal public keys, why should you be prevented from doing so?  
Don't let the mere fact that the recipient doesn't have an ElGamal 
key bother you :-)

If you're paranoid enough that you insist that your messages be
encrypted with CAST5, do that, add a note saying it's encrypted
with CAST5, and encrypt that with the 3DES the recipient wants.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 21 Mar 98 09:14:15 -0500
To: Bill Stewart <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

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

In <[email-masked]>, on 03/20/98 
   at 11:42 PM, Bill Stewart <[email-masked]> said:

>I agree with Jon Callas here - the list of symmetric algorithm
>preferences indicates which algorithms the recipient is prepared to
>accept. Ignoring the order of them is fine (sender and receiver will
>often have different sets of preferences, and especially different order,
>so you need to support this in general anyway.)
>But if you want to send somebody a message they can decrypt, you need to
>send an algorithm they understand.
>The usual Internet principle about being conservative about what you send
>and liberal about what you accept certainly applies here.
>I'd call it a MUST.  DES3 is a special case, since supporting it is a 
>MUST, but putting it on your list of preferences probably shouldn't
>be.

I can think of several senarios where this would be impractical.

User x generates keys using WimpyPGP(tm) that only supports the bare
minimum of algorithms. He now goes and updates to SuperPGP(tm) that has
every algorithm under the sun. Before anyone can send him any messages
encrypted with the one of the "new" algorithms he must update his keys and
re-distribute it.

Another example may be that user x has SuperPGP(tm) at home and
WimpyPGP(tm) at work. User x has only one key. What preferences should be
on his key?

There also may be cases where a user *does not* wish to advertise what
algorithms he is using "in the clear".

My biggest objection is a matter of principle. It's *my* message. If I do
not trust the "security" of 3DES and wish to send all my messages out
using CAST5 why should I be prevented in doing so?

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Not just another pretty program loader!

Date: Fri, 20 Mar 1998 23:42:02 -0800
To: "William H. Geiger III" <[email-masked]>, Jon Callas <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Algorithms and specifiers
Cc: [email-masked]
Sender: [email-masked]

I agree with Jon Callas here - the list of symmetric algorithm preferences
indicates which algorithms the recipient is prepared to accept.
Ignoring the order of them is fine (sender and receiver will often have
different sets of preferences, and especially different order,
so you need to support this in general anyway.)
But if you want to send somebody a message they can decrypt,
you need to send an algorithm they understand.
The usual Internet principle about being conservative about what you send
and liberal about what you accept certainly applies here.
I'd call it a MUST.  DES3 is a special case, since supporting it is a 
MUST, but putting it on your list of preferences probably shouldn't be.

Callas:
>>The most important is what the symmetric algorithm preference is. It's a
>>list of symmetric algorithms that the keyholder accepts. If an algorithm
>>is not in the list, then the keyholder doesn't speak it, and consequently
>>an implementation MUST NOT use an algorithm absent from that list. If
>>that packet is absent, then it is implicitly stating a preference for
>>3DES, and all keys implicitly accept 3DES even if unstated.
>
Geiger:
>Well Jon and I are in disagrement on this issue.
>It is my position that algorithm preference is just that, a preference,
>and the final desision of what algorithms to use should be the sole
>decision of the owner of the document (ie the sender).

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 20 Mar 98 21:13:01 -0500
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Algorithms and specifiers
Sender: [email-masked]

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

In <[email-masked]>, on 03/20/98 
   at 05:58 PM, Jon Callas <[email-masked]> said:

>The most important is what the symmetric algorithm preference is. It's a
>list of symmetric algorithms that the keyholder accepts. If an algorithm
>is not in the list, then the keyholder doesn't speak it, and consequently
>an implementation MUST NOT use an algorithm absent from that list. If
>that packet is absent, then it is implicitly stating a preference for
>3DES, and all keys implicitly accept 3DES even if unstated.

Well Jon and I are in disagrement on this issue.

It is my position that algorithm preference is just that, a preference,
and the final desision of what algorithms to use should be the sole
decision of the owner of the document (ie the sender).
 
This covers the whole gauntlet of algorithms (symetric, hash, compression,
PKE). Now in most cases one would want to honor the recipiants preferences
other times one would not. IMHO this should be a SHOULD item not a MUST
item in the spec.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: I love running Windows! NOT!

Date: Fri, 20 Mar 1998 17:58:14 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Algorithms and specifiers
Sender: [email-masked]

I'm planning on writing a section on algorithm notes, because it seems
apparent that there are a number of things that need to be explained
explicitly.

The most important is what the symmetric algorithm preference is. It's a
list of symmetric algorithms that the keyholder accepts. If an algorithm is
not in the list, then the keyholder doesn't speak it, and consequently an
implementation MUST NOT use an algorithm absent from that list. If that
packet is absent, then it is implicitly stating a preference for 3DES, and
all keys implicitly accept 3DES even if unstated.

Similarly, the other algorithm preferences (compression, hash) state what
the keyholder accepts for those. The interesting case is the compression
preference, in which it is assumed you accept compressed data unless you
put in a preference for only uncompressed. We live with that because we
don't want to make compression a MUST, and we don't want to force all
existing keys to put in a compression preference.

Within this context, it is clearly wrong to use any encoding, be it a
cipher, a code (rot-13 is an code, and to my mind so is rot-n), or
plaintext (the null encoding) in a Symmetrically Encrypted Data Packet that
the recipient has not told you you may use. If a message is being encrypted
to more than one person, then you have to find a suitable algorithm from
the intersection of the recipients' preferences. The MUST algorithm (3DES)
is there to ensure than the intersection is not null. (To my mind, there is
a corrolary here that an implementation should (must?) warn someone when
they get a message that the implementation can decrypt, but the user
doesn't accept.)

I'm planning on a few other things in the algorithm section. Among them, I
plan some notes on Elgamal, particularly notes explaining the restriction
on an Elgamal key that is going to be used for signatures. I always thought
that "plaintext" means plaintext, with no CFB stuff, but after reading
tzeruch's comments, it seems that having 10 bytes of reset data is more
correct. Arguably, this is a way to satisfy the desire for a debugging
algorithm without grossing out the people who don't like the idea. Comments?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 20 Mar 1998 16:33:10 -0800
To: [email-masked] (Jim Gillogly), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Iterated-Salted S2Ks
Sender: [email-masked]

At 03:46 PM 3/20/98 PST, Jim Gillogly wrote:

   The original concept doesn't seem comparatively obnoxious -- yes, it has
the
   byzantine bit-twiddling that we've come to know and/or love, but at
least is
   only one octet's worth.  I don't see spending 4 octets on an iteration
count
   that likely won't be used beyond 2 octets' worth.  If we specify an
iteration
   count high enough to slow down a 333 GHz Pentium VIII enough to foil its
   dictionary attack, the pokey 333 MHz Pentium II won't be able to do it once
   in reasonable time.  I'd just as soon go back and save 3 octets, as long as
   the C-like conversion expression from the previous draft stays in the text.
   
There are a number of people (myself included) who find PGP's tendency to
bit-twiddle in order to save three octets maddening. I'm a lot more
sympathetic to Lindsay Mathieson's plea to live with the bit-twiddling
because when it's done it's done.

   However, I'd like a little more clarity in the next part of the section
that
   describes how the iterated octet count is actually used.  This and the
   previous section talking about multiple hash contexts could benefit from
   some diagrams, I think.
   
   While we're on clarity (well, I am, anyway), would it be possible to filter
   a diagrammatic form of Hal Finney's latest explanation of CFB into section
   5.7?
   
Certainly the explanation, I was already planning that. Diagrams, I'm not
so sure about. The RFC format of 58 lines per page of 72-character lines
make a constrained canvas for any sort of diagram. The few we have have an
unerring ability to find page breaks, which I then clean up by hand. I'm
considering it, though for the CFB explanation. I'm also considering
pseudo-code there.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 20 Mar 1998 16:36:27 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Free toolkit?
Sender: [email-masked]

Is anyone planning a free OpenPGP toolkit?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 20 Mar 1998 15:42:45 -0800
To: [email-masked] (Christopher Creutzig), "William H. Geiger III" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

At 11:08 AM 3/20/98 +0100, Christopher Creutzig wrote:
   
    In that case, all comments which may be necessary e.g. in the context of
   CAs (there's a whole bunch of them, e.g. 'may sign for company XY', 'member
   of CA UVW' or 'ID checked via postal agency' (possible in Germany)) would
   need to go into the User-ID itself. That may not be feasible. While your
   point is well taken, there are also meaningful comments for which a comment
   field in the signature packet would be a highly sensible place.
   
Such a field does exist in the OpenPGP spec. Take a look at the "notation"
subpacket, which is designed both for signature extensions, and for
comments on signatures. There's a flag on the packet to let you mark it as
human-readable.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 20 Mar 98 15:46:42 PST
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: Iterated-Salted S2Ks
Sender: [email-masked]

Jon Callas <[email-masked]> wrote on Fri, 20 Mar 1998:
> Previous discussion of this decided that we wanted to either simplify the
> iterated-salted S2K or drop it. In the current draft, I simplified by
> changing the 8-bit coded number to a 32-bit number.
> 
> It sounds to me like people are willing to live with the original
> description. Is this correct? I'm perfectly willing to change it back. Make
> your voice heard if you care.

The original concept doesn't seem comparatively obnoxious -- yes, it has the
byzantine bit-twiddling that we've come to know and/or love, but at least is
only one octet's worth.  I don't see spending 4 octets on an iteration count
that likely won't be used beyond 2 octets' worth.  If we specify an iteration
count high enough to slow down a 333 GHz Pentium VIII enough to foil its
dictionary attack, the pokey 333 MHz Pentium II won't be able to do it once
in reasonable time.  I'd just as soon go back and save 3 octets, as long as
the C-like conversion expression from the previous draft stays in the text.

However, I'd like a little more clarity in the next part of the section that
describes how the iterated octet count is actually used.  This and the
previous section talking about multiple hash contexts could benefit from
some diagrams, I think.

While we're on clarity (well, I am, anyway), would it be possible to filter
a diagrammatic form of Hal Finney's latest explanation of CFB into section
5.7?

	Jim Gillogly
	Hevensday, 28 Rethe S.R. 1998, 23:52
	12.19.5.0.8, 7 Lamat 6 Cumku, Eighth Lord of Night

CC: [email-masked]
To: "William H. Geiger III" <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Proposal for new Attribute packet
Date: Fri, 20 Mar 1998 11:08:47 +0100 (MET)
Sender: [email-masked]

On Thu, 19 Mar 1998, William H. Geiger III wrote:
 
-> No, I don't like it I don't like it at all. All a signature on a UserID is
-> to represent is authentication of ownership. I do *not* want my keys
-> cluttered up with a bunch of meaningless comments from 3rd parties.

 In that case, all comments which may be necessary e.g. in the context of
CAs (there's a whole bunch of them, e.g. 'may sign for company XY', 'member
of CA UVW' or 'ID checked via postal agency' (possible in Germany)) would
need to go into the User-ID itself. That may not be feasible. While your
point is well taken, there are also meaningful comments for which a comment
field in the signature packet would be a highly sensible place.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873

Date: Fri, 20 Mar 1998 11:56:57 -0800
To: Lindsay Mathieson <[email-masked]>, Jon Callas <[email-masked]>, IETF OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Iterated-Salted S2Ks
Sender: [email-masked]

Previous discussion of this decided that we wanted to either simplify the
iterated-salted S2K or drop it. In the current draft, I simplified by
changing the 8-bit coded number to a 32-bit number.

It sounds to me like people are willing to live with the original
description. Is this correct? I'm perfectly willing to change it back. Make
your voice heard if you care.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 19 Mar 1998 10:30:18 -0500
From: [email-masked]
To: Werner Koch <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Content-MD5: O6W/65VwShT3LJoGtyCycw==
Content-MD5-Origin: gizmo.lut.ac.uk
Sender: [email-masked]

On Thu, 19 Mar 1998, Werner Koch wrote:

> GNUPG uses Blowfish in standard CFB mode (without the PGP 2 byte

2 Byte???  There is a 10 byte header.  I'll have to see the code...

> feedback) and a 160 bit key.  A 128 bit version is also available
> and this still uses standard mode - if there is any other OpenPGP app
> which uses Blowfish, I maybe able to switch to PGP CFB mode for this
> 128 bit key version.

> By the way, how can I get an assigned number for my (standard) Blowfish
> implementation?

Blowfish, 128 bit key, 16 rounds is defined as cipher number 4.

> Werner                      (finger [email-masked] for info about GnuPG)

The finger has a URL that points to one that says I need to update my
bookmark.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 19 Mar 1998 22:55:10 +0100 (MET)
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Reply-to: Salvo Salasio <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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

tzeruch asks:
> Is the plaintext put through the cfb system, i.e. xored with the iv?
>
> (I assume I would discard any key material, but not the iv).
>
> Or is it intended to be completely unencrypted?

Hal Finney answered as if this question were about the use of CFB for
Blowfish, but tzeruch asked about the "plaintext" encryption algorithm,
algorithm 0 of Section 9.2.  It's a good question, because Section 5.7
says that any selected symmetric algorithm is stuffed through the rather
arcane CFB variant.

I think the answer must depend on why we want symmetric algorithm 0.
At some level it might be a security risk to have it there: if an
attacker can get the naive user's configuration file to specify that
algorithm as the default encryption algorithm and the CFB/IV system
were used as tzeruch and Section 5.7 suggest, there would be no easy
way for the user casually looking at an encrypted file to know that
it was unprotected.  This would also be true if an Algorithm 0 packet
were left clear (i.e. without random IV and CFB) but compressed.

Is Algorithm 0 specified for debugging?  If so, do we need to say it
MUST NOT be enabled outside of debugging environments?

The same question still holds for Algorithm 5, ROT-N: should we
make that "MUST NOT be enabled outside of debugging environments"?

	Salvo Salasio

Date: Thu, 19 Mar 1998 14:26:47 -0800
To: [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

>>On Tue, 10 Mar 1998, Jack Repenning wrote:
>
>>The end goal is (I think) the ability to
>>-> express the meaning of your signature ...

We can stop discussing this now ... I wasn't proposing it, merely trying to
explain someone else's proposal - but it turns out, I was completely wrong,
anyway!

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 19 Mar 98 16:21:30 -0500
To: [email-masked] (Christopher Creutzig)
Cc: Jack Repenning <[email-masked]>, [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

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

In <[email-masked]>, on 03/19/98

   at 08:25 PM, [email-masked] (Christopher Creutzig) said:

>On Tue, 10 Mar 1998, Jack Repenning wrote:

>-> to") the key owner doing so.  The end goal is (I think) the ability to
>-> express the meaning of your signature ... "I certify this key for
>business -> purposes, but I wouldn't trust this blighter with the
>personal secrets of a -> snail."  

> I think the comment packet would be OK for this, it would just need to
>be allowed in signatures in general, not just self-signatures. IMHO that
>would be a good thing[tm]. Of course, user interfaces would need to
>clearly state that this is *not* a comment the key owner set.

No, I don't like it I don't like it at all. All a signature on a UserID is
to represent is authentication of ownership. I do *not* want my keys
cluttered up with a bunch of meaningless comments from 3rd parties.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Bill Gates' worst nightmare!

To: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: UserID Revocation
Date: Thu, 19 Mar 1998 20:34:12 +0100 (MET)
Reply-TO: [email-masked] (Christopher Creutzig)
Sender: [email-masked]

On 11 Mar 1998, Lutz Donnerhacke wrote:

-> >think that there are some more pressing issues like the ability to revoke
-> >userID's if modifying the format is still open game.
-> 
-> No. It's already solved an implemented since about than a year.

 I haven't seen it in the spec yet. Your reference implementation does not
define anything, it *only* implements the spec and serves as something
people can check their programs for interoperability with. It had been
solved with the old key format, though...

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
<HTML><META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
function X() {var Text = "HTML is not acceptable for use in mail " +
"or usenet so your browser will stop."; alert(Text); parent.close();};
</SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>

CC: [email-masked]
To: Jack Repenning <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Proposal for new Attribute packet
Date: Thu, 19 Mar 1998 20:25:42 +0100 (MET)
Sender: [email-masked]

On Tue, 10 Mar 1998, Jack Repenning wrote:

-> to") the key owner doing so.  The end goal is (I think) the ability to
-> express the meaning of your signature ... "I certify this key for business
-> purposes, but I wouldn't trust this blighter with the personal secrets of a
-> snail."  

 I think the comment packet would be OK for this, it would just need to be
allowed in signatures in general, not just self-signatures. IMHO that would
be a good thing[tm]. Of course, user interfaces would need to clearly state
that this is *not* a comment the key owner set.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
<HTML><META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
function X() {var Text = "HTML is not acceptable for use in mail " +
"or usenet so your browser will stop."; alert(Text); parent.close();};
</SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>

CC: [email-masked]
To: Hal Finney <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Algorithm questions
Date: Thu, 19 Mar 1998 20:06:19 +0100 (MET)
Sender: [email-masked]

On Tue, 10 Mar 1998, Hal Finney wrote:

-> According to this reference, k is simply a random number mod p-1.
-> Bruce states that it needs to be relatively prime to p-1, but this was
-> not in the original paper and I don't think it is necessary.

 It's only necessary for ElGamal signatures. The spec uses DSA signatures
and ElGamal encryption, so you're probably right.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
<HTML><META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
function X() {var Text = "HTML is not acceptable for use in mail " +
"or usenet so your browser will stop."; alert(Text); parent.close();};
</SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>

Date: Thu, 19 Mar 1998 10:41:06 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: The spec is unconventional
Sender: [email-masked]

> There is one mention (in the first paragraph of 5.3) of  a Conventional
> Encrypted Session Key packet.
>
> But otherwise, the old 2.6.2 "pgp -c" type encryption is left unaddressed.

We don't discuss command line arguments in this spec.  The old style
conventional encryption is a bare Symmetrically Encrypted Data Packet
(section 5.7):

   The conventional cipher used may be specified in an Encrypted Session
   Key or Conventional Encrypted Session Key packet which precedes the
   Symmetrically Encrypted Data Packet.  In that case, the cipher
   algorithm octet is prepended to the session key before it is encrypted.
   If no packets of these types precede the encrypted data, the IDEA
   algorithm is used with the session key calculated as the MD5 hash of
   the passphrase.

The last sentence is what is used for the old pgp -c case.

To do -c encryption with something other than IDEA and simple hashing
you use a Conventional ESK packet follwed by the Symmetrically Encrypted
packet.

Hal Finney

From: Uri Blumenthal <[email-masked]>
Subject: Re: And on SAFER SK/128...
To: [email-masked]
Date: Thu, 19 Mar 1998 11:49:17 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

> Anyone have a link for DES/SK source?

Being written as we speak. But no completion date is set yet, sorry.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Thu, 19 Mar 1998 11:38:03 -0500
From: [email-masked]
To: [email-masked]
Subject: The spec is unconventional
Sender: [email-masked]

There is one mention (in the first paragraph of 5.3) of  a Conventional
Encrypted Session Key packet.

But otherwise, the old 2.6.2 "pgp -c" type encryption is left unaddressed.

I haven't implemented anything since 5.0 doesn't either.  The routines are
there, but I don't have a shell that implements something that would
create a conventionally encrypted message.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 19 Mar 1998 17:10:44 +0100
From: Werner Koch <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:

> 2 Byte???  There is a 10 byte header.  I'll have to see the code...

The 16 bit shift operation inseatd of the normal 64 bit one.

> Blowfish, 128 bit key, 16 rounds is defined as cipher number 4.

I know, but I'm taking about a 160 bit key version :-)

-- 
Werner                      (finger [email-masked] for info about GnuPG)

Date: Thu, 19 Mar 1998 10:30:18 -0500
From: [email-masked]
To: Werner Koch <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

On Thu, 19 Mar 1998, Werner Koch wrote:

> GNUPG uses Blowfish in standard CFB mode (without the PGP 2 byte

2 Byte???  There is a 10 byte header.  I'll have to see the code...

> feedback) and a 160 bit key.  A 128 bit version is also available
> and this still uses standard mode - if there is any other OpenPGP app
> which uses Blowfish, I maybe able to switch to PGP CFB mode for this
> 128 bit key version.

> By the way, how can I get an assigned number for my (standard) Blowfish
> implementation?

Blowfish, 128 bit key, 16 rounds is defined as cipher number 4.

> Werner                      (finger [email-masked] for info about GnuPG)

The finger has a URL that points to one that says I need to update my
bookmark.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 19 Mar 1998 10:12:12 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

On Wed, 18 Mar 1998, Hal Finney wrote:

> > Is the plaintext put through the cfb system, i.e. xored with the iv?
> >
> > (I assume I would discard any key material, but not the iv).
> >
> > Or is it intended to be completely unencrypted?
> 
> I don't follow you here.  In CFB mode, the ciphertext is fed back through
> the cipher (Blowfish in this case), and the result of that is xored with
> the plaintext to produce the next block of ciphertext.

You misunderstand my question.

Type 0 is indicated as a "plaintext" conventional algorithm.  But is says
nothing about the rest of the CFB and key stuff which applies to every
other cipher type.

It can mean one of the following, or even something else:

1. Although there is a PGP PK header, the data where the conventional
encryption packet should be will not be a conventional encryption packet,
but a literal, or other unencrypted plain text.

2. There is a conventional encryption packet, but no IV is present (i.e.
the first 10 bytes for the reset), and it merely encapsulates literal data
which requires no further processing.  Or the 10 bytes are present and
ignored, with the plaintext data starting after the cfbreset.

3. Everything is handled like every other cipher, with a 10 byte iv prefix
(last byte pair as a check), with a reset, and using the IV to XOR things,
the only difference is where the CAST, IDEA, 3DES, etc. transform is,
nothing happens.  The key material is provided for the other ciphers is
not used in any way.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 19 Mar 1998 09:41:50 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Hal Finney <[email-masked]> writes:

> I am not aware of any other implementations of Blowfish within the
> OpenPGP framework.

GNUPG uses Blowfish in standard CFB mode (without the PGP 2 byte
feedback) and a 160 bit key.  A 128 bit version is also available
and this still uses standard mode - if there is any other OpenPGP app
which uses Blowfish, I maybe able to switch to PGP CFB mode for this
128 bit key version.

By the way, how can I get an assigned number for my (standard) Blowfish
implementation?

-- 
Werner                      (finger [email-masked] for info about GnuPG)

Date: Wed, 18 Mar 1998 20:29:23 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: S/MIME winz
Sender: [email-masked]

>* A. Padgett Peterson P.E. Information Security wrote:
>>compliant. Will say that the crypto (other than being intercommunicating)
>>is really the least part - it is the directory and key management structure
>>that will make or break. At the moment it is the only one I have seen that 
>>is independant of a mail structure and provides for diversified management.
>>(opposing views welcome).

At 07:49 AM 3/11/98 GMT, Lutz Donnerhacke wrote:
>X.509 (aka S/MIME) is a strong hierachical PKI. PGP has a complete
>distributed PKI.

X.509 is NOT a hierarchical PKI.
It's a syntax for one key certifying another key.
It doesn't provide the infrastructure or restrict the relationships.
You can build hierarchies with it, or with PGP, and you can
build non-hierarchical webs of trust with it or with PGP.

Unlike PGP, which has a complex key structure that
encourages each key to have multiple signatures,
an X.509 cert only has one signature on it,
so multiple signatures require multiple X.509 records.
That's more work for a directory structure to manage;
it's just a tuple, and fits fine in a relational database structure.
You just have to make sure the directory APIs can handle
multiple records in response to a query.
(Does anybody know how LDAP feels about this?)

IMHO, any directory system that can't handle collisions is
nearly unusable anyway, because it requires complex validation
of every record stored in it to avoid them,
and even then you still have companies with multiple
employees named Joe Johnson that you need to differentiate between.

Some of X.509's early advocates, like Steve Kent,
strongly believe in and push the hierarchical model with certs
indicating True Names, but the standard itself doesn't require it,
and later X.509 versions don't force you to use X.500 names.

It may be that one of the most important things we can do
is create a good web-of-trust management tool that's
easily readable by S/MIME programs, so the S/MIME users get
off on the right foot and don't build hierarchies into the system.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 19 Mar 1998 01:31:25 +0000
To: "PowerMail announcements" <[email-masked]>
From: CTM Info <[email-masked]>
Subject: [ANN] PowerMail 2.0b3 available
Reply-To: "PowerMail announcements" <[email-masked]>
Sender: [email-masked]

Greetings,

Thank you for your on-going interest in PowerMail. With the help of the
numerous testers who wrote in their comments and opinions, we are pleased
to release the 2.0b3 seed just two (hard) weeks after our initial public
beta; it is available now from:

           http://powermail.simplenet.com/PowerMail_2.0_public_beta_3.hqx

Please try this version out and send your comments and impressions to
[email-masked]. For those who kindly pre-ordered (see our special
20% discount offer below), we thank you and apologize for not having
answered each one of you *yet* - we'll be contacting you soon you soon.

This release is mostly feature complete, and will expire on April 18th,
1998. Although CTM has made all due efforts in order to make your
evaluation of this program a pleasure, as with any pre-release version of
software we encourage you to use common sense with respect to the
integrity of your files (see the section below "Upgrading from a previous
version of PowerMail")

NEW FEATURES:
- New address book design - initially planned for 2.1 - partially
included by popular demand. It features groups, comments, sorting,
editing and type-finding. Import/Export is currently done by drag and drop
- Multiple signatures are now in place. As is customary, new signatures
are created with a"-- " [CR] line at the beginning of each signature
- Hierarchical folders are now in ! - read the "known issues" below
- Colored priority labels for either subject or entire message entry that
can be assigned manually or using a mail action
- A "redirect" button makes messages look as if they came from the
original sender
- A "Connect Again" button lets you check your mail without going through
a dialog; also added optional mail checking/sending on startup/quit
- Support for APOP
- If the "Systematically retrieve all messages" checkbox is on, we can
speak to POP3 servers which do not know the "UIDL" command
- New IMAP Options dialog offers a proper "Root path" dialog to filter
out all unwanted hierarchies.
- IMAP folders starting with "." are omitted
- IMAP passwords containing spaces or slashes are now accepted
- Selected text gets entered as a default search string
- If an IMAP server takes too much time to disconnect, holding the Option
key when clicking on Quit will ignore the server's response
- When the cursor is in the message body, the Enter key now acts as "Send"

BUG FIXES:
- Accelerated over 800% the importing and VTwin indexing of large Eudora
mailbox files
- Both installer and application are fully supported on 68k Macintosh models
- Fixed "-8739" error in some instances of Japanese text
- Date and time of sent and received messages are no longer 8 hours ahead
or behind
- Replying, redirecting or forwarding a Roman message written in Kanji is
correctly handled
- Fixed behavior and appearance on 1 bit black/white screens
- One can no longer deduce the length of a password by looking at the
account setup dialog
- Sending a message during another SMTP operation is supported;
- Eliminated the "Send now" option; the "Send" icon now applies to
selected messages
- Got rid of not-yet-implemented search options
- If an incorrect IMAP password is specified, the connection is not left
hanging
- When sending messages "when next connected", waiting messages were sent
even if they were trashed! - and if the trash was been emptied while
containing waiting messages, there was a crash
- When the application is in the foreground, the alert that notifies of a
new message allows background processing

KNOWN ISSUES IN 2.0B3:
- Do not attempt to drop a hierarchical folder onto a daughter sub-folder
*SINCE YOU WOULD LOSE ACCESS TO MESSAGES IN BOTH FOLDERS*
- The right border of a message window is not painted correctly
- Address book: Deleting groups does not work, cosmetic problems in
updating the list when moving items in and out of groups, speed issue
when finding, sorting, etc...
- Issue with updating the window list when application has been in
background Issue with updating the message list when changing the Labels
to apply to entiere line or subject (refresh problem)
- Addresses are either in or out of a group, so entries need to be
duplicated if you want them to appear in several containers
you can have the same address more than once now
- There may be a problem with enclosures in messages from Exchange
clients/Outlook for Windows
- The speed at which large enclosures get sent needs much optimization,
especially on fast connections (10BaseT or higher)
- Be cautious when using the Disconnect menu item

MORE TO DO FOR 2.0:
- Properly insert "by way of" when redirecting
- Import/Export of address book as text files
- Screen update issue when drag-selecting 2-byte text in mail browser content
- Implement function keys (F1-F4, help, etc...) as well as command-arrow
text editing shortcuts
- The "Trash" button will apply to the current message
- Improve other SMTP-related items
- Tabbing from the "mailer" fields to the text body of outgoing message
will no longer require command-tab as it does now (tab will do)
... and a few dozens other points

LEFT OVER FOR OUR 2.1 RELEASE:
- Suggest email recipients as addresses are being typed in
- Collapse the text body/opening the folder list as a separate window.
- sort through over 200 suggestions from users...
- ...and a offer peek at our Rhapsody/fully native Yellow box version !

UPGRADING FROM A PREVIOUS VERSION OF POWERMAIL (Public Beta 1)
As some file formats have changed, we strongly advise that you start over
a new set of PowerMail files after installing PowerMail 2.0b3. If you
wish to save addresses before deleting the public beta,drag them from the
address book to a Finder Folder, and later drag the clipping files back
into the new address book in beta 3.

If you wish to save a previously created Message Database, back it up and
after installing PowerMail b3 replace the newly installed "Message
Database" by your old copy.

In either case you should probably reenter your account information.

//What's next ?:

Would you like to be automatically notified about significant future
milestones in the life of PowerMail? Then send an e-mail to
"[email-masked]" with the subject "subscribe powermail-announce". We
promise not to flood you with mail or give your address to anyone else.
Of course, you can stop receiving notifications at any time by sending a
message to the same address with the subject "unsubscribe powermail-announce"

Thank you for taking the time to try out PowerMail. We hope that you will
enjoy using our program and we welcome your feedback.

The CTM PowerMail team
[email-masked]

//////////////////////////////////////////////////////////////////////////
//  Limited offer: save over 20% on the final version of PowerMail 2.0 ! //
//////////////////////////////////////////////////////////////////////////

If you decide, after trying out this public beta, that PowerMail is on
the right track and might over time become your choice in e-mail clients,
you can pre-order your copy or site-license during *until March
31st,1998* starting at US$ 39 per copy, decreasing with volume (instead
of US$ 49 per user). Drop us a line at [email-masked] and let us know
you care !

//Reminder: What is PowerMail:

PowerMail is an e-mail client for MacOS that combines powerful features
with a clear, intuitive, and easy-to-use interface. PowerMail supports
multiple e-mail accounts, both POP and IMAP, has advanced indexing and
searching capabilities, and supports multiple languages and script systems.

PowerMail 2.0 is being developed by a dedicated team of five Macintosh
software developers who are determined to meet the needs of demanding
users of electronic mail. We think that an e-mail client can be powerful
and full-featured and still have an elegant interface and be easy to use.
We have implemented the features commonly found in leading e-mail
applications (multiple accounts, filtering, encoding, enclosure
management) while offering a unique focus on the following areas:

Mobile usage: 
* PowerMail's IMAP4 functionality lets users display and manipulate the
contents of server-based mailboxes without having to download all
messages. It is a convenient, standards-based successor to LAN e-mail
systems such as QuickMail or Microsoft/Quarterdeck/StarNine mail.

* For users of the widespread POP3 services, we have added the ability to
minimize PPP connection durations by converting and indexing messages
once off line, in addition to deferring periodic mail checking until a
PPP connection is active.

Find by content:
* By including support for Apple's Information Access Toolkit, PowerMail
offers unparalleled speed in searching archived mail message content as
well as relevance-ranked searches.

* PowerMail's ability to import and export messages--notably from Eudora
mailboxes--makes it easy to start enjoying the benefits of find-by-content
using your existing mail archives. If you use Claris Emailer, we
recommend the Export-Eudora script available from
ftp://ftp.fogcity.com/pub/Emailer/2.0/ImportExport3.1.hqx to create files
which PowerMail can import. 

World-ready:
* Because the Internet connects users of many languages, we have focused
on meeting the needs of simple and complex languages alike, and allow for
messages to be written and read in Japanese, Korean, Chinese (simplified
and traditional), Arabic, Persian, Cyrillic (Bulgarian, Russian, and
Ukrainian), Hindi, Sanskrit, Gujarati, Marathi, Punjabi, and Nepali text
(using any of three Indian writing systems: Devanagari, Gujarati, and
Gurmukhi) in addition to all accented Western languages (English, French,
German, Italian, Swedish, Danish, Norwegian, Dutch, Spanish, Portuguese,
Danish and others).

WHAT YOU NEED TO RUN POWERMAIL 2.0
PowerMail 2.0 requires a PowerMacintosh or 68K Macintosh running System
7.5.5 or later with OpenTransport. PowerMail requires the Text Encoding
Converter version 1.3. or later and Internet Config (these are installed
by PowerMail).

In addition, you need either a network or dial-up TCP/IP connection to
the internet and an internet e-mail account, either POP3 (Post Office
Protocol) or IMAP4 (Internet Mail Access Protocol). You will also need
the account information from your network administrator or Internet
Service Provider in order to configure PowerMail.

Date: Wed, 18 Mar 1998 16:32:08 -0800
To: Jon Callas <[email-masked]>, Ian Brown <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Armour
Cc: Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

My apologies for that last message.

Sometime yesterday, a number of old messages of mine from November decided
to send themselves again. 

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 18 Mar 1998 16:24:53 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: HAVAL - But which variant (and what OID?)
Sender: [email-masked]

I am not very familiar with HAVAL.  For consistency with our other hash
functions, it might be reasonable to choose a hash size of 160 bits,
like SHA and RIPEMD.  On the other hand, there is a need for larger
hashes to support larger DSA keys.  I don't know if HAVAL is the best
choice for that.

I can't find an OID assignment for HAVAL.  Peter Gutmann has a long list
of known security related OIDs in his dumpasn1.cfg file, but it does not
list HAVAL.  You might direct email to the author and ask if he knows
of an OID assignment.  I suspect we would need a family of OIDs, one for
each length/passes combination.

There is probably no point in defining new hash algorithm identifiers in
the spec unless we are able to define an OID for them.  Both values are
needed for an implementation.

Hal

Date: Wed, 18 Mar 1998 19:19:39 -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: And on SAFER SK/128...
Sender: [email-masked]

On Wed, 18 Mar 1998 [email-masked] wrote:

> * void Safer_Expand_Userkey(safer_block_t userkey_1,
> *                           safer_block_t userkey_2,
> *                           unsigned int nof_rounds,
> *                           int strengthened,
> *                           safer_key_t key)
> 
> I assume nof_rounds will be SAFER_MAX_NOF_ROUNDS?
> (and sk implies setting strengthened, and 128 implies using both userkey_X
> values).

With that assumption, I enclose the latest test message
(aren't shared libraries wonderful?)

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 18:48:14 -0500
From: [email-masked]
To: [email-masked]
Subject: And on SAFER SK/128...
Sender: [email-masked]

* void Safer_Expand_Userkey(safer_block_t userkey_1,
*                           safer_block_t userkey_2,
*                           unsigned int nof_rounds,
*                           int strengthened,
*                           safer_key_t key)

I assume nof_rounds will be SAFER_MAX_NOF_ROUNDS?
(and sk implies setting strengthened, and 128 implies using both userkey_X
values).

And I am anxiously awaiting the ROT-N description.

Anyone have a link for DES/SK source?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 15:26:26 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

>From [email-masked]:
> I am using the SSLeay call as:
>
>     BF_set_key(&bfkey, 16, key);
>
> key is the key material from the iterated salted hash, 16 is the length
> (i.e. 128 bits), then the BF_cfb64_encrypt call with the wierd reset.
>
> It works against itself - anyone have a test case?  Or do I have the first
> implmentation?

I am not aware of any other implementations of Blowfish within the
OpenPGP framework.

> Is the plaintext put through the cfb system, i.e. xored with the iv?
>
> (I assume I would discard any key material, but not the iv).
>
> Or is it intended to be completely unencrypted?

I don't follow you here.  In CFB mode, the ciphertext is fed back through
the cipher (Blowfish in this case), and the result of that is xored with
the plaintext to produce the next block of ciphertext.

For the first block, the IV is encrypted with the cipher, and the output
is xored with the first block of plaintext to produce the first block
of ciphertext.

PGP's implementation uses an IV of all zeros, and prepends ten bytes
of random data (such that bytes 9 and 10 match bytes 7 and 8) to the
plaintext.  It does a CFB "resync" after encrypting those ten bytes.

Let me explain that step by step.

1. The feedback register (FR) is set to the IV, which is all zeros.
2. FR is encrypted to produce FRE (FR Encrypted).  This will be the
   encryption of an all-zero value.
3. FRE is xored with the first 8 bytes of random data which have been
   prepended to the plaintext to produce C1-C8, the first 8 bytes of
   ciphertext.
4. FR is loaded with C1-C8.
5. FR is encrypted to produce FRE, the encryption of the first 8 bytes of
   ciphertext.
6. The left two bytes of FRE get xored with the next two bytes of data
   which were prepended to the plaintext.  This produces C9-C10, the next
   two bytes of ciphertext.
7. (The resync step) FR is loaded with C3-C10.
8. FR is encrypted to produce FRE.
9. FRE is xored with the first 8 bytes of the given plaintext, now that we
   have finished encrypting the 10 bytes of prepended data.  This produces
   C11-C18, the next 8 bytes of ciphertext.
10. FR is loaded with C11-C18
11. FR is encrypted to produce FRE.
12. FRE is xored with the next 8 bytes of plaintext, to produce the next
    8 bytes of ciphertext.  These are loaded into FR and the process is
    repeated until the plaintext is used up.

Hopefully this will help you verify that your code is following this logic.

Hal Finney

Date: Wed, 18 Mar 1998 17:52:52 -0500
From: [email-masked]
To: [email-masked]
Subject: HAVAL - But which variant (and what OID?)
Sender: [email-masked]

>From one of the HAVAL files...

 *  havalapp.h:  specifies the following three constants needed to
 *               compile the HAVAL hashing library:
 *                     LITTLE_ENDIAN, PASS and FPTLEN
 *
 *   PASS     define the number of passes        (3, 4, or 5)
 *   FPTLEN   define the length of a fingerprint (128, 160, 192, 224 or 256)

The FPTLEN is in bits, so 16, 20, 24, 28, or 32 byte hash output is
possible.

And since pgp uses the DER stuff, what bytes do I prepend?

And is there an implementation without copyright or patent problems?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 17:36:13 -0500
From: [email-masked]
To: [email-masked]
Subject: Plaintext, symmertric algorithm 0 (9.2)?
Sender: [email-masked]

Is the plaintext put through the cfb system, i.e. xored with the iv?

(I assume I would discard any key material, but not the iv).

Or is it intended to be completely unencrypted?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 13:53:22 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-op-formats-01.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

In the PGP source code, the conversion from the byte value to a count
is done by one line.  This code is either by Colin Plumb or Derek Atkins
and predates the formation of PGP, Inc.

#define EXPBIAS	6
	return ((PGPUInt32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

Hal

Date: Wed, 18 Mar 1998 16:48:25 -0500
From: [email-masked]
To: [email-masked]
Subject: Blowfish?  How do I set the key?
Sender: [email-masked]

I am using the SSLeay call as:

    BF_set_key(&bfkey, 16, key);

key is the key material from the iterated salted hash, 16 is the length
(i.e. 128 bits), then the BF_cfb64_encrypt call with the wierd reset.

It works against itself - anyone have a test case?  Or do I have the first
implmentation?

Attached is a README encrypted with (DH(BF)DSA(SHA1))

And a url bibliography would help - I could implement the rest of the
algorithm list except I can't easily find most of them.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 16:21:08 -0500
From: [email-masked]
To: [email-masked]
Subject: ciphercopia 0.98 - beta release of SSLeay based PGP library
Sender: [email-masked]

I fixed some things making it easier to compile on FreeBSD (I use Linux),
and broke out all the routines into individual files archived into
libpgp.a (and .so for linux).  There are also a number of other goodies
including a pgp2 and pgp5 CLI program I use it to test interoperability by
running against the PGP Inc. implementations.  You will need SSLeay and
Eric Young's libcast, 0.82 or better (contact me for a 64bit safe version
for DEC alphas).

It should be on www.cryptography.org soon.  Contact me if you want it
earler and state your citizenship info and such so it will be ok for me to
export it to you.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 18 Mar 1998 13:01:26 -0800
To: Ian Brown <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Armour
Cc: Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:37 PM 11/15/97 +0000, Ian Brown wrote:
   Jon Callas wrote:
   
   > From PRZ's first documents, he labeled
   > armoring as an integral piece of PGP. It's too useful as a generalized
   > mechanism for holding an object (data, keys, etc.) without having to
worry
   > about what odd thing something will do to your binary.
   
   I'm not sure what you mean. Do you mean safely holding an object while
   it is transmitted by mail?
   
   Armour was a very necessary part of PGP. But now we have MIME, which is
   meant for the same purpose - safely transmitting binary data across
   7-bit or less mail systems.
   
I mean safely holding an object in any system that can't handle raw binary.
PGP objects (messages, keys, files, etc.) are constructed so as to not have
a lot of known plaintext in them. Whatever your opinion is about this, it's
the way PGP was designed. Phil has explained this to me in detail. This is
also the rationale behind such things as that a V3 private key encrypts the
body of the MPIs but not their length -- the length is known plaintext. But
I digress.

There are a number of places where having an armored binary object is
useful. Mail is one. Network transport is another. Any place where the
receiving program is a C program is a third (anyone who is careless enough
to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
to find -- I know, I've done it).

Most of the present key servers, from the HTTP ones to the LDAP ones
transport their keys in armored form. The idea that the key server has to
have a MIME handler in it seems silly.

PGP objects are not just mail messages. Any data-thingie that you want to
encrypt can be put into PGP format, and if you don't trust raw binary,
armor works. Let me say this again, OP is *NOT* an email-encryption
standard, it is a data-object encryption standard (I'm quoting our esteemed
area director here). Of course, the most obvious use of a data-object
encryption standard is to send secure mail, but that is among the uses of
OP, not the sole one.

There are people who want to put PGP, especially OP, especially a
minimalistic OP into a number of limited environments -- pagers, PDAs,
smart cards (which are still a few years off, as they are *really*
limited). These people need to have a minimal set of things to implement.
These are, of course, all the MUST features. This is also why other
features like the hash preference are there -- there's no other way an
encrypted pager system can advertise that it has only implemented SHA-1.

I think that it is wrong to make MIME a MUST feature. It is obvious to me
that it is a SHOULD feature, but it is wrong to cut out small developers by
adding complexity and code size.

I'll add as a related note that making MIME a requirement actually helps
PGP Inc. Our toolkit does all the MIME/armor/compression handling
transparently for the caller. We'll just shrug. I feel compelled myself,
though, as editor of this spec to argue for a simple format spec, and then
layer MIME handling on top of it for the benefit of the small developer.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 18 Mar 1998 16:03:12 -0500
From: [email-masked]
To: Lindsay Mathieson <[email-masked]>
cc: Jon Callas <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: draft-ietf-op-formats-01.txt
Sender: [email-masked]

On Sat, 14 Mar 1998, Lindsay Mathieson wrote:

> >String-to-Keys
> > So I reserved the old tag (0x03) as obsolete, and modified the
> >definition to have a new tag and use a 32-bit integer.
> 
> I feel I must object to this. All it does is create a new (unneccessary)
> format. Anyone who wants to maintain compatibility with PGP (which will be
> most) will still have to support the 8 bit floating point format. The
> change just complicates things, not simplifies.
> 
> And when all's said and done, what is so complicated about it ? sure its a
> finicky irritating design choice but once implemented you can forget about
> it. I can post source code if anyone finds it that difficult.

I agree.  Currently the floating point conversion is four lines.  I don't
know how good my compiler is, but it should compile down to fewer
instructions than the error checking to not support type 3 salt.

    i = *(*bp)++; /* get the number of iterations byte */
    j = i >> 4;
    i = (i & 15) + 16;
    i <<= j + 6;

Date: Wed, 18 Mar 1998 12:14:28 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Fwd: 41st IETF-LOS ANGELES: OPENPGP
Sender: [email-masked]

>Date: Mon, 16 Mar 1998 17:26:56 -0500
>To: "John  W. Noerenberg" <jwn2>
>From: Marcia Beaulieu <[email-masked]>
>Subject: 41st IETF-LOS ANGELES: OPENPGP
>Cc: "Jeffrey I. Schiller" <[email-masked]>
>Mime-Version: 1.0
>
>This is to confirm one session for OPENPGP as follows:
>
>	Wednesday, April 1 at 1300-1500 (opposite ipp, schema, aatn, mboned,
>		vrrp, pint)
>
john  w noerenberg, ii
[email-masked]
  ------------------------------------------------------------------
  "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said.
 "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!"
  -- John Irving, A Prayer for Owen Meany, 1989
  ------------------------------------------------------------------

Date: Sun, 15 Mar 1998 18:36:08 -0500
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-01.txt
Reply-to: Salvo Salasio <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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

Good job on draft-ietf-openpgp-formats-01.txt.  I've spent the
weekend coding up a prototype reference implementation of the
basic formatting parts in order to parse and identify the
different packets of a PGP message.  It's been sent to the
coderpunks mailing list, in case it's of any use to others.
It does a few things that are hard in some versions of PGP,
such as telling all the recipients of an encrypted message.

I ran across a few small things that should be addressed in
the next version of the draft.

1. In the CRC section 6.1 there should be a typedef for crc24.
2. In the CRC section 6.1 CRC_INIT should be CRC24_INIT in the body.
3. The example Armored Message in 6.6 has a typo in the plaintext:
   it's missing the word "be".
4. Section 5.11 "User ID" and section 4.3 "Name" refer to the same
   kind of packet.  One shoul be fixed.
5. In section 9.2, I'm still not wild about the ROT-N transform.
   Humour is nice in general, but I prefer it in text rather than
   specification.  If a debugging mode is needed, perhaps it could
   be defined with a "MUST NOT" be implemented in a shipping version.
6. Section 6.5 has a typo in the Radix-64 example.  The last 6-bit
   quantity in the first example correctly shows the binary value
   as 111110, but incorrectly calls it 63 decimal.  It should be 62
   and translate to '+'.

	Salvo Salasio <[email-masked]>
	PGP Key ID 0xFFFFFFFF

Date: 15 Mar 1998 1:50:45 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: draft-ietf-op-formats-01.txt
To: Jon Callas <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>String-to-Keys
> So I reserved the old tag (0x03) as obsolete, and modified the
>definition to have a new tag and use a 32-bit integer.

I feel I must object to this. All it does is create a new (unneccessary)
format. Anyone who wants to maintain compatibility with PGP (which will be
most) will still have to support the 8 bit floating point format. The
change just complicates things, not simplifies.

And when all's said and done, what is so complicated about it ? sure its a
finicky irritating design choice but once implemented you can forget about
it. I can post source code if anyone finds it that difficult.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on March 15, 1998, in Win95 3.51
	http://www.blackpaw.com/

Date: Sat, 14 Mar 1998 08:58:21 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Hashed signature material
Sender: [email-masked]

> The new draft correctly states how to hash the user-id to make
> a signature, but it left out some padding data:
> Werner                      (finger [email-masked] for info about GnuPG)

Werner is correct.  In the case of V4 signature packets, 6 more bytes
are added at the end, for technical reasons to prevent some signature
aliasing attacks.  The contents are:

	byte 0 - Version of signature packet, in this case 4
	byte 1 - 0xff
	bytes 2-5 - Length of hashed data from sig packet (not including
		these last 6 bytes), bigendian

We added the hashing information to the draft at the final stages, and
it was an oversight on my part in not getting this information to Jon
correctly.

The information on V3 signature hashing is correct in the draft.

Hal Finney

Date: Sat, 14 Mar 1998 12:18:57 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Hashed signature material
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The new draft correctly states how to hash the user-id to make
a signature, but it left out some padding data:

            byte buf[6];
            size_t n;
            md_putc( digest, sig->pubkey_algo );
            md_putc( digest, sig->digest_algo );
            if( sig->hashed_data ) {
                n = (sig->hashed_data[0] << 8) | sig->hashed_data[1];
                md_write( digest, sig->hashed_data, n+2 );
                n += 6;
            }
            else
                n = 6;
            /* add some magic */
            buf[0] = sig->version;
            buf[1] = 0xff;
            buf[2] = n >> 24;
            buf[3] = n >> 16;
            buf[4] = n >>  8;
            buf[5] = n;
            md_write( digest, buf, 6 );
        }
        md_final( digest );

-- 
Werner                      (finger [email-masked] for info about GnuPG)

Date: Fri, 13 Mar 1998 12:20:10 -0800
To: Andrew Bromage <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: S/MIME wins
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Sender: [email-masked]

--PGPplugin/Eudora-5.0-31173890324-1322330867
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:05 AM +1100 3/7/98, Andrew Bromage wrote:
>
>Also ask yourself if anyone would go to the same effort over S/MIME as
>the PGPi group did with PGP 5.0 (with scanning and proofreading etc).
>This suggests that PGP/MIME may well be the only interoperable strong
>crypto system for your email available world-wide, which has to be a
>point in its favour.

Questions of how to support a particular technology around the world with
commercial ventures radically change the ground.  We see this over and over
again.  The IETF has been remarkably successful in avoiding the pitfalls in
this transition in other realms, our experience with http and html,
notwithstanding.

Crypto technology is new ground because of the intense political scrutiny
to which it is subjected.  The fact that PGP has already crossed many
international boundaries is a significant advantage in gaining acceptance.
It enables PGP to be less sensitive to pressures to compromise the quality
of technology.

The S/MIME group is to be applauded in their attempts to resist that same
pressure.

But both group's work on defining protocols is only the beginning.
Implementation, deployment, and acceptance will finally tell the tale.  The
end of the story is still years off, in my estimation.  It won't finally be
written until there is a certificate distribution system that works as well
as DNS has worked for the net up to today.

However, right now, I just want to get the keys right and establish that we
can reliably exchange signed and encrypted mail.  Then we can go on to
other, bigger things.

best,
john noerenberg
[email-masked]
  --------------------------------------------------------------------
  There is no illusion more dangerous than the belief that the
  progress of science is predictable.
  -- Freeman Dyson, "Six Cautionary Tales for Scientists", 1988
  --------------------------------------------------------------------

--PGPplugin/Eudora-5.0-31173890324-1322330867
Content-Type: application/pgp-signature

--PGPplugin/Eudora-5.0-31173890324-1322330867--

Date: Fri, 13 Mar 1998 09:30:07 -0800
To: "William H. Geiger III" <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: WG Meeting at LA??
Cc: [email-masked]
Sender: [email-masked]

At 7:08 AM -0500 3/12/98, William H. Geiger III wrote:
>
>Hi,
>
>I was just looking over the itinerary for the LA IETF and I did not find
>anything for the OpenPGP WG. Is this a mistake or is there not going to be
>a meeting??
>

I am late getting it scheduled, but I am attempting to get one on the
agenda.  No details yet from the Secretariat.
john  w noerenberg, ii
[email-masked]
  ------------------------------------------------------------------
  "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said.
 "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!"
  -- John Irving, A Prayer for Owen Meany, 1989
  ------------------------------------------------------------------

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-01.txt
Date: Fri, 13 Mar 1998 08:39:36 -0500
Sender: [email-masked]

--NextPart

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

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

Internet-Drafts are 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-formats-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-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-formats-01.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New and wonderful algorithms
Date: 13 Mar 1998 07:48:02 GMT
Organization: IKS GmbH Jena
Lines: 13
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Werner Koch wrote:
>Lutz Donnerhacke <[email-masked]> writes:
>> May be in OpenPGPv2 the current approach has one octet for all algorithms.
>
>  The scheme used by ssh v2 is extensible and does not need centralized
>algorithm number assignement (plain text stings).  What about using
>0xff, "[email-masked]" instead of 0x??.  Or if you care
>about space, add a new packet type to map those algorithm identifiers
>to some numbers from the private/experimental number space. 

We have a very limited schedule. Thnx to the editors (including mine) the ML
was not involved as expected. Such a major change would cause a lot of
trouble. Solving this would require about two month. We do not have this time.

Date: Thu, 12 Mar 1998 17:45:58 +0100
From: Werner Koch <[email-masked]>
To: Lutz Donnerhacke <[email-masked]>
Subject: Re: New and wonderful algorithms
Sender: [email-masked]

Lutz Donnerhacke <[email-masked]> writes:

> May be in OpenPGPv2 the current approach has one octet for all algorithms. EOT

  The scheme used by ssh v2 is extensible and does not need centralized
algorithm number assignement (plain text stings).  What about using
0xff, "[email-masked]" instead of 0x??.  Or if you care
about space, add a new packet type to map those algorithm identifiers
to some numbers from the private/experimental number space. 

-- 
Werner                      (finger [email-masked] for info about GnuPG)

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New and wonderful algorithms
Date: 12 Mar 1998 14:52:27 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* A. Padgett Peterson P.E. Information Security wrote:
>Guess what I am trying to say is that if you want to create a real standard,
>1) do not design capability *out*.
>2) provide maximum flexibility
>3) do not worry about what the extensions will be other than the ICD, just
>   provide for them

May be in OpenPGPv2 the current approach has one octet for all algorithms. EOT

Date: Thu, 12 Mar 1998 09:27:18 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: New and wonderful algorithms
To: [email-masked]
Sender: [email-masked]

-> Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is 
-> this enough ?

(I really ned to get off VAXMail & bein using a modern quoting reader
like Eudora...)

To me the answer is simple - make the algoritm list open-ended and 
extensible via plug-ins. Should not be very hard. Guess I am talking more 
about implimentation than standard though needs to be there as well. We
need to remove the ITAR blinders and think of what a standard should
be.

That way a basic product would include only the MUSTs. MAYs would be
"optional extras at slight additional cost".

May be heretical but since Dave demonstrated the "Enclyptor" at the CSI
show a few years ago have been convinced that the future is in the network
and user interfaces, not the algorithms. Buying public could care less
so long as it is Good Enough (C). Can see a future where the user buys/
downloads the main program from PGP and then goes to the Security Dynamics
(RSA) web page for the RSA plugin.

Guess what I am trying to say is that if you want to create a real standard,
1) do not design capability *out*.
2) provide maximum flexibility
3) do not worry about what the extensions will be other than the ICD, just
   provide for them

Above all, do not waste time on optional modules while creating the standard
"time is of the essence".
					Warmly,
						Padgett

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 12 Mar 98 07:25:26 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

This is a MIME encapsulated message

--==_00A1D_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/10/98 
   at 08:07 PM, Hal Finney <[email-masked]> said:

>William H. Geiger III, <[email-masked]>, writes:
>> Well if we are going to modify the userID field so that any binary data
>> can be used then I think that it is improtant that we add some type of
>> field identifyer so that the applications processing this data have some
>> idea of what they are dealing with.

>That's in there.  The format I proposed has a representation of the type
>of data, then the data itself.

>I did get a suggestion in private mail that rather than defining a type
>for "JPEG data in JFIF format", it would be better to define the type
>more generically as "Image data".  Then the body would have the image
>data format, in this case JFIF, and the formatted data.

>The advantage would be that if we added more image formats in the future
>we wouldn't have to define new top-level attribute types, and it would
>set a similar precedent for other kinds of attributes.

>Another point which has been raised in the past is the issue of number of
>bytes.  Is one byte enough for the type?  Should we use four bytes in the
>interests of future expandability?

I prefer the method of using a text type field for the userID's. This
allows the greatest flexibility for the type identifiers. We could have a
predefined list of ID types yet allow the ability of application specific
types to be added. Perhaps we could borrow from the MIME identifiers
(image/jpeg, audio/wav, ...ect). 

I don't like the generic type much as it requires 2 separate checks to
determine the data. In the case of image files it requires the PGP app to
have knowledge of the various image formats (my graphics program support 
~50 different formats). I invisioned a mechanism similar to how many MIME
mailers handle displaying the variety of MIME types by giving the user a
means of assigning viewers and defining new types.

I would like to see some of the most common userID types pre-defined.
Things like e-mail address, real name, url, ldap, ...ect. Perhaps an ID
class of types: ID/email, ID/realname, ID/url, ...ect.

The use of biometrics has been brought up. Type identifiers of image/jpeg
or audio/wav may not be enough. One may wish to use bio/face/image/jpeg or
bio/voiceprint/audio/wav. Perhaps those working with biometrics could jump
in as to wether they feel a specific "biometric" sub-type is needed.

I don't have any "set in stone" format for the type identifier but it
should be somthing that is flexible yet structured enough to be of use. I
would hate to see 5 different implementations using 5 different
identifiers all for the same data.

>> IMHO it is a little late in the game to be adding things to the spec. I
>> think that there are some more pressing issues like the ability to revoke
>> userID's if modifying the format is still open game.

>The direction I'd like to go on this would be to say that if a userid is
>not self-signed, it should not be used.  Then you could revoke a userid
>by revoking your self-signature.  This also solves the problems of people
>adding fake names to other people's keys.

>It has backwards compatibility problems, though, because a lot of old
>signatures are not self-signed.  You'd have to get people with old keys
>to self-sign all their (valid) userids.

I don't think that would be too big of an issue. My understanding is that
all 5.x versions of PGP do this already.

>A variant would be to accept unsigned userids, but if the userid has a
>REVOKED SELF SIGNATURE then that would mean that the keyholder is
>explicitly saying not to use this key anymore.

I think that you ment that a revoked self signature would mean not to use
the UserID anymore.

I have noticed that there is a real user "education" problem when it comes
to the meaning of signing of keys. This is not a OpenPGP format problem
but *is* somthing we should be aware of when designinging our user
interfaces.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: My best view from a Window was through OS/2.

--==_00A1D_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00A1D_===--

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 12 Mar 98 07:08:23 -0500
To: [email-masked]
Subject: WG Meeting at LA??
Sender: [email-masked]

This is a MIME encapsulated message

--==_00EE8_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I was just looking over the itinerary for the LA IETF and I did not find
anything for the OpenPGP WG. Is this a mistake or is there not going to be
a meeting??

Thanks

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Windows with bullet-proof glass.

--==_00EE8_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00EE8_===--

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 12 Mar 98 06:55:16 -0500
To: [email-masked]
Subject: OpenPGP and E-Mail Integration
Sender: [email-masked]

This is a MIME encapsulated message

--==_019CA_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I have put together and informal "checklist" for various features that a
OpenPGP integrated e-mail package should contain.

This checklist centers more on user<-->program interactions and basic
funtionality rather than the underlying formats.

If you are intrested in looking this over and/or contributing to the
checklist please drop me a note and I will e-mail you a copy.

I plan on using this checklist as a tool for reviewing the various PGP
applications currently available.

Thanks,

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: How do you spell relief? OS/2!

--==_019CA_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_019CA_===--

Date: Wed, 11 Mar 1998 17:48:28 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: draft-ietf-op-formats-01.txt
Sender: [email-masked]

It's been submitted.

There have been a flurry of changes, which I'll give a synopsis of. There
are also a number of remaining issues.

I've not done a lot with the algorithm issues. I added in more references
for Elgmal as per Hal and Tim Dierk's suggestions, but settling out those
are one of the major issues left before we can go to final call.
Fortunately, this isn't really a major issue. But I bring it up here, as I
think it needs discussion. I am planning to add a new section to the next
revision on algorithm issues, and we can therein discuss details of any
algorithm.

There are a few feature requests worth considering. In Washington and on
the list, we briefly discussed both non-text user ids, and user-id
revocations. I think that each is a good idea, and worth having in OpenPGP
V1.0. I think we just need to hammer out what the syntax is, and then they
can go in.

Here's a synopsis of changes, not guaranteed to be complete:

String-to-Keys
* In Washington, the consensus was that the iterated-salted S2K should be
either a MUST or eliminated (I suggested that we could make it be a MAY).
There was also a consensus that objections to it would go away if the 8-bit
floating point format were replaced by a 32-bit integer. The creators of
the feature argued convincingly that it is a useful thing for cutting down
on dictionary attacks, by raising the cost of computing an S2K to something
large. So I reserved the old tag (0x03) as obsolete, and modified the
definition to have a new tag and use a 32-bit integer.

Armor, cleartext signatures, etc.
* There are now two sections describing them, in the back of the document.
* There is a sample implementation in C of armor's CRC-24

Signatures, etc.
* The ARR subpacket is gone, replaced by placeholder.
* There are several new subpacket types: primary user id, policy URL, key
flags, and signer's user id. A formatting error at the top of page 15 makes
it easy to miss the latter two. I've already fixed this in the source, and
will get better formatting tools even if I have to write them myself.
* There is a new description of the critical flag.
* Signature types 0x11-0x13 are back in. These are persona, casual, and
positive certification signatures. In Washington, consensus was that if no
one was using them, they should go. RFC1991 and informal surveys said they
weren't being used, but I have been notified that they used in Europe. It
is possible that there are still some places in the document that say
there's only one type of certification, 0x10. If you find one, let me know
and I'll fix it.
* There is a new signature type, 0x1f. A number of people have observed
that preference and attribute subpackets end up in certification sigs, and
thus applying to a user id, rather than to the key proper. This new
signature type allows a certifier or keyholder to make statements about the
entire key.
* There is a new section describing how to form signatures.

Comment packets
* They are gone, as per discussion in Washington. I think that nearly all
reasonable uses of them can be implemented using standalone sigs and
notations.

Regular expressions
* There is a new section giving their syntax. This section is taken from
the "nearly public domain" implementation. See the document for details.

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 11 Mar 1998 08:14:55 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

At 07:53 AM 3/11/98 GMT, Lutz Donnerhacke wrote:
>* Hal Finney wrote:
>>I don't know what your "formal draft" says a zero certificate is.
>>There is nothing in the draft OpenPGP Message Format spec called a
>>"zero certificate".
>
>You know at as '0x02: Standalone signature.'

Or a name field saying "Unused - go look at the JPEG in the 
Notation/Comment/Attribute field"
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 11 Mar 1998 09:24:58 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Lutz Donnerhacke wrote:
>* Hal Finney wrote:
>>Lutz Donnerhacke, <[email-masked]>, writes:
>>> I see. Is is now allowed to add a zero certificate to the key as described
>>> in the formal draft? Zero certificates can hold the key expiration time and
>>> related entities. So defining a JPEG subtype in the signature allows to
>>> bind it even to the key, but this cannot be certified by others.
>>
>>I don't know what your "formal draft" says a zero certificate is.
>>There is nothing in the draft OpenPGP Message Format spec called a
>>"zero certificate".
>
>You know at as '0x02: Standalone signature.'

Forget this. Jon introduced a new type: '0x1f'

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 11 Mar 1998 09:24:32 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Bill Stewart wrote:
>At 05:25 PM 3/9/98 -0800, Hal Finney wrote:
>>This is a proposal for a new packet type, the "attribute packet,"
>>which is a generalization of the userid packet.  Attribute packets can
>>appear in a PGP key structure anywhere a userid packet could appear.
>
>Can you get by with the current "Notation Data" subpacket type,
>or is the 2-octet length field too limiting?

No. It should be used to set up other USER IDs! You might certify a picture
or voice snapshot instead of a name.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: UserID Revocation
Date: 11 Mar 1998 07:58:09 GMT
Organization: IKS GmbH Jena
Lines: 56
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>IMHO it is a little late in the game to be adding things to the spec. I
>think that there are some more pressing issues like the ability to revoke
>userID's if modifying the format is still open game.

No. It's already solved an implemented since about than a year.

/*
 * OpenPGP Reference implementation and specification to be
 * Author/Editor: [email-masked]
 * Source is GPLed.
 */

%{
%}
%union {
}
%type <signature> user_ID_compromise
%%

user_ID_compromise:
	CTB_SIGNATURE v23 '\5' '\x30' sig_v23_data eop
	{$$ = $5; $$.type = CERT_USERID_COMPROMISE}
	| CTB_SIGNATURE v4 '\x30' sig_v4_data eop
	  {$$ = $4; $$.type = CERT_USERID_COMPROMISE}
;

%%%

Together with:

/*
 * OpenPGP Reference implementation and specification to be
 * Author/Editor: [email-masked]
 * Source is GPLed.
 */

%{
%}
%union{
}
%type <userID> signed_userID
%%

signed_userID:
	user_ID_packet maybe_trust self_compromise {$$ = $2; $$.revoked = 1}
	| user_ID_packet maybe_trust
	  self_certificate maybe_trust
	| user_ID_packet maybe_trust
	  self_certificate maybe_trust
	  key_signatures
;

%%%

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 11 Mar 1998 07:53:33 GMT
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>Lutz Donnerhacke, <[email-masked]>, writes:
>> I see. Is is now allowed to add a zero certificate to the key as described
>> in the formal draft? Zero certificates can hold the key expiration time and
>> related entities. So defining a JPEG subtype in the signature allows to
>> bind it even to the key, but this cannot be certified by others.
>
>I don't know what your "formal draft" says a zero certificate is.
>There is nothing in the draft OpenPGP Message Format spec called a
>"zero certificate".

You know at as '0x02: Standalone signature.'

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: S/MIME winz
Date: 11 Mar 1998 07:49:40 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* A. Padgett Peterson P.E. Information Security wrote:
>compliant. Will say that the crypto (other than being intercommunicating)
>is really the least part - it is the directory and key management structure
>that will make or break. At the moment it is the only one I have seen that 
>is independant of a mail structure and provides for diversified management.
>(opposing views welcome).

X.509 (aka S/MIME) is a strong hierachical PKI. PGP has a complete
distributed PKI.

Date: Tue, 10 Mar 1998 23:30:51 -0800
To: Hal Finney <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

At 05:25 PM 3/9/98 -0800, Hal Finney wrote:
>This is a proposal for a new packet type, the "attribute packet,"
>which is a generalization of the userid packet.  Attribute packets can
>appear in a PGP key structure anywhere a userid packet could appear.

Can you get by with the current "Notation Data" subpacket type,
or is the 2-octet length field too limiting?
(64KB is a bit small for some JPEGs, and it's a pretty short voiceprint
at any decent quality.)

>The only type defined initially is a JPEG photo, in the JPEG File
>Interchange Format (JFIF) [ftp://ftp.uu.net/graphics/jpeg/jfif.txt].
>The subpacket data is the JFIF data which holds the image.

I agree with another commenter that JPEG is pretty limiting,
and "image" might be better, especially since JPEGs and GIFs
identify themselves just fine.  In particular, GIF support is good
for pictures that need lossless handling and few colors,
such as fingerprints or cartoons.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Tue, 10 Mar 1998 21:12:09 -0800
To: Tim Dierks <[email-masked]>, [email-masked] (Christopher Creutzig)
From: Jon Callas <[email-masked]>
Subject: Re: Algorithm questions
Cc: [email-masked]
Sender: [email-masked]

In reply to Tim Dierks and Christopher Creutzig:

Thanks for the comments, my last message went out just as I received this
one, which is why you're likely to say "Huh?" as you read its comments on
EC.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 10 Mar 1998 21:06:26 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Draft, Algorithm, and packet updates
Sender: [email-masked]

I got the answer I needed for Blowfish, I've specified it at 128 bits, 16
rounds. It appears no further EC definition is needed.

David Formosa has said he's writing up a ROT-N description for me.

I still don't have any other algorithm questions resolved (notably Haval).
They don't have to be resolved now, but when I create the "final call"
draft (after LA but it is to be hoped soon after), algorithms with
unresolved questions are just going to be dropped. So what this means is
that if you care about some algorithm, I need your help, and if you don't
help, it means you don't care.

It appears that there's consensus that non-text ids are a good thing, but
there are questions about the exact syntax of them. So I'm not putting
anything in this draft, but I'm expecting we can get the details in for a
draft thereafter.

I'll be editing up the last few things tonight, and will send it to our
working group chair tomorrow for official blessing. Do people want me to
send it directly here just to get it in everyone's hands sooner?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 10 Mar 1998 20:57:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Algorithm questions
Sender: [email-masked]

Tim Dierks, <[email-masked]>, writes, regarding elliptic curves:
> Specifically, are you just reserving an identifier (which seems pretty
> useless to me; it shouldn't be reserved until its specified), or are you
> indending to provide all the necessary info to allow implementation?

It sounds like it would be best to wait until the algorithm is
implemented.  Personally I don't see much value in assigning identifiers
for which there is no implementation, unless we are sure that one is
coming soon.

> I have the same problem with the existing specification for ElGamal: it's
> not detailed enough to be complete. Here is the entire description of the
> ElGamal encryption system from draft-ietf-openpgp-formats-00.txt:
>
> >    Algorithm Specific Fields for Elgamal encryption:
> >    - MPI of DSA value g**k.
> >    - MPI of DSA value m * y**k.
>
> There's no discussion of how to generate k, and this description isn't
> detailed enough to expect any but true initiates into the secrets to be
> able to implement it. There's no mention of mod p, for example, let alone
> the arcana of key generation or how to decrypt this packet.

You're right, those expressions should have "mod p" added to them.
The description of RSA on the previous line should have "mod n" added.
(This is in section 5.1.)

We should add a reference to ElGamal's original paper, which according
to Bruce Schneier's _Applied_Cryptography_ is:

T. ElGamal, "A Public-Key Cryptosystem and a Signature Scheme Based on
Discrete Logarithms," IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp. 469-472.

According to this reference, k is simply a random number mod p-1.
Bruce states that it needs to be relatively prime to p-1, but this was
not in the original paper and I don't think it is necessary.

Providing the ElGamal reference should be sufficient for implementors.
The only PGP specific part is the format of m, which is documented in
the spec.

Hal

Date: Tue, 10 Mar 1998 20:41:11 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

Andrew Bromage, <[email-masked]>, writes:
> I may be missing something here, but why don't we just mandate that
> the attribute is a MIME document (possibly compressed, possibly
> multipart), then leave the interpretation of that document up to the
> client?

It's true that MIME is a widely used standard which can represent many
different kinds of data.  And it is used for more than its original
designed purpose of multimedia email these days.  But it's not clear
that it is appropriate for this use.

We are looking at a relatively limited application and may not need the
full power of MIME, with multiparts, etc.  MIME has considerable overhead,
which may not matter for a multi-K picture or voiceprint, but could be
costly for smaller attributes.  It's not really in keeping with the PGP
philosophy of compactness.

The specific things we might want to put in attributes will not
necessarily have MIME types defined for them.  We might use some special
encoding of fingerprints or other biometric data.  This would require
defining new MIME types before we could add them to our standard.

> Somebody is going to want to stick in a voiceprint, someone is going
> to want to put in their v-card (don't blame me; some people like them),
> someone is going to want to put in a link to their web page etc etc.
> Much easier to borrow an existing well-supported standard, IMO.

If we need to I could see defining an attribute type later which is a
MIME object.  But initially I would prefer to keep it simple.

> Possible security risk: It should be made clear to the person doing the
> checking that information stored via a hyperlink is not necessarily
> signed.

Good point, although I think MIME has provisions to include the hash of
externally referenced documents so that they do end up being signed.

Hal

From: Andrew Bromage <[email-masked]>
Subject: Re: Proposal for new Attribute packet
To: [email-masked] (Will Price)
Date: Wed, 11 Mar 1998 14:30:00 +1100 (EST)
Cc: [email-masked]
Sender: [email-masked]

G'day all.

Will Price wrote:

> We are only talking about formats here.  Whether somebody wants to add a 10
> MB Photoshop file, the collected works of shakespeare, fingerprint
> information, a voiceprint, or a simple 20 character user ID is not relevant
> here.
[...]
> For convenience
> and because it is simple, a photo ID constant has been defined and I'm sure
> at a later point in time, other uses will be defined by this group.

I may be missing something here, but why don't we just mandate that
the attribute is a MIME document (possibly compressed, possibly
multipart), then leave the interpretation of that document up to the
client?

Somebody is going to want to stick in a voiceprint, someone is going
to want to put in their v-card (don't blame me; some people like them),
someone is going to want to put in a link to their web page etc etc.
Much easier to borrow an existing well-supported standard, IMO.

Possible security risk: It should be made clear to the person doing the
checking that information stored via a hyperlink is not necessarily
signed.

Cheers,
Andrew Bromage

Date: Tue, 10 Mar 1998 18:58:16 -0800
To: [email-masked] (Christopher Creutzig)
From: Tim Dierks <[email-masked]>
Subject: Re: Algorithm questions
Cc: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:38 AM +0100 3/10/98, Christopher Creutzig wrote:
>On Fri, 6 Mar 1998, Jon Callas wrote:
>
>-> Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is this
>-> enough?
>
> The same thing I already asked you in an unanswered private e-mail some
>months ago: Wat encryption system over elliptic curves do you mean by that?
>You can use RSA and ElGamal over elliptic curves, amongst others. So far,
>only ElGamal and RSA are defined for encryption, so your probably mean one
>of those.

Specifically, are you just reserving an identifier (which seems pretty
useless to me; it shouldn't be reserved until its specified), or are you
indending to provide all the necessary info to allow implementation?

If the former, specifying a value is relatively harmless, but short-sighted.

If the latter, there is an awful lot of work left to do before you're done.

I have the same problem with the existing specification for ElGamal: it's
not detailed enough to be complete. Here is the entire description of the
ElGamal encryption system from draft-ietf-openpgp-formats-00.txt:

>    Algorithm Specific Fields for Elgamal encryption:
>    - MPI of DSA value g**k.
>    - MPI of DSA value m * y**k.

There's no discussion of how to generate k, and this description isn't
detailed enough to expect any but true initiates into the secrets to be
able to implement it. There's no mention of mod p, for example, let alone
the arcana of key generation or how to decrypt this packet.

Since ElGamal isn't even standardized (as opposed to RSA's PKCS#1), this
isn't even a stand-in for another document.

Elliptic curve will have all the same issues and more. For example, how to
encode the keys. An RSA key has two elements: e and n. An ElGamal key,
three: p, g, and y. An elliptic curve key can have up to 13.

An elliptic-curve note: If you use PKCS#1 padding for EC encryption, that
will result in an 11 byte (88 bit) overhead. The internal encoding in the
encrypted block adds another 3 bytes, for a total of 14 bytes (112 bits).
This means that if you use raw elliptic curve encryption, you'll need to
use key lengths of at least 240 bits for 128 bit symmetric algorithms and
at least 304 bits for 3DES. This is radical overkill: it's like requiring
RSA keys to be at least 3000-4000 bits long.

This is the sort of unexpected pitfall that causes me to recommend complete
specification or total omission.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

CC: [email-masked]
To: Jon Callas <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Algorithm questions
Date: Tue, 10 Mar 1998 10:38:10 +0100 (MET)
Sender: [email-masked]

On Fri, 6 Mar 1998, Jon Callas wrote:

-> Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is this
-> enough?

 The same thing I already asked you in an unanswered private e-mail some
months ago: Wat encryption system over elliptic curves do you mean by that?
You can use RSA and ElGamal over elliptic curves, amongst others. So far,
only ElGamal and RSA are defined for encryption, so your probably mean one
of those.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
  # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
        "(Das sind keine gesicherten Zahlen, sondern Realitäten.)"
                                                    (Horst Willenberg)

Date: Tue, 10 Mar 1998 17:07:27 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> Well if we are going to modify the userID field so that any binary data
> can be used then I think that it is improtant that we add some type of
> field identifyer so that the applications processing this data have some
> idea of what they are dealing with.

That's in there.  The format I proposed has a representation of the
type of data, then the data itself.

I did get a suggestion in private mail that rather than defining a type
for "JPEG data in JFIF format", it would be better to define the type
more generically as "Image data".  Then the body would have the image
data format, in this case JFIF, and the formatted data.

The advantage would be that if we added more image formats in the future
we wouldn't have to define new top-level attribute types, and it would
set a similar precedent for other kinds of attributes.

Another point which has been raised in the past is the issue of number
of bytes.  Is one byte enough for the type?  Should we use four bytes
in the interests of future expandability?

> IMHO it is a little late in the game to be adding things to the spec. I
> think that there are some more pressing issues like the ability to revoke
> userID's if modifying the format is still open game.

The direction I'd like to go on this would be to say that if a userid is
not self-signed, it should not be used.  Then you could revoke a userid
by revoking your self-signature.  This also solves the problems of people
adding fake names to other people's keys.

It has backwards compatibility problems, though, because a lot of old
signatures are not self-signed.  You'd have to get people with old
keys to self-sign all their (valid) userids.

A variant would be to accept unsigned userids, but if the userid has
a REVOKED SELF SIGNATURE then that would mean that the keyholder is
explicitly saying not to use this key anymore.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 18:16:47 -0500
To: Will Price <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

This is a MIME encapsulated message

--==_0240A_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <v04003a00b12b6f31fa32@[161.69.9.50]>, on 03/10/98 
   at 02:42 PM, Will Price <[email-masked]> said:

>The only intent is to extend the user ID packet format to allow
>extensions in the future so that we're not locked into a non-extensible
>format which supports only strings.  What a particular implementation
>decides to do with that ability is again outside the scope of the
>discussion.  For convenience and because it is simple, a photo ID
>constant has been defined and I'm sure at a later point in time, other
>uses will be defined by this group.

Well if we are going to modify the userID field so that any binary data
can be used then I think that it is improtant that we add some type of
field identifyer so that the applications processing this data have some
idea of what they are dealing with.

IMHO it is a little late in the game to be adding things to the spec. I
think that there are some more pressing issues like the ability to revoke
userID's if modifying the format is still open game.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: What I like about MS is its loyalty to customers!

--==_0240A_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_0240A_===--

Date: Tue, 10 Mar 1998 15:00:28 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

> From hal  Tue Mar 10 14:37:28 1998
> Message-Id: <[email-masked]>
> From: "William H. Geiger III" <[email-masked]>
> Date: Tue, 10 Mar 98 15:48:23 -0500
Jack Repenning, <[email-masked]>, write:
>I'm not sure this addresses the use Hal had in mind.  An implication of
>allowing an attribute packet "wherever a userid packet may be" is that it
>can be signed by another party.  I imagine the UI he has in mind would
>allow this other party to add the attribute, rather than (or, "in
>addition to") the key owner doing so.  The end goal is (I think) the
>ability to express the meaning of your signature ... "I certify this key
>for business purposes, but I wouldn't trust this blighter with the
>personal secrets of a snail."  

That's not quite the idea, since what you are describing is more
of a qualification on your signature, rather than an attribute of
the keyholder.  The expectation is that typically attributes would be
created by the keyholder, like userids, and then be both self-certified
and also certified by other people.

As an aside, remember that signing a key/userid does not mean that
you are attesting to the trustworthiness of the keyholder.  All you
are vouching for is his identity as described in the userid packet.
So the actual sentiment quoted above is completely consistent with an
ordinary key signature.

William H. Geiger III, <[email-masked]>, replied:

> I'm not sure I like this at all. It is one thing to allow 3rd parties to
> attach their verification of the userID of a key. It is quite another
> thing to allow then to add any information they wanted to. There are quite
> a few nasty and malicious people out there and I for one would not support
> letting them have the ability to add extra information of any kind to my
> public keys.
>
> The more I think about this the less I like it. Seems to be opening a real
> can of worms.

This is one reason the Key Server Preferences subpacket was added.
It is designed to allow the keyholder to tell key servers that he does
or does not want to allow third parties to add things to his key.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 16:49:35 -0500
To: Jon Callas <[email-masked]>
Cc: Jack Repenning <[email-masked]>, [email-masked]
Subject: Export/Import (Was: Re: Proposal for new Attribute packet)
Sender: [email-masked]

This is a MIME encapsulated message

--==_00811_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <v04003a0db12b6cd10461@[161.69.9.131]>, on 03/10/98 
   at 02:37 PM, Jon Callas <[email-masked]> said:

>One of the things we discussed for putting in OpenPGP was what I've
>called "SDSI names." These are local name or other user IDs. The
>consensus I've seen is that while people think it's a good idea, there
>was no implementation proposal for it.

>There is presently an -- ummm -- situation (I don't know if it's a bug)
>with the way keys work. There is no reason why anyone can't add a
>username to a key, which is not necessarily a good thing. Arguably, a key
>server should trim off any user id that is not self-signed, because it's
>the self-signature that says that the key owner agrees to be known by
>that name.

>On the other hand, SDSI names, local names, or whatever you want to call
>them are a Good Thing. It strikes me that the Attribute packet could
>easily have a constant in there for a local name -- a text user id that
>acts like any other user id, except that it won't be exported.

This brings up and interesting subject: the export of attributes.

I have brought this up in the past that that things like trust attributes
(SDSI names also) have a legitimate use to be exported with a key. One of
the thing I have been working on is the use of a local PGP CA for a
company. In such a situation you would want trust, SDSI, and other
attributes exported along with the keys when a local user retrieved keys
from the local server. On the other hand you would not (or only under
certain conditions) want these same attributes imported to the local
server when a key is uploaded (you may even wish to put restrictions on
who can upload keys at all). 

You can also get into interesting things like distributed "web of trust"
over multiple keyrings. Rather than importing trust packets on a key
(which has some problems of it's own) the client PGP can query the local
PGP server for WoT data for calculating the trust of a given key.
Something like this could be extended to the Public Keyservers sort of an
extended PathServer built into the keyserver protocols.

While I agree that public keyservers should strip all such attributes from
a key before it is added to the server, I think unilaterally preventing
them from being exported is needlessly restrictive.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: If at first you don't succeed, work for Microsoft.

--==_00811_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00811_===--

Date: Tue, 10 Mar 1998 14:42:25 -0800
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

That's why the capability for non-owners of the key to add User IDs to a
key was removed from the 5.X client, because it generally makes no sense in
the context of a user ID representing information about the key's owner --
information which generally should be modified only by the key's owner.
However, I think this conversation is now far away from the topic at hand.
The fact is that the format of UserIDs technically allows anyone to add a
UserID and old PGP 2.X didn't even add a self-signature on that data unless
told to do so.

We are only talking about formats here.  Whether somebody wants to add a 10
MB Photoshop file, the collected works of shakespeare, fingerprint
information, a voiceprint, or a simple 20 character user ID is not relevant
here.

The only intent is to extend the user ID packet format to allow extensions
in the future so that we're not locked into a non-extensible format which
supports only strings.  What a particular implementation decides to do with
that ability is again outside the scope of the discussion.  For convenience
and because it is simple, a photo ID constant has been defined and I'm sure
at a later point in time, other uses will be defined by this group.

-Will

At 3:48 PM -0500 3/10/98, William H. Geiger III wrote:
>In <9803101816.AA17326@parrot>, on 03/10/98
>   at 01:15 PM, Jack Repenning <[email-masked]> said:
>
>>I'm not sure this addresses the use Hal had in mind.  An implication of
>>allowing an attribute packet "wherever a userid packet may be" is that it
>>can be signed by another party.  I imagine the UI he has in mind would
>>allow this other party to add the attribute, rather than (or, "in
>>addition to") the key owner doing so.  The end goal is (I think) the
>>ability to express the meaning of your signature ... "I certify this key
>>for business purposes, but I wouldn't trust this blighter with the
>>personal secrets of a snail."
>
>>You might do this with additional UserIDs, but only if you allow them to
>>be added by non-owners (a capability recently retracted by PGPInc
>>implementations); you also would have some conflict over whether to match
>>values in the attributes when searching for a key.
>
>>At least, I think that's the sort of thing he was getting at.  Perhaps a
>>bit more info about intended use, and structure of the packet to support
>>it, would be in order.
>
>I'm not sure I like this at all. It is one thing to allow 3rd parties to
>attach their verification of the userID of a key. It is quite another
>thing to allow then to add any information they wanted to. There are quite
>a few nasty and malicious people out there and I for one would not support
>letting them have the ability to add extra information of any kind to my
>public keys.
>
>The more I think about this the less I like it. Seems to be opening a real
>can of worms.
>
>--
>---------------------------------------------------------------
>William H. Geiger III  http://users.invweb.net/~whgiii

Will Price
Architect/Sr. Mgr.
Total Network Security Division
Network Associates, Inc.
(650)473-2906

Date: Tue, 10 Mar 1998 14:37:12 -0800
To: "William H. Geiger III" <[email-masked]>, Jack Repenning <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

One of the things we discussed for putting in OpenPGP was what I've called
"SDSI names." These are local name or other user IDs. The consensus I've
seen is that while people think it's a good idea, there was no
implementation proposal for it.

There is presently an -- ummm -- situation (I don't know if it's a bug)
with the way keys work. There is no reason why anyone can't add a username
to a key, which is not necessarily a good thing. Arguably, a key server
should trim off any user id that is not self-signed, because it's the
self-signature that says that the key owner agrees to be known by that name.

On the other hand, SDSI names, local names, or whatever you want to call
them are a Good Thing. It strikes me that the Attribute packet could easily
have a constant in there for a local name -- a text user id that acts like
any other user id, except that it won't be exported.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 15:48:23 -0500
To: Jack Repenning <[email-masked]>
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

This is a MIME encapsulated message

--==_0117B_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <9803101816.AA17326@parrot>, on 03/10/98 
   at 01:15 PM, Jack Repenning <[email-masked]> said:

>I'm not sure this addresses the use Hal had in mind.  An implication of
>allowing an attribute packet "wherever a userid packet may be" is that it
>can be signed by another party.  I imagine the UI he has in mind would
>allow this other party to add the attribute, rather than (or, "in
>addition to") the key owner doing so.  The end goal is (I think) the
>ability to express the meaning of your signature ... "I certify this key
>for business purposes, but I wouldn't trust this blighter with the
>personal secrets of a snail."  

>You might do this with additional UserIDs, but only if you allow them to
>be added by non-owners (a capability recently retracted by PGPInc
>implementations); you also would have some conflict over whether to match
>values in the attributes when searching for a key.

>At least, I think that's the sort of thing he was getting at.  Perhaps a
>bit more info about intended use, and structure of the packet to support
>it, would be in order.

I'm not sure I like this at all. It is one thing to allow 3rd parties to
attach their verification of the userID of a key. It is quite another
thing to allow then to add any information they wanted to. There are quite
a few nasty and malicious people out there and I for one would not support
letting them have the ability to add extra information of any kind to my
public keys.

The more I think about this the less I like it. Seems to be opening a real
can of worms.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: You said Windows was a Power Tool???

--==_0117B_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_0117B_===--

Date: Tue, 10 Mar 1998 12:04:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

Lutz Donnerhacke, <[email-masked]>, writes:
> I see. Is is now allowed to add a zero certificate to the key as described
> in the formal draft? Zero certificates can hold the key expiration time and
> related entities. So defining a JPEG subtype in the signature allows to
> bind it even to the key, but this cannot be certified by others.

I don't know what your "formal draft" says a zero certificate is.
There is nothing in the draft OpenPGP Message Format spec called a
"zero certificate".

The idea of the attribute is that it is certified by others, like
the userid.  It is intended to be a generalization of the userid.

Jack Repenning, <[email-masked]>, writes:
> I'm still not at all sure I grasp the purpose of this packet.  But as the
> discussion progresses, I'm becoming very concerned about the timeliness of
> the data (size bothers me as well, but that's already been touched).  We
> already have problems, both conceptual and practical, with expired user IDs
> (changing mail addresses, for example).  Why do we suppose this as-yet only
> vaguely understood (at least, by me) "attribute" will be any less
> ephemeral?  Might it, for example, be a JPG of my lovely face?  What if I
> shave my beard?

To the extent that timeliness is an issue, it applies to attribute packets
as well as userids.  Attribute packets don't make the problem any worse,
but they don't solve it, either.  The timeliness issue is therefore
independent of whether we add attribute packets.

Generally, timeliness can be dealt with by using signature expirations
and signature revocations.  If a userid or attribute is no longer valid,
signatures on it can be revoked.  If it is anticipated that the userid or
attribute may be valid only temporarily, signatures can be issued with
expiration dates, and re-issued as needed.  These are fairly standard
procedures for dealing with certification issues.

Hal

Date: Tue, 10 Mar 1998 15:01:59 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: S/MIME winz
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>I would imagine that the majority of S/MIME implementations are based on
>RSADSI's BSafe. In my phone conversations with RSADSI last week they made
>it plain in no uncertian terms that they will *not* be supporting these
>unencumbered algorithms and their position is that DH/DSS is "untested"
>and "insecure" (Their basic position is if it's not from RSADSI it's not
>"secure").

Have just been looking at the S/Mime v3 spec page 25 section 12 at 
http://www.imc.org/draft-ietf-smime-cms and the MUST impliment includes
DSS, SHA-1, D-H (x9.42) and triple DES CBC (three keys - 168 bit).

MAY impliment includes the proprietary RSA mechanisms.

If this stays that way there is no reason why PGP could not be S/MIME
compliant. Will say that the crypto (other than being intercommunicating)
is really the least part - it is the directory and key management structure
that will make or break. At the moment it is the only one I have seen that 
is independant of a mail structure and provides for diversified management.
(opposing views welcome).
					Warmly,
						Padgett

Date: Tue, 10 Mar 1998 11:49:40 -0800
To: Jack Repenning <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

At 11:19 AM -0800 3/10/98, Jack Repenning wrote:

   I'm still not at all sure I grasp the purpose of this packet.  But as the
   discussion progresses, I'm becoming very concerned about the timeliness of
   the data (size bothers me as well, but that's already been touched).  We
   already have problems, both conceptual and practical, with expired user IDs
   (changing mail addresses, for example).  Why do we suppose this as-yet only
   vaguely understood (at least, by me) "attribute" will be any less
   ephemeral?  Might it, for example, be a JPG of my lovely face?  What if I
   shave my beard?

The purpose is for non-text user-ids. There are a number of good uses for
it. For example, this would enable a company to make a PGP key that was an
badge-equivalent that included a photo. It also allows other interesting
things like a photo-certification of someone known only by a nym. (The
protocol for esablishing certification criteria is left as an exercise by
reader.) It would function like the present user-ids -- it is some
identifier of the person owning the key -- it would just be some non-text
medium.

It could indeed be a photo of your lovely face. If you shave your beard?
Probably nothing. I recently shaved mine, and had no trouble with a bearded
passport. :-)

I have some procedural comments:

In Washington, (and the last draft), this concept was mentioned, and
briefly discussed. The consensus (as I perceive it) is that this is a good
idea, but an actual proposal needed to be made. I specifically told the
proposer (PRZ) that a description of the non-text user id had to be made to
the list before it got in the draft.

My intent (as editor) is that we finish this RFC ASAP, and then progress
from there. I liken it to what some other groups (like TLS) have done. Make
a base V1 specification that no one hates, and then start putting in the
things people like.

There is going to be at least one more draft before we take this to final
call, so while a decision on this draft needs to be made today (or tomorrow
with cause), it's only a local rush.

I see that we have a number of options which include:

(1) Put the packet in the spec, see how we like it, and know that if we
don't like it in three weeks, out it comes.
(2) Debate the packet for a few weeks, and if we like it put it in the next
draft.
(3) Decide that it must wait for post-V1.
(4) Decide that we don't like it at all.

Any of these is fine with me.

	Jon

Date: Tue, 10 Mar 1998 11:19:14 -0800
To: [email-masked] (Lutz Donnerhacke)
From: Jack Repenning <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

I'm still not at all sure I grasp the purpose of this packet.  But as the
discussion progresses, I'm becoming very concerned about the timeliness of
the data (size bothers me as well, but that's already been touched).  We
already have problems, both conceptual and practical, with expired user IDs
(changing mail addresses, for example).  Why do we suppose this as-yet only
vaguely understood (at least, by me) "attribute" will be any less
ephemeral?  Might it, for example, be a JPG of my lovely face?  What if I
shave my beard?

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

Date: Tue, 10 Mar 1998 13:50:16 -0500 (EST)
From: Ryan Anderson <[email-masked]>
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

On Tue, 10 Mar 1998, Hal Finney wrote:

> Jack Repenning, <[email-masked]>, writes:
> > >This is a proposal for a new packet type, the "attribute packet,"
> >
> > Meaning, "for the draft that needs to come out this month"?
> 
> It depends on whether agreement can be reached in time.
> 

In that case, put it off for V2.    We're going to b e very tight on time
as it is in getting a real spec out, let's not try to add features that
aren't truly necessary until we've got somethign out there to compete with
S/MIME...

Ryan Anderson - Alpha Geek
PGP fp: 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9

"With this word of power, I cast thy soul into the void: (void)soul"

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 10 Mar 1998 18:24:49 GMT
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Jack Repenning wrote:
>I'm not sure this addresses the use Hal had in mind.  An implication of
>allowing an attribute packet "wherever a userid packet may be" is that it
>can be signed by another party.  I imagine the UI he has in mind would
>allow this other party to add the attribute, rather than (or, "in addition
>to") the key owner doing so.  The end goal is (I think) the ability to
>express the meaning of your signature ... "I certify this key for business
>purposes, but I wouldn't trust this blighter with the personal secrets of a
>snail."  

It is better to add it the the signature subpacket or the zero certificate.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 10 Mar 1998 18:23:50 GMT
Organization: IKS GmbH Jena
Lines: 59
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>Lutz Donnerhacke, [email-masked], writes:
>> I'm very unhappy with it. It seems to make no sense at all. Imagine a JPEG
>> of the owner of a key. Where should it inserted in the database? IMHO it's
>> related to the UserID. So simply use the URL subpacket of the signature page
>> or define an new one. But *do* *not* bind it to the key!
>
>The idea is that a userid describes information about the key holder:
>his name, and email address.  The attribute packet can describe other
>forms of information about the keyholder.  So conceptually it is an
>alternative to the userid, and should be placed at the same level in the
>hierarchy.

I see. Is is now allowed to add a zero certificate to the key as described
in the formal draft? Zero certificates can hold the key expiration time and
related entities. So defining a JPEG subtype in the signature allows to
bind it even to the key, but this cannot be certified by others.

/*
 * OpenPGP Reference implementation and specification to be
 * Author/Editor: [email-masked]
 * Source is GPLed.
 */

%{
%}
%union{
}
%type <pubkey> public_key
%%

/* structure of a public key */
public_key:
	public_key_packet maybe_trust key_compromise
	{  $$=$1;
	   $$.revoked=1;
	}
	| public_key_packet maybe_trust signed_userIDs
	  {  $$=$1;
	     $$.userIDs=$3;
	  }
	| public_key_packet maybe_trust signed_userIDs subkeys
	  {  $$=$1;
	     $$.userIDs=$3;
	     $$.subkeys=$3;
	  }
	| public_key_packet maybe_trust zero_certificate signed_userIDs
	  {  $$=$1;
	     $$.userIDs=$3;
	  }
	| public_key_packet maybe_trust zero_certificate signed_userIDs subkeys
	  {  $$=$1;
	     $$.userIDs=$3;
	     $$.subkeys=$3;
	  }
;

%%%

Date: Tue, 10 Mar 1998 10:15:09 -0800
To: [email-masked] (Lutz Donnerhacke)
From: Jack Repenning <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

At 06:55 3/10/98 , Lutz Donnerhacke wrote:
>* Hal Finney wrote:
>>This is a proposal for a new packet type, the "attribute packet,"
>
>So simply use the URL subpacket of the signature page
>or define an new one. But *do* *not* bind it to the key!

I'm not sure this addresses the use Hal had in mind.  An implication of
allowing an attribute packet "wherever a userid packet may be" is that it
can be signed by another party.  I imagine the UI he has in mind would
allow this other party to add the attribute, rather than (or, "in addition
to") the key owner doing so.  The end goal is (I think) the ability to
express the meaning of your signature ... "I certify this key for business
purposes, but I wouldn't trust this blighter with the personal secrets of a
snail."  

You might do this with additional UserIDs, but only if you allow them to be
added by non-owners (a capability recently retracted by PGPInc
implementations); you also would have some conflict over whether to match
values in the attributes when searching for a key.

At least, I think that's the sort of thing he was getting at.  Perhaps a
bit more info about intended use, and structure of the packet to support
it, would be in order.

        /////   Informix Software Inc.	Jack Repenning
     ////\ /	  Config/Release Mgmt		[email-masked]
    ///// /     4100 Bohannon Drive		M/S: 4100/2
   ///// /      Menlo Park, CA 94025		FAX: 650/926-6571
  ///// /       PAGE:  800/782-9089		VOICE: 650/926-1044
 ///// /        PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
///// PGP/DSS: 955C 44AD 8FCE 77D4 9494 : 4AB2 51F1 3EED 3B82 E870

Date: Tue, 10 Mar 1998 09:45:10 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

Jack Repenning, <[email-masked]>, writes:
> >This is a proposal for a new packet type, the "attribute packet,"
>
> Meaning, "for the draft that needs to come out this month"?

It depends on whether agreement can be reached in time.

William H. Geiger III, <[email-masked]>, writes:
> While this is an intresting proposal I have some concerns over keysize.
>
> Current public databases are over 100Mb now and are growing at an ever
> increasing rate. I shudder to think what the size will grow to when BLOB's
> are added to the keys. Do we really want PGP keysize to grow into the Mb
> range?

The attribute packets don't have to be that large.  A small thumbnail
graphic can be a K or so, about the size of the key itself with
signatures.  Other attribute packets might consist of structured text
(e.g. database records), which would be small.  It is an extensible
mechanism for binding data to the key.

If size becomes an issue, key servers could limit the size of individual
keys or reject large attribute packets if they wish.  There can be
competition between key servers which have different policies to see
which are most successful.

The question is whether end users will find this a useful capability.
If so there will be pressure on key servers to provide more storage
capacity.  Storage costs are low and dropping, so I don't think it is
likely to be much of a problem.

Lutz Donnerhacke, [email-masked], writes:
> I'm very unhappy with it. It seems to make no sense at all. Imagine a JPEG
> of the owner of a key. Where should it inserted in the database? IMHO it's
> related to the UserID. So simply use the URL subpacket of the signature page
> or define an new one. But *do* *not* bind it to the key!

The idea is that a userid describes information about the key holder:
his name, and email address.  The attribute packet can describe other
forms of information about the keyholder.  So conceptually it is an
alternative to the userid, and should be placed at the same level in the
hierarchy.

Binding it to the key means that the signer certifies that the keyholder
possesses the attribute, which is conceptually the same as binding a
userid to the key.

Hal

Date: Tue, 10 Mar 1998 09:05:28 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME winz
Sender: [email-masked]

At 09:38 AM 3/10/98 -0500, William H. Geiger III wrote:
><sigh> you are missing the point. The fact that RSA/RC4 has been droped is
>irrelevant. If you implementation only uses DH/DSS and everyone else is
>using RSA then who are you going to talk to?

You are making a huge assumption here, that current S/MIME implementors
will choose to not comply with v3. You could be right, but from all
indications from the people at Netscape, Microsoft, and Worldtalk, you are
most likely wrong. Yes, your argument makes a nice argument for OpenPGP as
the bastion of interoperability, but that remains to be seen.

>Has Verisign made any offical position that they will even certify
>anything other than RSA?

Yes. They have said repeatedly they will certify whatever their major
customers want, regardless of the standards. Note that many Verisign people
contribute to the S/MIME mailing list.

I believe that having the OpenPGP vs. S/MIME argument on this list or on
the S/MIME list is a waste of time and will not help either effort move
forwards. The facts of what each working group is doing are out there (with
a few corrections on this list about misstatements aboout S/MIME). If
someone chooses to mis-implement a spec, they will win or lose based on
marketing pressure, not comments on IETF mailing lists.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: S/MIME winz
Date: 10 Mar 1998 17:07:57 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Dave Crocker wrote:
>S/MIME v3 is going to make DH/DSS mandatory.  v3 will be an IETF standard. 

But this is bad anyway. First of all DH is unusable for PKI. ElGamal is
usable. On the other hand DSS is too weak for most purposes.

Date: Tue, 10 Mar 1998 08:37:05 -0800
To: "William H. Geiger III" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: S/MIME winz 
Cc: [email-masked] (David P. Kemp), [email-masked]
Sender: [email-masked]

At 09:38 AM 3/10/98 -0500, William H. Geiger III wrote: 
>
> <sigh> you are missing the point. The fact that RSA/RC4 has been droped is
> irrelevant. If you implementation only uses DH/DSS and everyone else is
> using RSA then who are you going to talk to? If all the users of Netscape,

S/MIME v3 is going to make DH/DSS mandatory.  v3 will be an IETF standard. 
Hence anyone claiming to be standards compliant will be required to support
the
non-RSA algorithms.

>
> it plain in no uncertian terms that they will *not* be supporting these
> unencumbered algorithms and their position is that DH/DSS is "untested"
> and "insecure" (Their basic position is if it's not from RSADSI it's not
> "secure"). 

Such a marketing position from RSADSI is hardly newsworthy.  What else do you
expect them to say?  Since there is no indication that the bulk of the IETF
security community concurs with this assessment, it really is nothing more
than
marketing hype.

What matters, now, are only two things:  One is the set of requirements in the
emerging IETF S/MIME standard and the second is whether it gets implemented in
deployed product.  As of now, it appears very, VERY likely that non-RSA
defaults WILL get deployed for S/MIME.

d/
__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 10:05:08 -0500
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Algorithm questions
Sender: [email-masked]

This is a MIME encapsulated message

--==_00837_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <v04003a04b125f4fa7dcf@[207.230.132.154]>, on 03/06/98 
   at 05:51 PM, Jon Callas <[email-masked]> said:

>I have a couple of questions about the algorithms specified in the next
>draft:

>Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is
>this enough?

>X9.42: Should we add it?

>ROT-N: The reason this is here is to give an algorithm that all the
>proper transforms can be done on -- IV construction, encoding engines,
>etc. -- but won't be export controlled in a reference implementation.
>This would allow an international team of people to build and test the
>reference implementation. However, it has to be defined in more detail
>than that to really be interoperable. I think it's both useful and
>amusing, but I'm not so committed to it that I've actually done the work
>to spec it out. Someone who believes in having it needs to write up the
>details. If no one does so, I'm removing it.

>Haval: Similar to the above, someone who wants Haval has to decide how
>many rounds and the length. In Washington, we agreed that it should be at
>least as strong as SHA-1 or RIPEMD160. Someone with an opinion should
>state it, or it goes.

>Blowfish: Ditto. We need the variant specified.

It would be nice if there were pointers to reference implementations of
these algorithms so we can make sure that everyone is singing from the
same score. :)

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Windows done RIGHT!

--==_00837_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00837_===--

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 09:38:52 -0500
To: [email-masked] (David P. Kemp)
Cc: [email-masked]
Subject: Re: S/MIME winz
Sender: [email-masked]

This is a MIME encapsulated message

--==_00671_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/10/98 
   at 09:52 AM, [email-masked] (David P. Kemp) said:

>You obviously haven't been following S/MIME any more closely than Warmly
>Padgett.  Not only have MUST requirements for RSA/RC4 been dropped (RC2
>is already public), but MUST requirements for DSA/3DES have been added.

>Both S/MIME users and PGP users will be able to switch to free
>algorithms, and there is no interoperability problem between users who
>switch and those who don't (as long as they use standard-compliant
>software).

>I'll grant that PGP users may be more intellectually motivated to switch
>quickly.  PGP, Inc can speak to whether they intend to coerce users into
>switching by dropping support for optional algorithms.

<sigh> you are missing the point. The fact that RSA/RC4 has been droped is
irrelevant. If you implementation only uses DH/DSS and everyone else is
using RSA then who are you going to talk to? If all the users of Netscape,
Outlook, Lotus Notes, ...ect all use RSA keys how is your DH/DSS
implementation going to communicate with them?? Remember communication is
a two way street. If the "big players" add DH/DSS support so they can read
you messages but you still can't process the RSA messages that you
receive, what then?

I would imagine that the majority of S/MIME implementations are based on
RSADSI's BSafe. In my phone conversations with RSADSI last week they made
it plain in no uncertian terms that they will *not* be supporting these
unencumbered algorithms and their position is that DH/DSS is "untested"
and "insecure" (Their basic position is if it's not from RSADSI it's not
"secure").

Has Verisign made any offical position that they will even certify
anything other than RSA?

The simple fact is that if PGP, Inc. had not made the push for DH/DSS no
significant portion of PGP users would be using it.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN

--==_00671_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_00671_===--

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 09:10:55 -0500
To: Thomas Roessler <[email-masked]>
Cc: "The mutt developpers' list" <[email-masked]>, [email-masked], Werner Koch <[email-masked]>
Subject: Re: RFC 2015 problems
Sender: [email-masked]

This is a MIME encapsulated message

--==_011B2_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/10/98 
   at 06:57 AM, Thomas Roessler <[email-masked]> said:

>How do you suggest to handle these problems? Are there any
>plans for extensions to RFC 2015 to address them?

Well there was a lengthy tread on the PGP/MIME list on this topic (look in
the archives for the subject: "P/MIME"). The thread started after the 27
Jun 97 release of the PGP/MIME draft by Dave Del Torto to the list (same
subject: ).

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: Windows isn't crippleware: it's "Fuctionally Challenged"

--==_011B2_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_011B2_===--

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Proposal for new Attribute packet
Date: 10 Mar 1998 14:55:32 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>This is a proposal for a new packet type, the "attribute packet,"
>which is a generalization of the userid packet.  Attribute packets can
>appear in a PGP key structure anywhere a userid packet could appear.

I'm very unhappy with it. It seems to make no sense at all. Imagine a JPEG
of the owner of a key. Where should it inserted in the database? IMHO it's
related to the UserID. So simply use the URL subpacket of the signature page
or define an new one. But *do* *not* bind it to the key!

Date: Tue, 10 Mar 1998 09:52:27 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: S/MIME winz
Sender: [email-masked]

> From: "William H. Geiger III" <[email-masked]>
> 
> Well I think we have a *big* difference between S/MIME and OpenPGP here.
> 
> With OpenPGP we have only one corporation (PGP Inc.) involved with legacy
> software, and they have made a strong effort to push it's user base away
> from proprietary algorithms (RSA) to unencumbered ones.
> 
> In the S/MIME camp you have quite a different senario. You have several
> large corporations (Netscape, Microsoft, IBM/Lotus) all who have
> substantial investments in RSADSI software licenses. I hardly doubt that
> any of these companies will make any effort to move their users away from
> RSA. While it is true that the MUST requirements in the S/MIME v3 draft
> have been dropped you will not see any products on the shelf that do not
> support it.

You obviously haven't been following S/MIME any more closely than
Warmly Padgett.  Not only have MUST requirements for RSA/RC4 been
dropped (RC2 is already public), but MUST requirements for DSA/3DES
have been added.

Both S/MIME users and PGP users will be able to switch to free algorithms,
and there is no interoperability problem between users who switch and
those who don't (as long as they use standard-compliant software).

I'll grant that PGP users may be more intellectually motivated to
switch quickly.  PGP, Inc can speak to whether they intend to coerce
users into switching by dropping support for optional algorithms.

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 08:02:55 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal for new Attribute packet
Sender: [email-masked]

This is a MIME encapsulated message

--==_0221D_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/09/98 
   at 08:25 PM, Hal Finney <[email-masked]> said:

>This is a proposal for a new packet type, the "attribute packet," which
>is a generalization of the userid packet.  Attribute packets can appear
>in a PGP key structure anywhere a userid packet could appear.

While this is an intresting proposal I have some concerns over keysize.

Current public databases are over 100Mb now and are growing at an ever
increasing rate. I shudder to think what the size will grow to when BLOB's
are added to the keys. Do we really want PGP keysize to grow into the Mb
range?

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: I use OS/2 2.0 and I don't care who knows!

--==_0221D_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_0221D_===--

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 10 Mar 98 07:14:21 -0500
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: S/MIME winz
Sender: [email-masked]

This is a MIME encapsulated message

--==_02089_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <[email-masked]>, on 03/09/98 
   at 05:39 PM, Paul Hoffman / IMC <[email-masked]> said:

>And not needed. I take it you haven't been following the S/MIME working
>group. None of the drafts for S/MIME v3 have mandated any proprietary
>technology. The mandatory algorithms are the same as are proposed for
>OpenPGP: Diffie-Hellman for key exchange and tripleDES for encryption.
>The two groups are using different variants of each, but the requirements
>are by and large the same.

Well I think we have a *big* difference between S/MIME and OpenPGP here.

With OpenPGP we have only one corporation (PGP Inc.) involved with legacy
software, and they have made a strong effort to push it's user base away
from proprietary algorithms (RSA) to unencumbered ones.

In the S/MIME camp you have quite a different senario. You have several
large corporations (Netscape, Microsoft, IBM/Lotus) all who have
substantial investments in RSADSI software licenses. I hardly doubt that
any of these companies will make any effort to move their users away from
RSA. While it is true that the MUST requirements in the S/MIME v3 draft
have been dropped you will not see any products on the shelf that do not
support it.

The only way to build crypto e-mail software using unencumbered algorithms
is by using OpenPGP. While technically you can do it with S/MIME v3 you
woun't be able to talk to anyone else.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
---------------------------------------------------------------
 
Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN

--==_02089_===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==_02089_===--

Date: Tue, 10 Mar 1998 12:57:12 +0100
From: Thomas Roessler <[email-masked]>
To: "The mutt developpers' list" <[email-masked]>, [email-masked]
Cc: Werner Koch <[email-masked]>
Subject: RFC 2015 problems
Mail-Followup-To: The mutt developpers' list <[email-masked]>, [email-masked], Werner Koch <[email-masked]>
Sender: [email-masked]

[A copy of this goes to ietf-open-pgp.]

While thinking about further development of the PGP
integration with the mutt mail user agent, I am starting
to stumble over some problems with RFC 2015.

First, what's the plan?  The last two pgp related patches
are steps in the direction of an even more general PGP
integration which should allow mutt to automatically
select the correct PGP version to decrypt a message or
verify a signature.

To do this, we need some information about the algorithms
in use; this information has to be extracted from the
message's MIME headers since we don't want to parse the
PGP bodies ourselves.

The "micalg" parameter for PGP/MIME _signed_ messages is
one step in that direction - it would permit us to select
the correct "PGP" version for verifying signatures under
certain circumstances.

But there is no such parameter for encrypted messages, and
there is none for the encrypt/sign combo PGP permits to
generate.

Additionally, there may be "PGP" implementations which
permit various combinations of mic algorithms and
asymmetric algorithms, like rsa-rmd160, rsa-sha1,
elgamal-rmd160, elgama-md5, etc.

It is not possible for a mail user agent to handle such
versions properly - does micalg="pgp-sha1" mean a DSA
signature like pgp-5 generates it, or does it mean some
strange rsa-sha1 combination which has to be read by a
different "PGP" version?

How do you suggest to handle these problems? Are there any
plans for extensions to RFC 2015 to address them?

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Mon, 09 Mar 1998 18:45:28 -0800
To: Hal Finney <[email-masked]>
From: Jack Repenning <[email-masked]>
Subject: Re: Proposal for new Attribute packet
Cc: [email-masked]
Sender: [email-masked]

At 17:25 3/9/98 , Hal Finney wrote:

>This is a proposal for a new packet type, the "attribute packet,"

Meaning, "for the draft that needs to come out this month"?

Outside of a dog, a book is a man's best friend.
Inside of a dog, it's too dark to read.
=- Groucho Marx

Date: Mon, 09 Mar 1998 17:39:02 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME winz
Sender: [email-masked]

>Fine. And if RSA places the necessary pieces into the public domain as
promised,
>S/MIME may win in which case PGP will just have to build a plug-in. Not
>difficult. 

And not needed. I take it you haven't been following the S/MIME working
group. None of the drafts for S/MIME v3 have mandated any proprietary
technology. The mandatory algorithms are the same as are proposed for
OpenPGP: Diffie-Hellman for key exchange and tripleDES for encryption. The
two groups are using different variants of each, but the requirements are
by and large the same.

More info on both technologies can be found at
<http://www.imc.org/smime-pgpmime.html>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 9 Mar 1998 17:25:46 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Proposal for new Attribute packet
Sender: [email-masked]

This is a proposal for a new packet type, the "attribute packet,"
which is a generalization of the userid packet.  Attribute packets can
appear in a PGP key structure anywhere a userid packet could appear.

An attribute packet contains information which is being bound to the
key by signatures, just as a userid packet does.  However an attribute
packet allows more kinds of information to be bound than do userid
packets.

Possible examples of attribute packets would include biometric data
regarding the key holder, such as a photograph, fingerprint, or voice
print.  A signature on such an attribute packet binds it to the key
and represents an assertion that the key holder does possess the
biometric attribute.  Other kinds of attribute packets could be
defined to specify other characteristics which are being bound to the
key.

An attribute packet consists of one or more subpackets (usually just
one subpacket).  Each subpacket has a type and some data.  The
contents of the data portion will depend on the type.

The only type defined initially is a JPEG photo, in the JPEG File
Interchange Format (JFIF) [ftp://ftp.uu.net/graphics/jpeg/jfif.txt].
The subpacket data is the JFIF data which holds the image.

The format of attribute subpackets is proposed to be similar to
signature subpackets.  On Feb 12, 1998 I proposed a generalization of
the mechanism used to express packet and subpacket lengths, to allow
four-octet packet lengths, by preceding them with an octet of 255.  It
is proposed that this same mechanism be used to specify subpacket
lengths in attribute packets, with the non-four-octet encodings being
deprecated.

Accordingly, the format of an attribute packet would be
1 or more instances of an attribute subpacket; the format of an
attribute subpacket would follow that of a signature subpacket with
the restriction that four-octet lengths are used:

   Each subpacket consists of a subpacket header and a body.  The header
   consists of:

       - subpacket length (5):
	 Length includes the type octet but not this length.
	 1st octet = 255
	 2nd through 5th octets encode subpacket length in big-endian form

       - subpacket type (1 octet):

       - subpacket specific data:

Note that this length encoding is intended to be consistent with the
encoding for signature subpackets and other packets, except that the
short lengths are deprecated.  If we don't choose to add the four-octet
option to those cases, then it would be simpler to just define a new
subpacket format whose length is simply the first four octets.  However
I would prefer to see the various lengths unified as I proposed earlier
for ease in description and implementation.

Proposed constants:

Attribute Packet tag:		17
JFIF subpacket type:		1

Hal Finney
PGP, Inc.

Date: Mon, 09 Mar 1998 20:20:42 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: S/MIME winz
To: [email-masked]
Sender: [email-masked]

>At the IETF, the S/MIME working group is about one month away from
>completing its work on the specification. The OpenPGP group, however, has
>not updated the draft of its specification since October, when group
>members identified a number of problems. Both groups had agreed to submit
>their final drafts next month, but it is unlikely the PGP group can
>finish.

Fine. And if RSA places the necessary pieces into the public domain as promised,
S/MIME may win in which case PGP will just have to build a plug-in. Not
difficult. 

If not, I strongly doubt that it will become a standard, an *open* standard 
that is. And right now we need open standards. Besides there are sufficient
algorithms available that are Good Enough (C) so why bother with anything
proprietary ? That is the boring part anyway swap DH for RSA or IDEA for
RC4-128 and no one will really notice (other than needing new keys - if you
*could* use an RSA keypair with DH, then I would get concerned but just 
points out the triviality.

The problem is politics as usual, not anything technical and the last time 
I looked, the ietf wasn't for sale. (would like to know if it has changed)

Strong E-mail encryption is needed and will happen. Already exists for a few
people but is an individual thing today. What is needed is the universal
readers, the key management servers, and the directory services to support
a universal mechanism. Should have happened already but we have the US Patent
office to thank that it hasn't and Phil was the revolutionary who helped it
happen this fast (unfortunately, the first thing you do after a revolution
is to shoot the revolutionaries...)

For myself, I will *never* (never say never) advocate anything that is 
based on proprietary algorithms, there are too many open ones to stifle
development that way. Fortunately some listen.

So what is the status of RSA and "open" ? Or are they waiting for Exchange 5.5
SP1 ?
					Warmly,
						Padgett

Date: Sat, 7 Mar 1998 08:51:04 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Algorithm questions
Sender: [email-masked]

> Blowfish: Ditto. We need the variant specified.

(Information on Blowfish is at http://www.counterpane.com/blowfish.html)

I suggest that 128 bit keys be used.  This is the same as with IDEA
and CAST, so it is convenient for the implementation.  Blowfish is not
thought to have any special weaknesses at this key size.  And this size
provides a work factor far beyond anything possible for exhaustive search
in the foreseeable future.

Hal

Date: Sat, 7 Mar 1998 11:22:38 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Algorithm questions
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> Blowfish: Ditto. We need the variant specified.

Yes, please.

-- 
Werner

                                       finger [email-masked] for GNUPG key
              fingerprint = 8489 6CD0 1851 0E33 45DA  CD67 036F 11B8 FF3E AA0B

From: Andrew Bromage <[email-masked]>
Subject: Re: S/MIME wins
To: [email-masked] (Lutz Donnerhacke)
Date: Sat, 7 Mar 1998 11:05:06 +1100 (EST)
Cc: [email-masked]
Sender: [email-masked]

G'day all.

Lutz Donnerhacke wrote:

> "(...)
> Among U.S. campanies, momentum is building in favor of S/MIME. Both
> Microsoft and Netscape Communications have S/MIME clients and Lotus and
> Novell have announced support for S/MIME. Only Qualcomm Inc., maker of
> the Eudora E-mail client, supports PGP/MIME.

Let's not forget that if we move quickly, there could well be at least
one other PGP/MIME client: Netscape Communicator 5.x.  The timing of
the source release could be fortuitous for the Open PGP community.

> Both groups had agreed to submit
> their final drafts next month, but it is unlikely the PGP group can
> finish.

I think that a worse outcome than this working group not finishing on
time is this working group engaging in a firefighting effort and ending
up with an inferior standard.

Also ask yourself if anyone would go to the same effort over S/MIME as
the PGPi group did with PGP 5.0 (with scanning and proofreading etc).
This suggests that PGP/MIME may well be the only interoperable strong
crypto system for your email available world-wide, which has to be a
point in its favour.

Cheers,
Andrew Bromage

Date: Fri, 6 Mar 1998 18:51:36 -0400
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Algorithm questions
Sender: [email-masked]

I have a couple of questions about the algorithms specified in the next draft:

Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is this
enough?

X9.42: Should we add it?

ROT-N: The reason this is here is to give an algorithm that all the proper
transforms can be done on -- IV construction, encoding engines, etc. -- but
won't be export controlled in a reference implementation. This would allow
an international team of people to build and test the reference
implementation. However, it has to be defined in more detail than that to
really be interoperable. I think it's both useful and amusing, but I'm not
so committed to it that I've actually done the work to spec it out. Someone
who believes in having it needs to write up the details. If no one does so,
I'm removing it.

Haval: Similar to the above, someone who wants Haval has to decide how many
rounds and the length. In Washington, we agreed that it should be at least
as strong as SHA-1 or RIPEMD160. Someone with an opinion should state it,
or it goes.

Blowfish: Ditto. We need the variant specified.

	Jon

Date: Fri, 06 Mar 1998 12:30:48 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME wins
Sender: [email-masked]

At 08:29 PM 3/6/98 +0000, Lutz Donnerhacke wrote:
>The formal draft is on the way. Expect end of April.

Er, "the formal draft"? What's that?

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: S/MIME wins
Date: 6 Mar 1998 20:30:31 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>Well who is working on these drafts? where are they? And what needs to be
>done to get them finished??

Wonderful questions. Last month I drove through Germany to get money for
plugin development for the reference implementation. Now I'm back.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: S/MIME wins
Date: 6 Mar 1998 20:29:03 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* Jon Callas wrote:
>The next draft of formats is almost done. It'll be out next week.

If I still be on the editor list, I'd like to read and comment it first. thx.,

The formal draft is on the way. Expect end of April.

Date: Fri, 6 Mar 1998 14:18:28 -0400
To: "William H. Geiger III" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: S/MIME wins
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Sender: [email-masked]

At 1:07 PM -0400 3/6/98, William H. Geiger III wrote:

   Well who is working on these drafts? where are they? And what needs to be
   done to get them finished??

   I started making phone calls yesterday trying to find out the status of
   things but could not reach anyone. I have a lot of time and effort tied up
   in this too see it get pissed away before the race even gets started.

The next draft of formats is almost done. It'll be out next week.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 06 Mar 98 12:07:26 -0500
To: [email-masked] (Lutz Donnerhacke), [email-masked]
Subject: Re: S/MIME wins
Sender: [email-masked]

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

In <[email-masked]>, on 03/06/98 
   at 08:49 AM, Paul Hoffman / IMC <[email-masked]> said:

>>If that is the case, S/MIME by default could emerge as the dominant
>standard."

>And, if that is not the case, OpenPGP has the chance to "win". However,
>it will take more work than is being shown in this Working Group. It's
>been three months since the DC IETF meeting, but we haven't seen a second
>draft of the main spec or the first draft of the MIME integration spec.

>>From the discussion on this list, it looks like there are still thorny
>issues left in the main draft. The only way to for OpenPGP to finish is
>for it to keep going.

Well who is working on these drafts? where are they? And what needs to be
done to get them finished??

I started making phone calls yesterday trying to find out the status of
things but could not reach anyone. I have a lot of time and effort tied up
in this too see it get pissed away before the race even gets started.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------

Tag-O-Matic: Windows: an Unrecoverable Acquisition Error!

Date: Fri, 06 Mar 1998 08:49:38 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME wins
Sender: [email-masked]

>If that is the case, S/MIME by default could emerge as the dominant
standard."

And, if that is not the case, OpenPGP has the chance to "win". However, it
will take more work than is being shown in this Working Group. It's been
three months since the DC IETF meeting, but we haven't seen a second draft
of the main spec or the first draft of the MIME integration spec.

>From the discussion on this list, it looks like there are still thorny
issues left in the main draft. The only way to for OpenPGP to finish is for
it to keep going.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: S/MIME wins
Date: 6 Mar 1998 14:31:04 GMT
Organization: IKS GmbH Jena
Lines: 16
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

http://www.techweb.com/se/directlink.cgi?INW19980216S0024

"(...)
Among U.S. campanies, momentum is building in favor of S/MIME. Both
Microsoft and Netscape Communications have S/MIME clients and Lotus and
Novell have announced support for S/MIME. Only Qualcomm Inc., maker of
the Eudora E-mail client, supports PGP/MIME.

At the IETF, the S/MIME working group is about one month away from
completing its work on the specification. The OpenPGP group, however, has
not updated the draft of its specification since October, when group
members identified a number of problems. Both groups had agreed to submit
their final drafts next month, but it is unlikely the PGP group can
finish.

If that is the case, S/MIME by default could emerge as the dominant standard."