Subject: Re: undefined MAY algorithm example (Re: Question and note)
From: Uri Blumenthal <[email-masked]>
To: [email-masked] (Paul Lambert)
Cc: [email-masked]
Date: Wed, 1 Jul 1998 02:43:47 -0400 (EDT)

Paul Lambert says:
> >So I doubt that open-pgp will be able to include ECC.
> 
> If open-pgp contains RSA why can't it contain ECC?

Because today it is possible to have a free and legal
implementation of RSA. But it is not possible to have
a free and legal implementation of ECC. 

Several people and companies have various patents, the
rumor is that even some CURVES have been patented - so
how would you suggest the implementors of free 
software to deal with it? In my view the
simplest is to just leave that mirky
thing alone.

> ECC is an option in open-pgp and not mandatory. It is a very useful option
> that should have equal status to other patented algorithms.

I don't argue the usefulness of ECC - only its [in]availability for
the free code developers.

> Certicom has
> very reasonable licensing terms (as compared to other un-named companies
> with three letter acronyms in their names).  

Here we are not talking about commercial licensing.

> Certicom would issue a
> non-commercial use license for ECC in open-pgp that would allow broad
> "personal use" by the open-pgp community. 

That would be THE way. How close is Certicom to actually formulating
the non-commercial Personal Use Only license?

Oh, and is it true that there are other (non-Certicom) patents (such as
on the individual curves themselves etc.) that may require licensing
and thus may affect the free software developers? I assume that
Certicom might be aware of what parts of the field are 
covered, and if so - might be nice enough to share
that info?

> Certicom would charge for
> business use of ECC in open-pgp at our very low rates (we have to find some
> way to hordes of Ph.D. mathematicians in our research labs).

Of course. Nobody objects to that.

> In reviewing the specification, it does appear that some additional details
> would be useful to better define ECC in open-pgp.  I will try to get some
> of our cryptographers to submit some algorithm and parameter related text.

Cool. Thanks for the good news!
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 30 Jun 1998 23:03:41 -0400
From: [email-masked]
To: Paul Lambert <[email-masked]>
cc: [email-masked]
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

On Tue, 30 Jun 1998, Paul Lambert wrote:

> >So I doubt that open-pgp will be able to include ECC.
> 
> If open-pgp contains RSA why can't it contain ECC?
> 
> ECC is an option in open-pgp and not mandatory. It is a very useful option

now you can see why people like me MAY get confused ;).

MAY requires specific definition.  We don't have that.  EC will require
parameters (MPIs in a specific order and any other parameters needed).
Until this is completed, it can't be a MAY (but the algorithm ID will stay
in but marked "reserved").

The problem is that if I go ahead and do something with ECC (I already
aborted something based on the EC in Peter Gutmann's Cryptlib, and
another one I saw elsewhere), someone else may store the parameters in a
different order or use a different variant that uses parameters with
different definitions.

> In reviewing the specification, it does appear that some additional details
> would be useful to better define ECC in open-pgp.  I will try to get some
> of our cryptographers to submit some algorithm and parameter related text.

I might be able to start there - DH and even DSA were simple enough to do
from reading Applied Cryptography.

If you can get some sample code or information to me so that I can create
an implementation (my opgp library is sort of an unofficial reference
implementation), I will put it in and copy any license terms, but I will
need URLs or pointers or the source to include somewhere.  I haven't read
up on elliptic curves so application notes would be more helpful than a
mathematical treatise.

We are at final call, so I don't know if it would make it (if it is
undefined, or I can't be sure I implemented it right, it will move from
MAY to reserved-for).

(It sounds like your terms are similar to RSAref or IDEA).

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

From: "Paul Lambert" <[email-masked]>
To: [email-masked]
cc: [email-masked] (Adam Back), [email-masked]
Date: Tue, 30 Jun 1998 18:57:19 -0700
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

>So I doubt that open-pgp will be able to include ECC.

If open-pgp contains RSA why can't it contain ECC?

ECC is an option in open-pgp and not mandatory. It is a very useful option
that should have equal status to other patented algorithms.  Certicom has
very reasonable licensing terms (as compared to other un-named companies
with three letter acronyms in their names).  Certicom would issue a
non-commercial use license for ECC in open-pgp that would allow broad
"personal use" by the open-pgp community.  Certicom would charge for
business use of ECC in open-pgp at our very low rates (we have to find some
way to hordes of Ph.D. mathematicians in our research labs).

In reviewing the specification, it does appear that some additional details
would be useful to better define ECC in open-pgp.  I will try to get some
of our cryptographers to submit some algorithm and parameter related text.

Regards,

Paul

Adam Back says:
> I just read the spec end to end, and I think I found an example of the
> sort of problem Tom is referring to, from:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-formats-05.txt
> ............... For example (as Tom has been pointing out) it says
> Elliptic Curve.........
> PROBLEM: no definition of any Elliptic Curve parameters.

Elliptic Curve Cryptosystem is a VERY nice idea. Unfortunately,
despite the fac that its inventors intentionally did not patent
it, it is vastly covered by various patents. I heard that even
some eliptic curves have been patented! [How stupid was I not
to patent myself a few millions of primes. :-]

For at least some of those patents there appears to be no
freeware route (i.e. you pay for licening regardless).

So I doubt that open-pgp will be able to include ECC.
--
Regards,
Uri       [email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: Undefined and underdefined algorithms
To: [email-masked]
Date: Tue, 30 Jun 1998 21:14:46 -2800 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> Maybe I have uncovered another ambiguity

Maybe (:-)

> For 3DES I have:
> 
>     des_set_key((des_cblock *) key, ctx->ck.dk[0]);
>     des_set_key((des_cblock *) & key[8], ctx->ck.dk[1]);
>     des_set_key((des_cblock *) & key[16], ctx->ck.dk[2]);
> 
> Which is going 8 bytes between keys, If DES is 56 bit and not 64 bit the
> extra bytes are being wasted (the DES key size is 24 - should it have been
> 21?).

Since parity bits are never used (some implementation enforce that
they indeed are parity, some just ignore them), indeed the "real"
key length is 21 byte, not 24... (as 24 bits or three full bytes
are unusable from the security point of view).

> So I assume you would mean that it takes 16 bytes of key material.

DES/SK does not do that parity-bit business, thus every key bit is
"real". So 128-bit key gives full 16 bytes (like IDEA, only better :-).

> > .....[It isn't worth extending
> > to 128-bit, because the main idea was to preserve the "original" DES...
> > All the cryptanalytic tests done on DES apply fully. Once we start doin'
> > something to the rounds (besides increasing their number :-), many bets
> > are off.]
> 
> It also avoids worrying aobut the CFB length.

(:-)  This is the least of my worries.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 30 Jun 1998 19:55:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Uri Blumenthal <[email-masked]>
cc: [email-masked]
Subject: Re: Undefined and underdefined algorithms
Sender: [email-masked]

On Tue, 30 Jun 1998, Uri Blumenthal wrote:

> [email-masked] says:
> > > 2. The algorithm allows variable-length key. I say - make it 128 bits
> > >    for the sake of simplicity.
> > 
> > I assume this is the key material.
> 
> Hm... "Key material" isn't "officially" standard, so...
> 
> When people say "56-bit DES' - this is the key they mean.
> When they say "80-bit SKIPJACK" or "128-bit IDEA" - that's the key.
> 
> So here the key can be whatever you wish (between 40 and 256 bits),
> and I suggest to fix it at 128, because [in my understanding] a
> user isn't likely to input that key directly anyway. On the
> other hand, if you see it feasible to allow variable-ness,
> I of course won't mind. Or if you prefer a different length
> value (say, 256, or 80, or 96) - I can live with it too.

Maybe I have uncovered another ambiguity

For 3DES I have:

    des_set_key((des_cblock *) key, ctx->ck.dk[0]);
    des_set_key((des_cblock *) & key[8], ctx->ck.dk[1]);
    des_set_key((des_cblock *) & key[16], ctx->ck.dk[2]);

Which is going 8 bytes between keys, If DES is 56 bit and not 64 bit the
extra bytes are being wasted (the DES key size is 24 - should it have been
21?).

So I assume you would mean that it takes 16 bytes of key material.

> all of the DES round finction - it's 64-bit.  [It isn't worth extending
> to 128-bit, because the main idea was to preserve the "original" DES...
> All the cryptanalytic tests done on DES apply fully. Once we start doin'
> something to the rounds (besides increasing their number :-), many bets
> are off.]

It also avoids worrying aobut the CFB length.

Thanks!

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

From: Uri Blumenthal <[email-masked]>
Subject: Re: Undefined and underdefined algorithms
To: [email-masked]
Date: Tue, 30 Jun 1998 18:59:43 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> > 2. The algorithm allows variable-length key. I say - make it 128 bits
> >    for the sake of simplicity.
> 
> I assume this is the key material.

Hm... "Key material" isn't "officially" standard, so...

When people say "56-bit DES' - this is the key they mean.
When they say "80-bit SKIPJACK" or "128-bit IDEA" - that's the key.

So here the key can be whatever you wish (between 40 and 256 bits),
and I suggest to fix it at 128, because [in my understanding] a
user isn't likely to input that key directly anyway. On the
other hand, if you see it feasible to allow variable-ness,
I of course won't mind. Or if you prefer a different length
value (say, 256, or 80, or 96) - I can live with it too.

> > 3. Key schedule is described completely and explicitly in the paper
> >    I e-mailed to several list participants a while ago. 
> 
> Is there a URL?  You may want to upload it
> (to ftp://www.cryptography.org/pub/incoming if it is nonexportable).

Steve Bellovin has it on his Web:

	http://www.research.att.com/~smb/papers/ides.ps

I have a slightly updated copy (basically explains how and why DES/SK
is immune to related-key attacks).

Oh, and my attempt to upload it failed miserably - ftp doesn't get
a login prompt.

> > 4. Parts of the source code are available (alas, very incomplete).
> 
> This creates a problem.  If I can't do something like encrypt
> "abcdefghijklmnopqrstuvwxyz" and verify that it encrypts to 0x365ef2a or
> whatever. 

Look at it from a different prospective: whatever you do IS the
etalon for verification. (:-)

> > 5. The main "crypto" engine uses straight DES rounds, so everything
> >    applicable to DES (source code, docs etc) applies here.
> >    What it does is: takes the user key, does some funny things with
> >    it that are described on the algorithmic level in the paper, use
> >    the result as a longer key schedule for DES but iterate not 16
> >    but 32 rounds.
> 
> I would have to see the details.

Try to take a look at the paper, OK? Please let me know if it isn't
sufficiently clear, or if something doesn't jive...

> > 6. The mode can be PGP-CFB. Text prefixed with <BLKSIZE>+2 random bytes,
> >    zero IV.
> 
> and BLKSIZE is?

Since DES is 64-bit, and since it used part of the DES key schedule and
all of the DES round finction - it's 64-bit.  [It isn't worth extending
to 128-bit, because the main idea was to preserve the "original" DES...
All the cryptanalytic tests done on DES apply fully. Once we start doin'
something to the rounds (besides increasing their number :-), many bets
are off.]
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 30 Jun 1998 18:18:15 -0400
From: [email-masked]
To: Uri Blumenthal <[email-masked]>
cc: [email-masked]
Subject: Re: Undefined and underdefined algorithms
Sender: [email-masked]

On Tue, 30 Jun 1998, Uri Blumenthal wrote:

> OK, being "responsible" for DES/SK, here's what should remove any
> ambiguity left:
> 
> 1. The algorithm allows variable number of rounds. I say - use 32 rounds
>    (to be strength-equivalent to 3DES).

> 2. The algorithm allows variable-length key. I say - make it 128 bits
>    for the sake of simplicity.

I assume this is the key material.

> 3. Key schedule is described completely and explicitly in the paper
>    I e-mailed to several list participants a while ago. 

Is there a URL?  You may want to upload it
(to ftp://www.cryptography.org/pub/incoming if it is nonexportable).

> 4. Parts of the source code are available (alas, very incomplete).

This creates a problem.  If I can't do something like encrypt
"abcdefghijklmnopqrstuvwxyz" and verify that it encrypts to 0x365ef2a or
whatever. 

> 5. The main "crypto" engine uses straight DES rounds, so everything
>    applicable to DES (source code, docs etc) applies here.
> 
>    What it does is: takes the user key, does some funny things with
>    it that are described on the algorithmic level in the paper, use
>    the result as a longer key schedule for DES but iterate not 16
>    but 32 rounds.

I would have to see the details.

> 6. The mode can be PGP-CFB. Text prefixed with <BLKSIZE>+2 random bytes,
>    zero IV.

and BLKSIZE is?

From: Uri Blumenthal <[email-masked]>
Subject: Re: undefined MAY algorithm example (Re: Question and note)
To: [email-masked] (Adam Back)
Date: Tue, 30 Jun 1998 17:30:14 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> I just read the spec end to end, and I think I found an example of the
> sort of problem Tom is referring to, from:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-formats-05.txt
> ............... For example (as Tom has been pointing out) it says
> Elliptic Curve.........
> PROBLEM: no definition of any Elliptic Curve parameters.

Elliptic Curve Cryptosystem is a VERY nice idea. Unfortunately,
despite the fac that its inventors intentionally did not patent
it, it is vastly covered by various patents. I heard that even
some eliptic curves have been patented! [How stupid was I not
to patent myself a few millions of primes. :-]

For at least some of those patents there appears to be no
freeware route (i.e. you pay for licening regardless).

So I doubt that open-pgp will be able to include ECC.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: Undefined and underdefined algorithms
To: [email-masked]
Date: Tue, 30 Jun 1998 17:22:28 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

Paul Hoffman / IMC says:
> I suggest that the editors add an unambiguous reference for every 
> algorithm listed in section 9, and remove all the ones for which 
> no such reference exists.

OK, being "responsible" for DES/SK, here's what should remove any
ambiguity left:

1. The algorithm allows variable number of rounds. I say - use 32 rounds
   (to be strength-equivalent to 3DES).

2. The algorithm allows variable-length key. I say - make it 128 bits
   for the sake of simplicity.

3. Key schedule is described completely and explicitly in the paper
   I e-mailed to several list participants a while ago. 

4. Parts of the source code are available (alas, very incomplete).

5. The main "crypto" engine uses straight DES rounds, so everything
   applicable to DES (source code, docs etc) applies here.

   What it does is: takes the user key, does some funny things with
   it that are described on the algorithmic level in the paper, use
   the result as a longer key schedule for DES but iterate not 16
   but 32 rounds.

6. The mode can be PGP-CFB. Text prefixed with <BLKSIZE>+2 random bytes,
   zero IV.

Tom, if there are any ambiguities, I'd like to hear.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
To: [email-masked] (Adam Back)
Date: Tue, 30 Jun 1998 12:23:14 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> Re. the discussion of how to cope with combined random-prefix/checksum
> method with stream ciphers, this is a not an immediate problem because
> there are no stream ciphers listed as MAY/SHOULD/MUST algorithms
> currently.

I agree. However this shouldn't stop us from figuring out how to
deal with them, especially if a straightforward solution can be
found (I even claim it's obvious :-).

> A stream cipher would suffer even worse from attacks modifying known
> plaintext than conventionally encrypted data without MACs.

Certainly. Picking nits, it's not MACs that you mean, it's MDCs.
[Modification Detection Codes].

> A stream cipher would also be problematic if used for conventionally
> encrypted messages, and conventionally encrypted private keys on the
> private keyring -- the symmetric key is derived from the passphrase,
> which means you get the same key each time.

First - an observation. Just like a block cipher must have an IV (PGP
side-stepped this by prepending the message with random stuff), a
stram cipher must have a stream offset.

For messages it may be not as crucial, as the symmetric cipher key is
supposed to be random anyway (still IMHO having an offset helps).

For the keys to have a stream offset can mean the difference between
secure and insecure.

> Even using the Symmetric-Key Encrypted Session Key packets are dubious
> unless you start using a block cipher for the SKESK packet.

I do not see why.

> This suggests to me that stream ciphers need to be designed for
> properly before being put in, and that this can wait for next version.

(:-) No arguments from me.

> : Note that for an algorithm that has a larger block size than 64
> : bits, the equivalent function will be done with that entire block.
> 
> Though Jon and Tom are it sounds like suggesting changing 8 and 10 to
> blocksize and blocksize+2 to clarify.

This clarification is needed, I think.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 30 Jun 1998 08:59:50 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: What is MAY NOT
Sender: [email-masked]

At 08:38 AM 6/30/98 -0700, Paul Hoffman / IMC wrote:
   At 03:33 PM 6/30/98 +0200, Werner Koch wrote:

   >I did not found MAY NOT in rfc2119 and I guess is should be replaced
   >by SHOULD NOT.
   
   That looks like it was meant to be a MUST NOT, not a SHOULD NOT. That is,
   under no other circumstances can you use partial body lengths.
   
This is already a typo that's been corrected to MUST NOT. I also searched
the text for other occurrances of MAY NOT; the words only appear in the
standard boilerplate copyright in lower case.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 30 Jun 1998 08:44:46 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Undefined and underdefined algorithms
Sender: [email-masked]

I agree with the folks who have been saying that the spec should not even
list algorithms for which there isn't a solid reference about exactly how
to do the algorithm, including the exact parameters. For example, saying
"18 - elliptic curve" is sure to get you into much more trouble with
interoperability than not saying anything about elliptic curve. Company A
will choose one flavor of elliptic curve, Company B will choose another,
and they will publicly berate each other for doing the wrong thing.

This spec is about interoperability, and keeping focused on that now will
prevent a lot of debate and bad will in the future. I suggest that the
editors add an unambiguous reference for every algorithm listed in section
9, and remove all the ones for which no such reference exists.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 30 Jun 1998 08:38:02 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: What is MAY NOT
Sender: [email-masked]

At 03:33 PM 6/30/98 +0200, Werner Koch wrote:
>In section:
>
>  4.2.3. Packet Length Examples
>  [....]
>     they literal, compressed, or encrypted. The first partial length
>     MUST be at least 512 octets long. Partial Body Lengths MAY NOT be
>     used for any other packet types.
>
>I did not found MAY NOT in rfc2119 and I guess is should be replaced
>by SHOULD NOT.

That looks like it was meant to be a MUST NOT, not a SHOULD NOT. That is,
under no other circumstances can you use partial body lengths.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 30 Jun 1998 15:33:24 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: What is MAY NOT
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In section:

  4.2.3. Packet Length Examples
  [....]
     they literal, compressed, or encrypted. The first partial length
     MUST be at least 512 octets long. Partial Body Lengths MAY NOT be
     used for any other packet types.

I did not found MAY NOT in rfc2119 and I guess is should be replaced
by SHOULD NOT.

Werner

Date: Tue, 30 Jun 1998 08:51:16 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: 128 bit block ciphers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> This version or next version?  For this version I would leave a note that
> the CFB is going to change as I noted above - as I pointed out, all
> current algorithms happen to use 8 byte blocks.  The next version should
> define this correctly though.  I think I can interoperate with everything

I agree with Tom, leave it as it is.  We can do these changes in the
next version.

Werner

Date: Mon, 29 Jun 1998 23:31:00 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: areas of spec incomplete? (Re: Question and note)
Sender: [email-masked]

On Mon, 29 Jun 1998, Adam Back wrote:

> Would you like to kick off with a list of still outstanding problems?

In some offline discussions, moving ambiguous things to an
ID N - Reserved for whatever
type form is good.

The X9.42 DH, EC, and ECDSA should be moved to reserved.

TIGER should be reserved until we agree on how to handle it - it is too
wide for DSA, and doesn't have an OID, but I would like to keep the
algorithm ID fixed.

HAVAL can be used with DSA, but has no OID, so I am neutral.

DSA can theoretically be used with MD2, MD5 and RIPEMD160, but I suggest
prefixing zero octets if the hash size is less than 160.  (Another
alternative is to mask out the upper bits which can be made random). 

I am the only one AFAIK to implement SAFER/SK-128.  This can be left as
assigned or moved back to reserved if anyone is unsure that I did things
right.

DES/SK was supposed to have a reference implementation available by now,
but I have seen no news on the list and haven't been paying attention to
what is going on with AES.  If it isn't implemented yet, this should back
up to a reserved algorithm ID.

We should add "7 -Reserved for AES" since that will eventually exist.

I am open to reserving IDs for other algorithms.

The CFB when blocksize is not 8 is still a problem, but less so since no
assigned algorithms I know of use anything other than 8.

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

Date: Tue, 30 Jun 1998 03:02:53 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

Uri Blumenthal writes:
> [email-masked] says:
> > .........
> > I would rather delete every assigned algorithm number that isn't likely to
> > be implemented for public consumption than to have those show up, one per
> > implementation so no two implementations can talk except with RSA/IDEA/MD5
> > or DH/DSA/SHA1/3DES since my code will be much smaller if I just
> > implement these two subsets exactly.  
> 
> MAY are the algorithms that is entirely up to you to have or not to
> have. So the keys that are "for real" aren't likely to be of one of
> them... 

I just read the spec end to end, and I think I found an example of the
sort of problem Tom is referring to, from:

http://www.ietf.org/internet-drafts/draft-ietf-openpgp-formats-05.txt

: 9.1. Public Key Algorithms
: 
:        ID           Algorithm
:        --           ---------
:        1          - RSA (Encrypt or Sign)
:        2          - RSA Encrypt-Only
:        3          - RSA Sign-Only
:        16         - Elgamal (Encrypt-Only), see [ELGAMAL]
:        17         - DSA (Digital Signature Standard)
:        18         - Elliptic Curve
:        19         - ECDSA
:        20         - Elgamal (Encrypt or Sign)
:        21         - Diffie-Hellman (X9.42)
:        100 to 110 - Private/Experimental algorithm.
: 
:    Implementations MUST implement DSA for signatures, and Elgamal for
:    encryption. Implementations SHOULD implement RSA keys.
:    Implementations MAY implement any other algorithm.

This is wrong.  For example (as Tom has been pointing out) it says
Elliptic Curve.  But then it says:

:    Implementations MAY implement any other algorithm.

implying that 18 for Elliptic Curve is more than reserved, in fact
_stating_ that you MAY go ahead implement it.  

PROBLEM: no definition of any Elliptic Curve parameters.

I would suggest either deleting 18, 19, 21, or marking them as
reserved (which means you MUST NOT borrow this ID number for your
variant/interpretation of how one might implement this algorithm).

Btw what is 21, is this real Diffie-Hellman? or Elgamal referred to as
Diffie-Hellman?  And how can real Diffie-Hellman work as a OpenPGP
cipher because you can't choose the negotiated key, and therefore
can't store information inside the ESK as with other keys.

> MAY class says: "If you decide to do this - here is how it must be
> done." So that *if* two implementations both have a common subset of
> the MAY class, they could interoperate using them, too.

Precisely.  But as Tom says, and as the exerpt from the draft above
demonstrates, the draft is listing things as MAYs which are not
defined at all.

Adam
-- 
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: Tue, 30 Jun 1998 03:22:08 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: stream ciphers (Re: 128 bit block ciphers)
Sender: [email-masked]

Re. the discussion of how to cope with combined random-prefix/checksum
method with stream ciphers, this is a not an immediate problem because
there are no stream ciphers listed as MAY/SHOULD/MUST algorithms
currently.

A stream cipher would suffer even worse from attacks modifying known
plaintext than conventionally encrypted data without MACs.

A stream cipher would also be problematic if used for conventionally
encrypted messages, and conventionally encrypted private keys on the
private keyring -- the symmetric key is derived from the passphrase,
which means you get the same key each time.

Even using the Symmetric-Key Encrypted Session Key packets are dubious
unless you start using a block cipher for the SKESK packet.

This suggets to me that stream ciphers need to be designed for
properly before being put in, and that this can wait for next version.

re. larger block ciphers, the current draft does actually specify what
to do:

: Note that for an algorithm that has a larger block size than 64
: bits, the equivalent function will be done with that entire block.

Though Jon and Tom are it sounds like suggesting changing 8 and 10 to
blocksize and blocksize+2 to clarify.

Adam

Date: Mon, 29 Jun 1998 18:44:51 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Question and note
Sender: [email-masked]

At 06:32 PM 6/29/98 -0700, Paul Hoffman / IMC wrote:

   Uhhh, all I see in the intro is "RFC 1991". RFC 2119 is the definition of
   MUST, SHOULD, and MAY. You do have it in section 16, but there's nothing in
   the body referring to it.
   
   As someone who has started to become number dsylexic in the past few years,
   I can understand this one slipping by...
   
Mea culpa. You're right, I'm being numeral-dyslexic. I guess you can ignore
my off-list mail to you asking if you think I should have a 2119 ref in the
into, 'cause the answer is obvious now.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: Uri Blumenthal <[email-masked]>
Subject: Re: 128 bit block ciphers
To: [email-masked]
Date: Mon, 29 Jun 1998 21:33:05 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> > I'm for adding a checksum. Would be more reliable too. [Possibly it's
> > too late for that... Oh well...]
> 
> And was rejected when I originally suggested it although I brought up this
> specific problem, though not in the context of block ciphers.  Right now
> you have to stack each passphrase for a try (and may still get wrong 1/64k
> of the time).  Were there a checksum you could tell if any SKESK was
> correct before going further in the header, just as you can tell if the
> PKESK is correct.
> At the time, it would have only broken PGP 5.0.  Now it would break at
> least two more implementations. 

So maybe it should be reopened now? After all, what's right is right,
and what's wrong will turn around and bite your ***, eventually. And
it seems that the "biting-time" with no-checksum is approaching...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 29 Jun 1998 18:32:26 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Question and note
Sender: [email-masked]

At 02:30 PM 6/29/98 -0700, Jon Callas wrote:
>At 08:06 AM 6/29/98 -0700, Paul Hoffman / IMC wrote:
>
>   Jon: you don't have a reference to RFC 2119 in this document, which seems
>   to be the basis for the misunderstanding. Please put an explicit
pointer to
>   RFC 2119 in section 1.1 and a reference to it in section 16. Also, someone
>   should do a scan of the document for the RFC 2119 words and make sure that
>   is what we mean.
>   
>It was in section 16 and in the introduction, but I added language in 1.1
>that says that PGP 2.6 is decribed in it.

Uhhh, all I see in the intro is "RFC 1991". RFC 2119 is the definition of
MUST, SHOULD, and MAY. You do have it in section 16, but there's nothing in
the body referring to it.

As someone who has started to become number dsylexic in the past few years,
I can understand this one slipping by...

--Paul Hoffman, Director
--Internet Mail Consortium

From: Uri Blumenthal <[email-masked]>
Subject: Re: Question and note
To: [email-masked]
Date: Mon, 29 Jun 1998 21:25:30 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> Well we have common IDs, but no specs for what a lot of the IDs point to.
> No Detail.  So there are lots of different and non interoperable ways
> of implementing what already is there.  And that is my point.

Hmm... Why didn't you say so. With this point I can't argue.

> Except lots of these already exist in this state in the existing spec.So
> the current spec is stupid?  It isn't *reserving* numbers for algorithms,
> it is *defining* them.  And without specifying all the details.

Without answering the question, I'd say that a list of discrepancies
would make fixing those less-than-perfect specs easier.  I certainly
wouldn't like just throwing the "unclean" pieces out. Making them
"clean" would be the best.

> You want to add incomplete definitions of new algorithms to the
> existing incomplete definitions and submit the spec in this incomplete
> state?

Hmm... A good question (at last :-).

Had I any time before September (I'm working on two publications and
am behind the schedule as is)  I'd have said "Yes and I'll make 'em
complete." As it goes, I won't be able to invest any efforts worth 
mentioning until September. By then it probably will be solved
one way or another...

> The spec ..............does say (5.7):
>    The body of this packet consists of:
>      - Encrypted data, the output of the selected symmetric-key cipher
>        operating in PGP's variant of Cipher Feedback (CFB) mode.
> and so on, implying that ALL algorithms must use the CFB mode.

So what do we do with stream ciphers? Leave them alone until the
next version? [I could live with that decision.]

> ...PGP-CFB and advertised the fact and no one said anything about me getting
> it wrong, so I assume I got it right - and I asked about DES/SK at that
> time. ID 6 means DES/SK in PGP-CFB mode.  That is what the spec says. 

Damn. I dislike this PGP-CFB mode, but I can live with it.

> If you want it in "raw" CFB it would need another ID.  

Nein. I don't want it in "raw" CFB bad enough to justify a whole
new ID. My sanity check won't permit it. (:-)

> The spec should say a lot of things.  I can only go by what it actually
> does say.  And it says I "MAY" implement this algorithm - DES/SK-PGP/CFB.
> And I plan to if it remains in the spec as soon as I obtain source for the
> algorithm. This detail has been around for months.Did anyone else notice it?  
> How would anyone else have implemented DES/SK - raw, raw-cfb, or PGP-CFB?

So let's make the spec to state explicitly:
	UNless Otherwise Specified, all the block ciphers are to be
	implemented in PGP-CFB-<Blocksize> mode.

> .............You can blame the people who came up
> with the broken standard, but I don't see anyone who has stopped using the
> broken implementations, and worse, new implementations must copy the bad
> features.  History shows that correct implementation don't superceed
> broken ones - they adopt the flaws in order to interoperate.

A good point. However you're talking about major features of major
very popular products - where being incompatible with an earlier
released bug is instantly and unpleasantly noticeable...

> If those advocating the algorithms won't take the time to insure they are
> specified completely and correctly, who is going to take time to do the
> harder job of implementing them correctly?  Especially when the correct
> implementation may not be the one in the spec.

A fair point. But speaking for myself, I won't be able to contribute
until September.

> So there are three alternatives:
> 
> 1. Delete the unimplementable algorithms (reserving the numbers) and hope
>    that someone wants to define them in the next revision, but submitting
>    a clean spec.

Not nice...

> 2. Don't submit the spec until these things are defined (and I don't
>    see anyone rushing to do the necessary legwork so this might take a
>    very long time).

The most "right" but probably unacceptable because of time...

> 3. Submit a spec with ambiguities that will create lots of opportunites
>    for interoperability problems.
> My original post was a fourth suggestion:
> 4. Leave the ambiguities in but identify them and tell implementors not to
>    use them widely because they are ambiguous and won't interoperate
>    because the details are unclear.
> I am open to a number 5 if anyone has one.  I am against number 3. Many
> have expressed that we need to get something out now, so #2 is probably
> not acceptable.

To identify and list the ambiguities is good. I suspect that when you do 
that, it turns into a correction/solution list...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 29 Jun 1998 20:45:43 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: 128 bit block ciphers
Sender: [email-masked]

On Mon, 29 Jun 1998, Uri Blumenthal wrote:

> [email-masked] says:
> > > To add security you need an offset in a generated cryptostream. Which
> > > (the offset) necessarily should go in the clear.
> > 
> > The problem is there is no other way to determine if a key is correct than
> > to match the final pairs of bytes in the prefix.  It adds no security, but
> > without any means of checksumming the symmetrically encrypted ESKs, you
> > can't tell which of the passphrases actually match.  I suggested adding a
> > checksum to the SKESK, but that was shot down. 
> 
> Hmm... In block ciphers that random prefix does add a little bit of
> security and does make a non-zero IV unnecessary. In stream ciphers
> prefix does nothing and an IV (or a "stream offset") is a-must.
> 
> None of these is really good for checksumming. 
> While the existing solution that uses block cipher(s) copes with the 
> issue well, stream ciphers throw a monkey wrench into the gears. Yes
> it is possible to have both random prefix and random offset,  but it
> ain't look nice.
> 
> I'm for adding a checksum. Would be more reliable too. [Possibly it's
> too late for that... Oh well...]

And was rejected when I originally suggested it although I brought up this
specific problem, though not in the context of block ciphers.  Right now
you have to stack each passphrase for a try (and may still get wrong 1/64k
of the time).  Were there a checksum you could tell if any SKESK was
correct before going further in the header, just as you can tell if the
PKESK is correct.

At the time, it would have only broken PGP 5.0.  Now it would break at
least two more implementations. 

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

Date: Mon, 29 Jun 1998 20:37:11 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: 128 bit block ciphers
Sender: [email-masked]

On Mon, 29 Jun 1998, Jon Callas wrote:

> At 02:38 PM 6/29/98 -0400, [email-masked] wrote:
> 
>    I spotted this a few months ago.  Technically the prefix should be the
>    blocksize plus 2 and the text should be changed everywhere (including the
>    long description of the reset) replacing 8 with Blocksize.  I have these
>    as #defines in my implmentation but they are likely to become variables,
>    so I was ready for this.
> 
> I'm willing to do this -- replacing 8 with Blocksize, and 10 with
> Blocksize+2. It's an easy enough change that provides a lot of clarification.

This will be hard to get right.  There are a lot of places and I don't
think I found them all when I looked at it which is one of the reasons I
didn't suggest the change although I think I posted a note asking about
different block sizes.  The whole example at the end presupposes an 8 byte
block size.

>    For that matter, what is the block size of a stream cipher?  (Applause
>    with the sound of one hand clapping if you can answer correctly).  Or one
>    that is a number of bits that is not divisible by 8? 
> 
> The blocksize of a stream cypher is 1/8 octet. Octet-level stream cyphers
> (like RC4) can also be thought of as an 8-bit block cypher. Really.

Can be.  But it is simpler to pretend that they are 8 octet from a
implmentors point of view and this should not compromise security.  This
has not come up yet - how do you resynch with single bytes?

The worst questions aren't those without an answer, they are the questions
with several correct answers.

>    It would make sense to change the places that use "8" to Blocksize and
>    "10" to Blocksize+2, and do stream ciphers without any CFB (but prefix it
>    with either 4 or 10 bytes, the last pair being copies of the penultimate
>    pair).  This mod will have to be in the next version of the spec.
>    
> I'm willing to do this.

This version or next version?  For this version I would leave a note that
the CFB is going to change as I noted above - as I pointed out, all
current algorithms happen to use 8 byte blocks.  The next version should
define this correctly though.  I think I can interoperate with everything
wk is doing, so if he adds something we can verify that we both do it the
same way until work on 1.1 starts.

(is this final call or not?  Far less drastic and complex changes are
being rejected).

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

Date: Tue, 30 Jun 1998 01:31:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: areas of spec incomplete? (Re: Question and note)
Sender: [email-masked]

Personally I find Tom's input to this working group very useful, as
his input is based on actually trying to implement an OpenPGP
implementation from the spec.

Tom writes:
> > Algorithm numbers are assigned so that IF two people decide to use
> > THAT particular algorithm, they have a common ID for it and a spec
> > they can follow to interoperate.
> 
> Well we have common IDs, but no specs for what a lot of the IDs point to.
> No Detail.  So there are lots of different and non interoperable ways
> of implementing what already is there.  And that is my point.

You appear to be saying that there are algorithms which are
incompletely defined.

I think we should distinguish between "ID reserved" and an algorithm
which is intended to be fully defined.

It seems reasonable to reserve an algorithm ID, even absent parameter
details (block mode, etc.,) as long as this ID is clearly marked as
reserved.  (I interpret this as "ID Reserved, don't implement yet".)

If there are algorithms which are intended to be defined, but are
incompletely defined (and Tom would know more than most about this
area having tried to implement as much as possible from the spec) then
they either need to be relegated to "ID reserved", or to have the gaps
filled in quickly!

Perhaps if we could clarify the intended development path for reserved
IDs, this area could be made more clear.

For example that they will be defined in a separate RFC? or that they
will be defined in future revisions of OpenPGP?  And some comment
accompanying them: that you should not implement them in the mean
time, or that it would be reasonable to discuss how to implement them
on list rather than rushing off and implementing and deploying some
random and possibly not-so-good selection of parameters.

> I thought the spec (for this revision) was in final call and isn't being
> written any further and editing is limited to only the most severe
> problems.  You want to add incomplete definitions of new algorithms to the
> existing incomplete definitions and submit the spec in this incomplete
> state?

An incomplete definition of an algorithm is a servere problem!  (And
that includes MAY algorithms.)

> I have been pointing these problems out for months.  Well it is now final
> call, so there is no time for me to repeat my questions about what is
> missing (or do I hear a suggestion that we don't submit the draft for
> another two months).  No one defined these things, nor have I seen any
> messages filling any gaps in the specifications. 

I think that the set of algorithms which go forward in as the final
document should be fully defined.  This could happen by filling such
gaps quickly now, and maybe by removing some algorithms, or by
demoting those algorithms which are not fully defined to be IDs
reserved for future use if necessary for timeliness.

Would you like to kick off with a list of still outstanding problems?

Adam
-- 
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: Mon, 29 Jun 1998 17:13:32 -0700
To: [email-masked], Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: 128 bit block ciphers
Cc: [email-masked]
Sender: [email-masked]

At 02:38 PM 6/29/98 -0400, [email-masked] wrote:

   I spotted this a few months ago.  Technically the prefix should be the
   blocksize plus 2 and the text should be changed everywhere (including the
   long description of the reset) replacing 8 with Blocksize.  I have these
   as #defines in my implmentation but they are likely to become variables,
   so I was ready for this.

I'm willing to do this -- replacing 8 with Blocksize, and 10 with
Blocksize+2. It's an easy enough change that provides a lot of clarification.
   
   For that matter, what is the block size of a stream cipher?  (Applause
   with the sound of one hand clapping if you can answer correctly).  Or one
   that is a number of bits that is not divisible by 8? 

The blocksize of a stream cypher is 1/8 octet. Octet-level stream cyphers
(like RC4) can also be thought of as an 8-bit block cypher. Really.
   
   It would make sense to change the places that use "8" to Blocksize and
   "10" to Blocksize+2, and do stream ciphers without any CFB (but prefix it
   with either 4 or 10 bytes, the last pair being copies of the penultimate
   pair).  This mod will have to be in the next version of the spec.
   
I'm willing to do this.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: Uri Blumenthal <[email-masked]>
Subject: Re: 128 bit block ciphers
To: [email-masked]
Date: Mon, 29 Jun 1998 20:10:52 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> > To add security you need an offset in a generated cryptostream. Which
> > (the offset) necessarily should go in the clear.
> 
> The problem is there is no other way to determine if a key is correct than
> to match the final pairs of bytes in the prefix.  It adds no security, but
> without any means of checksumming the symmetrically encrypted ESKs, you
> can't tell which of the passphrases actually match.  I suggested adding a
> checksum to the SKESK, but that was shot down. 

Hmm... In block ciphers that random prefix does add a little bit of
security and does make a non-zero IV unnecessary. In stream ciphers
prefix does nothing and an IV (or a "stream offset") is a-must.

None of these is really good for checksumming. 
While the existing solution that uses block cipher(s) copes with the 
issue well, stream ciphers throw a monkey wrench into the gears. Yes
it is possible to have both random prefix and random offset,  but it
ain't look nice.

I'm for adding a checksum. Would be more reliable too. [Possibly it's
too late for that... Oh well...]

> So you require a checksum like mechanism in the cryptostream. 

Yup.

> The simplest is to do the same type that the existing CFB system uses. 

Probably.  But is it the best...?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 29 Jun 1998 18:42:56 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: 128 bit block ciphers
Sender: [email-masked]

On Mon, 29 Jun 1998, Uri Blumenthal wrote:

> > It would make sense to change the places that use "8" to Blocksize and
> > "10" to Blocksize+2, and do stream ciphers without any CFB (but prefix
> > it with either 4 or 10 bytes, the last pair being copies of the
> > penultimate pair).  This mod will have to be in the next version of 
> > the spec.
> 
> MAY I suggest that prefixing for a stream cipher is rather useless?
> 
> To add security you need an offset in a generated cryptostream. Which
> (the offset) necessarily should go in the clear.

The problem is there is no other way to determine if a key is correct than
to match the final pairs of bytes in the prefix.  It adds no security, but
without any means of checksumming the symmetrically encrypted ESKs, you
can't tell which of the passphrases actually match.  I suggested adding a
checksum to the SKESK, but that was shot down.  So you require a checksum
like mechanism in the cryptostream.  The simplest is to do the same type
that the existing CFB system uses. 

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

From: Tim Hudson <[email-masked]>
Subject: Re: Question and note
To: [email-masked]
Date: Tue, 30 Jun 1998 08:39:03 +1000 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

According to [email-masked]:
> This is happening with TLS - no one does TLS.  Everyone does SSL2 or SSL3
> compelete with impelementation bugs that need to be compensated for so
> they are rarely true SSL2 or SSL3.  So there are three "definitions" of
> the protocol and lots of small implementation nits that must be coded for.
    Actually this isn't the case. TLS code is available and interoperability
testing has been occuring prior to ending up in products. We got the TLS
release available (and C2Net has it the current released version of Stronghold)
and other vendors have been doing interoperability testing with the SSLeay
implementation to iron out any "interesting" areas. This is done outside
of public view and basically at a technical implementors level.

    Our intent is to avoid the problem of having to permanently allow for
broken implementations after one or more major vendors ship code that doesn't
follow the specification which is what happens when there is nothing to test
against and the specification is complex.

Tim.

Date: Mon, 29 Jun 1998 18:30:11 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: Question and note
Sender: [email-masked]

On Mon, 29 Jun 1998, Uri Blumenthal wrote:

> [email-masked] says:
> 
> > If there is an algorithm number assigned, it would be useful if there was
> > a specific reason to use it and a likelyhood it would appear in many
> > implementations.  In this, I agree with PRZ that having extra algorithms
> > simply for the sake of having extra algorithms is not a good idea.
> 
> Algorithm numbers are assigned so that IF two people decide to use
> THAT particular algorithm, they have a common ID for it and a spec
> they can follow to interoperate.

Well we have common IDs, but no specs for what a lot of the IDs point to.
No Detail.  So there are lots of different and non interoperable ways
of implementing what already is there.  And that is my point.

> Sane ones would reserve the next number for AES and put together a mode
> in which AES should be used, because it would be even more stupid than
> keep this argument going, to think that it is enough to just define a
> cipher without specifying all the details, like mode, IV, prefix, key
> thingie and such.

Except lots of these already exist in this state in the existing spec.  So
the current spec is stupid?  It isn't *reserving* numbers for algorithms,
it is *defining* them.  And without specifying all the details.

> Don't you understand that an "implementable" algorithm specification must
> include such minute details as what mode it is to be used in, what kind 
> of key, what kind of IV if any etc...?  It is not enough to just have
> an implementable crypto-engine.
...
> Those who write the spec will have to decide whether they want "normal"
> CFB, PGP-CFB or both. In the unlikely case they want both - you will
> have to have TWO identifiers: one for the "normal" and one for the
> PGP-CFB. Naturally, a spe that doesn't tell that is incomplete.

I thought the spec (for this revision) was in final call and isn't being
written any further and editing is limited to only the most severe
problems.  You want to add incomplete definitions of new algorithms to the
existing incomplete definitions and submit the spec in this incomplete
state?

> > > The implementor, s****d. In your implementation - you do. So you
> > > must implement the MUST ones, you should implement the SHOULD 
> > > ones, and the rest is entirely up to you. What is there NOT
> > > to undertand?!
> > > 
> > > Now DO YOU get it??
> > 
> > So if you implement DES/SK as raw, using algorithm ID 6, it is my option
> > to implement a PGP-CFB DES/SK also using algorithm ID 6.
> 
> No... Sigh... The spec should say that DES/SK ID 6 uses "raw" CFB. If
> you want it with PGP-CFB, it would be ID 7, 17 or whatever.

The spec does not say this.  But it does say (5.7):

   The body of this packet consists of:

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in PGP's variant of Cipher Feedback (CFB) mode.

and so on, implying that ALL algorithms must use the CFB mode.  Nowhere
does it mention the use of any Cipher in "RAW" or raw-cfb mode and any
such exception should have been clearly stated.  I implemented SAFER in
PGP-CFB and advertised the fact and no one said anything about me getting
it wrong, so I assume I got it right - and I asked about DES/SK at that
time.

ID 6 means DES/SK in PGP-CFB mode.  That is what the spec says.  If you
want it in "raw" CFB it would need another ID.  The spec should say a lot
of things.  I can only go by what it actually does say.  And it says I
"MAY" implement this algorithm - DES/SK-PGP/CFB.  And I plan to if it
remains in the spec as soon as I obtain source for the algorithm.

This detail has been around for months.  Did anyone else notice it?  How
would anyone else have implemented DES/SK - raw, raw-cfb, or PGP-CFB?

> > For a new algorithm I might have the first working
> > implementation, and then *my* implmementation will be copied - modes and
> > other details and all (because I can verify messages and produce a test
> > suite).  So I might even kill an algorithm by doing a bad implementation
> > that gets widely adopted but rarely used. 
> 
> Unless somebody finds enough time and desire to to the implementation
> right - and then it would your implementation and its implementor that
> "reap the blame"...

Which is why PKCS12 has all problems since Microsoft didn't get it right
(neither did Netscape) and now everyone has to copy them?  I don't see
them moving to the correct implementations.  X509 has lots of small
problems that no one is correcting.  You can blame the people who came up
with the broken standard, but I don't see anyone who has stopped using the
broken implementations, and worse, new implementations must copy the bad
features.  History shows that correct implementation don't superceed
broken ones - they adopt the flaws in order to interoperate.  I already
gave the example of SSL/TLS.  All SSL implementations need to compensate
for bugs if they want to interoperate widely.

If those advocating the algorithms won't take the time to insure they are
specified completely and correctly, who is going to take time to do the
harder job of implementing them correctly?  Especially when the correct
implementation may not be the one in the spec.

I stand neutral on algorithms - I have done the work to make those I could
implementable so I know which ones are and what the problems are.  But I
wouldn't mind deleting many, and would prefer removing all that would
cause interoperability problems. 

> If you were asking quesitions like: "Algorithm X is not implementable
> cleanly because the spec doesn't tell A, B, C and D is unclear -  how
> do we define those missing links?", I'd applauded you. When you start 
> castrating the program, I become annoyed.

I have been pointing these problems out for months.  Well it is now final
call, so there is no time for me to repeat my questions about what is
missing (or do I hear a suggestion that we don't submit the draft for
another two months).  No one defined these things, nor have I seen any
messages filling any gaps in the specifications. 

So there are three alternatives:

1. Delete the unimplementable algorithms (reserving the numbers) and hope
   that someone wants to define them in the next revision, but submitting
   a clean spec.

2. Don't submit the spec until these things are defined (and I don't
   see anyone rushing to do the necessary legwork so this might take a
   very long time).

3. Submit a spec with ambiguities that will create lots of opportunites
   for interoperability problems.

My original post was a fourth suggestion:

4. Leave the ambiguities in but identify them and tell implementors not to
   use them widely because they are ambiguous and won't interoperate
   because the details are unclear.

I am open to a number 5 if anyone has one.  I am against number 3.  Many
have expressed that we need to get something out now, so #2 is probably
not acceptable.

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

Date: Mon, 29 Jun 1998 14:30:37 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Question and note
Sender: [email-masked]

At 08:06 AM 6/29/98 -0700, Paul Hoffman / IMC wrote:

   Jon: you don't have a reference to RFC 2119 in this document, which seems
   to be the basis for the misunderstanding. Please put an explicit pointer to
   RFC 2119 in section 1.1 and a reference to it in section 16. Also, someone
   should do a scan of the document for the RFC 2119 words and make sure that
   is what we mean.
   
It was in section 16 and in the introduction, but I added language in 1.1
that says that PGP 2.6 is decribed in it.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: Uri Blumenthal <[email-masked]>
Subject: Re: 128 bit block ciphers
To: [email-masked]
Date: Mon, 29 Jun 1998 15:59:45 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> > Wouldn't it be better to prefix it with 16 random bytes for 128 bit
> > ciphers?  Maybe we can remove the special CFB mode for these
> > ciphers?
> 
> I spotted this a few months ago.  Technically the prefix should be the
> blocksize plus 2 and the text should be changed everywhere (including
> the long description of the reset) replacing 8 with Blocksize. 

If a dictionary-building adversary is not a big concern, then prefixing
could be abandoned in favor of more traditional (i.e. non-zero) IV. One
advantage of it would be the ability to accomodate stream ciphers as
well. A disadvantage is: having a known (or a chosen) plaintext,
an adversary can put a few entries in his dictionary for the
given (but still unknown) key.

> For that matter, what is the block size of a stream cipher?  (Applause
> with the sound of one hand clapping if you can answer correctly).  Or
> one that is a number of bits that is not divisible by 8? 

Since stream cipher doesn't need IV but definitely requires an offset
(and if you can explain the difference in format between the two, one
hand clapping for you), it would be to a clear advantage to have a
non-zero IV (in clear) to accompany the encrypted data.

In that case weird questions like stream cipher blocksize could be
forgotten.

> Since no listed algorithm used a different block size it wasn't an
> issue (and why I will oppose adding any new ones, and am strongly 
> suggesting deleting some).

Tough, but those that WILL definitely BE ADDED will be different enough
to upset your whole apple cart.

> It would make sense to change the places that use "8" to Blocksize and
> "10" to Blocksize+2, and do stream ciphers without any CFB (but prefix
> it with either 4 or 10 bytes, the last pair being copies of the
> penultimate pair).  This mod will have to be in the next version of 
> the spec.

MAY I suggest that prefixing for a stream cipher is rather useless?

To add security you need an offset in a generated cryptostream. Which
(the offset) necessarily should go in the clear.

> Just say MAY and nits go away.

And if your feet bother you - cut 'em off. You'll also save on shoes.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 29 Jun 1998 14:38:16 -0400
From: [email-masked]
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: 128 bit block ciphers
Sender: [email-masked]

On Mon, 29 Jun 1998, Werner Koch wrote:

> I am just curious:
> 
> How does OpenPGP cope with 128 bit block ciphers (AES)?
> 
>    The data is encrypted in CFB mode, with a CFB shift size equal to
>    the cipher's block size.  The Initial Vector (IV) is specified as
>    all zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet
>    string to the data before it is encrypted.  The first eight octets
>    are random, and the 9th and 10th octets are copies of the 7th and
> 
> Wouldn't it be better to prefix it with 16 random bytes for 128 bit
> ciphers?  Maybe we can remove the special CFB mode for these ciphers?

I spotted this a few months ago.  Technically the prefix should be the
blocksize plus 2 and the text should be changed everywhere (including the
long description of the reset) replacing 8 with Blocksize.  I have these
as #defines in my implmentation but they are likely to become variables,
so I was ready for this.

For that matter, what is the block size of a stream cipher?  (Applause
with the sound of one hand clapping if you can answer correctly).  Or one
that is a number of bits that is not divisible by 8? 

Later the spec says:

   After encrypting the first 10 octets, the CFB state is resynchronized
   if the cipher block size is 8 octets or less.  

but as you point out, using an IV of all zeros might still compromise the
first few bytes (of possibly known plaintext).  The resynch should be BS+2
(similar problems occur with blocksizes smaller than 8).

Since no listed algorithm used a different block size it wasn't an issue
(and why I will oppose adding any new ones, and am strongly suggesting
deleting some).

It would make sense to change the places that use "8" to Blocksize and
"10" to Blocksize+2, and do stream ciphers without any CFB (but prefix it
with either 4 or 10 bytes, the last pair being copies of the penultimate
pair).  This mod will have to be in the next version of the spec.

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

Just say MAY and nits go away.

Date: Mon, 29 Jun 1998 14:18:00 -0400
From: [email-masked]
Reply-To: [email-masked]
cc: [email-masked]
To: <[email-masked]>
Subject: MAY use X where X is variable or undefined...
Sender: [email-masked]

On Mon, 29 Jun 1998, Paul Hoffman / IMC wrote:

> At 05:16 AM 6/29/98 -0400, [email-masked] wrote:
> >Because all these terms have no meaning to the end user, and probably not
> >to many of the implementors.
> 
> Well, end users won't be seeing this stuff if the implementors do it right.
> If the implementors don't understand the terms, we're in deep trouble.

It doesn't matter if I understand the difference between MUST, SHOULD and
MAY if there is ambiguity or contradiction in what I must, should or may
implement.  Implementors can "do it right" but still not interoperate
because there is more than one way of doing it right.  Most, if not all,
of the problems occur in the MAY sections of the specification.

The problem is not that the MAY algorithms are MAY, it is that many aren't
well enough defined to implement unambiguosly, but when I point the
implementation interoperability problems out the response is to the effect
that it doesn't matter *because* it is a "MAY".

I assume that RFC 2119 does not imply that "MAY" means that if implemented
"correctly" you can still have diverse noninteroperable implementations of
whatever is covered in the MAY.  I thought it only said there was
nothing wrong in leaving something out, although that something should be 
clearly defined.

Compression is a MAY (2.3), but ZIP is a SHOULD (9.3)?  But at least there
are no ambiguous algorithms, so if I do compress, I must use one of two
algorithms in the manner detailed in other RFCs (except to limit the
window size to interoperate with PGP 2.6).  If I want to use bzip2, it is
experimental and I don't have to worry about if the block size is 100k or
900k.  If there was a compression algorithm "3 - BZIP2" it would need to
specify the minimum compression block size and any other parameter which
might affect interoperability.  But in other areas things are less well
defined.

It is one thing if you do algorithm 6, and I do not, and such cases are
handled.  It is a different thing if you and I do algorithm 6 in
incompatible ways, so that I send you a message using your preferred (MAY) 
algorithm that you can't decrypt although both implementations are correct
as far as the spec says. 

Take EC.  It is a MAY (and you are going to add an RFC pointer for "MAY",
but not for "EC" - does one exist?).  There is no detail about what the
order of the parameters used for the keys are.  No two implementors are
likely to pick the exact same format.  So although many implementations
might use EC, no two will be able to decrypt messages made by a different
one.  But I still MAY implement EC.  Any way I choose?  It has been
suggested that HAVAL - which has two reference implementations and enough
detail to be useful - be deleted if it doesn't get an OID.  EC has nothing
beyond an algorithm ID, so why keep it?

For something that cannot be unambiguously implemented, should it be
deleted or kept as a "MAY"?  Everyone kept telling me that "It doesn't
matter that it isn't well defined and will be implemented 20 different
ways, don't worry, it is just a 'MAY'".  So you can see where my semantic
confusion comes from.  If MAY means what people are saying it means now,
then for any algorithms that lack either an RFC or other final
specification, and/or reference implementation, or cannot be implemented
correctly (e.g. hashes which lack OIDs) as of the close date, they should
be changed to "Reserved for XXX" or deleted entirely to prevent
impelmentation.

As I already pointed out, Blowfish was a MAY that already was implemented
two non-interoperable ways.  I have caught many of these but doubt I have
caught all.  And I may have gotten things wrong in what I already have
implemented.  Remember that I have actually been using the spec to create
real code, and have generally succeeded.  But at the same time I have
found pitfalls.  I can interoperate with GNUPG and the PGP programs.  But
in doing so I found things that weren't done in exactly the same way and
needed to be unified.

I can change lots of subtle things that would not violate the spec in any
way but not be interoperable.  Now people want to delete things that at
least are well enough defined to implement, and add other things without
giving enough detail.  When I warn about this the attitude is to shoot the
messenger.

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

From: Uri Blumenthal <[email-masked]>
Subject: Re: Question and note
To: [email-masked]
Date: Mon, 29 Jun 1998 13:25:40 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> .........
> I would rather delete every assigned algorithm number that isn't likely to
> be implemented for public consumption than to have those show up, one per
> implementation so no two implementations can talk except with RSA/IDEA/MD5
> or DH/DSA/SHA1/3DES since my code will be much smaller if I just
> implement these two subsets exactly.  

You have already said that several times. Enough is enough.

I'm explaining for the last time. RFCs define "how" things must be
implemented, if at all.

MUST are the algorithms that you must have, otherwise you are not in
compliance with that RFC.

SHOULD are the algorithms that you can claim compliance even not having
those implemented, but you must have a really good (and convincing for
your customers) reason and explanation why you didn't include them.

MAY are the algorithms that is entirely up to you to have or not to
have. So the keys that are "for real" aren't likely to be of one of
them... MAY class says: "If you decide to do this - here is how it
must be done." So that *if* two implementations both have a common
subset of the MAY class, they could interoperate using them, too.

> And then there will be no reason to
> have any other algorithm, so why bother putting them into the OpenPGP
> spec?  If we have them as official, they should be limited in scope so
> that it is possible to produce a full implementation.

The reason is that some people want more than the MUST gives them, and
IETF does not want to forbid that.

> If there is an algorithm number assigned, it would be useful if there was
> a specific reason to use it and a likelyhood it would appear in many
> implementations.  In this, I agree with PRZ that having extra algorithms
> simply for the sake of having extra algorithms is not a good idea.

Algorithm numbers are assigned so that IF two people decide to use
THAT particular algorithm, they have a common ID for it and a spec
they can follow to interoperate.

I really wish you'd learned something about IETF before making loud noises.

> "Can't use" is necessary in the absence of strong
> language saying "Don't Use".  

Neither one is necessary. IETF managed to live without it till now
and hopefully will keep surviving even your onslaught.

> If you admit that different vehicles might be designed for different local
> conditions, why is it hard to believe that different algorithms or
> implementation levels might be designed for different usages? 

That isprecisely why mAY algorithms are NOT required to be there. The
only thing MAY mandates, is that IF you have one or more of those,
then THIS is the way to implement them.

> I don't want to see keys with preferred algorithms of 100 on keyservers,
> nor do I want to see any with MAY algorithms on the preferred list of any 
> key submitted to a server.

And I don't want to see any of your keys on a server regardless, nor to see
your e-mails cluttering the list. I guess we both don't get our wishes.

> So should we delete DES/SK and reassign it as "whatever AES is", or
> reserve the next number as "whatever AES is"?

Sane ones would reserve the next number for AES and put together a mode
in which AES should be used, because it would be even more stupid than
keep this argument going, to think that it is enough to just define a
cipher without specifying all the details, like mode, IV, prefix, key
thingie and such.

> There is already a category for undefined algorithms.

We aren't talking about "undefined" here and now.

> So if you define a number for
> X now, and AES is X+ do we assign a new, different number?  What if there
> are already messages using X if we want to keep the number?

AES won't "fill its position" until tested. At that time whatever that X
is, will have the number of X. If later on (a month, a year, a decade)
an X+ comes out - how different is it from a (hypotetical) discovery
that IDEA needs strengthening against "quadruple" attack and from
now on everybody should move to IDEA+?

[This was a rhetoric question - no need to bother answering.]

> > Is SKIPJACK not qualified to be an "example" of a new encryption algorithm 
> > that one MAY implement?
> 
> That is what the experimental numbers 100-110 are for.

If you design a cipher, it will be "experimental". I daresay SKIPJACK is
more than that.

> > Do you interoperate with raw algorithms, or with cfb-reset-after-10?
> > Isn't it bloody obvious that an algorithm definition must be specific
> > enough to be unambiguously implementable (and make sense at the same
> > time, so ECB mode isn't likely to cut it, for example)?
> > 
> > Do you really have this much free time on your hands to ask such questions?
> 
> Well, IDEA, 3DES, CAST, Blowfish, and SAFER/SK-128 are all specified
> clearly in other documents and PGP doesn't implement them directly, but
> puts them through the PGP-CFB code (and does not say that these must do
> this) and the specification says nothing about any new algorithm.  This is
> an ambiguity in the spec.

Don't you understand that an "implementable" algorithm specification must
include such minute details as what mode it is to be used in, what kind 
of key, what kind of IV if any etc...?  It is not enough to just have
an implementable crypto-engine.

> You keep proposing adding algorithms by some title.  I have code that can
> implement it either raw, or via the PGP-cfb reset or even by other means. 
> I can do that now (and have done it with RC2 and RC4).  And there are
> other modes.  Which do I do?  I have two switch statements, one for
> PGP-CFB and one for raw.  For consistency, I should go through PGP-CFB. 
> But to be absolutely true to a spec I should go with raw. 

Those who write the spec will have to decide whether they want "normal"
CFB, PGP-CFB or both. In the unlikely case they want both - you will
have to have TWO identifiers: one for the "normal" and one for the
PGP-CFB. Naturally, a spe that doesn't tell that is incomplete.

If you implemented RC2 only with PGP-CFB (ID223) and I implemented RC2 
only with "normal" CFB (ID224) then our implementations won't be able
to interoperate using RC2. Simple. MAY guarantees interoperability ONLY
if both entities did implement the algorithm in question.

> > The implementor, s****d. In your implementation - you do. So you
> > must implement the MUST ones, you should implement the SHOULD 
> > ones, and the rest is entirely up to you. What is there NOT
> > to undertand?!
> > 
> > Now DO YOU get it??
> 
> So if you implement DES/SK as raw, using algorithm ID 6, it is my option
> to implement a PGP-CFB DES/SK also using algorithm ID 6.

No... Sigh... The spec should say that DES/SK ID 6 uses "raw" CFB. If
you want it with PGP-CFB, it would be ID 7, 17 or whatever.

> Lest you think this irrelevant, Blowfish ALREADY RAN INTO THIS PROBLEM.
> I implemented it as 128bit/16 rounds in CFB mode, but another implementor
> was first and used a 192 bit key as I remember.  Mine won and the only
> reason was because I clarified the specification first and not for any
> technical reason.

Since you seem to have already learned the hard way that the specs must
be complete in order to be usable, what is all this **** about?!

> I already have many more algorithms I can implement instantly since they
> are already contained within SSLeay.  I have avoided suggesting them
> because I don't want the number of algorithms to grow.

That is your choice. You are entitled to it. My choice is different. I
hope that it is my choice that is in line with the WG's position.

> There are EXPERIMENTAL algorithm IDs and there are MAY algorithm IDs.  Not
> all the MAY algorithms are specified in enough detail for anyone to
> implement unambiguously (those that exist as code somewhere). 

So that should be dealt with, and the ambiguity has to be removed.
Now do you feel enlightened.

> Instead you are saying it is up to each individual implementor to use his
> own judgement or that there should be some free-for-all to decide which
> variant of each MAY algorithm will win.

Why don't you read what I say, instead of putting [foul] words in my
mouth (<spitting sound>)? 

I said that it is up to each individual implementor to use his own
judgement on WHICH algorithms from the MAY group (if any) he will
put in HIS implementation. What the RFCs should say is exactly
HOW each of those MAY ones must be implemented, if at all.

There must be no "variants" except in your imagination. Each
differentone is, well, different and requires a diffeent ID.

> > No it is not. The natural selection will "wither" some of the defined
> > algorithms and make others "blossom". But it is absolutely not up to
> > you to guesstimate which ones will "live" and which ones will "die".
> 
> I don't have to guesstimate.  All I have to do is implement first and get
> the widest usage. 

So do that. What's your problem?

> For a new algorithm I might have the first working
> implementation, and then *my* implmementation will be copied - modes and
> other details and all (because I can verify messages and produce a test
> suite).  So I might even kill an algorithm by doing a bad implementation
> that gets widely adopted but rarely used. 

Unless somebody finds enough time and desire to to the implementation
right - and then it would your implementation and its implementor that
"reap the blame"...

> How many of the corrections and clarifications in the specification have
> you done?  You seem to see it as a completed mathematical proof.  I see it
> as something with contradictions and assumptions (but far less than many
> others), and not a single existing correct implementation.

In PGP-5 I've done zero corrections, as you bloody well know. I've done
plenty in SNMP, for example, and some other things.

> A second algorithm protects against a point-failure.  3des and cast is
> better than either alone. 

You do not understand the idea of MAY algorithms. Fine, you don't have
to have those at all.

> A list of 12 is much worse unless you measure code's value by the KLOC.  

I measure it by the capabilities mapped onto my needs.

> Cryptography is stronger when it is simpler. 
> More algorithms complicate everything. 

I don't see how having 20 algorithms is any different wrt. to the
program logic than 3 or 4. And lest you asked, I've done quite a
fwe implementations of various things (yes, they work).

> Why are you advocating that PGP become as bad, if not worse. 

"Beauty is in the eye of the beholder". "Bad" for you" is "nice"
and "useful" for me.

> Like having an available reference implementation of each algorithm you
> are suggesting and maybe a sample PGP message using it?

Maybe.

> I have done the implementation, and have run into the problems.  I have
> time to ask questions which you think silly now because it will take a lot
> more time later to try to resolve why one "Open PGP" can't decrypt the
> messages from another "Open PGP" when both don't do anything contradicted 
> by the spec.

That's why the specs have to be cleaned, and that's why there are
reference implementations before the standard advances. NOBODY IS
ARGUING WITH IT, BUT IT IS NOT THE POINT YOU ARE PUSHING.

If you were asking quesitions like: "Algorithm X is not implementable
cleanly because the spec doesn't tell A, B, C and D is unclear -  how
do we define those missing links?", I'd applauded you. When you start 
castrating the program, I become annoyed.

I've spent enough of my time on this. No further message on this topic
will earn a response.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: 128 bit block ciphers
To: [email-masked] (Werner Koch)
Date: Mon, 29 Jun 1998 12:29:31 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Werner Koch says:
> How does OpenPGP cope with 128 bit block ciphers (AES)?
>    The data is encrypted in CFB mode, with a CFB shift size equal to
>    the cipher's block size.  The Initial Vector (IV) is specified as
>    all zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet
>    string to the data before it is encrypted.  The first eight octets
>    are random, and the 9th and 10th octets are copies of the 7th and
> Wouldn't it be better to prefix it with 16 random bytes for 128 bit
> ciphers?  Maybe we can remove the special CFB mode for these ciphers?

Yes, it would be better to follow your propossal.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 29 Jun 1998 08:06:31 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Question and note
Sender: [email-masked]

At 05:16 AM 6/29/98 -0400, [email-masked] wrote:
>Because all these terms have no meaning to the end user, and probably not
>to many of the implementors.

Well, end users won't be seeing this stuff if the implementors do it right.
If the implementors don't understand the terms, we're in deep trouble.

Jon: you don't have a reference to RFC 2119 in this document, which seems
to be the basis for the misunderstanding. Please put an explicit pointer to
RFC 2119 in section 1.1 and a reference to it in section 16. Also, someone
should do a scan of the document for the RFC 2119 words and make sure that
is what we mean.

Now, can we stop the name-calling and move forwards? Ad hominem attacks,
while terribly popular in the security industry, don't help us finish the
work of getting out standards.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 29 Jun 1998 15:51:17 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Re: Secret Key Packet III
Sender: [email-masked]

Hi !

Sorry - forget my last posting. I read the Draft again and found the answer.
Stupid - sorry again.

Bye

 Christoph

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

Date: Mon, 29 Jun 1998 15:34:45 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Secret Key Packets III
Sender: [email-masked]

Hi again ;) !

The secret key packet contains an encrypted algo-spec. MPIs:

     - Encrypted multi-precision integers comprising the secret key
       data. These algorithm-specific fields are as described below.

Does that mean that all MPI's are encrypted, also the 2-Octet MPI-
Length-Fields. I ask because when I read a secret key packet of Version 3
then the MPI-Length-Fields doesn't seem to be encrypted. But if I read
a Version 4 one the whole algo-spec. data seems to be encrypted.

Thanks again for your help. 

Bye 

  Christoph

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

Date: Mon, 29 Jun 1998 12:22:19 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: 128 bit block ciphers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Lutz Donnerhacke <[email-masked]> writes:

> At the moment OpenPGP uses the same mode for all ciphers. It will be an
> issue of the next version to change it.

I'm not talking about the encryption mode (CFB or
reset-after-10bytes-CFB) but the blocksize.  Because there are a lot
of submissions for AES which require a 128 block cipher we should at 
least talk about a way, how to integrate 128 bit block ciphers. 

In section 12.7 OpenPGP explicitly talks about ciphers with blocksizes
greater than 64 bits, so this is not the problem.  My question was,
whether the 8 byte random prefix is sufficient; the statement in
the above mentioned section can be read that this prefix should be
18 bytes long - but how can we pack it into a pubkey_enc packet or
the secret key packets?

Werner  

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: 128 bit block ciphers
Date: 29 Jun 1998 09:24:39 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Werner Koch wrote:
>How does OpenPGP cope with 128 bit block ciphers (AES)?

At the moment OpenPGP uses the same mode for all ciphers. It will be an
issue of the next version to change it.

Date: Mon, 29 Jun 1998 05:16:09 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: Question and note
Sender: [email-masked]

On Mon, 29 Jun 1998, Uri Blumenthal wrote:

> [email-masked] says:
> > But my self-sig can have X in it, and might be a self-sig using X.  So if
> > I create an El-Gamal signature using MD2, and send it to the public
> > keyservers, what happens?  I don't know if every keyserver will take 5.0
> > keys yet, nor if every impelmentation will fail gracefully.
> 
> So...? If you want your sig to be universally accepted, you'll not
> use MD2, and probably not PGP-5 yet. On the other hand, if you
> need or want the features of PGP-5 (or MD2), you'll knowingly
> sacrifice some accessibility...
> 
> Why are you wasting time proving that water is wet?

Because all these terms have no meaning to the end user, and probably not
to many of the implementors.  It bothers me that the specification is
cluttered with lots of algorithms that don't actually offer any benefit
perceiveable to anyone but a cryptographer, and then only at the margin. 
Bloat in the implementation is bad.  Bloat in the specification is worse.

I would rather delete every assigned algorithm number that isn't likely to
be implemented for public consumption than to have those show up, one per
implementation so no two implementations can talk except with RSA/IDEA/MD5
or DH/DSA/SHA1/3DES since my code will be much smaller if I just
implement these two subsets exactly.  And then there will be no reason to
have any other algorithm, so why bother putting them into the OpenPGP
spec?  If we have them as official, they should be limited in scope so
that it is possible to produce a full implementation.

This is happening with TLS - no one does TLS.  Everyone does SSL2 or SSL3
compelete with impelementation bugs that need to be compensated for so
they are rarely true SSL2 or SSL3.  So there are three "definitions" of
the protocol and lots of small implementation nits that must be coded for.

If there is an algorithm number assigned, it would be useful if there was
a specific reason to use it and a likelyhood it would appear in many
implementations.  In this, I agree with PRZ that having extra algorithms
simply for the sake of having extra algorithms is not a good idea.

Going through this process should create more interoperability and fewer
implementation problems, not more.

The OpenPGP spec is still ambiguous on some points and contradictory in
others.  I think the trouble is minimal if people limit their packets
specifically designed to interoperate with foreign implementations and
keyservers to avoid MAYs since this is where most of the problems occur. 

So I am given a choice between suggesting we hold off until the
ambiguities and contradictions are recursively resolved, or suggesting the
posting of sign akin to "Here there be Tigers", i.e. don't go there
without good reason. 

As is, it appears that what might happen is that what is still ambiguous
will be excised.  But "Can't use" is necessary in the absence of strong
language saying "Don't Use".  

> > SHOULD NOT implement is not the same as SHOULD NOT be used for
> > publication.  
> 
> Look: this "should not" idea of yours is crap. Accept it and get
> back to doing something useful.

I was correcting a misunderstanding in the original reply.  I was not
saying that MAY algorithms SHOULD NOT be implemented (which is how it was
taken).  I was saying that MAY algorithms (as they currently exist) are
likely to create interoperability problems, and since the PKI isn't
addressed directly in the spec I wanted to head off some problems (or we
could put the thing on hold for another 3 months while we define exactly
what will go on with the keyservers).

> > Just as there is a distinction between a residential street and
> > a freeway,
> 
> The car I drive does not know that distinction. Neither should PGP.

So why not just forget PGP altogether and go with S/MIME?  Maybe you take
your Corvette on logging trails, and try to hit 1G cornering in your Jeep.
Cars are nonsentient, but they still obey the laws of physics.

If you admit that different vehicles might be designed for different local
conditions, why is it hard to believe that different algorithms or
implementation levels might be designed for different usages? 

I don't want to see keys with preferred algorithms of 100 on keyservers,
nor do I want to see any with MAY algorithms on the preferred list of any 
key submitted to a server.

> > .....there should be a distinction between algorithms used to
> > interoperate with nonPGP things (like Fortrezza or X509) or an
> > experimental or specific local purpose and those used to publish things
> > like keys, or for interoperability without foreknowledge. 
> 
> MUST defines the minimum necessary for interoperability. SHOULD defines
> "you might not have it if you really have a bloody good reason..."  MAY
> defines things that you may have if you choose, but you're blameless if
> you don't.

But are you culpable if you do [implement a MAY] and get it wrong?  It is
hard enough getting the MUST and SHOULDs right.  How many implementations
have you tested your version of OpenPGP against?  Did they all get
everything right?  How do you know yours is correct?  If it is difficult
to get the details right now, adding more of them won't make it easier.

> > > I'm against it. As a matter of fact, I'd like to propose to ADD some
> > > more, that AES competition will "unearth". Surely we'll want to AT
> > > THE VERY LEAST support the AES winner itself? And for the sake
> > > of interoperability with Fortezza might we not include SKIPJACK?
> > > Just two examples...
> > 
> > Except you haven't really given any examples. 
> 
> Does "AES" mean anything to you? Some candidates (quite good, BTW) 
> were already published, the rest will be published shortly. There
> will be a winner, as I hope you understand. So, RC6 is not an
> example worth your attention? TwoFish? LOKI97? Or do I have
> to waste my time spelling out every candidate, one of who
> will become "the" AES? And of course you don't think any of
> the above should be in the MAY category, let alone SHOULD?

So should we delete DES/SK and reassign it as "whatever AES is", or
reserve the next number as "whatever AES is"?

There is already a category for undefined algorithms.  I don't have my
copy of AC here, but I think some of these have multiple variants, or
might be adjusted from their current reference implementations before
being adopted as DES' S-boxes were changed.  So if you define a number for
X now, and AES is X+ do we assign a new, different number?  What if there
are already messages using X if we want to keep the number?

> Is SKIPJACK not qualified to be an "example" of a new encryption algorithm 
> that one MAY implement?

That is what the experimental numbers 100-110 are for.  You can implement
anything you want in these slots and I won't care.  If you want to assign
a low number to "SKIPJACK" and say nothing more I do have objections.  If
you have a reference implementation for anything you want to add, please
give a URL, state whether it should be done in PGP-CFB, raw, or some other
variant, and a proposed algorithm number.  Then we can start the
discussion. 

> > Do you mean the raw algorithms, or the cfb-reset-after-10 that PGP uses?
> 
> Do you interoperate with raw algorithms, or with cfb-reset-after-10?
> Isn't it bloody obvious that an algorithm definition must be specific
> enough to be unambiguously implementable (and make sense at the same
> time, so ECB mode isn't likely to cut it, for example)?
> 
> Do you really have this much free time on your hands to ask such questions?

Well, IDEA, 3DES, CAST, Blowfish, and SAFER/SK-128 are all specified
clearly in other documents and PGP doesn't implement them directly, but
puts them through the PGP-CFB code (and does not say that these must do
this) and the specification says nothing about any new algorithm.  This is
an ambiguity in the spec.

You keep proposing adding algorithms by some title.  I have code that can
implement it either raw, or via the PGP-cfb reset or even by other means. 
I can do that now (and have done it with RC2 and RC4).  And there are
other modes.  Which do I do?  I have two switch statements, one for
PGP-CFB and one for raw.  For consistency, I should go through PGP-CFB. 
But to be absolutely true to a spec I should go with raw. 

Or are you suggesting that you will only get specific enough long after
the spec is out and everyone has a different idea of what is meant to be
implemented by the name and number?

> > What decides, whoever is first-to-implement?
>   ^^^^ I hope it will be "who" that decides, but in your case...

Well, when I refer to an RFC or other fixed standard, it is a what and not
a who.

> The implementor, s****d. In your implementation - you do. So you
> must implement the MUST ones, you should implement the SHOULD 
> ones, and the rest is entirely up to you. What is there NOT
> to undertand?!
> 
> Now DO YOU get it??

So if you implement DES/SK as raw, using algorithm ID 6, it is my option
to implement a PGP-CFB DES/SK also using algorithm ID 6.

Lest you think this irrelevant, Blowfish ALREADY RAN INTO THIS PROBLEM.  I
implemented it as 128bit/16 rounds in CFB mode, but another implementor
was first and used a 192 bit key as I remember.  Mine won and the only
reason was because I clarified the specification first and not for any
technical reason.

I already have many more algorithms I can implement instantly since they
are already contained within SSLeay.  I have avoided suggesting them
because I don't want the number of algorithms to grow.

There are EXPERIMENTAL algorithm IDs and there are MAY algorithm IDs.  Not
all the MAY algorithms are specified in enough detail for anyone to
implement unambiguously (those that exist as code somewhere). 

Instead you are saying it is up to each individual implementor to use his
own judgement or that there should be some free-for-all to decide which
variant of each MAY algorithm will win.

> No it is not. The natural selection will "wither" some of the defined
> algorithms and make others "blossom". But it is absolutely not up to
> you to guesstimate which ones will "live" and which ones will "die".

I don't have to guesstimate.  All I have to do is implement first and get
the widest usage.  For a new algorithm I might have the first working
implementation, and then *my* implmementation will be copied - modes and
other details and all (because I can verify messages and produce a test
suite).  So I might even kill an algorithm by doing a bad implementation
that gets widely adopted but rarely used. 

> > If you are going to let every implementation use whatever combination it
> > wants, the only way of limiting it is to remove algorithms.
> 
> Pure unadulerated bulshit. Since when did we enter a "single-Party"
> system... Interoperability is ensured by (a) defining the common
> set of algorithms that is always present and (b) describing all
> the algorithms correctly and unambiguously.

The "single-Party" is the Open PGP specification itself.

(a) fails because this spec won't interoperate with earlier versions of
PGP at this level almost inviting one or more of the PGP-2.6.x plus
implmementations to form another branch.  There are good reasons not to
have the 2.6.x things as a must, but if OpenPGP turns into bloatware at
the specification stage and a lot of MAYs will be shifted to SHOULDs in
the next draft it invites going back to a simpler starting point.

(b) is even worse since you can't describe what doesn't yet exist, and
much of what is left is still ambiguous.  The only reason HAVAL is the 5
pass, 160 bit variant is that I actually went out and tried to implement
it and needed it to be more specific.  There are many more things like
this where I simply implemented the way I thought best.

How many of the corrections and clarifications in the specification have
you done?  You seem to see it as a completed mathematical proof.  I see it
as something with contradictions and assumptions (but far less than many
others), and not a single existing correct implementation.

A second algorithm protects against a point-failure.  3des and cast is
better than either alone.  A list of 12 is much worse unless you measure
code's value by the KLOC.  Cryptography is stronger when it is simpler. 
More algorithms complicate everything. 

X509 has variants, and PKCS#12 has more.  And they don't interoperate
(MSIE rejecting some certs, Netscape rejecting others, neither really
conforming at some points).  We already have one cryptographic
implementation nightmare.  Why are you advocating that PGP become as bad,
if not worse. 

> Now may we all return to solving the real problems at hand?  Please?

Like having an available reference implementation of each algorithm you
are suggesting and maybe a sample PGP message using it?

I have done the implementation, and have run into the problems.  I have
time to ask questions which you think silly now because it will take a lot
more time later to try to resolve why one "Open PGP" can't decrypt the
messages from another "Open PGP" when both don't do anything contradicted 
by the spec.

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

Date: Mon, 29 Jun 1998 10:33:09 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: 128 bit block ciphers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I am just curious:

How does OpenPGP cope with 128 bit block ciphers (AES)?

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet
   string to the data before it is encrypted.  The first eight octets
   are random, and the 9th and 10th octets are copies of the 7th and

Wouldn't it be better to prefix it with 16 random bytes for 128 bit
ciphers?  Maybe we can remove the special CFB mode for these ciphers?

Werner

Date: Mon, 29 Jun 1998 08:57:31 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Secret Key Packets II
Sender: [email-masked]

Hi !

Just another short question :

Secret Key Packets...

   The packet contains:

     - ...

     - One octet indicating string-to-key usage conventions.  0
       indicates that the secret key data is not encrypted.  255
       indicates that a string-to-key specifier is being given.  Any
       other value is a symmetric-key encryption algorithm specifier.

     - [Optional] If string-to-key usage octet was 255, a one-octet
       symmetric encryption algorithm.

     - [Optional] If string-to-key usage octet was 255, a string-to-key
       specifier.  The length of the string-to-key specifier is implied
       by its type, as described above.

     - [Optional] If secret data is encrypted, eight-octet Initial Vector.
                                                           ^^^^^^^^^^^^^^

Is an IV used if the S2K Usage Identifier is greater than 0 or only if
it's 255 ?

And just another question - what is the latest PGP version that uses
most of the conventions made in the Open-PGP-Draft ?

Thanks and Bye

        Christoph 

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

From: Uri Blumenthal <[email-masked]>
Subject: Re: Question and note
To: [email-masked]
Date: Mon, 29 Jun 1998 01:21:23 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

Oh boy, do you annoy me...

[email-masked] says:
> But my self-sig can have X in it, and might be a self-sig using X.  So if
> I create an El-Gamal signature using MD2, and send it to the public
> keyservers, what happens?  I don't know if every keyserver will take 5.0
> keys yet, nor if every impelmentation will fail gracefully.

So...? If you want your sig to be universally accepted, you'll not
use MD2, and probably not PGP-5 yet. On the other hand, if you
need or want the features of PGP-5 (or MD2), you'll knowingly
sacrifice some accessibility...

Why are you wasting time proving that water is wet?

> SHOULD NOT implement is not the same as SHOULD NOT be used for
> publication.  

Look: this "should not" idea of yours is crap. Accept it and get
back to doing something useful.

> You MAY drive your moped, but you SHOULD NOT drive it on the
> freeway.  

Your analogy sucks because you don't understand (a) the terminology
of IETF standards and (b) how they work. You ignore the fact that 
some use cars exclusively for highway driving, some others use
them for the backroads only, and yet others for both. Using
the very same vehicle. What you are trying to say is "forbid
that Corvette fro showing on back-roads, and expel Ford Escort
from the freeway". 

[I don't know why I'm wasting my time on this. Need to vent the spleen
that you stirred, I guess - no other sane reason in sight.]

> Just as there is a distinction between a residential street and
> a freeway,

The car I drive does not know that distinction. Neither should PGP.

> .....there should be a distinction between algorithms used to
> interoperate with nonPGP things (like Fortrezza or X509) or an
> experimental or specific local purpose and those used to publish things
> like keys, or for interoperability without foreknowledge. 

MUST defines the minimum necessary for interoperability. SHOULD defines
"you might not have it if you really have a bloody good reason..."  MAY
defines things that you may have if you choose, but you're blameless if
you don't.

What is there not to understand?! This tree seems particularly unworthy
to be barked at.  Don't know about you time, but I'm getting positively
annoyed by this sh**, er, stuff.

> But there is an implicit set of algorithms:
> 
> PGP 5.X unencumbered (DSA/DH/3DES/SHA1) PGP 5.X general (above + CAST)
> PGP 2.6 interoperable (RSA/RSA/IDEA/MD5)
> --------
> PGP 5.X general (above + ElGamal, RIPEMD160, DSA w/ !SHA1)
> GNUPG (adds TIGER, BlowFish, and gzip compression)
> 
> My point is that for publication, one should stay above the line.

Your point doesn't make sense and isn't worth the electrons used to 
carry it, if you forgive my bluntness.  But I have little time and 
even less patience left to deal with this nonsense.

> > I'm against it. As a matter of fact, I'd like to propose to ADD some
> > more, that AES competition will "unearth". Surely we'll want to AT
> > THE VERY LEAST support the AES winner itself? And for the sake
> > of interoperability with Fortezza might we not include SKIPJACK?
> > Just two examples...
> 
> Except you haven't really given any examples. 

Does "AES" mean anything to you? Some candidates (quite good, BTW) 
were already published, the rest will be published shortly. There
will be a winner, as I hope you understand. So, RC6 is not an
example worth your attention? TwoFish? LOKI97? Or do I have
to waste my time spelling out every candidate, one of who
will become "the" AES? And of course you don't think any of
the above should be in the MAY category, let alone SHOULD?

Is SKIPJACK not qualified to be an "example" of a new encryption algorithm 
that one MAY implement?

> Do you mean the raw algorithms, or the cfb-reset-after-10 that PGP uses?

Do you interoperate with raw algorithms, or with cfb-reset-after-10?
Isn't it bloody obvious that an algorithm definition must be specific
enough to be unambiguously implementable (and make sense at the same
time, so ECB mode isn't likely to cut it, for example)?

Do you really have this much free time on your hands to ask such questions?

> What decides, whoever is first-to-implement?
  ^^^^ I hope it will be "who" that decides, but in your case...

The implementor, s****d. In your implementation - you do. So you
must implement the MUST ones, you should implement the SHOULD 
ones, and the rest is entirely up to you. What is there NOT
to undertand?!

Now DO YOU get it??

> What if there are multiple variants (e.g.
> a 3-aes, or there are advantages to an ofb mode, or different key or
> block sizes?)... And what of the other layers?..............

I'm tired.  You go and figure it out yourself.

> The point of my language is that if the PGP email and public key
> infrastructure is more limited as to what will be seen by all the diverse
> implementations (as my language would suggest) then I am for adding
> algorithm IDs as MAYs even if they aren't fully defined or will rarely be
> used.

No it is not. The natural selection will "wither" some of the defined
algorithms and make others "blossom". But it is absolutely not up to
you to guesstimate which ones will "live" and which ones will "die".

> If you are going to let every implementation use whatever combination it
> wants, the only way of limiting it is to remove algorithms.

Pure unadulerated bulshit. Since when did we enter a "single-Party"
system... Interoperability is ensured by (a) defining the common
set of algorithms that is always present and (b) describing all
the algorithms correctly and unambiguously.

If you absolutely have to limit something, please limit your arguments.

> Remember that there is going to be a 1.1 version of the spec and I assume
> a corresponding RFC.  Not having an OID for HAVAL isn't critical if the
> algorithm ID isn't coming soon to a PKserver near you.  If the intent is
> to allow publication to the PKI of every possible algorithm, I would be
> for removing most of those that aren't completely defined or don't add to
> any existing implementation.

It sounds like you're being force to pay for each OID from your own
pocket, and in hard currency.  Please relax - we got plenty of OIDs
and they are still pretty cheap.

Now may we all return to solving the real problems at hand?  Please?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Sun, 28 Jun 1998 23:36:49 -0400
From: [email-masked]
cc: [email-masked]
To: <[email-masked]>
Subject: Re: Question and note
Sender: [email-masked]

On Fri, 26 Jun 1998, Uri Blumenthal wrote:

> > The users are protected by symmetric pref rules. If my self-sig doesn't
> > have algorithm X in it, then an implementation is not to use X. This
> > permits us to be relatively free with assigning algorithm IDs. In any
> > event, once IDs are assigned by IANA, they're more likely to be more free
> > than the stingy folks would like.
> 
> This protection is perfectly good enough in my opinion.

But my self-sig can have X in it, and might be a self-sig using X.  So if
I create an El-Gamal signature using MD2, and send it to the public
keyservers, what happens?  I don't know if every keyserver will take 5.0
keys yet, nor if every impelmentation will fail gracefully.

> > To sum up, MAY means MAY, it doesn't mean SHOULD NOT. I think that any new
> > algorithm that is born SHOULD NOT simply shouldn't be there. If there's
> > rousing, quick, consensus here to delete some set of algorithms, that
> > change is easy for me to do. If anyone wants to comment, the comments
> > better come quickly.

SHOULD NOT implement is not the same as SHOULD NOT be used for
publication.  You MAY drive your moped, but you SHOULD NOT drive it on the
freeway.  Just as there is a distinction between a residential street and
a freeway, there should be a distinction between algorithms used to
interoperate with nonPGP things (like Fortrezza or X509) or an
experimental or specific local purpose and those used to publish things
like keys, or for interoperability without foreknowledge. 

This isn't clearly stated in the spec as it stands.  But there is an
implicit set of algorithms:

PGP 5.X unencumbered (DSA/DH/3DES/SHA1)
PGP 5.X general (above + CAST)
PGP 2.6 interoperable (RSA/RSA/IDEA/MD5)
--------
PGP 5.X general (above + ElGamal, RIPEMD160, DSA w/ !SHA1)
GNUPG (adds TIGER, BlowFish, and gzip compression)

My point is that for publication, one should stay above the line.

> I'm against it. As a matter of fact, I'd like to propose to ADD some
> more, that AES competition will "unearth". Surely we'll want to AT
> THE VERY LEAST support the AES winner itself? And for the sake
> of interoperability with Fortezza might we not include SKIPJACK?
> Just two examples...

Except you haven't really given any examples.  Do you mean the raw
algorithms, or the cfb-reset-after-10 that PGP uses?  What decides,
whoever is first-to-implement?  What if there are multiple variants (e.g.
a 3-aes, or there are advantages to an ofb mode, or different key or
block sizes?).

And what of the other layers?  I can interchange X509 and PGP formats
easily, but no one has mentioned that capability of my implementation,
while they want algorithms added specifically to do this function (which
won't really work - e.g. MD2 digests different material in X509 and PGP,
so why have the algorithm in PGP since you can't place the correct
information to be hashed into any PGP signature packet). 

The point of my language is that if the PGP email and public key
infrastructure is more limited as to what will be seen by all the diverse
implementations (as my language would suggest) then I am for adding
algorithm IDs as MAYs even if they aren't fully defined or will rarely be
used.

If you are going to let every implementation use whatever combination it
wants, the only way of limiting it is to remove algorithms.

Remember that there is going to be a 1.1 version of the spec and I assume
a corresponding RFC.  Not having an OID for HAVAL isn't critical if the
algorithm ID isn't coming soon to a PKserver near you.  If the intent is
to allow publication to the PKI of every possible algorithm, I would be
for removing most of those that aren't completely defined or don't add to
any existing implementation.

Date: Sun, 28 Jun 1998 23:10:13 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: preventing Gary Howland's attack
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> At 11:53 PM 6/25/98 +0100, Adam Back wrote:
>    
>    - Gary Howlands attack which can undetectably garble unsigned
>      encrypted messages ... has this was been fixed?
>    
>      If not perhaps we could either fix it (include optional? unsigned
>      digest inside message) or have wording added to highlight that
>      unsigned encrypted messages offer little protection against garbling.
> 
> As I remember the consensus on this one, garbling is a problem on all
> messaging systems unless you have a signature or a MAC. 

Yes, that's why most of them have MACs or signatures :-) I countered
this point last time this was discussed with the example of SSL, which
uses MACs to prevent against garbling and truncation attacks.  It is a
known problem with a known solution.  I think it is actually quite a
bad problem.  So why not fix it?

There are very good reasons not to sign all messages, whilst still
requiring confidentiality:

a) not having to enter ones passphrase to send a message (each use
   adds to risk of exposure, and may be using in an untrusted environment)

b) automated systems which are running as processes without user
   input, and you don't want the private signing key in memory (eg
   backup daemons, encrypting mail forwarders, etc)

c) not wanting to have transferable non-repudiable signatures on all
   your email.  (non-transferable sigs can reduce this problem...)

> Adding in a MAC or digest to an encrypted packet breaks backwards
> compatibility. 

No, disagree.

We can add MACs as a fix defined to be only available where public
keys indicate open-pgp 1.0.  That means it will not be created in
messages sent to pre open-pgp 1.0 implementations, and therefore there
is no backwards compatibility problem.

I would suggest either HMAC, defined over the same set of hashes
availble for signatures, keyed with the symmetric key used for
encryption, or more simply just an existing digest packet as used
inside signatures.  (It only makes sense to add MACs or digests to
encrypted messages, and an encrypted digest packet is a form of keyed
MAC).

> I thought the consensus was that with 1.X we would look at adding
> some form of integrity check, perhaps with a new type of encrypted
> data packet.

The reason I am keen on adding a MAC is a) it is broken (badly in my
view) and needs fixing; b) it is easy to fix; c) it does not affect
backwards compatibility.

I prefer a digest packet inside the encrypted envelope (at the end of
the plaintext to aid one-pass processing), rather than a MAC for
reasons of simplicity (people already have code to compute and emit
digest packets for the available hashes).  It is probably easiest to
define the digest packet as a signature packet.  (This can then borrow
the one pass packets etc from existing signature parts).

So changes required would be:

- define a digest packet in the same framework as signature packets 
  emit the unsigned digest packet which would otherwise have been
  signed

- use the same mechanism used to allow one pass processing of
  signatures to allow one pass processing of digest packets.

- define that the digest packet can be optionally skipped if the
  message is signed

Adam

Date: Fri, 26 Jun 1998 14:02:13 -0700
To: [email-masked]
From: Uri Blumenthal <[email-masked]> (by way of Jon Callas <[email-masked]>)
Subject: Re: Question and note
Sender: [email-masked]

Jon Callas says:
> Ummm, I don't agree. An implementor may implement any "MAY implement"
> algorithm. They are not required to, but they MAY. The above language would
> change MAY to SHOULD NOT. I don't see the sense in adding an algorithm,
> only to say it shouldn't be used.

I support Jon's position.

> The users are protected by symmetric pref rules. If my self-sig doesn't
> have algorithm X in it, then an implementation is not to use X. This
> permits us to be relatively free with assigning algorithm IDs. In any
> event, once IDs are assigned by IANA, they're more likely to be more free
> than the stingy folks would like.

This protection is perfectly good enough in my opinion.

> To sum up, MAY means MAY, it doesn't mean SHOULD NOT. I think that any new
> algorithm that is born SHOULD NOT simply shouldn't be there. If there's
> rousing, quick, consensus here to delete some set of algorithms, that
> change is easy for me to do. If anyone wants to comment, the comments
> better come quickly.

I'm against it. As a matter of fact, I'd like to propose to ADD some
more, that AES competition will "unearth". Surely we'll want to AT
THE VERY LEAST support the AES winner itself? And for the sake
of interoperability with Fortezza might we not include SKIPJACK?
Just two examples...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 26 Jun 1998 08:09:08 -0500
To: Christoph Moser <[email-masked]>
Cc: [email-masked]
Subject: Re: Secret Key Packets
Sender: [email-masked]

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

In <[email-masked]>, on 06/26/98

   at 01:04 PM, Christoph Moser <[email-masked]> said:

>A secret key packet contains :
>  - A Public Key or Public Subkey packet, as described above

>But how can I find out the length of this Public Key Packet, I mean how
>can I find out the length of the algorithm specific data, especially when
>a new Algorithm (other then RSA, DSA or Elgamal) is used (e.g. in the
>future) ?

Well if a new algorithm is used in the future then the RFC will have to be
updated with the relevent information.

>I think the length Header field after the Packet Tag does include the
>size of both, the Secret Key Packet with it's included Public Key Packet
>?

Yes, the packet size inculdes all the data in the Secret Key Packet. While
the Secret Key Packet containes all the data of a Public Key Packet this
data is not a packet itself. Because of this there is no seperate header
for the public key data.

- -- 
- ---------------------------------------------------------------
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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: This marks Logical End-Of-Message. Physical EOM follows

Date: Fri, 26 Jun 1998 13:04:02 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Secret Key Packets
Sender: [email-masked]

Hi !

A secret key packet contains :
  - A Public Key or Public Subkey packet, as described above

But how can I find out the length of this Public Key Packet, I mean
how can I find out the length of the algorithm specific data, especially
when a new Algorithm (other then RSA, DSA or Elgamal) is used (e.g. in
the future) ?

I think the length Header field after the Packet Tag does include the size
of both, the Secret Key Packet with it's included Public Key Packet ?

Bye

  Christoph Moser

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

Date: Thu, 25 Jun 1998 18:09:37 -0700
To: Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-openpgp-formats
Cc: [email-masked]
Sender: [email-masked]

At 11:53 PM 6/25/98 +0100, Adam Back wrote:
   
   - Gary Howlands attack which can undetectably garble unsigned
     encrypted messages ... has this was been fixed?
   
     If not perhaps we could either fix it (include optional? unsigned
     digest inside message) or have wording added to highlight that
     unsigned encrypted messages offer little protection against garbling.

As I remember the consensus on this one, garbling is a problem on all
messaging systems unless you have a signature or a MAC. 

Adding in a MAC or digest to an encrypted packet breaks backwards
compatibility. I thought the consensus was that with 1.X we would look at
adding some form of integrity check, perhaps with a new type of encrypted
data packet.

I'm willing to add a note in security considerations. How about something
like:

Please note that encrypting an object but not signing it leaves open the
possibility that it might have been damaged (by accident or attack). If an
implementation wants to ensure the integrity of a message, it must be
signed as well as encrypted.
   
   - Is it defined that an implementation would keep processing packets
     until it gets to a terminal packet (terminal packets being
     literal packets, or the text of a clear signed message)?
   
     This is important as it allows super-encryption, and allows
     encrypted messages to contain clear signed messages (which William
     Geiger uses) plus it would be useful for experimental combinations
     people may use.
   
It is my belief that that is defined. It's implicit that an implementation
needs to keep unwrapping an object until it hits bottom, and that since a
literal packet could contain a clearsigned message, a literal should be
scanned for one. If you think a paragraph needs to be added, let us know.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 25 Jun 1998 19:16:56 -0400 (EDT)
From: Ryan Anderson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-openpgp-formats
Sender: [email-masked]

On Thu, 25 Jun 1998, John  W. Noerenberg wrote:

> It sounds like -05 is the rev we take to the IESG.

Agreed.  I haven't been following the details of many of the more
technical issues on here lately, but the general flow lately has seemed to
be, "This is wrong, this other thing is the correct version"  And then Jon
replying with, "Yes, that's better"

Just my view of the status of things,

Ryan Anderson 
PGP fp: 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9

Date: Thu, 25 Jun 1998 15:36:46 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Question and note
Cc: [email-masked]
Sender: [email-masked]

At 05:11 PM 6/24/98 -0400, [email-masked] wrote:
   What is the status of HAVAL's algorithm number.

Haval is 7 -- 4 is reserved for the double-width experimental.
   
   Also, I didn't write this up in detail before, but somewhere, probably
   near the top or in the algorithm section it should say (feel free to
   edit):

   
   "MAY implement" algorithms are only for experimental or internal use. 
   Implementations MUST NOT send keys to any public keyserver that uses
   algorithms other than those listed below.  Implementations SHOULD NOT
   create keys or messages that use algorithms other than those listed below
   in any normal or common useage.  Implementations SHOULD make it very
   difficult to generate PGP packets using "MAY" or experimental algorithms. 
   
   This limits the available algorithms: hashes to MD5, SHA1, and RIPEMD160; 
   symmetric algorithms to IDEA, 3DES, and CAST5; encryption algorithms to
   RSA and DH (ElGamal); and signature algorithms to RSA and DSA.  Further,
   DSA signatures should be limited to using SHA1.  MD5, IDEA, and RSA should
   only be used to interoperate with earlier implementations of PGP. 

   
   This is sort of implied by the definition of MAY, SHOULD, etc. but I think
   it would be a good idea to reinforce it by stating this clearly and
   explicitly.  Although I am for leaving the algorithm list alone at this
   late stage, I do think it would be best to strongly state that the extra
   stuff is experimental and not intended for use in any commercial product.
   
Ummm, I don't agree. An implementor may implement any "MAY implement"
algorithm. They are not required to, but they MAY. The above language would
change MAY to SHOULD NOT. I don't see the sense in adding an algorithm,
only to say it shouldn't be used.

I understand that there are also now a flurry of new algorithms coming out,
because of AES that are worth looking at. I've also had the suggestion that
some of the algorithms there be included, even replacing ones already here
because the AES submissions are often later versions of algorithms that are
here.

Implementors are free to do what they want with MAY algorithms. Some
implementors might do precisely what you suggest -- restrict yourself to
the minimal set. (In fact, that's the likely outcome here. There is no
consensus at NAI to add any new algorithms to our products.)

The users are protected by symmetric pref rules. If my self-sig doesn't
have algorithm X in it, then an implementation is not to use X. This
permits us to be relatively free with assigning algorithm IDs. In any
event, once IDs are assigned by IANA, they're more likely to be more free
than the stingy folks would like.

To sum up, MAY means MAY, it doesn't mean SHOULD NOT. I think that any new
algorithm that is born SHOULD NOT simply shouldn't be there. If there's
rousing, quick, consensus here to delete some set of algorithms, that
change is easy for me to do. If anyone wants to comment, the comments
better come quickly.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 25 Jun 1998 23:53:29 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: WG Last Call: draft-ietf-openpgp-formats
Sender: [email-masked]

Re the last call:

A few minor queries someone might like to comment on, this one I think
is still not resolved:

- Gary Howlands attack which can undetectably garble unsigned
  encrypted messages ... has this was been fixed?

  If not perhaps we could either fix it (include optional? unsigned
  digest inside message) or have wording added to highlight that
  unsigned encrypted messages offer little protection against garbling.

Also:

- Is it defined that an implementation would keep processing packets
  until it gets to a terminal packet (terminal packets being
  literal packets, or the text of a clear signed message)?

  This is important as it allows super-encryption, and allows
  encrypted messages to contain clear signed messages (which William
  Geiger uses) plus it would be useful for experimental combinations
  people may use.

Adam

Date: Thu, 25 Jun 1998 14:22:18 -0700
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: WG Last Call: draft-ietf-openpgp-formats
Cc: Jon Callas <[email-masked]>, "Jeffrey I. Schiller" <[email-masked]>
Sender: [email-masked]

It sounds like -05 is the rev we take to the IESG.

Please keep this subject in the Subject header so I can hear if there's a
hum of consensus.  (In the 17th & 18th century, conferees banged their
walking sticks on the wooden floor -- think of this as the late 20th
century equivalent...)

If you've been holding out on something that's bugging you, now would be a
real good time to mention it.

If there are no substantial issues raised by July 8th, 1998, I will close
WG Last Call, and we'll submit this puppy to the IESG for consideration as
a Proposed RFC.
john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  Anyone who breathes the spirit of American roots and values knows
  instinctively that censorship is the feeble response of an insecure,
  beleaguered society.
  -- Russell Sherman, "Piano Pieces", 1997
  ----------------------------------------------------------------------

Date: Wed, 24 Jun 1998 17:11:36 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Question and note
Sender: [email-masked]

What is the status of HAVAL's algorithm number.

Also, I didn't write this up in detail before, but somewhere, probably
near the top or in the algorithm section it should say (feel free to
edit):

"MAY implement" algorithms are only for experimental or internal use. 
Implementations MUST NOT send keys to any public keyserver that uses
algorithms other than those listed below.  Implementations SHOULD NOT
create keys or messages that use algorithms other than those listed below
in any normal or common useage.  Implementations SHOULD make it very
difficult to generate PGP packets using "MAY" or experimental algorithms. 

This limits the available algorithms: hashes to MD5, SHA1, and RIPEMD160; 
symmetric algorithms to IDEA, 3DES, and CAST5; encryption algorithms to
RSA and DH (ElGamal); and signature algorithms to RSA and DSA.  Further,
DSA signatures should be limited to using SHA1.  MD5, IDEA, and RSA should
only be used to interoperate with earlier implementations of PGP. 

This is sort of implied by the definition of MAY, SHOULD, etc. but I think
it would be a good idea to reinforce it by stating this clearly and
explicitly.  Although I am for leaving the algorithm list alone at this
late stage, I do think it would be best to strongly state that the extra
stuff is experimental and not intended for use in any commercial product.

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

Date: Wed, 24 Jun 1998 11:06:53 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Additions to draft
Sender: [email-masked]

I just noticed that there's an RFC for CAST5, RFC 2144. This is the same
version we implement, and the NAI PGP code uses the same test vectors even.
So I'm adding references.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 22 Jun 1998 15:14:10 -0700
To: Noah Salzman <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: More Typos
Sender: [email-masked]

At 06:01 PM 6/17/98 -0700, Noah Salzman wrote:
   
Thanks for the corrections. They are in place. As Bill Stewart said, Raph
Levien's name is spelled as it is in this sentence.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 22 Jun 1998 15:15:43 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Problem with Version 4 subpackets :(
Sender: [email-masked]

Bill, here is the new wording. I have it for both the hashed and unhashed
sections (with the word "hashed" or "unhashed" as appropriate:

Two-octet scalar octet count for following unhashed subpacket data. Note
that this is the length in octets of all of the unhashed subpackets; a
pointer incremented by this number will skip over the unhashed subpackets.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 22 Jun 1998 11:11:54 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Problem with Version 4 subpackets :(
Sender: [email-masked]

At 02:57 AM 6/18/98 -0500, William H. Geiger III wrote:
   -----BEGIN PGP SIGNED MESSAGE-----
   
   In section 5.2.3:
   
    - Two-octet scalar octet count for following unhashed subpacket data.
   
   I was mistakenly reading this as a count of how many subpackets were to
   follow rather than a length of the following group of subpackets.
   
   If it's not too late you may wish to re-word this for greater clarity.
   
Will do.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 17 Jun 1998 15:25:08 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Minor typo in 11.2
Cc: [email-masked]
Sender: [email-masked]

At 05:56 PM 6/17/98 -0400, [email-masked] wrote:
   In 11.2 at a.3) d) says "algorithm (1 octet): 7 = DSA..."
   
   Shouldn't this be 17?

Yes, it should. Thank you.
   
	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Subject: More Typos
Date: Wed, 17 Jun 1998 18:01:55 -0700
From: Noah Salzman <[email-masked]>
To: "Jon Callas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Section 4.2.2 (item 4)
spelling error, "indeterminite" should be indeterminate

Section 5.3, last paragraph
repeated word, "either a a Salted S2K..."

Section 11.1, 4th paragraph from end
spelling, "...but V4 is prefered, of course."  should be preferred

Section 12.1, last sentence
spelling, "Consenquently..." should be Consequently

section 12.2.1, last sentence
"If the preferences are mot present, then they are assumed...."
                        ^^^

Section 14, top of page 55
repeated word, "keylength differs from the the S2K..."

Section 14, second to last bullet item
repeated word, "There are many ways possible for for..."

In the credits section at the end:
"Raph Levine"  (Ralph?)

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 18 Jun 1998 02:57:40 -0500
To: [email-masked]
Subject: Problem with Version 4 subpackets :(
Sender: [email-masked]

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

Hi,

Well this was going to be a question regarding a problem parsing signature
subpackets. Half way through writting this message I found my problem. :)

In section 5.2.3:

 - Two-octet scalar octet count for following unhashed subpacket data.

I was mistakenly reading this as a count of how many subpackets were to
follow rather than a length of the following group of subpackets.

If it's not too late you may wish to re-word this for greater clarity.

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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: What?!?  DOSSHELL *isn't* supposed to be a joke?

Date: Wed, 17 Jun 1998 16:52:57 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Another typo
Sender: [email-masked]

In the section "Key IDs and Fingerprints" (p48, section 11.2):

	The key ID is either the low order 64 bits of the fingerprint.

The word "either" is extraneous. It's been struck.

	Jon

Date: Wed, 17 Jun 1998 17:56:27 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Minor typo in 11.2
Sender: [email-masked]

In 11.2 at a.3) d) says "algorithm (1 octet): 7 = DSA..."

Shouldn't this be 17?

-----

Since I am finalizing my opgp library, does anyone else have changes
(other than the potential change of the algid for HAVAL from 4 to 7)?

opgp99q is at www.cryptography.org, soon to be in the new directory.
Minor fixes including an issue with the sigids program.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-05.txt
Date: Wed, 17 Jun 1998 09:22:45 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy 
Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-05.txt
	Pages		: 58
	Date		: 16-Jun-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP 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 storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric 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
   OpenPGP.

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-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-05.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: ftp.ietf.org
	
	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-05.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-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 16 Jun 1998 14:58:43 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Changing HAVAL definition.
Sender: [email-masked]

I don't like departing from the standard DigestInfo structure for some
hashes while keeping it for others.  It is inconsistent.

It is not difficult for a company to get a number assigned by the
Internet Assigned Numbers Authority.  You just fill out the entry form
at http://www.isi.edu/cgi-bin/iana/enterprise.pl, and wait a week.
It's free.

Once you have the assignment you can make your own subsidiary assignments.
We could define OIDs for Haval and any other hashes which need them.

PGP, Inc. was purchased by and is now a part of Network Associates, Inc.
NAI does not have an assigned number, but some of the other companies
which combined to form it do: McAfee, TIS, and Network General all
have assignments.

What I would recommend is that NAI get an assigned number, create a sub
tree specifically for OpenPGP related identifiers, and define OIDs for
any hashes we want to use which don't have them, within that sub tree.

Hal

Date: Tue, 16 Jun 1998 21:32:08 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Changing HAVAL definition.
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> To all: by the bye, we still don't have OIDs for HAVAL and Tiger. I am
> content to leave this situation as it is. But I would be delighted to add

What about a note, that some implementations use:

    /* 40: SEQUENCE {
     * 12:   SEQUENCE {
     *  8:     OCTET STRING   :54 49 47 45 52 31 39 32
     *  0:     NULL
     *   :     }
     * 24:   OCTET STRING
     *   :   }
     *
     * By replacing the 5th byte (0x04) with 0x16 we would have;
     *        8:     IA5String 'TIGER192'
     */
    static byte asn[18] =
     { 0x30, 0x28, 0x30, 0x0c, 0x04, 0x08, 0x54, 0x49, 0x47,
       0x45, 0x52, 0x31, 0x39, 0x32, 0x05, 0x00, 0x04, 0x18 };

This is a simple and pragmatic solution (Thanks to Tom).

Werner 

Date: Tue, 16 Jun 1998 15:04:40 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Changing HAVAL definition.
Sender: [email-masked]

On Tue, 16 Jun 1998, Jon Callas wrote:

> At 05:10 PM 6/15/98 -0700, Hal Finney wrote:
>    In looking at the source to PGP 5.5, I see that it had defined hash
>    algorithm 4 as an experimental double-width version of SHA.  It never
>    created messages with that hash, but if it sees hash algorithm 4, it will
>    think that is double-SHA rather than HAVAL as the spec has it.  Can we
>    reserve hash algorithm 4 and redefine HAVAL to be 7?  That way 5.5 will
>    know that it is seeing an unrecognized hash if it ever sees hash 7,
>    and produce an error message.  Otherwise it is likely to report a bad
>    signature if it sees hash 4 because someone used HAVAL.
>    
> I have no objection to this. Anyone else?
> 
> To all: by the bye, we still don't have OIDs for HAVAL and Tiger. I am
> content to leave this situation as it is. But I would be delighted to add
> OIDs if someone were to scrounge them. I am even willing to drop them
> completely if there's consensus in that direction. I'm just bringing up the
> issue. No response means you agree it's okay to leave it as it is.

Please restate this since you don't want to "leave it as it is".

What I think is being proposed:

Hash#	Old	New
4	HAVAL	(reserved)
7	(undef)	HAVAL

However, the next revision of PGP after 5.5 should treat hash #4 as
reserved (and use 100+ for experimenting).  Since I expect one of the hot
items for the next version of this spec will be a wide hash (to go with a
wide DSA variant), I will expect such a hash to be dropped in as #4. 

Someone should also create a patch for the source of 5.5 that disables
hash #4.  So when is there going to be a PGP source code journal?

As far as the OIDs (or lack thereof), I made a suggestion to alternately
use an octet string, or IA5 string with the string from the Hash:
clearsign header in place of the OID.  This way the issue goes away.  I
plan on proposing this for the next revision.  There won't be an OID for
the wide hash whatever it is.

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

Date: Tue, 16 Jun 1998 10:25:33 -0700
To: Hal Finney <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Changing HAVAL definition.
Sender: [email-masked]

At 05:10 PM 6/15/98 -0700, Hal Finney wrote:
   In looking at the source to PGP 5.5, I see that it had defined hash
   algorithm 4 as an experimental double-width version of SHA.  It never
   created messages with that hash, but if it sees hash algorithm 4, it will
   think that is double-SHA rather than HAVAL as the spec has it.  Can we
   reserve hash algorithm 4 and redefine HAVAL to be 7?  That way 5.5 will
   know that it is seeing an unrecognized hash if it ever sees hash 7,
   and produce an error message.  Otherwise it is likely to report a bad
   signature if it sees hash 4 because someone used HAVAL.
   
I have no objection to this. Anyone else?

To all: by the bye, we still don't have OIDs for HAVAL and Tiger. I am
content to leave this situation as it is. But I would be delighted to add
OIDs if someone were to scrounge them. I am even willing to drop them
completely if there's consensus in that direction. I'm just bringing up the
issue. No response means you agree it's okay to leave it as it is.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 16 Jun 1998 08:46:35 +0200 (MET DST)
From: Michael Baumer <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Hash of Keys and Sync of Servers
Sender: [email-masked]

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

On Mon, 15 Jun 1998, William H. Geiger III wrote:
> I am not quite sure what you mean by serial number and how it relates to
> insuring that two DB's have the same key?

A serial number is an ID for each PGP-Packet (i.e. pubkey, sigs, revocs
etc). Its main purpose is to ensure that all keyservers taking part on
this "KBone" have received all updates. 
 
> If we are talking about a end users how does he insure that his local
> copy of a key is the same as the servers without periodically
> downloading the keys? 

In normal operation the PGP-Packets containing the serial numbers are not
exported. I only suggested that one could use these serial numbers for
this. This is not fully thought through yet, but imagine a function which
takes serial numbers as paramter and returns the updates which are not
covered by those. 

A more realistic possibility would be a local keyserver
which receives incrementals (only updates, not whole keys) and stores only
interesting ones (e.g. all with your.sub.domain on the userid).

Michael
- --
Michael Baumer, Praesident VIS
VIS - Verein der Informatikstudierenden an der ETH Zuerich
e-mail (pers.): [email-masked]
e-mail (Verein): [email-masked]

PGP-KeyID: 2238F089, 2048 Bits
finger [email-masked] for pgp-key

Date: Mon, 15 Jun 1998 17:10:23 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Another draft coming your way.
Sender: [email-masked]

In looking at the source to PGP 5.5, I see that it had defined hash
algorithm 4 as an experimental double-width version of SHA.  It never
created messages with that hash, but if it sees hash algorithm 4, it will
think that is double-SHA rather than HAVAL as the spec has it.  Can we
reserve hash algorithm 4 and redefine HAVAL to be 7?  That way 5.5 will
know that it is seeing an unrecognized hash if it ever sees hash 7,
and produce an error message.  Otherwise it is likely to report a bad
signature if it sees hash 4 because someone used HAVAL.

Hal

Date: Mon, 15 Jun 1998 15:55:44 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Relevant diffs between -04 and -05
Sender: [email-masked]

This is it. I edited out header/footer diffs, TOC diffs, and version number
change diffs.

	Jon

749c749
<    MUST be at least 512 octets long. Partial Body Lengths MAY NOT be
---
>    MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
1285,1287c1285,1287
<    uncompressed data is preferred; the key holder's software may not
<    have compression software. This is only found on a self-signature.
<
---
>    uncompressed data is preferred; the key holder's software might have
>    no compression software in that implementation. This is only found
>    on a self-signature.
1934,1935c1934,1935
<    implementation uses more bits of compression, If an implementation
<    uses more bits of compression, PGP V2.6 cannot decompress it.
---
>    implementation uses more bits of compression, PGP V2.6 cannot
>    decompress it.
2199a2200,2208
>      - "Hash", a comma-separated list of hash algorithms used in this
>        message. This is used only in clear-signed messages.
>
>      - "Charset", a description of the character set that the plantext
>        is in. Please note that OpenPGP defines text to be in UTF-8, so
>        this Armor Header Key is only useful for backwards
>        compatibility. An implementation MAY implement it; an
>        implementation MAY ignore it.
>
2361c2367
<      - Zero or more "Hash" Armor Headers,
---
>      - One or more "Hash" Armor Headers,
2373,2375c2379,2382
<    SHA-1 is used. If more than one message digest is used in the
<    signature, the "Hash" armor header contains a comma-delimited list
<    of used message digests.
---
>    MD5 is used, an implementation MAY omit them for V2.x compatibility.
>    If more than one message digest is used in the signature, the "Hash"
>    armor header contains a comma-delimited list of used message
>    digests.
2877c2887
<    algorithm identifier 20.
---
>    algorithm identifier 20 for an Elgamal public key that can sign.
2961a2976,2982
>    Many security protocol designers think that it is a bad idea to use
>    a single key for both privacy (encryption) and integrity
>    (signatures). In fact, this was one of the motivating forces behind
>    the V4 key format with separate signature and encryption keys. If
>    you as an implementor promote dual-use keys, you should at least be
>    aware of this controversy.
>
2973c2990,2991
<    could leak the secret key.
---
>    could leak the secret key. These same considerations about the
>    quality of the hash algorithm apply to Elgamal signatures.
3030,3031c3050,3052
<      * PGP 5.0 can read an RSA key in V4 format, but will only
<        recognize it using V3 format.
---
>      * PGP 5.0 can read an RSA key in V4 format, but can only recognize
>        it with a V3 keyid, and can properly use only a V3 format RSA
>        key.
3041,3043d3061
<      * PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a
<        zero-length compressed data packet.
<

Date: Mon, 15 Jun 1998 15:45:31 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Another draft coming your way.
Sender: [email-masked]

I'm sending out today what I hope is really, really the last draft of the
spec. I've added in Tom Zerucha's comments here about my last
forgetfulness, added in the headers that Lutz pointed out, and dealt some
more with the issue of Elgamal signatures.

I've spoken to a number of people on both sides of the Elgamal issue. While
it's true that DSS produces shorter signatures than Elgamal, and is
potentially faster, there's no evidence that Elgamal signatures are
insecure, provided that the proper care has been taken. I went over all the
discussion that I put in for the -04 draft, and made a tweak.

The relevant diffs will be coming in another message.

Note that while I'm really happy to fix any other problems someone finds,
it's way too late to start a controversy. I expect that draft -05 is it,
short of fixing an important typo, thinko, or braino.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
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: Mon, 15 Jun 1998 10:51:28 -0500
To: Michael Baumer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Hash of Keys and Sync of Servers
Sender: [email-masked]

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

In <[email-masked]>, on
06/15/98 
   at 05:26 PM, Michael Baumer <[email-masked]> said:

>Since this mechanism uses serial numbers for requesting retransmitts you
>could get the functionality of your hash-functionality with simply
>comparing those serial numbers with a local "database" of serials.

>Since the serial numbers are stored in pgp-packets you could use an
>extended pgp for this. 

I am not quite sure what you mean by serial number and how it relates to
insuring that two DB's have the same key?

Is the serial number directly related to the contents of a key or is it
just a unique ID for a key? If it is the second then how does one insure
that an updated key has the updates propegated to all the servers? If we
are talking about a end users how does he insure that his local copy of a
key is the same as the servers without periodically downloading the keys?

- -- 
- ---------------------------------------------------------------
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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windws is ine for bckgroun comunicaions

Date: Mon, 15 Jun 1998 17:26:57 +0200 (MET DST)
From: Michael Baumer <[email-masked]>
Reply-To: Michael Baumer <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Hash of Keys and Sync of Servers
Sender: [email-masked]

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

Hello

[For the poeple on open-pgp: 
This is only informational, but interesting because our solution uses a
new PGP-Packet type, which should be ignored and may be stored by a PGP
implementation (instead of aborting)]

We're currently working on a replacement for the mail based
synchronization mechanism, relying on the MBone, but also allowing unicast
connectivity, single update messages (less flooding) and a reliable
mechanism to detect missed updates and re-request them.

This mechanism should reduce today's problems with keyservers which are
out of sync or not reachable (ie. crashed...) and e-mail bouncing around.

A release date is in "near future" ;-) 

Since this mechanism uses serial numbers for requesting retransmitts you
could get the functionality of your hash-functionality with simply
comparing those serial numbers with a local "database" of serials.

Since the serial numbers are stored in pgp-packets you could use an
extended pgp for this. 

Michael
- --
Michael Baumer, Praesident VIS
VIS - Verein der Informatikstudierenden an der ETH Zuerich
e-mail (pers.): [email-masked]
e-mail (Verein): [email-masked]

PGP-KeyID: 2238F089, 2048 Bits
Key fingerprint: A8 E3 D9 73 72 8F E2 60  87 BC 86 4B 53 86 B5 79
finger [email-masked] for pgp-key

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 15 Jun 1998 09:50:16 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Hash of Keys and Sync of Servers
Sender: [email-masked]

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

Hi,

I had made this proposal last year but never heard anything back on it so
I thought I would bring it up again.

I would like to see the ability to retreive the hash of a key from the
database. This would be a hash of the complete key (key, userid's, sigs).

This hash would be used for comparing two keys without haveing to download
the key from a server. 

The user would send the keyID to the server requesting the hash.

The server would return the hash of the key.

The user would compare the hash to a locally generated hash.

If the hashes match then no further action is needed.

If the hashes are different then:

The user downloads the key and updates his keyring.

The user then generates a new local hash of the key.

If the hashes are still different then the user uploads the key to the
server.

Calculations of local hashes:

Local hashes consist of:

Public Key
UserID's
Exportable Signatures (this includes self sigs and revocation sigs)

Trust packets and non-exportable sigs are not used in the local hash
calculations.

Preferably the server would accept a list of keyID's to query for hashes
to cut down on traffic. A maximum number of keys per query could be set by
the server to prevent it from being overloaded by large requests.

Key hashes would be stored in the server DB and hases would only be
calculated by the server when a key is added/updated. This will cause a
slight increase in the size of the DB but would be well compensated by the
saving of time in doing the calculations on a per request basis.

This could also be used for sync of the various servers. Periodically the
public servers could publish a index of all their keys and corresponding
hashes. Sync sites would use this list to compare to their current DB of
keys.

Some form of agreement between the sync sites should be made of when the
hash lists will be published and when the syncing of servers should take
place. It might be a good idea for two servers that are in the process of
syncing to go "off-line" during the sync process.

I have not done any time trials on this yet but IMHO such a sync process
should be relatively fast. Hash lists should be ~234k per 100,000 keys
(64bit keyID and 128bit MD5 hash). If the servers have pre-calculated and
stored the key hases and are working with sorted hash lists (by keyID)
then a quick diff of the list and then corresponding key exchange of the
keys should not take too much time or bandwidth.

The sync process should be of a master-slave relationship:

The master site publishes the hash list.

The slave site requests the list and compares to his local list.

The slave site requests keys based on the diff of the two lists.

The slave recalcs the hashes of the updated/new keys.

The slave compares the the new hashes to the master hash list.

The slave uploads keys based on second diff.

The master treats these uploads as it would any other key upload and
propagates them to his sync sites.

I think that a monthly sync to start with would work quite well for
keeping all the servers in sync and keeping the work involved in a sync to
a manageable level. Depending on how much time it takes to create a hash
list the master server may wish to create the hash list "on demand" of a
slave site.

I am going to CC this over to the OpenPGP list to see what they think of
this.

- -- 
- ---------------------------------------------------------------
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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 12 Jun 1998 14:49:11 -0500
To: [email-masked]
Subject: List of PGP Public Keyservers
Sender: [email-masked]

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

Hi,

This is just a quick note to let everyone that I have a webpage available
that lists all the known http based PGP Public Keyservers:

http://users.invweb.net/~whgiii/pgpsrv.html

I just updated all the links last night and have added several new severs
and corrected the links for several others.

You can directly lookup keys from any of the servers from this webpage. To
upload keys follow the link to the indivdule server and use their upload
page.

If there are any servers that you know of that I have missed please drop
me a note with the url.

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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Windows with bullet-proof glass.

Tag-O-Matic: Dos: Venerable.  Windows: Vulnerable.  OS/2: Viable.
 
Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-04.txt
Date: Wed, 03 Jun 1998 10:25:21 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good 
Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-04.txt
	Pages		: 57
	Date		: 02-Jun-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP 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 storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric 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
   OpenPGP.

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-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-04.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: ftp.ietf.org
	
	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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 11 Jun 1998 09:33:51 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Armor Headers in 04
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Is Hash: valid for anywhere other than Clearsigned messages?  Are any
> other headers valid at the top of Clearsigned messages?

"Hash:" is only for clearsigned messages.  PGP 5 and later will not
accept any other headers on clearsigned messages.

Hal

Date: Wed, 10 Jun 1998 19:51:38 -0700 (PDT)
From: 4n6n61 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  44
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 18:03:09 -0700 (PDT)
From: 3rstyhd <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  3  g
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 18:33:02 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Lutz Donnerhacke <[email-masked]>, [email-masked]
Subject: Re: Armor Headers in 04
Sender: [email-masked]

On Wed, 10 Jun 1998, Jon Callas wrote:

> At 10:03 AM 6/5/98 GMT, Lutz Donnerhacke wrote:
>       Currently defined Armor Header Keys are:
>         - "Version", that states the OpenPGP Version used to encode the
>         - "Comment", a user-defined comment.
>         - "MessageID", a 32-character string of printable
>    
>    Do I miss "Hash" and "Charset"?
>    
> I added in "Hash". Should I add in Charset? OpenPGP defines the charset to
> be UTF-8. It's useful for a non-OpenPGP program to state what charset it
> did use, but no one is required to honor it.

Is Hash: valid for anywhere other than Clearsigned messages?  Are any
other headers valid at the top of Clearsigned messages?

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

Date: Wed, 10 Jun 1998 13:06:18 -0700
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Armor Headers in 04
Sender: [email-masked]

At 10:03 AM 6/5/98 GMT, Lutz Donnerhacke wrote:
      Currently defined Armor Header Keys are:
        - "Version", that states the OpenPGP Version used to encode the
        - "Comment", a user-defined comment.
        - "MessageID", a 32-character string of printable
   
   Do I miss "Hash" and "Charset"?
   
I added in "Hash". Should I add in Charset? OpenPGP defines the charset to
be UTF-8. It's useful for a non-OpenPGP program to state what charset it
did use, but no one is required to honor it.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 10 Jun 1998 12:50:13 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: More (some already reported) spec nits
Cc: [email-masked]
Sender: [email-masked]

At 11:12 AM 6/4/98 -0400, [email-masked] wrote:
   1. in 5.6, para beginning with ZIP-compressed, it repeats the phrase "If
   an implementation uses more bits of compression,"
   
   2. In section 14, "PGP 5.0 can read an RSA key in V4 format but will only
   recognize it using V3 format." should say "... V3 keyid." - it recognizes
   either format, but only V3 keyids.
   
   3. "PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a
   zero-length ocmpressed data packet." should be removed.  The cause of this
   was a "compressed" block of type store which appeared to be of zero
   length because it was simply a prefix.
   
All of these changes have been made. I adapted Hal's comments into 2. The
wording there is: PGP 5.0 can read an RSA key in V4 format but can only
recognize it with a V3 keyid, and can only properly use a V3 format RSA key.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Subject: Re: The case against ElGamal signatures in PGP
To: [email-masked] (Philip Zimmermann)
Date: Tue, 9 Jun 1998 11:39:08 +0200 (+0200)
Cc: [email-masked], [email-masked]
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

> "RSA has been done wrong"?  I see no mention of RSA in the above paragraph 
> that you quoted.

That's the point. The literature has several examples of RSA being
done wrong, just as with ElGamal signatures. Yet you don't argue that
RSA should be removed from OpenPGP.

Date: Tue, 9 Jun 1998 08:50:54 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: Bill Stewart <[email-masked]>
cc: Tony Bartoletti <[email-masked]>, Vinnie Moscaritolo <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>, Bill Frantz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: PGPticket
Sender: [email-masked]

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

On Sun, 7 Jun 1998, Bill Stewart wrote:

> At 03:52 PM 5/27/98 -0700, Tony Bartoletti wrote:
> >  >A client should never sign a challenge on it's own. the challenge should 
> >  >have a client random nonce  appended to it, then sign that. the nonce
> >  >can in fact be used as a counter challenge for the server to sign (whereby
> >  >it also attaches a random nonce)
> >
> >Vinnie,  You are absolutely right.  I was led astray by the wording of 6:
> >  "The client signs and returns the challenge string with a
> >  random nonce appended."

> Is appending the nonce good enough, or should you really prepend as well?
> The problem is that lots of applications can potentially be tricked by
> 	sign( "syntactically-correct-stuff,junk" )
> while they're less likely to accept messages with the junk first.
> 				Thanks! 

	I am working on this draft with Vinnie and have an idea on how to
solve this. I talked with him briefly about it. Basically, the response
should be another V4 standalone signature. The challenge is placed in a
notation subpacket that is the only 'hashed' subpacket. The signature on
the V4 sig packet is the hash of the notation subpacket containing the
challenge (kinda like a 'meta' signature).

	In the case of a client being one of several subjects in the
original PGPticket, their subject information should go in a separate
notation subpacket in the unhashed subpacket section. This will tell the
server which client is actually trying to use the ticket and keep them from
having to check the signature with each subject's key.

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

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F       ***** Important: John 17:3 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

From: "Domenico Rotondi" <[email-masked]>
To: "<openpgp" <[email-masked]>
Subject: OFF TOPIC: PGP Plug In for Outlook Express
Date: Mon, 8 Jun 1998 20:39:11 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01BD931D.7E2DB020
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry to bother all of you with the following problem.
I'm trying to use the available PGP Plug in for Outlook Express, but, =
even if I've tried both a national (Italian) and an international (US) =
version of Outlook Express under Windows 95, I can't succeed in using =
it.
It seems that the Plug In available on pgp.net (which declares itself as =
version 5.5.5) is able to correctly encrypt or "encrypt and sign" e-mail =
messages, but does not correctly "sign" e-mail messages.
Indeed, all sent messages are not recognised as correctly structured by =
receiving Outlook Express with the PGP Plug-in or receiving full =
Outlook.

If I select the "Decrypt message" entry from the PGP menu while reading =
a signed message I always get the following diagnosys "The message/data =
contains a detagned signature".

Viceversa, if I both encrypt and sign a message everything works fine.
Can someone give me a hint?
Please reply directly to me.
Thanks in advance. Ciao
    Dom

------=_NextPart_000_002D_01BD931D.7E2DB020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Sorry to bother all of you with the =
following=20
problem.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I'm trying to use the available PGP =
Plug in for=20
Outlook Express, but, even if I've tried both a national (Italian) and =
an=20
international (US) version of Outlook Express under Windows 95, I can't =
succeed=20
in using it.</FONT></DIV>
<DIV><FONT size=3D2>It seems that the Plug In available on pgp.net =
(which declares=20
itself as version 5.5.5) is able to correctly encrypt or &quot;encrypt =
and=20
sign&quot; e-mail messages, but does not correctly &quot;sign&quot; =
e-mail=20
messages.</FONT></DIV>
<DIV><FONT size=3D2>Indeed, all sent messages are not recognised as =
correctly=20
structured by receiving Outlook Express with the PGP Plug-in or =
receiving full=20
Outlook.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If I select the &quot;Decrypt message&quot; entry =
from the PGP=20
menu while reading a signed message I always get the following diagnosys =

&quot;The message/data contains a detagned signature&quot;.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Viceversa, if I both encrypt and sign a message =
everything=20
works fine.</FONT></DIV>
<DIV><FONT size=3D2>Can someone give me a hint?</FONT></DIV>
<DIV><FONT size=3D2>Please reply directly to me.</FONT></DIV>
<DIV><FONT size=3D2>Thanks in advance. Ciao</FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Dom</FONT></DIV></BODY></HTML>

------=_NextPart_000_002D_01BD931D.7E2DB020--

Date: Mon,  8 Jun 1998 09:56:43 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: Re: PGPticket
To: Bill Stewart <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>, Bill Frantz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On 6/7/98, Men from Black Helicopters forced Bill Stewart to write:
 > 
> Is appending the nonce good enough, or should you really prepend as well?
> The problem is that lots of applications can potentially be tricked by
>  sign( "syntactically-correct-stuff,junk" )
> while they're less likely to accept messages with the junk first.
>

this is a great point! well taken..

I will fix this in the protocol..

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Sun, 07 Jun 1998 16:41:35 -0500
To: Tony Bartoletti <[email-masked]>, Vinnie Moscaritolo <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: PGPticket
Cc: Bill Frantz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 03:52 PM 5/27/98 -0700, Tony Bartoletti wrote:
>  >A client should never sign a challenge on it's own. the challenge should 
>  >have a client random nonce  appended to it, then sign that. the nonce
>  >can in fact be used as a counter challenge for the server to sign (whereby
>  >it also attaches a random nonce)
>
>Vinnie,  You are absolutely right.  I was led astray by the wording of 6:
>  "The client signs and returns the challenge string with a
>  random nonce appended."

Is appending the nonce good enough, or should you really prepend as well?
The problem is that lots of applications can potentially be tricked by
	sign( "syntactically-correct-stuff,junk" )
while they're less likely to accept messages with the junk first.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sun, 07 Jun 1998 01:38:44 -0700
To: Jon Callas <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

At 11:33 AM 6/1/98 -0700, Jon Callas wrote:
>At 11:57 PM 5/29/98 -0700, Bill Stewart wrote:
>
> >  Null-terminating the string would be a nice touch; it's not necessary,
> >  since there's a length field, but it would probably reduce accidents,
> >  and it also makes it convenient for tools such as "strings" to find.
...
>With counted strings, someone has to go and terminate them anyway, and the
>only place where a null-terminated string is specified in the whole draft
>is in the regular expression subpacket (and I don't know why it's there). 
>
>When I put on my developer's hat, I look at it and think that I'd write to
>code to look at the length of the subpacket, and if it's greater than 1,
>then I have text. If the string is null-terminated, how do I handle the
>bizarre case of a specified comment that is a null string? Do I treat it
>the same as no specified string, or as a blank comment? There's an easy
>answer (treat it as no comment), but the question goes away if we just use
>the count.

The "yes, that \0 in the middle of the string is part of the comment" case
does seem to make null-terminating a less-than-good idea.
My concern was the number of times I've seen C programmers assume
null-terminated strings and read past the end, even if they've got
a length count.
				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: Armor Headers in 04
Date: 5 Jun 1998 10:03:20 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

   Currently defined Armor Header Keys are:
     - "Version", that states the OpenPGP Version used to encode the
     - "Comment", a user-defined comment.
     - "MessageID", a 32-character string of printable

Do I miss "Hash" and "Charset"?

Date: Thu, 4 Jun 1998 22:27:19 -0400
From: [email-masked]
To: [email-masked]
Subject: Minor updates to opgp & palmopgp
Sender: [email-masked]

sent to www.cryptography.org.  opgp99o.tgz corrects some small nits.

palmopgp03.tgz now implements all SSLeay supported algorithms, and does
compression (very usable, but less than even 13 bit zip) and
decompression, so it should be able to decrypt any OpenPGP message (I also
got the extra algorithms compiling in another lib after I uploaded, but
haven't tried them).  The test program won't go past two messages,
probably because I have memory leaks that I need to fix, but I added an
automatic continue-till-literal, and it will do the entire test suite (Any
message in the Memo Pad beginning with TEST will be literal/signed,
compressed, encrypted, armored, and then dearmored, decrypted,
decompressed, extracted/verified. 

I still don't have any form of key management (I am using keyids), nor key
generation.  The general idea will be to copy the valid keys from your
desktop [note, you will need to armor your secring.skr file and install it
as a memo].

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

Date: Thu, 4 Jun 1998 12:11:17 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

One of the points offered in support of ElGamal signatures is that this will
allow ElGamal keys to be used for both encryption and signatures.

Actually, this is not a good idea.  It is a useful principle of
cryptographic protocol design that the same key should not be used for
more than one protocol.  That is why even with RSA keys you are seeing
more and more implementations using separate keys for encryption and
signatures.

There are a couple of reasons for this precaution.  One is simply to
partition the usage of keys so that if a key is stolen or broken then
less functionality is compromised.  But the more significant point is
that it may be that using a key in more than one protocol causes specific
cryptographic weaknesses.

As a trivial example, some digital cash protocols use RSA based "blind
signatures" where the data being signed is mathematically hidden from
the signer.  Obviously if that same key were used to sign messages,
someone could get a blind signature on the hash of a message and easily
forge signatures.

Another case might be an upcoming paper from Bleichenbacher to be
presented at Crypto 98, where he shows chosen-plaintext attacks against
RSA keys which use PKCS padding.  The attacker sends chosen RSA-encrypted
messages, and if information leaks back to him about which ones happened
to decrypt to syntactically legal PKCS-padded data, then he can eventually
construct an exponentiation on a chosen value using the private exponent.
If the RSA key is used only for decryption, he can decrypt a message.
But if it is also used for signatures, he can get an RSA signature on
a chosen message.  Breaking one protocol leaks into breaks of other
protocols.

Bruce Schneier and his group have come up with the idea of a "chosen
protocol attack" where two protocols, each individually secure, will
compromise a key when it is used for both protocols.  See
http://www.counterpane.com/chosen_protocol.html for more information.

Even if we support ElGamal signatures, we should move away from dual
use keys.  Encryption and signatures are very different kinds of
functionality, and we should not use the same keys for both if we can
avoid it.

Hal

Date: Thu, 4 Jun 1998 11:36:23 -0700
To: [email-masked]
From: Philip Zimmermann <[email-masked]>
Subject: Re: The case against ElGamal signatures in PGP
Cc: [email-masked]
Sender: [email-masked]

Just to clarify things for William Geiger, I was not speaking of a PGP
PKI in a formal sense, but rather in a de facto sense.  There is a PGP
PKI, and there has been for some years.  It was the first widely deployed
PKI.  I was merely acknowledging this fact, and making some educated
guesses as to how this de facto PKI would behave if we deploy software 
that supports this OpenPGP spec.  There is no need for us to get involved
in any formal discussions of how to standardize on a PGP PKI.

On other matters...

At 13:12 +0200 6/3/98, Ulf Möller wrote:
>PRZ wrote:
>> If discrete logs prove to be a solvable problem, both DSA and
>> ElGamal will fall, as well as DH encryption.
>
>As you probably know, discrete logs are a solvable problem, the
>difficulty of which is a function of the key size.  You fail to
>consider the effect of progress in algorithms to efficiently compute
>discrete logarithms.

I did not fail to consider that.  In fact, that is precisely what I 
meant by "solvable" -- that it becomes *feasibly* solvable.  I was 
using a shorthand expression that I thought would be acceptable to 
crypto colleagues.

>> it would be just as easy to expand the p and q parameters of DSS as 
>> it would to expand the parameters of pure ElGamal.
>
>Then we need a specification, and a notice from the DSA patent holder
>(NSA) that they have no objections against this use.

There is no time to expand DSA in time for this OpenPGP spec.  I thought
we could do it later.  I don't think NSA would object.  I talked with
some NSA crypto people at Crypto97 about this.

We already know how to expand DSA.  We know how big to grow p and q,
how to keep them well balanced.  It's only the lack of a larger hash
that kept us from doing that in PGP software.  The lack of a larger
hash affects DSA and ElGmal signatures equally.  If this lack is cured,
it would be applicable to both signature schemes.

>> Since the DH patent is now expired, that opens the door for free
>> unencumbered public key cryptography, creating a level playing
>> field.
>
>You seem to imply that the DSA is not covered by patents.  That again
>is wrong.  Please refer to the past discussion on the Kravitz patent
>on DSA, and Schnorr's US patent, which the owner claims covers DSA and
>which has not been challenged in court.

The legal burden of challanging RSA's claim (that Schnorr covers DSA) 
in court rests on RSA, not on the rest of us.  It is up RSA to challange 
anyone else in court over DSA usage, and that has not happened.  No one 
but RSA believes that the Schnorr patent covers DSA.  Many software
products that implement DSA, including PGP, will be commercially deployed 
by many vendors, without any patent licensing from anyone.  NIST indemnifies
anyone who implements it for the government, and Cylink indemnifies their 
customers as well.  I didn't think we needed to debate the patent status
of DSA here.  Obviously we are going ahead with DSA deployment along with
everyone else.  Surely you are not suggesting that we not deploy DSA
(oops-- too late for that!).

>
>> In principal, an especially careful implementation could avoid these 
>> weaknesses.  But at least one implementation of OpenPGP's ElGamal signatures 
>> has done it wrong.  Others might also do it wrong.  PGP users should not 
>> have to lie awake at night wondering if the implementor did a perfect job,
>> or did he fall into one of the pitfalls that are so easy to fall into.
>
>Netscape, SecuDE and several others fell into one of the pitfalls that
>are so easy to fall into by fielding crypto implementations with
>fatally flawed PRNGs.  RSA has been done wrong.  Your poing being
>what?

"RSA has been done wrong"?  I see no mention of RSA in the above paragraph 
that you quoted.

When I was at Eurocrypt97, 3 or 4 well-respected cryptographers approached 
me and asked me (with concern in their voices) if PGP's use of ElGamal included
signatures.  In other words, when they heard that PGP 5.0 was using ElGamal for encryption, they immediately raised doubts about PGP's quality if PGP were to
use ElGamal for signatures as well.  This is because they were concerned that
there were ways to get it wrong.  If we had been using ElGamal for signatures,
I would have made sure we were doing it the right way, and I would have told
them that.  But that would require me to talk with each and every cryptographer
who harbors such doubts and assure him that we did it right.  They did not
express such doubts about DSA.  They just assumed that we would do it right
if it were DSA.  It's not enough that PGP implement ElGamal correctly.  It is
also necessary that all the cryptographers believe that we all (all of the
various OpenPGP implementors) did it correctly.

>
>> It does not matter that it is a bad algorithm, reviewers will
>> compare products in such a way as to make it look better if you
>> implement ElGamal signatures.
>
>It is not a bad algorithm.  If you feel that your company is not
>capable of implementing it properly, well, don't do it.  Others can
>avoid all known weaknesses and provide their users with a useful
>algorithm.

Of course we can implement it correctly.  It was only in experimental
code that should not have been released that there was a flaw in our
implementation.  We ifdef'ed it out, and so should not be judged on it.

Providing users with a useful algorithm should not be the point.  We can 
add hundreds of variants of discrete log signature algorithms to PGP.  
Why not support them all?  They are all useful.  Why not add Rabin's 
algorithm on the factoring side as well?  Because there is no need to.

We don't need more algorithms unless they bring something unique to the 
table.  Having one PK algorithm based on factoring and one based on discrete 
logs is enough.  Even though EC is also based on discrete logs, we can
add it when we need to because it's much easier to compute on cheap
processors.

There will be harm done to the deployed PGP PKI if large numbers of ElGamal
signature keys get deployed, even if there are no weaknesses in the
implementations.  The signatures are much bigger than DSA, without any 
additional benefits that would not apply equally to DSA.  If you want
bigger signatures, we can expand DSA, and get more bang for the buck.
More strength for fewer bits in the signature.  But I would prefer not to
hold up the spec, so can we wait until after the RFC is issued before we
do that?

How about this.  Let's deploy the standard with just the 1024-bit DSA,
and say "SHOULD NOT" on the ElGamal algorithm, but leave it in.  That
will inhibit its deployment.  After the standard is out, we can then
immediately start work on expanding DSA the right way.  If we succeed
in that, we can meet everyone's needs with a bigger DSA, and issue a
revision that includes that and deprecate ElGamal.

Date: Thu, 4 Jun 1998 13:51:42 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: More (some already reported) spec nits
Sender: [email-masked]

On Thu, 4 Jun 1998, Hal Finney wrote:

> > 2. In section 14, "PGP 5.0 can read an RSA key in V4 format but will only
> > recognize it using V3 format." should say "... V3 keyid." - it recognizes
> > either format, but only V3 keyids.
> 
> I think Jon's wording is better here.  The fact that it doesn't calculate
> the keyid properly means that the key can't be used for encryption,
> decryption, signature, etc. and interoperate with openpgp implementations.
> This fact may not be obvious if we just mentioned the keyid difference -
> people may think the only problem is the keyid display in the properties
> dialog box.  It is better to say that PGP 5.0 doesn't handle V4 RSA
> keys properly.

Well, another point I made is that handling of RSA keyids is ambiguous.  I
can derive V3 keyids from V4 keys and vice versa.  My implementation
actually matches on both keyids, and uses whatever is given as a keyid
(which again will retrieve the key material if it matches either method) 
for the routines that do encryption and signing.

Or the wording should be more "but will only operate on it as if it was
the equivalent key material in V3 format".  I haven't confirmed this since
the version byte changes, so the fingerprint should differ although the V3
keyid would be the same.

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

Date: Thu, 4 Jun 1998 09:00:30 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: More (some already reported) spec nits
Cc: [email-masked]
Sender: [email-masked]

> 2. In section 14, "PGP 5.0 can read an RSA key in V4 format but will only
> recognize it using V3 format." should say "... V3 keyid." - it recognizes
> either format, but only V3 keyids.

I think Jon's wording is better here.  The fact that it doesn't calculate
the keyid properly means that the key can't be used for encryption,
decryption, signature, etc. and interoperate with openpgp implementations.
This fact may not be obvious if we just mentioned the keyid difference -
people may think the only problem is the keyid display in the properties
dialog box.  It is better to say that PGP 5.0 doesn't handle V4 RSA
keys properly.

Hal

Date: Thu, 4 Jun 1998 11:12:55 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: More (some already reported) spec nits
Sender: [email-masked]

1. in 5.6, para beginning with ZIP-compressed, it repeats the phrase "If
an implementation uses more bits of compression,"

2. In section 14, "PGP 5.0 can read an RSA key in V4 format but will only
recognize it using V3 format." should say "... V3 keyid." - it recognizes
either format, but only V3 keyids.

3. "PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a
zero-length ocmpressed data packet." should be removed.  The cause of this
was a "compressed" block of type store which appeared to be of zero
length because it was simply a prefix.

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

Date: Wed, 03 Jun 1998 18:17:51 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: AGAIN: "Hash:" either SHOULD be used, or default to MD5
Cc: [email-masked]
Sender: [email-masked]

At 07:16 PM 6/3/98 -0400, [email-masked] wrote:
   Is the third or fourth time?
   
   Section 7 states...
   
   Zero or more "Hash:" armor headers.
   
   That should be One or more "Hash:" armor headers, with a note that an
   implementation MAY omit them only for MD5/V3/etc. interoperability.
   
   I had some different substitute text last time, but then there was a
   suggested ammendment.
   
   This really needs to be fixed.  Open PGP implementations should have Hash:
   headers.  Otherwise the default must be MD5 to interoperate with earlier
   implementations.
   
   ____________
   
   On another note, you may want to grep for MAY NOT (in the section for
   partial packet length bytes).  I thing MAY NOT should read SHOULD NOT or
   MUST NOT, and MAY NOT might occur elsewhere.
   
Sorry, I'll take care of those.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 3 Jun 1998 19:16:13 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: AGAIN: "Hash:" either SHOULD be used, or default to MD5
Sender: [email-masked]

Is the third or fourth time?

Section 7 states...

Zero or more "Hash:" armor headers.

That should be One or more "Hash:" armor headers, with a note that an
implementation MAY omit them only for MD5/V3/etc. interoperability.

I had some different substitute text last time, but then there was a
suggested ammendment.

This really needs to be fixed.  Open PGP implementations should have Hash:
headers.  Otherwise the default must be MD5 to interoperate with earlier
implementations.

____________

On another note, you may want to grep for MAY NOT (in the section for
partial packet length bytes).  I thing MAY NOT should read SHOULD NOT or
MUST NOT, and MAY NOT might occur elsewhere.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-04.txt
Date: Wed, 03 Jun 1998 10:25:21 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good 
Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-04.txt
	Pages		: 57
	Date		: 02-Jun-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP 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 storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric 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
   OpenPGP.

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-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-04.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: ftp.ietf.org
	
	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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 3 Jun 98 13:12 +0200
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Organization: HR13
Cc: [email-masked]
Sender: [email-masked]

Two main reasons have been given on the OpenPGP list for allowing
ElGamal signatures: flexibility in key size and its patent status.
Your discussion of the first is wrong (see below), you don't address
the second.  In much of the rest of your message, you are beating a
strawman ("can imagine some of the reasons").  All in all, your mail
does not justify changing the status of ElGamal signatures in the
draft.

> to admit I didn't follow the traffic on this list when this type of
> signature was introduced, but I can imagine some of the reasons that one
> might have for introducing them into OpenPGP.  Let's review them.

Please do read the messages in the archive, then feel free to review
them.

> If discrete logs prove to be a solvable problem, both DSA and
> ElGamal will fall, as well as DH encryption.

As you probably know, discrete logs are a solvable problem, the
difficulty of which is a function of the key size.  You fail to
consider the effect of progress in algorithms to efficiently compute
discrete logarithms.

> it would be just as easy to expand the p and q parameters of DSS as 
> it would to expand the parameters of pure ElGamal.

Then we need a specification, and a notice from the DSA patent holder
(NSA) that they have no objections against this use.

> Since the DH patent is now expired, that opens the door for free
> unencumbered public key cryptography, creating a level playing
> field.

You seem to imply that the DSA is not covered by patents.  That again
is wrong.  Please refer to the past discussion on the Kravitz patent
on DSA, and Schnorr's US patent, which the owner claims covers DSA and
which has not been challenged in court.

> But straight ElGamal signatures offers no new real capability.  It brings
> nothing new to the table.

As pointed out above, they do.

> In principal, an especially careful implementation could avoid these 
> weaknesses.  But at least one implementation of OpenPGP's ElGamal signatures 
> has done it wrong.  Others might also do it wrong.  PGP users should not 
> have to lie awake at night wondering if the implementor did a perfect job,
> or did he fall into one of the pitfalls that are so easy to fall into.

Netscape, SecuDE and several others fell into one of the pitfalls that
are so easy to fall into by fielding crypto implementations with
fatally flawed PRNGs.  RSA has been done wrong.  Your poing being
what?

> It does not matter that it is a bad algorithm, reviewers will
> compare products in such a way as to make it look better if you
> implement ElGamal signatures.

It is not a bad algorithm.  If you feel that your company is not
capable of implementing it properly, well, don't do it.  Others can
avoid all known weaknesses and provide their users with a useful
algorithm.

> there will always be doubts raised when mainstream lay journalists
> (or lay users) rediscover any of the old academic papers that have
> reported on weaknesses or attacks on ElGamal signatures.  We will
> find ourselves having to explain this away, over and over again.

There are academic papers on weaknesses of RSA, PRNGs and what not.
There even are papers on specific weaknesses of PGP.  The purpose of
academic papers is to learn from the past and do better afterwards.
None of those papers is a reason not to implement RSA or ElGamal. You
just have to know the weaknesses and avoid them.

Date: Wed, 3 Jun 1998 09:38:05 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

[email-masked] writes:

> It was and is.  I think I was the only one to actually enable them.  I
> also enabled DSA/RIPEMD and such.

So does gnupg.

> How about "Algorithms that are not 'MUST' or 'SHOULD' SHOULD NOT be
> entered into the PGP PKI".  This is perfectly reasonable - you wouldn't
> want experimental algorithms widely published, nor keys that are rarely
> implemented.  Since ElGamal is MAY, keyservers SHOULD NOT accept them.

Current keyserves accept everything including faked user-ids and keys.
I talked to some keyserver people and we came to the conclusion that a
new keyserver software should address this problem by verifying at
least the self-signatures of all OpenPGP keys.  As the design of gnupg
is based on keyservers, I have to write such software anyway and of
course it will support ElGamal signatures.

> I would like to keep it at 20.  I can move it, but that number was created
> for the specific reason.

So do I.  I saw the reason for the additional identifier 20 and
changed my software so that it now generates ElGamal keys with 20 and
inhibits the usage of v4 packets with pubkey 16 for signatures.

I can't count the hours of voluntary work on gnupg only to support
the changes in OpenPGP and I'm not willing to add code for another=20
algorithm identifier.  The comment packet case and the reuse of
existing (rfc1991) packets for different purposes has been bothering
me enough.  Every time I code some of these changes I am thinking why at
all using this ugly pgp format and not going for a more versatile
format and dropping any pgp support.

If we can stay with the current draft, I will make DSA the default
algorithm for gnupg.

Werner

p.s.
Signed with a ElGamal key in a v3 packet which is a RFC1991 compliant
extension - used due to the undocumented pgp5 format.
[finger [email-masked] for the pubkey]

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature

--PEIAKu/WMn1b1Hv9--

Date: Tue, 2 Jun 1998 19:19:18 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PGP PKI? (Was: The case against ElGamal signatures in PGP)
Cc: Philip Zimmermann <[email-masked]>, [email-masked]
Sender: [email-masked]

At 5:21 PM -0700 6/2/98, William H. Geiger III said:

   I was unable to make the LA meeting and this is the first I have heard
   anything about a PGP PKI.

   Who is working on this? What information is available on this, who is
   working on this, how far along has design gone and why hasn't this been
   brought up on this list before now? IMHO if a PKI is being desinged then
   this MUST be disscused on the list (or a seperate list) now not 6mo. from
   now after a draft has been presented.

I think Phil was speaking metaphorically. There is no OpenPGP PKI as part
of this working group.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860
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, 02 Jun 1998 19:21:58 -0500
To: [email-masked]
Cc: Philip Zimmermann <[email-masked]>, [email-masked]
Subject: PGP PKI? (Was: The case against ElGamal signatures in PGP)
Sender: [email-masked]

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

In <[email-masked]>, on 06/02/98 
   at 06:18 PM, [email-masked] said:

>> Maybe that would work, if we can keep ElGamal from entering the PGP PKI.
>> I would rather extend DSA as soon as we can find a suitable hash.  But
>> let's not hold up the spec to do it.  It will take a while to find a good 
>> hash.

>How about "Algorithms that are not 'MUST' or 'SHOULD' SHOULD NOT be
>entered into the PGP PKI".  This is perfectly reasonable - you wouldn't
>want experimental algorithms widely published, nor keys that are rarely
>implemented.  Since ElGamal is MAY, keyservers SHOULD NOT accept them.

>I think this addresses your concerns with the least disruption.

Ok guys,

I was unable to make the LA meeting and this is the first I have heard
anything about a PGP PKI.

Who is working on this? What information is available on this, who is
working on this, how far along has design gone and why hasn't this been
brought up on this list before now? IMHO if a PKI is being desinged then
this MUST be disscused on the list (or a seperate list) now not 6mo. from
now after a draft has been presented.

Now as far as not allowing ElGamal signatures IMHO if they are valid under
the OpenPGP RFC I don't see how you can exclude them from the PKI.

- -- 
- ---------------------------------------------------------------
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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Speed Kills - Use Windows!

Date: Tue, 2 Jun 1998 18:18:38 -0400
From: [email-masked]
To: Philip Zimmermann <[email-masked]>
cc: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

On Tue, 2 Jun 1998, Philip Zimmermann wrote:

> No, "PGP" is not playing a game.  These were my own remarks, not PGP's.
> I didn't know which implementation got it wrong.  I knew that we had it
> wrong in our experimental code (that's why it was experimental, and 
> ifdef'ed out), and I knew that Jon had told me that someone else did too, 
> but I didn't remember who it was.  I guess "they" got it wrong because we
> got it wrong first, and they used our ifdef'ed code as a base.  Maybe 
> "they" is you.  I'm sorry if that sounded insulting in my posting; I 
> didn't mean it that way, and I didn't know who it was.  I typed those 
> remarks at home in the wee hours of the A.M., without the benefit of 
> having Jon Callas around to ask him for details.

It is best to avoid hearsay even at wee hours of the morning.  The only
defect that I know of is given in the link on El Gamal signatures from

http://www.bell-labs.com/user/bleichen/bib.html

Which is also covered briefly in the Handbook of Applied Cryptography.

I think I fixed my version to take care of this security hole before the
OpenPGP WG was formed.  I don't know of any other security flaw in
ElGamal, but don't subscribe to abstract mathematical journals.

> >The original PGP published source contained disabled support for ElGamal
> >signatures and was broken.  This code should have been removed, though I
> >may have been the only one to enable it.
> 
> We should not have let it out.  It was experimental.  Hal thought that
> the #ifdef around it would be enough.  It keeps the compiler away from
> it, and he thought that was enough to keep people away from it, too.

It was and is.  I think I was the only one to actually enable them.  I
also enabled DSA/RIPEMD and such.

> >They will be subjected to Haval, Tiger, DES/SK (when it is available),
> >Blowfish, Safer/SK-128, MD2, EC (in whatever form), on the same basis as
> >ElGamal.  Why include all these, but not ElGamal? 
> 
> I don't think we should include these either, but I didn't want to make a
> fuss over them, in the interest of making people happy.

These were less controversial than ElGamal.  There is little use for extra
algorithms which provide similar function.  Suggesting that we drop any of
these would have caused less furor.

> >This late in the game, I would agree to changing the MAY to a SHOULD NOT
> >for ElGamal.  I would even be willing to disable it by default in my code
> >in the same way that PGP 5.0 disabled support (after fixing it if mine is
> >the errant implementation).  And I think the other implementors may agree
> >to do the same thing and do a moratorium on "enabled ElGamal" until the
> >next spec is released and we can then either delete it or place caveats
> >or come up with a way of extending DSA.
> 
> Maybe that would work, if we can keep ElGamal from entering the PGP PKI.
> I would rather extend DSA as soon as we can find a suitable hash.  But
> let's not hold up the spec to do it.  It will take a while to find a good 
> hash.

How about "Algorithms that are not 'MUST' or 'SHOULD' SHOULD NOT be
entered into the PGP PKI".  This is perfectly reasonable - you wouldn't
want experimental algorithms widely published, nor keys that are rarely
implemented.  Since ElGamal is MAY, keyservers SHOULD NOT accept them.

I think this addresses your concerns with the least disruption.

> Maybe we could use the algorithm byte value that is used for experimental 
> algorithms.  It would be nice to find a way to buy some more time without 
> holding up the spec, while limiting the uptake of ElGamal signatures.  

I would like to keep it at 20.  I can move it, but that number was created
for the specific reason.

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

Date: Tue, 02 Jun 1998 14:54:24 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

At 02:39 PM 6/2/98 -0700, Philip Zimmermann wrote:
>Maybe that would work, if we can keep ElGamal from entering the PGP PKI.

Which PKI is that? A PGP PKI draft was promised at the IETF meeting two
months ago, but I haven't seen it yet. (Actually, I don't think I saw the
minutes of the WG, either...)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 2 Jun 1998 14:39:07 -0700
To: [email-masked]
From: Philip Zimmermann <[email-masked]>
Subject: Re: The case against ElGamal signatures in PGP
Cc: [email-masked]
Sender: [email-masked]

[email-masked] wrote:
>In any case walking into a meeting at the last minute is rude.  Walking in
>like you own the place is ruder still.  And then trying to overturn an
>issue that was discussed and decided much earlier without even reviewing
>the minutes is downright barbaric.

I'm sorry for any apparant rudeness of bringing these matters up so late
in the game.  I didn't mean to act like I own the place.  I tried to
raise these points phrased in a way that would not make anyone feel that 
way, and if I failed in that regard, I'm sorry.

>If size was a concern, you would have split out a separate parameter
>packet since it is likely that all PGP 5.0 1024 bit DSS and DSA keys have
>the parameters in common, and then used a parameter ID and just the public
>key. 

This is a good idea, and I proposed it to our team two years ago, but our 
implementation bandwidth was not up to it.

>If I got it wrong, I would like to know where so I can fix it.  If I
>didn't I would like to know that too.  Or is PGP now going to play a game
>of "guess which competitor has the problem - we know but aren't telling"?
>If it is by request of the implementor that would be a different thing,
>but you now have called into question every one of your competitors.  Is
>this how PGP is going to act now?  Even if you haven't checked the other
>impelmentations, you need to say that too.

No, "PGP" is not playing a game.  These were my own remarks, not PGP's.
I didn't know which implementation got it wrong.  I knew that we had it
wrong in our experimental code (that's why it was experimental, and 
ifdef'ed out), and I knew that Jon had told me that someone else did too, 
but I didn't remember who it was.  I guess "they" got it wrong because we
got it wrong first, and they used our ifdef'ed code as a base.  Maybe 
"they" is you.  I'm sorry if that sounded insulting in my posting; I 
didn't mean it that way, and I didn't know who it was.  I typed those 
remarks at home in the wee hours of the A.M., without the benefit of 
having Jon Callas around to ask him for details.

>The original PGP published source contained disabled support for ElGamal
>signatures and was broken.  This code should have been removed, though I
>may have been the only one to enable it.

We should not have let it out.  It was experimental.  Hal thought that
the #ifdef around it would be enough.  It keeps the compiler away from
it, and he thought that was enough to keep people away from it, too.

>They will be subjected to Haval, Tiger, DES/SK (when it is available),
>Blowfish, Safer/SK-128, MD2, EC (in whatever form), on the same basis as
>ElGamal.  Why include all these, but not ElGamal? 

I don't think we should include these either, but I didn't want to make a
fuss over them, in the interest of making people happy.

>This late in the game, I would agree to changing the MAY to a SHOULD NOT
>for ElGamal.  I would even be willing to disable it by default in my code
>in the same way that PGP 5.0 disabled support (after fixing it if mine is
>the errant implementation).  And I think the other implementors may agree
>to do the same thing and do a moratorium on "enabled ElGamal" until the
>next spec is released and we can then either delete it or place caveats
>or come up with a way of extending DSA.

Maybe that would work, if we can keep ElGamal from entering the PGP PKI.
I would rather extend DSA as soon as we can find a suitable hash.  But
let's not hold up the spec to do it.  It will take a while to find a good 
hash.

Maybe we could use the algorithm byte value that is used for experimental 
algorithms.  It would be nice to find a way to buy some more time without 
holding up the spec, while limiting the uptake of ElGamal signatures.  

Date: Tue, 02 Jun 1998 12:31:54 -0500
To: Philip Zimmermann <[email-masked]>, [email-masked]
From: David Hayes <[email-masked]>
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

At 01:24 AM 6/2/98 -0700, Philip Zimmermann wrote:
>
> ... long discussion of El Gamal signatures deleted.

This would seem to be an important issue. It asks us to change a standard
after some people have already implemented the ElG feature. 

Why, then, does this letter from Phil Zimmermann not bear Phil's PGP
signature? Is this an oversight, or a forgery? OK, maybe I'm paranoid. OK, I
_am_ paranoid, but Phil created PGP to handle issues like this, and I'm
thankful that he did. Phil, did you forget to use your own tool?

--
David Hayes                                       [email-masked]
Switch Systems Planning & Engineering             voice: 972-918-7236
MCI Communications, Inc.                               VNET: 777-7236
--If these thoughts were MCI's official opinions, the line above would
--read "MCI - Law & Public Policy Department".

Date: Tue, 2 Jun 1998 13:29:06 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Philip Zimmermann <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

On Tue, 2 Jun 1998, Philip Zimmermann wrote:

> I know I should have brought this up earlier, but better late than never.
> I would like to suggest to the OpenPGP Working Group that we remove ElGamal
> signatures from this draft RFC.  Here's why.

I can also go back and plead for the OpenPGP WG to change lots of things
which I have been silent on and sent messages at earlier points.  If you
want to open settled issues, I would like an equal chance to do so.
 
Generally I have remained silent about things settled in a manner which I
disagree with, and have actively participated and reviewed the
specification and several changes I suggested had been adopted.  You
haven't even said you have read the spec, and the only other message I see
is from a week ago.

> First, I see no reason to add ElGamal signatures to the standard.  I have
> to admit I didn't follow the traffic on this list when this type of
> signature was introduced, but I can imagine some of the reasons that one
> might have for introducing them into OpenPGP.  Let's review them.

There was a fair amount of traffic about this.  Maybe you should read it
before you create a list of straw men from your imagination and mow them
down. Final call is supposed to be final call, and this is too large of an
issue to be this radically changed at this point.

In any case walking into a meeting at the last minute is rude.  Walking in
like you own the place is ruder still.  And then trying to overturn an
issue that was discussed and decided much earlier without even reviewing
the minutes is downright barbaric.  But I will go over the old ground and
respond anyway.

> 1)  Adding a new public key algorithm is good, in case the others are later
> discovered to have weaknesses.
> 
> I disagree.  ElGamal signatures are no better than DSA signatures.  They 
> are similar in that they both rely on the difficulty of computing discrete 
> logs.  If discrete logs prove to be a solvable problem, both DSA and
> ElGamal will fall, as well as DH encryption.  Indeed, DSA is a variation
> on ElGamal.  Thus, ElGamal signatures offer no real algorithmic diversity.

It is not a different genus but is a different species - ElGamal
signatures have weaknesses that DSA doesn't and possibly vice versa. 
Schneier notes that there are thousands of variants possible given the
generalized equation used to create the signature.  And the weaknesses in
ElGamal don't require the discrete log problem to fall, but only weak
parameters.  Some of these may exist yet undiscovered in DSA.

> 2)  DSS is only 1024 bits max, while ElGamal can be bigger and thus stronger.
> 
> Again, wrong. ...

Technically not.  DSS can have P become larger than 1024 bits, but as you
point out that is not the weakest link and thus is irrelevant...

> But making q bigger doesn't really pay off unless the hash 
> grows by the same amount.  In fact, the DSS is balanced so that the work 

Tiger-192, which isn't yet completely analyzed is larger.  There is a 256
bit variant of HAVAL.  These don't work with DSS.  Or even duplicate
hashes (place a RIPEMD160 and a SHA1 hash, or maybe two SHA1 hashes
drawn on different parts of the signed material).

I could also point out CAST.  In fact the 5.0 versions I know about
default to using it and there is no way of overriding it. It is far newer
than 3DES or IDEA.  DES/SK isn't even out yet as a reference
implementation, but is in the spec as a MAY. 

If you would propose a strong-DSA with a larger q, I could accept it, or
even a double DSA signature.  But no one has proposed any upward path from
DSA except ElGamal and they have had a long time to do so.

> I would like to find a suitable hash of perhaps 192 bits or better yet,
> 256 bits, thus opening the door for expanding q and p beyond 160 bits
> and 1024 bits.  But I think that any such candidate hash would have to
> be extensively peer reviewed before acceptance into OpenPGP, lest it
> suffer the same fate as MD4 and MD5.

So start reviewing.  Has anyone at pgp.com done anything about Tiger,
Haval or even Snefru?

> 3)  Adding more public key algorithms is good, because more features is
> always better.
> 
> Well, that one is so silly that I should not have included it.  Each
> public key algorithm should be justified on its merits.  It should bring
> something to the table that the other algorithms do not bring.

ElGamal Signatures allow a single primary key to be used for both signing
and encryption.  They also aren't limited to 160 bits on the size of the
material signed.  These are the issues upon which the inclusion of ElGamal
turned.  You might not weigh them as important, but then you weren't part
of the discussion when all the things you brought up were weighed.

> But straight ElGamal signatures offers no new real capability.  It brings
> nothing new to the table.  In fact, it actually has real disadvantages.
> 
> The first disadvantage of ElGamal compared with DSS is that ElGamal makes
> much bigger signatures.  Have you noticed that DSS signatures are so much
> more compact than RSA signatures?  They are only about one and a half lines
> of radix64 characters.  I think that is really cool.  We lose that if we
> go to pure ElGamal signatures.  That will bloat the public key infrastructure,
> as each key collects many signatures on it from other keys.  It will
> bloat everything that gets signed.

I have to bypass more junk in signature packets that any difference in
signature sizes is likely to be irrelevant.  Now that the MPI is smaller,
we now have to change the signature structure because 64K is insufficient
for the hashed and unhashed material in a standalone packet.  And more
bloat is coming to signatures with the next release.

If size was a concern, you would have split out a separate parameter
packet since it is likely that all PGP 5.0 1024 bit DSS and DSA keys have
the parameters in common, and then used a parameter ID and just the public
key. 

And isn't someone over at PGP proposing including a picture within the
keyring material?  Or other ID material?

Further, if you only have one primary DH key, you lose all the extra
overhead of the DSA key and the packet/subpacket binding.

If you are really serious about key infrastructure bloat, then you should
immediately look at and condemn the subpacket bloat already occuring.

And it sound more sincere if you didn't have things like cute but large
animations in your programs.  How many printed volumes did the all the eye
candy take?

> Another disadvantage is that ElGamal requires more computation than DSS, 
> in part because all the calculations are done in a larger field.  DSS does 
> a substantial amount of its calculations in the field of q, which is 160 
> bits.  That's why it's faster.

And DSS requires a *lot* more than RSA which RSA.com often points out. 
And it also explains why it is limited in the size of material to be
signed.  And MD5 takes less than SHA1, but TIGER takes less than either.

I don't think anyone would use ElGamal except in two situations: 1. where
extra security is needed for signed material (thus signing multiple hashes
or a larger hash), or where space is at a greater premium (using a
param/pubkey infrastructure).

> Another important disadvantage of pure ElGamal is that a number of attacks
> and weaknesses have been published that apply only to pure ElGamal 
> signatures.  These attacks and weaknesses do not apply at all to DSS, nor 
> do they apply to DH encryption.  

A known weakness is not a weakness if it can be avoided.  I haven't seen
anything on DSS, but does that mean that nothing exists?  Or that it
hasn't been found or published?

> In principal, an especially careful implementation could avoid these 
> weaknesses.  But at least one implementation of OpenPGP's ElGamal signatures 
> has done it wrong.  Others might also do it wrong.  PGP users should not 
> have to lie awake at night wondering if the implementor did a perfect job,
> or did he fall into one of the pitfalls that are so easy to fall into.

I know only of three implementations of ElGamal within PGP.  One was
within PGP 5.0 and was "wrong", but it is what I used as a template and
have since fixed the flaws I was contacted about which were in the
original.  No one has since contacted me about my implementation getting
it wrong (other than a note that I was too strict in one place and another
suggesting I look at some references about problems, and I replied that I
fixed those liste).  The other one I know about is gnupg.

Maybe my implementation is the one you are talking about.  If it is, then
it has been around for 6 months, and initally was #ifdef-ed so I could
easily have disabled or removed the code before the threads on ElGamal
signatures and incorporation into the spec.  Remember that it was not a
light issue, and even has a different algorithm number for the key.  I
pointed out some subtle errors in pgp 5.0 (not having to do with security)
and suggested corrections because I am interested in having better
products on all sides.  I have had no contact from anyone pointing out any
specific problems in my implementation of ElGamal, so even I am left to
wonder.  Anyone who has looked at the many releases I uploaded knows that
I don't get everything right.

If I got it wrong, I would like to know where so I can fix it.  If I
didn't I would like to know that too.  Or is PGP now going to play a game
of "guess which competitor has the problem - we know but aren't telling"?
If it is by request of the implementor that would be a different thing,
but you now have called into question every one of your competitors.  Is
this how PGP is going to act now?  Even if you haven't checked the other
impelmentations, you need to say that too.

Technically, my implementation won't interoperate with OpenPGP ElGamal
signatures - it generates ElGamal keys, but only with the DH-encryption
algorithm tag.

> In short, ElGamal signatures are bigger, slower, and in many cases less 
> secure, than DSS.  It is inferior in every way to DSS.  It does not belong 
> in the OpenPGP standard.  PGP stands for quality, and so should OpenPGP.

Inferior in every way except two - it can use a single key for both
encryption and signing, and it can handle more than 160 bits.

> ... The users will begin generating
> millions of keys in that form, and we will have a substantial part of the user 
> population doing The Wrong Thing.  ElGamal signatures will begin to accumulate
> on other people's keys, including DSS keys.  We will all be penalized for this,
> costing us all more compute time to check the signatures, more bulk 
> accumulating in our signature collections on our DSS keys.

The switch from 2.6.x to 5.0 already bloated things far more than ElGamal
ever will.  The key material is larger, and now I have to maintain two
keys, a 2.6.x for those who still only have the old version, and now a
DSS/DH to be trendy.  And there is still the unresolved issue of a V3 v.s.
V4 RSA key since the IDs can differ in two ways, so I will need two
versions of my RSA keys to interoperate in addition to the DH/DSA stuff.

And I don't think your worries are warranted.  I am still trying to find
SSL sites that use any form of DH instead of RSA for their public key
exchanges.  More than enough older implementations don't interoperate with
ElGamal signatures that it won't be a factor.

Worse, there are lots more algorithms besides ElGamal.  For example, the
elliptic curve encryption and signatures that aren't specified, so every
implementor is free to do the parameters and algorithms the way they
please.  Why even put these in to this revision when there is NO
implementation that uses them?  Technically it is the same with Blowfish
and Safer though they have multiple variants.  Why leave these in since
they are the same "MAY" as ElGamal?  And the extra hashes without OIDs. 

> If anyone breaks an ElGamal signature because it was improperly implemented,
> the reputation of the whole OpenPGP standard will suffer. ...
...
> using this variant.  In his mind, the entire 3DES standard was called into
> question because of the cloud raised by this article.  We could all be 
> similarly haunted by any weaknesses found in any implementation of ElGamal 
> signatures in any OpenPGP product.  In fact, even if no one improperly
> implements ElGamal signatures in any OpenPGP product (despite the fact that
> this has already happened), there will always be doubts raised when mainstream
> lay journalists (or lay users) rediscover any of the old academic papers that
> have reported on weaknesses or attacks on ElGamal signatures.  We will find
> ourselves having to explain this away, over and over again.

The original PGP published source contained disabled support for ElGamal
signatures and was broken.  This code should have been removed, though I
may have been the only one to enable it.

As far as the panic by the public, every time any paper is published
anywhere on any algorithm, someone will say the entire crypto
infrastructure is broken.  As you note, a single form of a single
algorithm was flawed, and you had to explain it didn't apply.

And I thought PGP would be the leader in OpenPGP.  Regardless of what the
specification says, if you don't implement ElGamal, most people won't use
it specifically because the PGP Inc. version doesn't use it.

If PGP stands for quality, you should have the best implementation
(including *NOT* doing things you think are flawed), the best programs,
the best SDKs, and the best support.  Quality is more than the algorithm
list.

> It's noteworthy that the X9F1 committee was in the final call for its draft 
> standard when Biham and Knudsen discovered this flaw.  The draft was changed
> accordingly.  It's not too late for us to change our draft as well.

Except you have not discovered any new weaknesses - but only an
implementation error (which you aren't identifying).  If there is a new
attack that would threaten the security of previously correctly
implemented ElGamal keys I would like to know and would agree.

> I'm sorry to not have brought this up earlier, but I hope that the arguments
> stand despite my tardiness.  I also hope that those of you who have already
> implemented ElGamal signatures (because it's been in the draft for so long)
> will not allow the investment that you have made in software implementation
> to prejudice you too much in deciding what is best for the PGP user 
> population to be subjected to.

They will be subjected to Haval, Tiger, DES/SK (when it is available),
Blowfish, Safer/SK-128, MD2, EC (in whatever form), on the same basis as
ElGamal.  Why include all these, but not ElGamal? 

This late in the game, I would agree to changing the MAY to a SHOULD NOT
for ElGamal.  I would even be willing to disable it by default in my code
in the same way that PGP 5.0 disabled support (after fixing it if mine is
the errant implementation).  And I think the other implementors may agree
to do the same thing and do a moratorium on "enabled ElGamal" until the
next spec is released and we can then either delete it or place caveats
or come up with a way of extending DSA.

But I would want to leave the code and infrastructure in place until then,
and leave it in the spec.

Alternately we could leave the OpenPGP spec open for another few months to
let everyone get up to speed and we can reopen everything to make the spec
perfect.

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

Date: Tue, 2 Jun 1998 13:20:32 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Sender: [email-masked]

>>>>> "Philip" == Philip Zimmermann <[email-masked]> writes:

 Philip> I know I should have brought this up earlier, but better late
 Philip> than never.  I would like to suggest to the OpenPGP Working
 Philip> Group that we remove ElGamal signatures from this draft RFC.
 Philip> Here's why.
>...

I think Phil's suggestion makes sense.  (I suspect elliptic crypto
will end up with its own pile of patent troubles, so I don't view it
as optimistically, but that doesn't affect the argument with respect
to ElGamal.

And while I'm writing... rather than let silence imply consent...  the
suggestion for "revocation reason" (in another note) sounds good.

	paul

Date: Tue, 02 Jun 1998 09:37:41 -0700
To: Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: key revocation types (Re: implicit IDEA with V3 keys)
Cc: [email-masked]
Sender: [email-masked]

At 11:52 AM 6/2/98 +0100, Adam Back wrote:
   
   The problem is that someone who has compromised your private keys can
   also sign a new key to propogate the trust.  If you allowed or defined
   the semantics of multiple revocations to be that the old trust was
   voided in the case that there is also a `compromise' revocation cert,
   then I think you can avoid this problem.
   
   Somewhat similar to seeing a public key on a key server with:
   
   	`Don't use compromised' as a self signed user id
   
   followed by a new key signed by the old one anyway.
   
   Formalising what this should imply you shouldn't take any notice of
   the self signature as the keys it was made with were compromised.
   
   The user won't create a key compromise cert unless the key is
   compromised.
   
Again, we're in violent agreement.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 02 Jun 1998 09:36:37 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Cc: [email-masked]
Sender: [email-masked]

At 11:49 AM 6/2/98 +0100, Adam Back wrote:
   
   There is a conflict no matter what: the minimal subset of common
   algorithms is the empty set.  What you do to fix this is either as you
   suggest if the implementation's architecture allows send separate
   messages to resolve the problem; or failing that perhaps minimise the
   damage by finding the subset which results in unreadable messages to
   the minimum number of recipients.

And that's precisely what we've done. For OpenPGP, the there's a solution
-- 3DES. For 2.x compatibilty, the real solution is to generate separate
messages. If you can't, then there's a problem, and the implementation can
cope.
   
   I can't see how this will help: you are either going to render the
   message unreadable to the 2.x user, or to the minimal OpenPGP user.
   Take your pick.  Unless you like 2) above.
   
Exactly. We're in violent agreement.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 02 Jun 1998 11:06:12 +0200
To: Jon Callas <[email-masked]>, Bill Stewart <[email-masked]>, Philip Zimmermann <[email-masked]>, [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

At 11:33 01.06.98 -0700, Jon Callas wrote:
>At 11:57 PM 5/29/98 -0700, Bill Stewart wrote:
>
>   Null-terminating the string would be a nice touch; it's not necessary,
>   since there's a length field, but it would probably reduce accidents,
>   and it also makes it convenient for tools such as "strings" to find.
>
>Bill, I didn't mean to ignore your comment in my comment I just sent.
>Obviously, I needed another cup of coffee this morning. How nice is it to
>make it null-terminated?
>
>With counted strings, someone has to go and terminate them anyway, and the
>only place where a null-terminated string is specified in the whole draft
>is in the regular expression subpacket (and I don't know why it's there). 
>
>When I put on my developer's hat, I look at it and think that I'd write to
>code to look at the length of the subpacket, and if it's greater than 1,
>then I have text. If the string is null-terminated, how do I handle the
>bizarre case of a specified comment that is a null string? Do I treat it
>the same as no specified string, or as a blank comment? There's an easy
>answer (treat it as no comment), but the question goes away if we just use
>the count.
>
The SNMPv3 group just had a dustup where they had an example where
the text said that it was a hash over "tanstaafl", while the example
hash was actually computed over "tanstaafl\0".

If you go with counted strings, null terminators are just trouble, IMHO.

Besides, what is the meaning of (len=12)"tan\0staafl\0" if you do
both NULL termination and bytecounts?

Take care,

                   Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Tue, 2 Jun 1998 11:36:52 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Sender: [email-masked]

William writes:
> Adam Back <[email-masked]> said:
> >BUT, if you choose to implement RSA and IDEA, then you MUST treat V3 keys
> >as implicit statement that IDEA is the only cipher supported.
> 
> I have to disagree, take the following example:
> 
> I have 2 users of my OpenPGP implementation who have upgraded from PGP x.x
> and have migrated their V2/V3 RSA keys. Why should they be forced to use
> IDEA/MD5 if they both chose not to?

You have two options here:

1) When promoting the V3 RSA key to V4+ (OpenPGP) RSA key increment
   it's version number.  Then you can list any ciphers you choose on
   the capability list.  Any v3 certs promoted with the public key (to
   retain existing v3 WoT) would be defined as signatures over the v3
   representation of the v4 key packet (ie with all v4 features
   removed using some repeatable standard procedure) This procedure
   could be called demoting the key from v4 down to v3 with loss of
   various capability and v4 WoT information.

   With this option you have the problem of the numerous methods of
   key distribution: if there are v3 public keys on key servers, your
   option then is to add the v4 promoted keys also -- it should be
   able to co-exist because of the different keyID.  However this
   introduces the need for proactive key servers -- ones which return
   different public keys depending on the version number of the key
   requester -- something which could be done.  It could for example
   invoke the demotion algorithm on the v4 public key to derive the
   subset which is a v3 public key

   This still does not cope with keys distributed manually or on web
   pages: pgp2.x will choke on the v4 keys.

or

2) Have a syntax for expressing the cipher suite and any other v4
   features in a way which is transparent to a v3 implementation.  This
   could have been done, relatively easily: define the packets to be
   encoded in the little used v3 comment packet.  That allows you
   then to send someone a V3 key which expresses algorithm
   capabilities, without promoting it's version number, and the
   existance of the comment packets is can contain the actual version
   number (from an OpenPGP implementation's point of view).

Option 2) is not possible now because it is not backwards compatible
with pgp5.x.  Option 1) should work I think.

> I have to bring up my objections again about making preferences a
> *MUST*.

Must things are for compatibility.  You can choose to over-ride them,
but then you are no longer compliant.  You've got to publish the
algorithm capabilities in your public key otherwise people won't know
what you can cope with.

> It should be up to the users of the product what algorithms they
> wish to use (It is their communications after all). I don't have a
> problem with saying that the default actions of the program should
> follow the preferences but if the users are sophisticated enough to
> choose different encryption/hash algorithms who am I to prevent
> them?

I think that this is fine but within the bounds of the capabilities of
both parties.  Sending some eliptic curve variant / with a tiger hash,
and experimental non-transferable sig won't work if the other side
doesn't have the same extensions.  There is a mechanism to express
extensions.

> I have coresponded with with other PGP 5.x users using all different
> combinations of symetric/hash algorithm with both EL & RSA keys
> depending on what mood takes me at the time.

Fine.  But I presume you didn't send them combinations which were not
listed in their capability spec.

> There is also the issue of what happens if the user upgrades/changes
> his OpenPGP implementation or works with several different
> implementations that have a variety of different capabilities?

Yes, this is really a problem.  I would think your options are:

   1) generate a new key (as you suggest);
or
   2) promote the public key packet by adding a new capability self
      signature packet superceding the old one; or replace the old
      capability packet
or
   3) allow capability self sigs to be sent as part of messages

Options 1) only works for permanent upgrade (and not switching between
different versions), same problem for option 2).

Option 3) stands a chance of working, as you send a message to someone
their implementation updates their copy of your public key.  You send
an update to the keyservers (using a key altered using method 2).  You
can even move back to a previous less capable version.

In general though the whole topic is pretty messy and almost
intractible.  I think the simplest compromise is to say that if you
want to change capabilities you do the following:

a) generate a new key (use the same secret components if you wish)
b) sign the new key with your old key
c) revoke the old key with `key retired use this key instead'
   notification

This means you can't use different versions with the same key, or that
if you do you must use algorithms in the common subset of capabilities
of all the implementations you are using with the same key.  Building
more functionality seems to complicated.  This may as you suggest
imply inability to receive messages from pgp2.x, and/or selection of
SHA1/3DES/Elgamal only.  I don't see a practical alternative.

Adam

Date: Tue, 2 Jun 1998 11:49:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Sender: [email-masked]

Jon writes:
> Adam Back wrote:
>    BUT, if you choose to implement RSA and IDEA, then you MUST treat V3
>    keys as implicit statement that IDEA is the only cipher supported.
> 
> That's a good point. I'll think about a re-wording. But it would be nice to
> encourage some 2.X users to revise 2.X to do 3DES, too. There are 2.X
> implementations with SHA, so why not 3DES?

I don't think it is a good idea to start another 2.x variant with more
ciphers.  It makes even more problems for backwards compatiblity, then
you won't even know what 2.x means from a capability point of view,
adn you really need a version number upgrade for the packets generated
by such an implementation, and yet there is no gap in the version
numbers reserved for this.

> We have to deal with this situation. Imagine that you're using a maximal
> (supports everything) OpenPGP implementation, and you're sending a message
> a minimal OpenPGP implementation (which is 3DES only) and a 2.6
> implementation (which is IDEA only), then there's a conflict.

There is a conflict no matter what: the minimal subset of common
algorithms is the empty set.  What you do to fix this is either as you
suggest if the implementation's architecture allows send separate
messages to resolve the problem; or failing that perhaps minimise the
damage by finding the subset which results in unreadable messages to
the minimum number of recipients.

> My wording change is to help some developers who want an exemption there. 

Transfering your statement into the "MAY cope with V3, MUST use IDEA if
chose to do so" would come out something like:

 1) If an implementation which can create IDEA packets is requested to
    send a message to two implementations one which supports IDEA and one
    which doesn't the implementation MAY send two separate messages or
    report failure.
or

 2) An alternative failure mode would be to send a message with a cipher
    chosen to render the message readable by the maximum number of
    recipients, and report a warning.  (I am doubtful about the value of
    this one, probably simpler just to fail outright).

>    Why does the message creator need to be warned?  It seems like a
>    perfectly reasonable thing to do to send an IDEA encrypted message to
>    someone who can only decrypt IDEA messages.
> 
> In the above case, if you send a single message encrypted with IDEA, you're
> violating the protocol. I think if we allow this protocol violation, they
> oughta at least warn the sender that one of the receivers may not be able
> to decrypt the message.

I can't see how this will help: you are either going to render the
message unreadable to the 2.x user, or to the minimal OpenPGP user.
Take your pick.  Unless you like 2) above.

I'll take the revocation reason comments to another message.

Adam
-- 
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: Tue, 2 Jun 1998 11:52:54 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: key revocation types (Re: implicit IDEA with V3 keys)
Sender: [email-masked]

Jon writes:
> Adam wrote:
>    All useful functionality.  I think you need the exception that if the
>    reason for revocation is private key compromise, then the new
>    fingerprint is ignored.  (Clearly an attacker with the private key
>    won't create a compromise reason of "key compromise", but this
>    definition allows you the owner to create a competing compromise cert
>    which does say "key compromise" and then we can define a "compromise"
>    revocation to take precedence over a "key retired and here is new key
>    fingerprint" revocation, where more than one compromise is present on
>    keyring.)
>    
> When I looked at putting it in, I kept it the way it was proposed -- with
> the text comment only. The reason is that if I'm retiring a key, I can sign
> the new key with my old one, and then put a retiry certification on my old
> one. An implementation that wants to propagate trust can easily do it, so I
> kept the simpler definition.

The problem is that someone who has compromised your private keys can
also sign a new key to propogate the trust.  If you allowed or defined
the semantics of multiple revocations to be that the old trust was
voided in the case that there is also a `compromise' revocation cert,
then I think you can avoid this problem.

Somewhat similar to seeing a public key on a key server with:

	`Don't use compromised' as a self signed user id

followed by a new key signed by the old one anyway.

Formalising what this should imply you shouldn't take any notice of
the self signature as the keys it was made with were compromised.

The user won't create a key compromise cert unless the key is
compromised.

Adam
-- 
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: Tue, 2 Jun 1998 12:56:58 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: The case against ElGamal signatures in PGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Philip Zimmermann <[email-masked]> writes:

> is.  That would also entail a work factor of about 2^80.  This means that
> unless we find a bigger hash, we gain little by making p or q bigger in 
> the DSS.

A new attack may decrease the work factor for DL schemes below 2^80
and in this case a larger DL may help.  Same for new attacks on SHA1.

> keys, it would be just as easy to expand the p and q parameters of DSS as 
> it would to expand the parameters of pure ElGamal.

Hmmm, there is still a patent on DSA and the government might want to
enforce the Kravitz patent if an implementation changes the parameters. 

> 3)  Adding more public key algorithms is good, because more features is
> always better.

This is not for featureism, but to give the user a choice.

> We probably will be able to justify adding elliptic curves at some point, 
> because they allow cheap 8-bit microcontrollers to compute and check

And run into a lot of patent conflicts.

> But straight ElGamal signatures offers no new real capability.  It brings
> nothing new to the table.  In fact, it actually has real disadvantages.

One advantage is that you can use one key for encryption and signing
(as pgp2 does it).

> The first disadvantage of ElGamal compared with DSS is that ElGamal makes
> much bigger signatures.  Have you noticed that DSS signatures are so much

Really true.

> go to pure ElGamal signatures.  That will bloat the public key infrastructure,
> as each key collects many signatures on it from other keys.  It will
> bloat everything that gets signed.

There are a lot of thinks which bloat the public keys too - here is a
new field of work.

> weaknesses.  But at least one implementation of OpenPGP's ElGamal signatures 
> has done it wrong.  Others might also do it wrong.  PGP users should not 

Which one? (and which OpenPGP draft)

> In short, ElGamal signatures are bigger, slower, and in many cases less 
> secure, than DSS.  It is inferior in every way to DSS.  It does not belong 
> in the OpenPGP standard.  PGP stands for quality, and so should OpenPGP.

PGP5 is just an implementation of OpenPGP, the PR can convince the user
that this or this program is a better or worser implementation of OP.

The correct implementation of an algorithm is easy compared to the
design of other parts of such a system (e.g. the RNG).

> If anyone breaks an ElGamal signature because it was improperly implemented,
> the reputation of the whole OpenPGP standard will suffer.  It will not matter

So does the reputation of MIME or rfc822 suffer just because M$ is not
able or willing to deliver a working system?

Werner

Date: Tue, 2 Jun 1998 01:24:03 -0700
To: [email-masked]
From: Philip Zimmermann <[email-masked]>
Subject: The case against ElGamal signatures in PGP
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I know I should have brought this up earlier, but better late than never.
I would like to suggest to the OpenPGP Working Group that we remove ElGamal
signatures from this draft RFC.  Here's why.

First, I see no reason to add ElGamal signatures to the standard.  I have
to admit I didn't follow the traffic on this list when this type of
signature was introduced, but I can imagine some of the reasons that one
might have for introducing them into OpenPGP.  Let's review them.

1)  Adding a new public key algorithm is good, in case the others are later
discovered to have weaknesses.

I disagree.  ElGamal signatures are no better than DSA signatures.  They 
are similar in that they both rely on the difficulty of computing discrete 
logs.  If discrete logs prove to be a solvable problem, both DSA and
ElGamal will fall, as well as DH encryption.  Indeed, DSA is a variation
on ElGamal.  Thus, ElGamal signatures offer no real algorithmic diversity.

2)  DSS is only 1024 bits max, while ElGamal can be bigger and thus stronger.

Again, wrong.  The strength of the Digital Signature Standard is a function 
of the size of prime p (1024 bits), the smaller prime q (160 bits), and the 
underlying hash function SHA (160 bits).  Making p bigger than 1024 bits 
does no good to add to the strength of the DSS unless q is also made larger
than 160 bits.  But making q bigger doesn't really pay off unless the hash 
grows by the same amount.  In fact, the DSS is balanced so that the work 
factor for attacking p is about the same as the work factor for attacking q. 
There is a square root attack on q (about 2^80 operations).  There is also a
birthday attack on the 160-bit hash, regardless of what the hash algorithm
is.  That would also entail a work factor of about 2^80.  This means that
unless we find a bigger hash, we gain little by making p or q bigger in 
the DSS.

It would be reasonable to point out here that it is likely to be operationally
harder for an attacker to exploit a birthday attack on the hash in a real
world situation.  He has to trick the target of the attack into signing
a message that has the same hash as the desired forgery.  Still, we must 
try to design our systems to resist that attack, even if it is less likely. 
Even if you think that a birthday attack is infeasible in your situation,
and would rather put your defenses into beefing up the size of the public
keys, it would be just as easy to expand the p and q parameters of DSS as 
it would to expand the parameters of pure ElGamal.

I would like to find a suitable hash of perhaps 192 bits or better yet,
256 bits, thus opening the door for expanding q and p beyond 160 bits
and 1024 bits.  But I think that any such candidate hash would have to
be extensively peer reviewed before acceptance into OpenPGP, lest it
suffer the same fate as MD4 and MD5.

3)  Adding more public key algorithms is good, because more features is
always better.

Well, that one is so silly that I should not have included it.  Each
public key algorithm should be justified on its merits.  It should bring
something to the table that the other algorithms do not bring.

We added DH/DSS because of the RSA patent regime, which has for many
years stunted the growth of public key cryptography.  Indeed, the RSA
patent and the patent cartel that once controlled all the public key 
algorithms has done more to stifle this technology than all that the 
NSA has done.  Since the DH patent is now expired, that opens the door
for free unencumbered public key cryptography, creating a level playing
field.  No longer can any companies be shut out of the game.

We probably will be able to justify adding elliptic curves at some point, 
because they allow cheap 8-bit microcontrollers to compute and check
signatures because the computing requirements are so much less.  This 
is good for really cheap smartcards or tokens, a substantial economic
advantage.

But straight ElGamal signatures offers no new real capability.  It brings
nothing new to the table.  In fact, it actually has real disadvantages.

The first disadvantage of ElGamal compared with DSS is that ElGamal makes
much bigger signatures.  Have you noticed that DSS signatures are so much
more compact than RSA signatures?  They are only about one and a half lines
of radix64 characters.  I think that is really cool.  We lose that if we
go to pure ElGamal signatures.  That will bloat the public key infrastructure,
as each key collects many signatures on it from other keys.  It will
bloat everything that gets signed.

Another disadvantage is that ElGamal requires more computation than DSS, 
in part because all the calculations are done in a larger field.  DSS does 
a substantial amount of its calculations in the field of q, which is 160 
bits.  That's why it's faster.

Another important disadvantage of pure ElGamal is that a number of attacks
and weaknesses have been published that apply only to pure ElGamal 
signatures.  These attacks and weaknesses do not apply at all to DSS, nor 
do they apply to DH encryption.  

In principal, an especially careful implementation could avoid these 
weaknesses.  But at least one implementation of OpenPGP's ElGamal signatures 
has done it wrong.  Others might also do it wrong.  PGP users should not 
have to lie awake at night wondering if the implementor did a perfect job,
or did he fall into one of the pitfalls that are so easy to fall into.

In short, ElGamal signatures are bigger, slower, and in many cases less 
secure, than DSS.  It is inferior in every way to DSS.  It does not belong 
in the OpenPGP standard.  PGP stands for quality, and so should OpenPGP.

Of course, one might point out that ElGamal is not a required algorithm in 
the OpenPGP standard.  Thus, implementors do not have to support it, so there 
is no problem.  I must disagree here too.  Some implementors will implement
it, in fact, some already have.  In the arms race of feature competition,
algorithm implementation shows up as more checkboxes for sales brochures and 
product reviews.  It does not matter that it is a bad algorithm, reviewers
will compare products in such a way as to make it look better if you implement 
ElGamal signatures.  Market pressure will thus ensure that it gets implemented 
in most OpenPGP-compliant products.  That will include user interfaces that
allow the user to generate keys in that form.  Are you going to make your
keygen wizard warn the user that he is a moron if he chooses to generate
his keys for ElGamal signatures?  I doubt it.  The users will begin generating
millions of keys in that form, and we will have a substantial part of the user 
population doing The Wrong Thing.  ElGamal signatures will begin to accumulate
on other people's keys, including DSS keys.  We will all be penalized for this,
costing us all more compute time to check the signatures, more bulk 
accumulating in our signature collections on our DSS keys.

If anyone breaks an ElGamal signature because it was improperly implemented,
the reputation of the whole OpenPGP standard will suffer.  It will not matter
that it was only one implementor that did it wrong, the whole community will 
take the hit.  I hold in my hand a NY Times piece by John Markoff from 31 
March,that is headlined "Powerful New Encryption Standard Delayed by a 
Weakness", which reports on the weakness found by Biham and Knudsen in an 
obscure variant of 3DES that was being used by X9F1.  One of my clients who
was considering 3DES for an application sent me the article with a panicky
note asking me if this was a threat to PGP's use of 3DES, or to his own
application.  I had to assure him there was no danger, because we were not
using this variant.  In his mind, the entire 3DES standard was called into
question because of the cloud raised by this article.  We could all be 
similarly haunted by any weaknesses found in any implementation of ElGamal 
signatures in any OpenPGP product.  In fact, even if no one improperly
implements ElGamal signatures in any OpenPGP product (despite the fact that
this has already happened), there will always be doubts raised when mainstream
lay journalists (or lay users) rediscover any of the old academic papers that
have reported on weaknesses or attacks on ElGamal signatures.  We will find
ourselves having to explain this away, over and over again.

It's noteworthy that the X9F1 committee was in the final call for its draft 
standard when Biham and Knudsen discovered this flaw.  The draft was changed
accordingly.  It's not too late for us to change our draft as well.

I'm sorry to not have brought this up earlier, but I hope that the arguments
stand despite my tardiness.  I also hope that those of you who have already
implemented ElGamal signatures (because it's been in the draft for so long)
will not allow the investment that you have made in software implementation
to prejudice you too much in deciding what is best for the PGP user 
population to be subjected to.

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 01 Jun 1998 21:06:09 -0500
To: [email-masked]
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Sender: [email-masked]

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

In <[email-masked]>, on 06/01/98 
   at 07:46 PM, Adam Back <[email-masked]> said:

>I would have thought this should be a MUST rather than a MAY, and that
>ability to deal with V3 keys should be the MAY.

>This would allow one to implement OpenPGP without having to as an
>implication of a MUST clause include a patented algorithm (IDEA, and
>RSA), because your option is simply to not be backwards compatible, which
>is precisely the implication of the limited backwards
>compatibility due to patent problems implication, and no more.

>BUT, if you choose to implement RSA and IDEA, then you MUST treat V3 keys
>as implicit statement that IDEA is the only cipher supported.

I have to disagree, take the following example:

I have 2 users of my OpenPGP implementation who have upgraded from PGP x.x
and have migrated their V2/V3 RSA keys. Why should they be forced to use
IDEA/MD5 if they both chose not to?

I have to bring up my objections again about making preferences a *MUST*.
It should be up to the users of the product what algorithms they wish to
use (It is their communications after all). I don't have a problem with
saying that the default actions of the program should follow the
preferences but if the users are sophisticated enough to choose different
encryption/hash algorithms who am I to prevent them?

I have coresponded with with other PGP 5.x users using all different
combinations of symetric/hash algorithm with both EL & RSA keys depending
on what mood takes me at the time.

There is also the issue of what happens if the user upgrades/changes his
OpenPGP implementation or works with several different implementations
that have a variety of different capabilities? Either he has to generate a
new key for each program he is using or he needs to set his preferences to
the default 3DES/SHA1 (and that is only good if he knows before-hand that
he will be changing application sometime in the future).

Oh well, I'll get off my soapbox now. :)

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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Dogs crawl under gates, software crawls under Windows!

Tag-O-Matic: Why look thru Windows? Open the door to the future: OS/2

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 01 Jun 1998 21:05:51 -0500
To: [email-masked]
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Sender: [email-masked]

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

In <[email-masked]>, on 06/01/98 
   at 02:30 PM, Jon Callas <[email-masked]> said:

>   The above deals with backwards compatibility without introducing need
>   to be non-compliant.  It is just a re-wording effectively, but is more
>   correct I feel (unless I have misunderstood some implication).

>We have to deal with this situation. Imagine that you're using a maximal
>(supports everything) OpenPGP implementation, and you're sending a
>message a minimal OpenPGP implementation (which is 3DES only) and a 2.6
>implementation (which is IDEA only), then there's a conflict.

For handeling such situations I had though of modifying the PGP/MIME spces
to include a new MIME Type: encrypted/alternative.

Say we have a text message M and we need to encrypt it to 2 recipiants, 1
using IDEA (S1) and 1 using Cast5 (S2).

What we would do is create a multipart document where the 1st part would
contain S1(M) along with the P1(S1) P2(S1) and the second part would
contain S2(M) along with P1(S2) P2(S2).

This way 1 message can be encrypted to multiple recipiants with
confilicting/unknown symetric key capabilities.

While I am on this topic I would like to see the ability for parallel
signatures for handeling confilicting public key & hash algorithms
capabilities.

Say we have a text message M and the signer has both RSA (P1) & DSA (P2)
keys.

The signer would generate 2 hashes of the message, one MD5 (H1(M)) and one
SHA1 (H2(M)). He would then generate 2 signatures P1(H1(M)) and P2(H2(M))
and attach them to the bottom of the message as signature/parallel
attachments.

This seems even more important that the encrypted/alternative becaues
unlike encryption there is no way of knowing the capabilities of the
reader of a signed message.

I have outlined both of these in my PGP Integration Paper:

http://users.invweb.net/~whgiii/pgpemail_5.html

- -- 
- ---------------------------------------------------------------
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 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Dogs crawl under gates, software crawls under Windows!

Tag-O-Matic: OS/2: Your brain.  Windows: Your brain on drugs.

Date: Mon, 1 Jun 1998 20:33:01 -0400
From: [email-masked]
To: [email-masked]
Subject: PalmIII Progress: most things except compression work
Sender: [email-masked]

palmopgp00.tgz will be on www.cryptography.org in the new directory
shortly.  It includes a test program based on the GNU programming
tutorial, and is simple, but does prove things work.

You also need zlib 1.1.2 and pilotSSLeay-2.01 with the full archive (with
the includes and .sa files).  I include the SSLeay routines that aren't in
there with my archive.  You need most of the .prc files on the Pilot, but
it will simply complain and ask you to reset if they aren't there.  And
you don't need libs for algorithms you aren't using.

This is a pre-alpha first pass, but does work - I can download files for
it to decrypt and upload encrypted files.  It works better with EcoHack in
turbo mode :).  And it needs a GUI, but I have been only doing Palm III
for just over a week, so reading the memo pad was a big deal for me.

It will convert memos with the right headers (BEGIN PGP
PUBLIC/PRIVATE/SECRET) into the keyring files, and I have started support
for decrypting messages there.

What works:

literaling.  one pass signatures (DSA/SHA1 tested).  encrypting, both
passphrase and public key (tested with DES, and DH). armoring.  And the
all the reverse (dearmor/decrypt/deliteral and verify).

What doesn't:

Compression/Decompression (ZLib has problems).

What isn't tested (but should work):

other algorithms: IDEA, CAST, MD2, MD5, RIPEMD160, RSA, ElGamal sigs.

What isn't tested and might not work:

Key generation and export routines.

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

Date: Mon, 01 Jun 1998 14:30:58 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Cc: [email-masked]
Sender: [email-masked]

At 07:46 PM 6/1/98 +0100, Adam Back wrote:
   
   I would have thought this should be a MUST rather than a MAY, and that
   ability to deal with V3 keys should be the MAY.
   
   This would allow one to implement OpenPGP without having to as an
   implication of a MUST clause include a patented algorithm (IDEA, and
   RSA), because your option is simply to not be backwards compatible,
   which is precisely the implication of the limited backwards
   compatibility due to patent problems implication, and no more.
   
   BUT, if you choose to implement RSA and IDEA, then you MUST treat V3
   keys as implicit statement that IDEA is the only cipher supported.

That's a good point. I'll think about a re-wording. But it would be nice to
encourage some 2.X users to revise 2.X to do 3DES, too. There are 2.X
implementations with SHA, so why not 3DES?
   
   > This is technically non-compliant, 
   
   The above deals with backwards compatibility without introducing need
   to be non-compliant.  It is just a re-wording effectively, but is more
   correct I feel (unless I have misunderstood some implication).

We have to deal with this situation. Imagine that you're using a maximal
(supports everything) OpenPGP implementation, and you're sending a message
a minimal OpenPGP implementation (which is 3DES only) and a 2.6
implementation (which is IDEA only), then there's a conflict.

My wording change is to help some developers who want an exemption there. 
      
   Why does the message creator need to be warned?  It seems like a
   perfectly reasonable thing to do to send an IDEA encrypted message to
   someone who can only decrypt IDEA messages.

In the above case, if you send a single message encrypted with IDEA, you're
violating the protocol. I think if we allow this protocol violation, they
oughta at least warn the sender that one of the receivers may not be able
to decrypt the message.
   
   It will be obvious that the OpenPGP users implementation does not
   support IDEA if the IDEA algorithm is not on it's algorihtm capability
   list in it's public key packet.  If it supports IDEA, then you don't
   have a problem.  If it doesn't support IDEA, you can't send the
   message, so you either report this to the user, of if your software
   architecture allows (preferable) do as suggested above: generate two
   separate messages.
   
We're in violent agreement -- the correct solution is to generate two
messages. However, that's easier said than done for some people. My
previous wording (to my mind anyway) allowed someone to break protocol in
this one instance. 

   All useful functionality.  I think you need the exception that if the
   reason for revocation is private key compromise, then the new
   fingerprint is ignored.  (Clearly an attacker with the private key
   won't create a compromise reason of "key compromise", but this
   definition allows you the owner to create a competing compromise cert
   which does say "key compromise" and then we can define a "compromise"
   revocation to take precedence over a "key retired and here is new key
   fingerprint" revocation, where more than one compromise is present on
   keyring.)
   
When I looked at putting it in, I kept it the way it was proposed -- with
the text comment only. The reason is that if I'm retiring a key, I can sign
the new key with my old one, and then put a retiry certification on my old
one. An implementation that wants to propagate trust can easily do it, so I
kept the simpler definition.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 1 Jun 1998 14:16:50 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

Jon Callas, <[email-masked]>, writes:
> With counted strings, someone has to go and terminate them anyway, and the
> only place where a null-terminated string is specified in the whole draft
> is in the regular expression subpacket (and I don't know why it's there). 

The reason I used one there is because the off-the-shelf regexp library
I used took null terminated strings.  I didn't want to go through and
munge it to make it take counted strings, and I didn't want to allocate a
buffer and make a copy so I could null-terminate each regexp as we use it.
It was just a lot simpler to store the null with the string.

With userids it's not so bad because they occupy a whole packet.  I have
to allocate a buffer for them when I read them into memory anyway, so
I allocate one extra byte at the end and put a null in it when I read
the userid.  This insures that the userid packet is followed in memory
by a null byte.

But for subpackets this trick doesn't work, so I put the null in the packet.

Hal

Date: Mon, 1 Jun 1998 19:46:15 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: implicit IDEA with V3 keys (Re: Silence is Consent Dept.)
Sender: [email-masked]

Jon writes:
> * My addendum to the key algorithm preferences text, that allows someone to
> use IDEA in an algorithm conflict with a V3 key. I cleaned up the language
> there a little more from what I sent before. The new language is:
> 
>   An implementation that is striving for backward compatibility MAY consider
>   a V3 key with a V3 self-signature to be an implicit preference for IDEA,
>   and no ability to do TripleDES. 

I would have thought this should be a MUST rather than a MAY, and that
ability to deal with V3 keys should be the MAY.

This would allow one to implement OpenPGP without having to as an
implication of a MUST clause include a patented algorithm (IDEA, and
RSA), because your option is simply to not be backwards compatible,
which is precisely the implication of the limited backwards
compatibility due to patent problems implication, and no more.

BUT, if you choose to implement RSA and IDEA, then you MUST treat V3
keys as implicit statement that IDEA is the only cipher supported.

> This is technically non-compliant, 

The above deals with backwards compatibility without introducing need
to be non-compliant.  It is just a re-wording effectively, but is more
correct I feel (unless I have misunderstood some implication).

> but an implementation MAY violate the above rule in this case only
>   and use IDEA to encrypt the message, provided that the message
>   creator is warned.

Why does the message creator need to be warned?  It seems like a
perfectly reasonable thing to do to send an IDEA encrypted message to
someone who can only decrypt IDEA messages.

> Ideally,
>   though, the implementation would follow the rule by actually generating two
>   messages, because it is possible that the OpenPGP user's implementation
>   does not have IDEA, and thus could not read the message. Consenquently, an
>   implementation MAY, but SHOULD NOT use IDEA in an algorithm conflict with a
>   V3 key.

It will be obvious that the OpenPGP users implementation does not
support IDEA if the IDEA algorithm is not on it's algorihtm capability
list in it's public key packet.  If it supports IDEA, then you don't
have a problem.  If it doesn't support IDEA, you can't send the
message, so you either report this to the user, of if your software
architecture allows (preferable) do as suggested above: generate two
separate messages.

> * Phil's request for a reason-for-revocation subpacket addresses one of my
> longstanding gripes about PGP -- that there is no way to distinguish
> between a key compromise and events that are much more likely to happen,
> such as getting a new ISP, deciding it's simply time for a new key, etc. My
> only addition would be that when the key is superceded by a new key, that
> the fingerprint of the new key be put there, which makes it a suitable
> implementation of the "I-used-to-be" feature I've wanted for years. 

All useful functionality.  I think you need the exception that if the
reason for revocation is private key compromise, then the new
fingerprint is ignored.  (Clearly an attacker with the private key
won't create a compromise reason of "key compromise", but this
definition allows you the owner to create a competing compromise cert
which does say "key compromise" and then we can define a "compromise"
revocation to take precedence over a "key retired and here is new key
fingerprint" revocation, where more than one compromise is present on
keyring.)

(This is the negative side of new features, they introduce new required
semantics and rules, and we get more complexity in the coding and in
the specs.)

Adam

Date: Mon, 1 Jun 1998 15:54:09 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

On Mon, 1 Jun 1998, Jon Callas wrote:

> When I put on my developer's hat, I look at it and think that I'd write to
> code to look at the length of the subpacket, and if it's greater than 1,
> then I have text. If the string is null-terminated, how do I handle the
> bizarre case of a specified comment that is a null string? Do I treat it
> the same as no specified string, or as a blank comment? There's an easy
> answer (treat it as no comment), but the question goes away if we just use
> the count.

Zero is not the empty set.  A zero length means no string, and a length of
1 would imply an empty but extant string.

I use the distinction for secret v.s. public keys - NULL means I want a
public key, "" means a non-passphrased secret key (or prompt if there is a
passphrase), and "passphrase" means a passphrase protected secret key. 

Since (almost) nothing else is null terminated, I would prefer
consistency.

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

Date: Mon, 01 Jun 1998 11:33:08 -0700
To: Bill Stewart <[email-masked]>, Philip Zimmermann <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

At 11:57 PM 5/29/98 -0700, Bill Stewart wrote:

   Null-terminating the string would be a nice touch; it's not necessary,
   since there's a length field, but it would probably reduce accidents,
   and it also makes it convenient for tools such as "strings" to find.

Bill, I didn't mean to ignore your comment in my comment I just sent.
Obviously, I needed another cup of coffee this morning. How nice is it to
make it null-terminated?

With counted strings, someone has to go and terminate them anyway, and the
only place where a null-terminated string is specified in the whole draft
is in the regular expression subpacket (and I don't know why it's there). 

When I put on my developer's hat, I look at it and think that I'd write to
code to look at the length of the subpacket, and if it's greater than 1,
then I have text. If the string is null-terminated, how do I handle the
bizarre case of a specified comment that is a null string? Do I treat it
the same as no specified string, or as a blank comment? There's an easy
answer (treat it as no comment), but the question goes away if we just use
the count.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 01 Jun 1998 11:13:18 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Silence is Consent Dept.
Sender: [email-masked]

No one's commented on a number of things, which I'm interpreting as
consent. They are:

* There's no consensus on sending out diffs. I'm going to solve this by
releasing a new draft, probably today.

* My addendum to the key algorithm preferences text, that allows someone to
use IDEA in an algorithm conflict with a V3 key. I cleaned up the language
there a little more from what I sent before. The new language is:

  An implementation that is striving for backward compatibility MAY consider
  a V3 key with a V3 self-signature to be an implicit preference for IDEA,
  and no ability to do TripleDES. This is technically non-compliant, but an
  implementation MAY violate the above rule in this case only and use IDEA to
  encrypt the message, provided that the message creator is warned. Ideally,
  though, the implementation would follow the rule by actually generating two
  messages, because it is possible that the OpenPGP user's implementation
  does not have IDEA, and thus could not read the message. Consenquently, an
  implementation MAY, but SHOULD NOT use IDEA in an algorithm conflict with a
  V3 key.

* Phil's request for a reason-for-revocation subpacket addresses one of my
longstanding gripes about PGP -- that there is no way to distinguish
between a key compromise and events that are much more likely to happen,
such as getting a new ISP, deciding it's simply time for a new key, etc. My
only addition would be that when the key is superceded by a new key, that
the fingerprint of the new key be put there, which makes it a suitable
implementation of the "I-used-to-be" feature I've wanted for years. 

I'm surprised there have been no comments whatsoever on it. In spite of its
coming in at the last moment, does anyone object to my adding it in before
I send out a new draft? Removing it is easier than adding it, even.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 01 Jun 1998 10:49:19 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Version 4 keystructure 
Cc: [email-masked]
Sender: [email-masked]

At 11:07 AM 5/23/98 +0200, Patrick Feisthammel wrote:

   In 10.1 Transferable Public Keys:
   
      Each Subkey packet must be followed by at least one Signature
      packet, which should be of the subkey binding signature type, issued
      by the top level key.
   
      Subkey and Key packets may each be followed by a revocation
      Signature packet to indicate that the key is revoked.
   
   and in 11.1. Key Structures:
   
              Primary-Key
                 [Revocation Self Signature]
                 [Direct Key Self Signature...]
                  User ID [Signature ...]
                 [User ID [Signature ...] ...]
                 [Subkey Primary-Key-Signature ...]
   
      A subkey always has a single signature after it that is issued using
      the primary key to tie the two keys together. 

   11.1 contradicts 10.1 because it says there is a _single_signature after 
   the subkey. But in 10.1 there is _at least one_ signature.

10.1 is wrong. There is exactly one binding signature on a subkey. I've
amended that paragraph to read:

Each Subkey packet must be followed by one Subkey Binding Signature packet
issued by the top level key.

   I'm also not sure about the revocation signature, I guess the key
   structure is:
   
You've pointed out an unclear place in the key structure chart, too. The
answer here is easy to describe but harder to write in this syntax.
Ordinarily, the subkey is followed by exactly one binding signature.
However, if there is a revocation of the binding signature, you may trim
off the binding signature.
   
I have redrawn the picture to be:

    Primary-Key
       [Revocation Self Signature]
       [Direct Key Self Signature...]
        User ID [Signature ...]
       [User ID [Signature ...] ...]
       [[Subkey [Binding-Signature-Revocation]
               Primary-Key-Binding-Signature] ...]

and added the paragraph:

In the above diagram, if the binding signature of a subkey has been
revoked, the revoked binding signature may be removed, leaving only one
signature.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)