Subject: Re: One-pass signatures
From: Jon Callas <[email-masked]>
To: Andrew Bromage <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 31 Jul 1998 09:32:24 -0700

At 02:06 PM 7/26/98 +1000, Andrew Bromage wrote:
   I suggest adding a sentence to the end of section 5.4 such as:
   
      Note that because multiple one-pass signatures applied to the one
      message are nested, the signature packets which follow the message
      should appear in reverse order to the one-pass signature packets
      which declare them.
   
   I'm not happy with my wording, but that should be the sense of it.
   
How's this:

Note that if a message contains more than one one-pass signature, then the
signature packets bracket the message; that is, the first signature packet
after the message corresponds to the last one-pass packet and the final
signature packet corresponds to the first one-pass packet.

	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, 29 Jul 1998 12:40:07 -0700
To: [email-masked] (Ulf M�ller)
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: DSA patent (more on RSADSI)
Cc: [email-masked]
Sender: [email-masked]

At 06:49 PM 7/29/98 +0200, Ulf M�ller wrote:
>> This is in line with what I posted before. RSA and Schnorr assert coverage
>> of "certain implementations of DSA". That is, there are implementations
>> that they don't claim coverage for.
>
>If that means they don't claim coverage for software implementations
>*in the US*, that's still a huge problem for the rest of us.

I fully agree. However, what some people at RSA told me, was that "certain
implementations" means implementations that do things a certain way, such
as some optimizations. Of course, what the told me verbally means nothing
relative to what they might claim in court. However, they have not made any
patent claims in the IETF, and I know of none in any legal arenas.

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: Re: DSA patent (more on RSADSI)
To: [email-masked] (Paul Hoffman / IMC)
Date: Wed, 29 Jul 1998 18:49:08 +0200 (DFT)
Cc: [email-masked]
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

> This is in line with what I posted before. RSA and Schnorr assert coverage
> of "certain implementations of DSA". That is, there are implementations
> that they don't claim coverage for.

If that means they don't claim coverage for software implementations
*in the US*, that's still a huge problem for the rest of us.

Date: Wed, 29 Jul 1998 08:06:24 +0200
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
Subject: Re: DSA patent
To: [email-masked]
Sender: [email-masked]

Schnorr's argument in 
http://grouper.ieee.org/groups/1363/letters/SchnorrMar98Study.ps
is a nice try, but ultimately fails to convince.

What it does show is how closely related many of the discrete log
signatures are, that with sufficient algebraic ingenuity you can
recast one to be quite similar to another.

DSS:

    Private key: x;   Public key: g^x mod p.

    r = (g^k mod p) mod q
    s = k^-1 (SHA(M) + xr) mod q

    Signature is (r, s).

    k is a random value chosen for this signature, and SHA(M) is the
    message hash.

Schnorr's signature, in one of the variants from the European patent
(apparently not a variant in the U.S. patent):

    Private key: s1, s2;   Public key: g^-s1 mod p, g^-s2 mod p

    r = g^k mod p

    h(r,m) is a double-width hash; call two halves LH(r,m) and RH(r,m)

    s = k + s1*LH(r,m) + s2*RH(r,m) mod q

    Signature is (h(r,m), s).

    k is a random value chosen for this signature.

Not too similar, huh?  Schnorr has two secret exponents, not just one;
he uses a double width hash, which is part of the signature; the
arithmetic in the choice of s doesn't look too similar to the
arithmetic in DSS, there is none of the "mod p mod q" which is so
distinctive in DSS.

Now he begins to transform it.

h(r,m) becomes defined as (SHA(m), (-r) mod q).  This means that
LH(r,m) is just SHA(m), while RH(r,m) is -r mod q.  Then the equation
for s becomes:

    s = k + s1*SHA(m) - s2*r mod q.

That's starting to look a little more like DSA's equation for s.  Now he
says, we don't really need two private exponents.  Just set s1=1 and
rely solely on s2, which we will rename as -x.  This produces:

    s = k + SHA(m) + x*r mod q.

Pretty close now.

Then he says, the signature is (h(r,m), s) which is SHA(m), -r mod q,
s.  But you don't really need SHA(m) to be part of it, that can be
calculated from the message.  So it leaves (-r mod q, s).  The first
term is now -g^k mod p mod q, just like DSS except for the negative
sign, and the second term is like DSS except instead of dividing by k
it adds k.

That's the best Schnorr can do.  He can't turn a division into an
addition, so he says, "A division modulo q is... equivalent to a
sequence of additions and shifts modulo q.  Thus the division modulo q
in the DSA iterates operations of the same type as the addition modulo
q...".

Sorry, I don't buy it.  Everything is ands and ors when you come right
down to it, but that doesn't mean that the XOR patent covers RSA.

In summary, Schnorr has to turn his two key system into one key, and
has to take his double width hash and set it up as SHA appended to a
specially chosen mathematical transformation.  Once he's done that, he
is pretty close to DSS.  But he is left with an addition where DSS has
a division, and that can't be substituted out.

From: Andrew Bromage <[email-masked]>
Subject: ElGamal signatures
To: [email-masked]
Date: Wed, 29 Jul 1998 14:51:33 +1000 (EST)
Sender: [email-masked]

G'day.

Section 5.2.2 of the draft doesn't say what the algorithm-specific
information for ElGamal signatures are.

Cheers,
Andrew Bromage

Date: Tue, 28 Jul 1998 20:07:36 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: DSA patent (more on RSADSI)
Sender: [email-masked]

>David Kravitz, former member of the NSA, holds a patent on DSA [Kra93].
>Claus P. Schnorr has asserted that his patent [Sch91] covers certain
>implementations of DSA. RSA Data Security has also asserted coverage of
>certain implementations of DSA by the Schnorr patent. 

This is in line with what I posted before. RSA and Schnorr assert coverage
of "certain implementations of DSA". That is, there are implementations
that they don't claim coverage for. The previous message shows that Schnorr
now claims coverage over all DSA, although he has never made that claim to
the IETF, as far as I know, and did not claim so last fall when I contacted
him.

The TLS draft, which is still waiting to become an RFC, requires DSS but
has no patent claims for it, FWIW. However, that draft came out before the
publication of Schnorr's revised paper that now claims coverage of all DSA.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 28 Jul 1998 22:10:30 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Interesting Webpage on RSA patent
Sender: [email-masked]

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

Since we are on the subjust of crypto patents I thought I would pass along
a URL to a rather interesting webpage.

http://www.cyberlaw.com/rsa.html

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Bill Gates' worst nightmare!

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 28 Jul 1998 21:47:55 -0500
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked] (Ulf =?US-ASCII?Q?M=F6ller), [email-masked]?=
Subject: Re: DSA patent (more on RSADSI)
Sender: [email-masked]

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

In <[email-masked]>, on 07/28/98 
   at 05:36 PM, Paul Hoffman / IMC <[email-masked]> said:

Just an added tidbit from the RSA FAQ:

http://www.rsa.com/rsalabs/newfaq/q28.html

Question 28. Is the Use of DSA Covered by Any Patents?

David Kravitz, former member of the NSA, holds a patent on DSA [Kra93].
Claus P. Schnorr has asserted that his patent [Sch91] covers certain
implementations of DSA. RSA Data Security has also asserted coverage of
certain implementations of DSA by the Schnorr patent. 

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: The sad thing about Windows bashing is it's all true.

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 28 Jul 1998 20:45:18 -0500
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked] (Ulf =?US-ASCII?Q?M=F6ller), [email-masked]?=
Subject: Re: DSA patent
Sender: [email-masked]

This is a MIME encapsulated message

--==_01668_===
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

In <[email-masked]>, on 07/28/98 
   at 05:36 PM, Paul Hoffman / IMC <[email-masked]> said:

>At 11:49 PM 7/28/98 +0200, Ulf M=94ller wrote:
>>Schnorr makes a plausible argument that DSA is covered by his patent
>>(see http://grouper.ieee.org/groups/1363/letters/SchnorrMar98.html),
>>and his European and Japanese patent claims are broader than the US
>>one. That probably means that there is no restriction to hardware
>>implementations in these patents.

>RSA is the licensor of the Schnorr patents. When asked about this, they
>have made no claims that these patents apply to DSA. If you read
>Schnorr's letter carefully, he doesn't really either. He says "The above=

>mentioned patents apply to various implementations of ...". It appears
>that he believes that you can implement DSA without infringing on his
>patent, but various things you do can cause you to infringe. This is
>similar to many other companies' "improvement patents".

Abstract:
                                                                         =
                             We
compare the Digital Signature Algorithm (DSA) of NIST with EP-Patent
0384475. We show that DSA--signatures are step by step equivalent with an=

instance described in and covered by the claims of EP-Patent 0384475.
Elliptic curve variants of the DSA are step by step equivalent with an
elliptic curve instance of EP-Patent 0384475.

And from the conclusion:

We have shown that DSA signatures are step by step equivalent to an
INSTANCE of the signatures presented and covered by the claims of
EP-Patent 0384475. The efficiencies of DSA compared to its precursor, the=

ElGamal signatures, come from computing logarithms modulo q whereas in th=
e
ElGamal signatures logarithms are modulo (p-1).

This novel feature of the PATENT has been presented for the first time in=

public at Eurocrypt'89, April 10-13,1989 in Houthalen Belgium. The
presentation at Eurocrypt'89 made it clear that the novel efficiencies ca=
n
be used in connection with known discrete log signature schemes such as
ElGamal. The inventor of the DSA, David K. Kravitz, attended this
presentation.

I think it is quite clear that Prof Schnorr considers DSA to be covered b=
y
his patent and there is the implication that the inventor of DSA based hi=
s
work directly off of Schnorr's.

Now as far as RSADSI "making no claims" is not very comforting. "Making n=
o
claims" and publicly stating that they have no intentions now or in the
future to enforce Schnorr's patent against DSA implementations are two
different things. Preferably they would do so in a nice notarized documen=
t
from their legal department.

As things stand right now there is no reason for RSADSI to say anything.
Let everyone implement DSA in their standards and then send out the
lawyers to collect payments.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------
 
Tag-O-Matic: I love running Windows! NOT!

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

--==_01668_===--

Date: Tue, 28 Jul 1998 16:24:02 -0700
To: [email-masked], Andrew Bromage <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: One-pass signatures
Cc: [email-masked]
Sender: [email-masked]

At 12:43 AM 7/26/98 -0400, [email-masked] wrote:

      One-Pass Signed Message :- One-Pass Signature Packet,
                  OpenPGP Message, Corresponding Signature Packet.

Done.

	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, 28 Jul 1998 16:22:08 -0700
To: "William H. Geiger III" <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Length specifiers
Cc: Ian Brown <[email-masked]>, ietf-open-pgp <[email-masked]>
Sender: [email-masked]

At 05:11 PM 7/27/98 -0500, William H. Geiger III wrote:

   Any particular reason why?
   
Presumably because they thought it was silly to have the termination of an
indeterminite encryption be a generic 32-bit number. It's one more case to
check. 

	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, 28 Jul 1998 15:36:24 -0700
To: [email-masked] (Ulf M�ller), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: DSA patent
Sender: [email-masked]

At 11:49 PM 7/28/98 +0200, Ulf M�ller wrote:
>Schnorr makes a plausible argument that DSA is covered by his patent
>(see http://grouper.ieee.org/groups/1363/letters/SchnorrMar98.html),
>and his European and Japanese patent claims are broader than the US
>one. That probably means that there is no restriction to hardware
>implementations in these patents.

RSA is the licensor of the Schnorr patents. When asked about this, they
have made no claims that these patents apply to DSA. If you read Schnorr's
letter carefully, he doesn't really either. He says "The above mentioned
patents apply to various implementations of ...". It appears that he
believes that you can implement DSA without infringing on his patent, but
various things you do can cause you to infringe. This is similar to many
other companies' "improvement patents".

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: DSA patent
To: [email-masked]
Date: Tue, 28 Jul 1998 23:49:00 +0200 (+0200)
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

DSA may not have been a good choice as a MUST algorithm.

Schnorr makes a plausible argument that DSA is covered by his patent
(see http://grouper.ieee.org/groups/1363/letters/SchnorrMar98.html),
and his European and Japanese patent claims are broader than the US
one. That probably means that there is no restriction to hardware
implementations in these patents.

RSA is patented only in the US and will expire in two years. Schnorr
is patented in US, Europe and Japan for a decade to come. Not very
nice.

>Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU)  id TAA00923 ; Mon, 27 Jul 1998 19:31:02 +0200
Message-ID: <[email-masked]>
Date: Mon, 27 Jul 1998 19:31:01 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Mail-Followup-To: [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.1i
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Sender: [email-masked]
Precedence: bulk

On Mon, Jul 27, 1998 at 09:47:11AM -0500, William H.
Geiger III wrote:

> Take the example of a message that is clearsigned and sent
> to A. A receives the message, signs and encrypts the
> message and forwards it to B. When B receives the message
> and decrypts it he is presented with a literal packet that
> in fact contains a PGP clear-signed message.

> Now should B's software:

> 1. Assume that because it is a literal packet check no
> further (as per the spec).

Yes.  

> 2. Check the literal packet anyway, as unless it is
> checked the contents are unknown.

Unknown is not the right thing.  PGP's standard assumption
is that the user knows what to do with the content of a
literal data packet.

> Also what should A's software do when presented with the
> original clear-signed message to be singed & encrypted?
> Does it just dump the entire clearsigned message into a
> literal packet (as current implementations do) or should
> it somehow pre-process the message so the receiving
> software knows that there is additional PGP data contained
> in the message?

It should not preprocess the message.  Imagine that some
sends me corrupted clear-signed messages and I want to
send them back...

My entire point is that PGP should not duplicate any of
MIME's efforts to give a sensible representation of
message content types.

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

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Jul 1998 17:11:21 -0500
To: Jon Callas <[email-masked]>
Cc: Ian Brown <[email-masked]>, ietf-open-pgp <[email-masked]>
Subject: Re: Length specifiers
Sender: [email-masked]

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

In <[email-masked]>, on 07/27/98 
   at 03:55 PM, Jon Callas <[email-masked]> said:

>At 06:06 PM 7/23/98 +0100, Ian Brown wrote:
>   One tiny change needed in section 4.2.2.4?
>   
>   "Another length header (of one of the three types -- one octet,
>two-octet, or partial) follows that portion."
>   
>   Should this be:
>   
>   "Another length header (of one of the four types -- one octet,
>two-octet, five-octet or partial) follows that portion."
>   
>That one's intentional. The relevant developers wanted to exclude the
>5-octet lengths there.

Any particular reason why?

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2 means...CURTAINS for Windows!

Date: Mon, 27 Jul 1998 14:44:47 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: KeyId subpackets
Sender: [email-masked]

I've looked this over and done some of my own thinking. There are lots of
cases where having the issuer key id in the signature is really useful.
However, there are also cases where it's useful to *not* have the key id
there at all. I'm thinking of a PGPticket-like system where you'd want to
hide the authenticatee's identity from any eavesdropper. There are still
other applications where the issuer's id is essentially meta-information.
This last one is what PGP does today, by putting it in the unhashed
information area.

One of the things I'm trying to pay attention to in this spec is that good
designs get used for things they weren't exactly intended for. I don't have
the details of a quasi-anonymous signature system worked out, but I can see
that it's an interesting thing. So this argues against making it a MUST.
The fact that PGP presently essentially *is* one of these quasi-anonymous
systems only adds to the argument.

So I removed the line that says it MUST be in the hashed area. I'm leaving
it in the developer's hands.

	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, 27 Jul 1998 14:13:34 -0700
To: Ian Brown <[email-masked]>, ietf-open-pgp <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Repeated paragraph
Sender: [email-masked]

At 03:15 PM 7/24/98 +0100, Ian Brown wrote:
   5.2.3.14. Revocation key

Thank you. The first paragraph was removed.

	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, 27 Jul 1998 13:55:08 -0700
To: Ian Brown <[email-masked]>, ietf-open-pgp <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Length specifiers
Sender: [email-masked]

At 06:06 PM 7/23/98 +0100, Ian Brown wrote:
   One tiny change needed in section 4.2.2.4?
   
   "Another length header (of one of the three types -- one octet,
two-octet, or partial) follows that portion."
   
   Should this be:
   
   "Another length header (of one of the four types -- one octet,
two-octet, five-octet or partial) follows that portion."
   
That one's intentional. The relevant developers wanted to exclude the
5-octet lengths there.

	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, 27 Jul 1998 13:35:39 -0500
To: [email-masked]
Subject: Another RFC reference note.
Sender: [email-masked]

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

I just noticed that rfc2045 has been updated by rfc2231. You might want to
include this in the References.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Turn your 486 into a Gameboy: Type WIN at C:\>

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Jul 1998 13:00:40 -0500
To: [email-masked]
Subject: Minor Note on Draft
Sender: [email-masked]

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

In the reference section of the draft it mentions rfc2044 UTF-8, a
transformation format of Unicode and ISO 10646.

This has been obsoleted by rfc2279 of the same title and author.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: I love running Windows! NOT!

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Jul 1998 12:43:51 -0500
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

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

>I don't think any of the numerous people who replied to this thread
>picked up on the fact that what I think Black Unicorn identities as a
>common user requirement is in fact possible already.

>That is you _can_ strip of the encryption layer leaving the signature
>layer.  What you get is not normally a clear signed text, but rather a
>binary signed text.  These are pretty readable, consisting of a few
>binary chars at the begining of the file (being the prepended binary
>signature), followed by the text signed.

>It should be easily possible to add the ability to one of the GUI
>versions of pgp to add support for retaining signatures in this form in a
>convenient searchable form.  A simple option tick box to retain
>signatures should therefore be easily implementable.

>I would presume that all versions of pgp already retain the ability to
>verify such signatures.

While this can address local signature retention it does not address the
issue of how to forward this signature with the message to another party.
Without the ability to convert this signature into a clearsigned signature
or a PGP/MIME signature there is no way to transfer this signature with
the message to a 3rd party.

IMHO it is just simpler to devalue the sign AND encrypt option in PGP and
use a 2 step process of sign (clearsigned or PGP/MIME) THEN encrypt.

It is the only way I see to guarantee signature retention through the
different mailers a PGP message may travel through.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows: an Unrecoverable Acquisition Error!

Date: Mon, 27 Jul 1998 17:21:00 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

I don't think any of the numerous people who replied to this thread
picked up on the fact that what I think Black Unicorn identities as a
common user requirement is in fact possible already.

That is you _can_ strip of the encryption layer leaving the signature
layer.  What you get is not normally a clear signed text, but rather a
binary signed text.  These are pretty readable, consisting of a few
binary chars at the begining of the file (being the prepended binary
signature), followed by the text signed.

It should be easily possible to add the ability to one of the GUI
versions of pgp to add support for retaining signatures in this form
in a convenient searchable form.  A simple option tick box to retain
signatures should therefore be easily implementable.

I would presume that all versions of pgp already retain the ability to
verify such signatures.

with pgp2.x you can test this out with:

% echo hello world > test
% pgp -eas test aba
% pgp -d test.asc
Output file 'test' may contain more ciphertext or signature.
Should 'test' be renamed to 'test.pgp' (Y/n)? y
% cat test.pgp
5��P)ȸUjJg�X;�Z]�RB@�PU@�����bR���-�
��_%C�~bB"3m�Kͪ�q*�*Y�         ��~��L�1NZ)��
        m��βp�}�p�VY!a�ˬbtesthello world
(you should see the hello world at the end).
% pgp test.pgp
Good signature from user "Adam Back <[email-masked]>".
Signature made 1998/07/27 16:14 GMT using 1024-bit key, key ID 556A4A67
%

(here's the test.pgp converted into armor:

% uuencode test.pgp test.pgp > test.uue
% cat test.uue

to verify cut and paste teh above into test.uue, then do:
% uudecode test.uue
% pgp test.pgp
% cat test.pgp
etc.

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, 27 Jul 1998 11:12:55 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: Public Keyring
Sender: [email-masked]

On Sun, 26 Jul 1998, William H. Geiger III wrote:

> In <[email-masked]>, on 07/26/98
> 
>    at 05:10 AM, Christoph Moser <[email-masked]> said:
> 
> >At 15:44 25.07.98 -0700, you wrote:
> >>> Just one (simple) question:
> >>>
> >>> How can I figure out which UserID fits to which KeyID ?
> >>
> >>The userid belongs to the key which precedes it in the keyring.

Only the DSA key precedes most user IDs.

> >Well, that's right, but how can I find out the KeyID the UserID belongs
> >to ? There is no field in a Public Key Packet.
> 
> In the old RSA keys (V2 & v3) the KeyID was the last 64bits of the 1st MPI
> (public modulus). In the version 4 keys the KeyID is the last 64bits of
> the 160bit hash (fingerprint) of the public key packet.
> 
> Read section 11.2 Key IDs and Fingerprints starting on page 49 of the
> draft.

There can be multiple encryption subkeys, but I think one is a default
(determined in the signature packets) and extra UserIDs can be attached to
the subkeys if I remember, but am not sure.

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

Date: Mon, 27 Jul 1998 11:08:36 -0400
From: [email-masked]
To: ietf-open-pgp <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

On Sun, 26 Jul 1998, Ian Brown wrote:

> >We have had some discussion on OpenPGP of a flag, perhaps in the literal
> >packet, which would indicate that messages are in this form.  Perhaps a
> >future version will have a clean way of doing this.
> 
> 
> This would also be nice for super-encrypting messages, for something
> like IDEA(CAST(plaintext)) 
> 
> Perhaps have an 'n' for nested mode in Literal packets that tells
> clients to treat the contained data as another PGP data structure. 

Several months ago there was an offline discussion on this topic.  PGP
uses the literal packet as a "stop processing here" construct, though that
is not clear from the spec.

The context of the original discussion was: Why have *nested* one pass
sigs, when you can encapsulate a signed message in a literal packet.  The
answer is that PGP uses the literal packet as an end-of-algorithms marker,
i.e. dearmor->decrypt->decompress->checksig&extract(stop).

For the next revision of this, I am going to strongly advocate a 'n'
literal data type to add to t and b to tell a PGP implemetation to process
the result of stripping the literal information off. 

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

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Jul 1998 09:47:11 -0500
To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

In <[email-masked]>, on 07/27/98 
   at 01:33 PM, Thomas Roessler <[email-masked]> said:

>To make a long story short: We should consider literal
>data packets as AS IS data.  Their content MUST NOT be
>interpreted by an OpenPGP implementation, but passed to
>the user or invoking software for further inspection.
>These programs MAY then interpret PGP/MIME content type
>definitions and invoke an OpenPGP client to work on the
>nested data.

Sounds good in theory but the problem is no one is doing so in any of the
current PGP implementations and doubtfull anyone will be any time soon.

Lets leave the MIME issue alone for right now and work with a simple PGP
ascii-armor example:

Take the example of a message that is clearsigned and sent to A. A
receives the message, signs and encrypts the message and forwards it to B.
When B receives the message and decrypts it he is presented with a literal
packet that in fact contains a PGP clear-signed message.

Now should B's software:

1. Assume that because it is a literal packet check no further (as per the
spec).

2. Check the literal packet anyway, as unless it is checked the contents
are unknown.

Also what should A's software do when presented with the original
clear-signed message to be singed & encrypted? Does it just dump the
entire clearsigned message into a literal packet (as current
implementations do) or should it somehow pre-process the message so the
receiving software knows that there is additional PGP data contained in
the message?

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows NT?  New Technology?  I don't think so...

>Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU)  id NAA23500 ; Mon, 27 Jul 1998 13:33:59 +0200
Message-ID: <[email-masked]>
Date: Mon, 27 Jul 1998 13:33:59 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Mail-Followup-To: [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.1i
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Sender: [email-masked]
Precedence: bulk

On Sat, Jul 25, 1998 at 06:45:28PM -0500, William H.
Geiger III wrote:

> One really needs to run a second pass over any encrypted
> message after it has been decrypted as the contents of the
> encrypted packet are unknown until decryption. The client
> software should be capable of handeling multiple layers of
> PGP messages one inside of another.

I'm not sure what you mean by this.  

IMNSHO, PGP client software should never ever interpret
the contents of a literal data packet, but handle it as
precisely this: Literal data. Interpreting data packets'
content has to be done by mail user agents or users
themselves.

An example: Think about someone who gets a message which
agrees to current PGP/MIME standards.  He encapsulates
this message into a message/rfc822 type attachment and
forwards it (along with some comment) to a friend.  The
forwarded message is PGP/MIME encrypted.

We get a message which looks like this:

	multipart/encrypted
	|
	+- application/pgp-encrypted (This is just "Version: 1")
	`- application/octet-stream

The application/octet-stream contains ASCII armored,
encrypted stuff.  After decryption, we get a valid
message/rfc822 MIME attachment which contains an
attachment tree like this one:

	multipart/signed
	|
	+- text/plain (This is the payload)
	`- application/pgp-signature

The application/pgp-signature attachment contains an ASCII
armored signature of the preceeding attachment.

Now, imagine a PGP implementation which tries to interpret
the contents of a literal data packet. Such an
implementation would recognize the
applicatin/pgp-signature attachment's contents as ASCII
armord PGP stuff and try to interpret it.  Bumm.

There are worse cases to be considered: Imagine the
forwarded message uses the traditional application/pgp
stuff.  In this case, a cleartext signature of the text in
question is generated _before_ any MIME encoding is being
applied.  This means that the PGP encrypted stuff I just
talked about will return a message/rfc822 MIME attachment
which contains precisely one body part of type
application/pgp:

	message/rfc822
	|
	`- application/pgp; transfer encoding: quoted printable

The armor delimiters will be left unchanged by quoted
printable encoding, while the messages' content _will_ be
changed.  An implementation of PGP which interprets
literal data packets' content will recognize the
delimiters, try to decode the message, and end up with a
bad signature where we actually had a good one.

Finally, a message may contain "sample code" which looks
like PGP armor, but is not.

Similar problems occur with public keys which are
formatted according to the PGP/MIME RFCs.  Note that this
is not just theory, but real problems.  E.g., try sending
and reading PGP/MIME signed public keys with recent Mutt
versions and PGP 5.  The output looks really funny.

To make a long story short: We should consider literal
data packets as AS IS data.  Their content MUST NOT be
interpreted by an OpenPGP implementation, but passed to
the user or invoking software for further inspection.
These programs MAY then interpret PGP/MIME content type
definitions and invoke an OpenPGP client to work on the
nested data.

Maybe something along these lines should be added to the
latest draft.  (I didn't check if it's there already.)

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

From: Andrew Bromage <[email-masked]>
Subject: Re: One-pass signatures
To: [email-masked]
Date: Mon, 27 Jul 1998 11:04:55 +1000 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

G'day all.

[email-masked] wrote:

> So what you are saying is that:
> 
>    One-Pass Signed Message :- One-Pass Signature Packet,
>                OpenPGP Message, Signature Packet.
> 
> doesn't imply that the One-Pass Signature Packet which prefixes the
> message MUST correspond to the Signature Packet which comes after the
> message.

It does suggest to me that my implementation MUST accept such messages,
but it doesn't imply that I MUST produce such messages, no.  The
obvious (for some definition of "obvious") way to produce one-pass
signatures is to produce one-pass signature packets by iterating over
some sequence, processing the data, then producing the signature packets
in the same order by a similar iteration.  The temptation is too great
to hope that people will simply get the hint.  :-)

Actually, come to think of it, it does remind me of a programming
language construct from the distant past: multiple assignment.
Some older languages allowed you to write things like:

	(a,b,c) := (1,2,3);

which was understood to mean:

	a := 1;
	b := 2;
	c := 3;

The only way you can express the constraint that the size of the tuple
on the LHS is the same as the size of the tuple on the RHS as part of
a context-free grammar is to use something like this:

	Assignment ::= '(', Multiple Assignment, ')'.

	Multiple Assignment ::= Variable, Multiple Assignment, Expression
		| ')' ':=' '('.

Note that the Variable and the Expression don't correspond here.

> Would this be better:
> 
>    One-Pass Signed Message :- One-Pass Signature Packet,
>                OpenPGP Message, Corresponding Signature Packet.

That would clear things up with the minimum of text, yes.

Cheers,
Andrew Bromage

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 26 Jul 1998 15:13:33 -0500
To: Cypherlist-watch-owner <[email-masked]>
Cc: Christoph Moser <[email-masked]>, [email-masked]
Subject: Re: Public Key Ring
Sender: [email-masked]

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

In <[email-masked]>, on 07/26/98 
   at 01:53 PM, Cypherlist-watch-owner
<[email-masked]> said:

>On Sun, 26 Jul 1998 12:25:53 +0200, Christoph Moser wrote:

>> Name                             KeyID

>> Jon Callas                    0xF12927A9

>> Public-Key Encrypted Session Key Packet
>> KeyID : 11 30 C6 76 C0 95 F2 72 
>> 
>> 
>> Symmetrically Encrypted Data Packet
>> 
>> But only the KeyIDs of Bontchev and Zimmermann fits to the ones that
>> the PGP 5.5i implementation shows. And these two keys are RSA keys - the
>> others are DSA keys. Why that ?

>Don't forget DSS/DH keys are exactly that - two key pairs.  The output is
>correct (just used Jon Callas to illustrate)

>Key Type: DSS	Key ID: 0x7DF9C2E6F12927A9	User: Jon Callas <[email-masked]>
>Key Type: DH 	Key ID: 0x1130C676C095F272	User: Jon Callas <[email-masked]>

Just as a side note I believe that PGP Keys (pgpk for the *nixers) only
operates with the keyID's of the signature keys. I don't think that you
can directly reference the encryption sub-key with the 5.x version of PGP.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Have you crashed your Windows today?

Date: Sun, 26 Jul 1998 13:53:47 -0500
From: Cypherlist-watch-owner <[email-masked]>
To: Christoph Moser <[email-masked]>
Cc: [email-masked]
Subject: Re: Public Key Ring
Sender: [email-masked]

On Sun, 26 Jul 1998 12:25:53 +0200, Christoph Moser wrote:

> Name                             KeyID

> Jon Callas                    0xF12927A9

> Public-Key Encrypted Session Key Packet
> KeyID : 11 30 C6 76 C0 95 F2 72 
> 
> 
> Symmetrically Encrypted Data Packet
> 
> But only the KeyIDs of Bontchev and Zimmermann fits to the ones that
> the PGP 5.5i implementation shows. And these two keys are RSA keys - the
> others are DSA keys. Why that ?

Don't forget DSS/DH keys are exactly that - two key pairs.  The
output is correct (just used Jon Callas to illustrate)

Key Type: DSS	Key ID: 0x7DF9C2E6F12927A9	User: Jon Callas <[email-masked]>
Key Type: DH 	Key ID: 0x1130C676C095F272	User: Jon Callas <[email-masked]>

Regards

Mark

--
       Potato software mirror: http://www.mbsystem.u-net.com
 Moderator of Cypher-list Watch  To subscribe send a blank e-mail to
       [email-masked]
      RSA key-ID:    0xB01F2EE5       DSS/DH key-ID: 0x54C5C59

From: Ian Brown <[email-masked]>
To: "Tony L. Svanstrom" <[email-masked]>, "William H. Geiger III" <[email-masked]>
Cc: ietf-open-pgp <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Date: Sun, 26 Jul 1998 17:52:30 +0100
Sender: [email-masked]

From: Tony L. Svanstrom <[email-masked]>
>As it is today it would be easy for my employer and/or government to keep
>copies of all communication that enters and leaves their network; that
>information could be used to create a "map" of my network of friends.
>If we were all using PGP they wouldn't be able to read what we write, and
>it would be very easy to set up and use some kind of remailer; but even
>if we were to do all that they still would be able to create that "map" by
>searching all e-mails for our signatures.

No. The signatures are encrypted along with the message.

Ian.

Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Date: Sun, 26 Jul 1998 17:53:55 +0200
From: "Tony L. Svanstrom" <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: <[email-masked]>
Sender: [email-masked]

A long time ago (07-26-98 16:34) from someone far away (William H. Geiger 
III):

>>As it is today it would be easy for my employer and/or government to keep
>>copies of all communication that enters and leaves their network; that
>>information could be used to create a "map" of my network of friends. If
>>we were all using PGP they wouldn't be able to read what we write, and it
>>would be very easy to set up and use some kind of remailer; but even if
>>we were to do all that they still would be able to create that "map" by
>>searching all e-mails for our signatures.

>If you don't want your signature retained on a document then don't sign it!!

Maybe you misunderstod me; what I meant to say was that haveing the 
message
clearsigned and then encrypted (without a second signing) is something 
that
will make it more secure.

     /Tony
-- 
                                 /\___/\ 
                                 \_@ @_/ 
 ------------------------------oOO-(_)-OOo------------------------------
 ID: Ox7F98CDAF, Fp: E6DF BEE1 FEF9 7888  7AD3 1BA1 98B0 4E9F, Type: RSA
 -------------------------------���---���-------------------------------
     No other keys are valid    \O/   \O/    �Tony Svanstrom 1998

Send an e-mail to me with the subject "Send PGPkey" to get my public key.

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 26 Jul 1998 09:38:39 -0500
To: Christoph Moser <[email-masked]>
Cc: [email-masked]
Subject: Re: Public Keyring
Sender: [email-masked]

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

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

   at 05:10 AM, Christoph Moser <[email-masked]> said:

>At 15:44 25.07.98 -0700, you wrote:
>>> Just one (simple) question:
>>>
>>> How can I figure out which UserID fits to which KeyID ?
>>
>>The userid belongs to the key which precedes it in the keyring.

>Well, that's right, but how can I find out the KeyID the UserID belongs
>to ? There is no field in a Public Key Packet.

In the old RSA keys (V2 & v3) the KeyID was the last 64bits of the 1st MPI
(public modulus). In the version 4 keys the KeyID is the last 64bits of
the 160bit hash (fingerprint) of the public key packet.

Read section 11.2 Key IDs and Fingerprints starting on page 49 of the
draft.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2.

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 26 Jul 1998 09:34:58 -0500
To: "Tony L. Svanstrom" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

In <[email-masked]>, on 07/26/98 
   at 04:17 PM, "Tony L. Svanstrom" <[email-masked]> said:

>That should also be a lot better from a security point of view; shouldn't
> it?

>As it is today it would be easy for my employer and/or government to keep
>copies of all communication that enters and leaves their network; that
>information could be used to create a "map" of my network of friends. If
>we were all using PGP they wouldn't be able to read what we write, and it
>would be very easy to set up and use some kind of remailer; but even if
>we were to do all that they still would be able to create that "map" by
>searching all e-mails for our signatures.

>I'd say that this is a big security mistake. To most of us this is not
>something that we have to care about, but think about what a government
>could do. A network of people trying to establish a democracy in their
>country might feel safe because they are using PGP, but just because they
>are using PGP the government might now about every single one of them
>even though that they are using remailers.

If you don't want your signature retained on a document then don't sign
it!!

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: How do you make Windows faster?  Throw it harder!

Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Date: Sun, 26 Jul 1998 16:17:49 +0200
From: "Tony L. Svanstrom" <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: <[email-masked]>
Sender: [email-masked]

A long time ago (07-26-98 11:53) from someone far away (William H. Geiger 
III):

>All that needs to be done to "fix" this is give the user the ability to
>clear-sign then encrypt his messages. Preferably as the default action but
>at least as a user setting. There is *no* reason to force the sender or
>the recipient to jump through hoops for signature retention. That is just
>poor software design.

That should also be a lot better from a security point of view; shouldn't 
it?

As it is today it would be easy for my employer and/or government to keep
copies of all communication that enters and leaves their network; that
information could be used to create a "map" of my network of friends.
If we were all using PGP they wouldn't be able to read what we write, and
it would be very easy to set up and use some kind of remailer; but even
if we were to do all that they still would be able to create that "map" by
searching all e-mails for our signatures.

I'd say that this is a big security mistake. To most of us this is not
something that we have to care about, but think about what a government
could do. A network of people trying to establish a democracy in their
country might feel safe because they are using PGP, but just because
they are using PGP the government might now about every single one of
them even though that they are using remailers.

I might be really wrong (I've been lurking on this list for awhile to
learn more) but I felt that I should try to say something smart. ;-)

     /Tony
-- 
                                 /\___/\ 
                                 \_@ @_/ 
 ------------------------------oOO-(_)-OOo------------------------------
 ID: Ox7F98CDAF, Fp: E6DF BEE1 FEF9 7888  7AD3 1BA1 98B0 4E9F, Type: RSA
 -------------------------------���---���-------------------------------
     No other keys are valid    \O/   \O/    �Tony Svanstrom 1998

Send an e-mail to me with the subject "Send PGPkey" to get my public key.

From: Ian Brown <[email-masked]>
To: "William H. Geiger III" <[email-masked]>, Hal Finney <[email-masked]>
Cc: ietf-open-pgp <[email-masked]>, unicorn <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Date: Sun, 26 Jul 1998 12:43:44 +0100
Sender: [email-masked]

>Ideally there would be only one way of calculating a signature so a sign &
>encrypt message could have it's signature retained and converted to a
>clear-sig. IMHO going with a flag is just giving the software designers an
>easy out from doing the PGP processing properly.

Right. RFC 2015 explicitly stated that encrypted+signed messages must be able to be rewritten as plaintext+signature by mailers.

Ian.

From: Ian Brown <[email-masked]>
To: Hal Finney <[email-masked]>, ietf-open-pgp <[email-masked]>, unicorn <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Date: Sun, 26 Jul 1998 12:40:56 +0100
Sender: [email-masked]

>We have had some discussion on OpenPGP of a flag, perhaps in the literal
>packet, which would indicate that messages are in this form.  Perhaps a
>future version will have a clean way of doing this.

This would also be nice for super-encrypting messages, for something like IDEA(CAST(plaintext))

Perhaps have an 'n' for nested mode in Literal packets that tells clients to treat the contained data as another PGP data structure.

Ian.

Date: Sun, 26 Jul 1998 12:25:53 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Public Key Ring
Sender: [email-masked]

Hi !

Just another thing I don't understand:

In PGP Version 5.5i are some public Keys included e.g.:
Name                             KeyID
 
Brett A. Thomas               0x38257478
Jon Callas                    0xF12927A9
Phillip R. Zimmermann         0xC7A966DD
Vesselin V. Bontchev          0x32DD98D9
Will Price                    0xCF73EC4C
Christoph Moser               0x579B336B

Ok, and when I encrypt a message to these persons the packets look just like
these:

Public-Key Encrypted Session Key Packet
KeyID : E7 2C D7 95 F2 79 E5 81 
Public-Key Encrypted Session Key Packet
KeyID : 56 B2 C7 B8 4C 12 CF B0 
Public-Key Encrypted Session Key Packet
KeyID : 7E FA 25 C6 73 35 7D 11 
Public-Key Encrypted Session Key Packet
KeyID : 11 30 C6 76 C0 95 F2 72 
Public-Key Encrypted Session Key Packet
KeyID : 36 56 97 C6 32 DD 98 D9 
Public-Key Encrypted Session Key Packet
KeyID : 65 79 84 B8 C7 A9 66 DD 

Symmetrically Encrypted Data Packet

But only the KeyIDs of Bontchev and Zimmermann fits to the ones that
the PGP 5.5i implementation shows. And these two keys are RSA keys - the
others are DSA keys. Why that ?

Bye

   Christoph

Date: Sun, 26 Jul 1998 12:10:00 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Re: Public Keyring
Sender: [email-masked]

At 15:44 25.07.98 -0700, you wrote:
>> Just one (simple) question:
>>
>> How can I figure out which UserID fits to which KeyID ?
>
>The userid belongs to the key which precedes it in the keyring.

Well, that's right, but how can I find out the KeyID the UserID belongs
to ? There is no field in a Public Key Packet.

Bye

 Christoph

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 26 Jul 1998 04:53:50 -0500
To: Bill Frantz <[email-masked]>
Cc: Black Unicorn <[email-masked]>, [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

In <v03110741b1e085323531@[209.109.235.248]>, on 07/26/98 
   at 02:09 AM, Bill Frantz <[email-masked]> said:

>At 12:53 PM -0800 7/25/98, Black Unicorn wrote:
>>As an example, suppose bob the stockbroker is accepting PGP based orders,
>>using PGP signature and encryption to secure and authenticate customer
>>security orders.
>>
>>If a dispute arises, surely bob would want to be able to find and present
>>the actual order along with its digital signature to defend his actions,
>>the same way most brokerages record order calls today.
>>
>>Unless I'm mistaken its currently impossible for bob to do this effectively
>>with PGP.  He can maintain an archive all of the encrypted messages from
>>clients, but keyword searching of the archive is impossible.  And
>>decrypting all the messages is likewise difficult (though I suppose filing
>>them by date might help).  There is, as far as I can tell, no way to detach
>>cleartext signatures from a signed and encrypted PGP message.

>If Bob has the problem in the imperfect world we inhabit today, I suggest
>the following.  Keep parallel files.  One contains the decrypted orders
>each of which has a pointer to the encrypted order.  The decrypted orders
>can be searched but not verified.  The encrypted orders can be verified,
>but not searched.  When it is necessary to search, search the decrypted
>orders and use the pointer to get the needed verification on the results
>of the search.

>Yes, it doubles the storage requirements.  However, for the given
>application, I can't see a stockbroker, even with the volume Charles
>Schwab, running into financial difficulties because of doubled storage
>costs for original order documentation.

That is really a sloppy approach to the problem.

All that needs to be done to "fix" this is give the user the ability to
clear-sign then encrypt his messages. Preferably as the default action but
at least as a user setting. There is *no* reason to force the sender or
the recipient to jump through hoops for signature retention. That is just
poor software design.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows: an Unrecoverable Acquisition Error!

Date: Sat, 25 Jul 1998 23:09:40 -0800
To: Black Unicorn <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Cc: [email-masked]
Sender: [email-masked]

At 12:53 PM -0800 7/25/98, Black Unicorn wrote:
>As an example, suppose bob the stockbroker is accepting PGP based orders,
>using PGP signature and encryption to secure and authenticate customer
>security orders.
>
>If a dispute arises, surely bob would want to be able to find and present
>the actual order along with its digital signature to defend his actions,
>the same way most brokerages record order calls today.
>
>Unless I'm mistaken its currently impossible for bob to do this effectively
>with PGP.  He can maintain an archive all of the encrypted messages from
>clients, but keyword searching of the archive is impossible.  And
>decrypting all the messages is likewise difficult (though I suppose filing
>them by date might help).  There is, as far as I can tell, no way to detach
>cleartext signatures from a signed and encrypted PGP message.

If Bob has the problem in the imperfect world we inhabit today, I suggest
the following.  Keep parallel files.  One contains the decrypted orders
each of which has a pointer to the encrypted order.  The decrypted orders
can be searched but not verified.  The encrypted orders can be verified,
but not searched.  When it is necessary to search, search the decrypted
orders and use the pointer to get the needed verification on the results of
the search.

Yes, it doubles the storage requirements.  However, for the given
application, I can't see a stockbroker, even with the volume Charles
Schwab, running into financial difficulties because of doubled storage
costs for original order documentation.

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

Date: Sun, 26 Jul 1998 00:43:50 -0400
From: [email-masked]
To: Andrew Bromage <[email-masked]>
cc: [email-masked]
Subject: Re: One-pass signatures
Sender: [email-masked]

On Sun, 26 Jul 1998, Andrew Bromage wrote:

> G'day all.
> 
> [email-masked] wrote:
> 
> > Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
> > headers is the proper one.  Someone check the syntax again.
> 
> The syntax doesn't say that.  As section 10.2 currently reads,
> {1pass-1 1pass-2 {lit} sig-1 sig-2} is a valid sequence SYNTACTICALLY,
> since the syntax doesn't say that the one-pass packet and trailing
> signature packet correspond to the same signature.  The semantics (see
> section 5.4) don't help, because they only say that the signature packet
> corresponding to a one-pass packet should be "at the end of the message"
> without saying where.

So what you are saying is that:

   One-Pass Signed Message :- One-Pass Signature Packet,
               OpenPGP Message, Signature Packet.

doesn't imply that the One-Pass Signature Packet which prefixes the
message MUST correspond to the Signature Packet which comes after the
message.

Would this be better:

   One-Pass Signed Message :- One-Pass Signature Packet,
               OpenPGP Message, Corresponding Signature Packet.

(Thanks for the C example, I didn't realize that was a valid construct).

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

From: Andrew Bromage <[email-masked]>
Subject: Re: One-pass signatures
To: [email-masked]
Date: Sun, 26 Jul 1998 14:06:57 +1000 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

G'day all.

[email-masked] wrote:

> Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
> headers is the proper one.  Someone check the syntax again.

The syntax doesn't say that.  As section 10.2 currently reads,
{1pass-1 1pass-2 {lit} sig-1 sig-2} is a valid sequence SYNTACTICALLY,
since the syntax doesn't say that the one-pass packet and trailing
signature packet correspond to the same signature.  The semantics (see
section 5.4) don't help, because they only say that the signature packet
corresponding to a one-pass packet should be "at the end of the message"
without saying where.

> The nesting is important.  For a one-pass implementation, it makes it hard
> if you have to check every onepass to see if it was NESTED - see the
> discussion of the nested octed in 1pass sig header packets. That is the
> major headache since only nonnested signatures could be moved around
> anyway.  The moment the signatures are nested (i.e this signature includes
> the following one-pass packet through the signature at the end), order is
> critical. 

Not necessarily.  You collect one-pass packets, compute all signatures
as you process the literal data, then as you hit signature packets,
search through the one-pass packets that you saw earlier to see what
matches, first by key id/algorithms, and in the case of a tie, by testing
the signature is actually valid or not.  Yes, performance is slightly
degraded, but only in the case of duplicate key ids, which we expect
to be rare.

I'm perfectly happy with either semantics (pure nesting or free ordering),
but the spec at the moment only hints at one without ruling out the other.
If it is as critical as you suggest (and I'm not convinced that it is
based on my own private implementation in the works, though I agree it
would certainly make things easier), the spec should make the situation
clear.

I suggest adding a sentence to the end of section 5.4 such as:

   Note that because multiple one-pass signatures applied to the one
   message are nested, the signature packets which follow the message
   should appear in reverse order to the one-pass signature packets
   which declare them.

I'm not happy with my wording, but that should be the sense of it.

> Syntactically, it is similar to a do { ... } while(...); in C - the do
> says to look for a while.

Using the programming language analogy (I'm actually a compiler person by
trade, not a cryptographer), the hole which needs patching in the spec is
similar to "Duff's device".  For those who are unfamiliar, XJ311 allows
the following C syntax:

	switch (...) {
		for (...;...;...) {
			case ...: ...
			default: ...
		}
	}

Many otherwise compliant implementations broke on this because nobody
realised that it was correct ANSI C.

> And if you do a onepass implementation like I do (the whole reason for
> having 1pass sig headers), it works better if you can create a stack and
> simply note the nesting level, then pop each context off the stack as its
> corresponding signature appears.

I agree that this is a neat implementation, but I have this feeling that
someone, based on the current spec, will produce the "same order" sequence
(as opposed to the "reverse order" sequence) and assume it's valid.

> Further, you might have to test more than one signature - keyids aren't
> guarnteed to be unique.

You may have to test more than one signature anyway, since you could have
multiple keys with the same ids on your public key ring.

Cheers,
Andrew Bromage

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 25 Jul 1998 18:45:28 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

In <[email-masked]>, on 07/25/98 
   at 03:42 PM, Hal Finney <[email-masked]> said:

>Bob could require/request his customers to prepare their messages in two
>passes, the first one to clearsign them and the second one to encrypt
>them.  Then when he processed the messages he could decrypt and leave a
>clearsigned message, on which the signature could be checked but the
>message left in clearsigned form.

>We at NetAss have considered changing the default behavior of the
>encrypt-and-sign option to behave in this manner (clearsign then
>encrypt). Unfortunately, messages prepared in this way require users with
>current client software to manually run two passes to decrypt and verify.
>The need for backwards compatibility has prevented us from going forward
>with this scheme.

One really needs to run a second pass over any encrypted message after it
has been decrypted as the contents of the encrypted packet are unknown
until decryption. The client software should be capable of handeling
multiple layers of PGP messages one inside of another.

>We have had some discussion on OpenPGP of a flag, perhaps in the literal
>packet, which would indicate that messages are in this form.  Perhaps a
>future version will have a clean way of doing this.

Ideally there would be only one way of calculating a signature so a sign &
encrypt message could have it's signature retained and converted to a
clear-sig. IMHO going with a flag is just giving the software designers an
easy out from doing the PGP processing properly.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows is to OS/2 what Etch-a-Sketch is to art.

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 25 Jul 1998 18:41:07 -0500
To: Cypherlist-watch-owner <[email-masked]>
Cc: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

In <[email-masked]>, on 07/25/98 
   at 05:59 PM, Cypherlist-watch-owner
<[email-masked]> said:

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

>On Sat, 25 Jul 1998 15:53:38 -0500, Black Unicorn wrote:

>> There is, as far as I can tell, no way to detach
>> cleartext signatures from a signed and encrypted PGP message.
>> 
>> Suggestions?

>How about some kind of dual pass in your given scenario?  First sign the
>plain text to provide the authentication - then encypt the signed output
>as an entity on it's own. Bob the stockbroker can then decrypt the order
>and store the signed text.

>Any use?

This is what I have been advocating for quite awhile now and how I have my
current PGP implementations working.

IMHO signature retention is more important than any advantages of a "one
pass" operation.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: I'm an OS/2 developer...I don't NEED a life!

Date: Sat, 25 Jul 1998 18:07:15 -0500
To: Hal Finney <[email-masked]>, [email-masked]
From: Black Unicorn <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

At 05:42 PM 7/25/98 , Hal Finney wrote:

>Bob could require/request his customers to prepare their messages in
>two passes, the first one to clearsign them and the second one to
>encrypt them.  Then when he processed the messages he could decrypt
>and leave a clearsigned message, on which the signature could be
>checked but the message left in clearsigned form.

This was the option I referred to when I said "without much nonsense on the
senders side."

Bob's clients would be annoyed and there would be constant non-compliance
and customer service strife.

>We at NetAss

Please tell me this abbreviation was intentional.

>have considered changing the default behavior of the
>encrypt-and-sign option to behave in this manner (clearsign then encrypt).

Continue considering it, please?

>Unfortunately, messages prepared in this way require users with current
>client software to manually run two passes to decrypt and verify.
>The need for backwards compatibility has prevented us from going forward
>with this scheme.
>
>We have had some discussion on OpenPGP of a flag, perhaps in the literal
>packet, which would indicate that messages are in this form.  Perhaps a
>future version will have a clean way of doing this.

I do hope so.  If Network Associates is trying to sell these services in
enterprise, and anticipates, as I think they have, a need for archiving and
corporate access as well as anti-repudiation features, it would seem this
is a major issue that has to be addressed.

Date: Sat, 25 Jul 1998 17:59:44 -0500
From: Cypherlist-watch-owner <[email-masked]>
To: [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

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

On Sat, 25 Jul 1998 15:53:38 -0500, Black Unicorn wrote:

> There is, as far as I can tell, no way to detach
> cleartext signatures from a signed and encrypted PGP message.
> 
> Suggestions?

How about some kind of dual pass in your given scenario?  First sign
the plain text to provide the authentication - then encypt the
signed output as an entity on it's own. Bob the stockbroker can then
decrypt the order and store the signed text.

Any use?

Regards

Mark

Date: Sat, 25 Jul 1998 15:44:06 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Public Keyring
Sender: [email-masked]

> Just one (simple) question:
>
> How can I figure out which UserID fits to which KeyID ?

The userid belongs to the key which precedes it in the keyring.

Hal

Date: Sat, 25 Jul 1998 15:42:32 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Sender: [email-masked]

Bob could require/request his customers to prepare their messages in
two passes, the first one to clearsign them and the second one to
encrypt them.  Then when he processed the messages he could decrypt
and leave a clearsigned message, on which the signature could be
checked but the message left in clearsigned form.

We at NetAss have considered changing the default behavior of the
encrypt-and-sign option to behave in this manner (clearsign then encrypt).
Unfortunately, messages prepared in this way require users with current
client software to manually run two passes to decrypt and verify.
The need for backwards compatibility has prevented us from going forward
with this scheme.

We have had some discussion on OpenPGP of a flag, perhaps in the literal
packet, which would indicate that messages are in this form.  Perhaps a
future version will have a clean way of doing this.

Hal

Date: Sat, 25 Jul 1998 15:53:38 -0500
To: [email-masked]
From: Black Unicorn <[email-masked]>
Subject: Re: Shortcomings of current schemes (Was: One-pass signatures)
Cc: [email-masked]
Sender: [email-masked]

It occurred to me recently that the current obsession with one pass
processing has resulted in rather an irritating side effect.

Unless I'm wrong the current implementations of PGP do not permit
businesses who want to rely on after-the-fact verification of digital
signatures to do so without much nonsense on the senders side.

As an example, suppose bob the stockbroker is accepting PGP based orders,
using PGP signature and encryption to secure and authenticate customer
security orders.

If a dispute arises, surely bob would want to be able to find and present
the actual order along with its digital signature to defend his actions,
the same way most brokerages record order calls today.

Unless I'm mistaken its currently impossible for bob to do this effectively
with PGP.  He can maintain an archive all of the encrypted messages from
clients, but keyword searching of the archive is impossible.  And
decrypting all the messages is likewise difficult (though I suppose filing
them by date might help).  There is, as far as I can tell, no way to detach
cleartext signatures from a signed and encrypted PGP message.

Suggestions?

At 02:08 AM 7/25/98 , [email-masked] wrote:
>Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
>headers is the proper one.  Someone check the syntax again.
>
>The nesting is important.  For a one-pass implementation, it makes it hard
>if you have to check every onepass to see if it was NESTED - see the
>discussion of the nested octed in 1pass sig header packets. That is the
>major headache since only nonnested signatures could be moved around
>anyway.  The moment the signatures are nested (i.e this signature includes
>the following one-pass packet through the signature at the end), order is
>critical. 
>
>Syntactically, it is similar to a do { ... } while(...); in C - the do
>says to look for a while.
>
>And if you do a onepass implementation like I do (the whole reason for
>having 1pass sig headers), it works better if you can create a stack and
>simply note the nesting level, then pop each context off the stack as its
>corresponding signature appears.
>
>Further, you might have to test more than one signature - keyids aren't
>guarnteed to be unique.
>
>--- reply to tzeruch - at - ceddec - dot - com ---
> 

Date: Sat, 25 Jul 1998 20:40:55 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Public Keyring
Sender: [email-masked]

Hi !

Just one (simple) question:

How can I figure out which UserID fits to which KeyID ?

E.g. a Public Keyring looks like this:

Public Key Packet (enthaelt keine KeyID)
Trust Packet
UserID
Trust Packet
....
Signature Packet
Trust Packet
....

I think I can't assume that any user signs his own key(s) and if so I can't
assume that it is the first signature under the key.

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: Sat, 25 Jul 1998 03:08:08 -0400
From: [email-masked]
To: Andrew Bromage <[email-masked]>
cc: [email-masked]
Subject: Re: One-pass signatures
Sender: [email-masked]

Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
headers is the proper one.  Someone check the syntax again.

The nesting is important.  For a one-pass implementation, it makes it hard
if you have to check every onepass to see if it was NESTED - see the
discussion of the nested octed in 1pass sig header packets. That is the
major headache since only nonnested signatures could be moved around
anyway.  The moment the signatures are nested (i.e this signature includes
the following one-pass packet through the signature at the end), order is
critical. 

Syntactically, it is similar to a do { ... } while(...); in C - the do
says to look for a while.

And if you do a onepass implementation like I do (the whole reason for
having 1pass sig headers), it works better if you can create a stack and
simply note the nesting level, then pop each context off the stack as its
corresponding signature appears.

Further, you might have to test more than one signature - keyids aren't
guarnteed to be unique.

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

From: Andrew Bromage <[email-masked]>
Subject: One-pass signatures
To: [email-masked]
Date: Sat, 25 Jul 1998 09:33:10 +1000 (EST)
Sender: [email-masked]

G'day all.

The grammar in section 10.2 seems to suggest that multiple one-pass
signature packets should appear in reverse order to their corresponding
signature packets.

Which of the following "messages" are be syntactically valid?

    1) Suggested by the grammar in section 10.2 ("pure nesting"):

	<O-P Signature Packet #1>
	<O-P Signature Packet #2>
	<O-P Signature Packet #3>
	<Literal Data Packet>
	<Signature Packet #3>
	<Signature Packet #2>
	<Signature Packet #1>

    2) Common sense suggests that most implementations would produce:

	<O-P Signature Packet #1>
	<O-P Signature Packet #2>
	<O-P Signature Packet #3>
	<Literal Data Packet>
	<Signature Packet #1>
	<Signature Packet #2>
	<Signature Packet #3>

    3) If we're allowing a free-for-all on ordering:

	<O-P Signature Packet #1>
	<O-P Signature Packet #2>
	<O-P Signature Packet #3>
	<Literal Data Packet>
	<Signature Packet #1>
	<Signature Packet #3>
	<Signature Packet #2>

    4) Strictly grammatically correct under section 10.2, semantically
    dodgy:

	<O-P Signature Packet #1>
	<O-P Signature Packet #2>
	<Compressed Data Packet containing:
		<O-P Signature Packet #3>
		<Literal Data Packet>
		<Signature Packet #1>
	>
	<Signature Packet #3>
	<Signature Packet #2>

My suggestion is that 1, 2 and 3 all make sense and an implementation
should accept them.  The obvious way to allow 1, 2 and 3 (collect
signatures to be computed, compute them when you hit the literal data,
play "match-up" as you find the corresponding signature packets) would
also accept 4, so I'd be happy to say that a robust implmentation MUST
(SHOULD?) accept it.

That's for accepting messages.  What about producing them?

Cheers,
Andrew Bromage

From: Ian Brown <[email-masked]>
To: ietf-open-pgp <[email-masked]>
Subject: Repeated paragraph
Date: Fri, 24 Jul 1998 15:15:23 +0100
Sender: [email-masked]

5.2.3.14. Revocation key

   (1 octet of class, 1 octet of algid, 20 octets of fingerprint)

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set, other bits are for future
   expansion to other kinds of signature authorizations. This is found
   on a self-signature.

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set. If the bit 0x40 is set,
   then this means that the revocation information is sensitive.
   Other  bits are for future expansion to other kinds of authorizations.
   This is found on a self-signature.

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 24 Jul 1998 07:06:42 -0500
To: Christian Kanja <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: nt implementations
Sender: [email-masked]

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

In <[email-masked]>, on
07/22/98 
   at 12:56 PM, Christian Kanja <[email-masked]> said:

>hi,

>does anyone know who is actualy developing an implementation of openPGP
>for compiling into a win32-dll for windows nt or to integrate as a
>library into own dll's?

>if this is not for public intrest, please mail private, i will collect
>all information and put it on a web-site.

I am developing a cross-platform OpenPGP Toolkit. It will support OS/2,
Win32, Win16, Dos, and various flavors of *nix. I am using Watcom for the
OS/2 & M$ platforms and gcc for the *nix & OS/2 platforms.

- -- 
- ---------------------------------------------------------------
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?

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 24 Jul 1998 07:00:25 -0500
To: [email-masked]
Cc: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Subject: Re: KeyId subpackets
Sender: [email-masked]

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

In <[email-masked]>, on 07/23/98 
   at 07:07 PM, [email-masked] said:

>Would it be ambiguous if a false keyid appeared in the unhashed section?
>If one did appear, but was fake, do you say the signature is actually bad
>when the hash corresponds (first two octets), and matches another key on
>your ring?

Well unless you check every public key in the users keyring you would
never know if another key would verify the signature or not. Since it is
doubtful that anyone is going to do this in their implementations I would
have to say if it has a fake keyID in the sig the sig is to be considered
invalid.

- -- 
- ---------------------------------------------------------------
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: Double your drive space! Delete Windows!

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 24 Jul 1998 07:05:30 -0500
To: Andrew Bromage <[email-masked]>
Cc: [email-masked]
Subject: Re: Another typo in draft-06
Sender: [email-masked]

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

In <[email-masked]>, on 07/24/98 
   at 09:53 AM, Andrew Bromage <[email-masked]> said:

>I dread to think what a pubic key is...

It unlocks a chastity belt. :)

- -- 
- ---------------------------------------------------------------
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: Get OS/2 - the best Windows tip around!

From: Ian Brown <[email-masked]>
To: dontspam-tzeruch <[email-masked]>, Hal Finney <[email-masked]>
Cc: ietf-open-pgp <[email-masked]>
Subject: Re: KeyId subpackets
Date: Fri, 24 Jul 1998 10:20:32 +0100
Sender: [email-masked]

OK, it's not important security-wise where the hash goes, but I think we at least need to make up our minds and adjust the draft if necessary.

If it goes in the hashed area, as Tom says, it saves having to look at the unhashed area at all (for whatever reason); but until PGP changed their software and everyone with V4 keys upgraded and rewrote them out and updated the keyservers, we would have a lot of confused software...

Ian.

From: Andrew Bromage <[email-masked]>
Subject: Another typo in draft-06
To: [email-masked]
Date: Fri, 24 Jul 1998 15:53:19 +1000 (EST)
Sender: [email-masked]

Section 10.2, page 48:

   ESK :- Pubic Key Encrypted Session Key Packet |
          ^^^^^
Should read:

   ESK :- Public Key Encrypted Session Key Packet |
          ^^^^^^
I dread to think what a pubic key is...

Cheers,
Andrew Bromage

Date: Thu, 23 Jul 1998 17:58:03 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: KeyId subpackets
Cc: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:
> I know that many drafts ago, there was nothing that needed to be included,
> and I pointed out that the Keyid and Signature Creation time (which are in
> all V3 sigs) should be a MUST, and the time MUST be in the hashed area,
> But I don't think I said the KeyID needed to be in the hashed area, only
> that it needed to be there. 
>
> Though I think someone else pointed out that it might be possible to find
> (or generate) a key with the 64 bit ID that when combined might match the
> two bytes of hash and the signature or something like that, and instead of
> anyone knowledgable investigation, it was decided to move it into the
> hashed area.

I don't think there is actually an attack here.  The only significance of
putting the keyid in the unhashed region is that a third party could change
the keyid without breaking the signature.  But the only key which will
verify the signature is the correct one.  He can't keep the signature
verifying unless he leaves the keyid alone.

If an attacker does change the keyid, all he can do is point at a
different key which won't verify the signature.  But he could do that just
as easily even if the keyid were in the hashed portion - the signature
would still not be verified by the key selected by the altered keyid.

> Would it be ambiguous if a false keyid appeared in the unhashed section?
> If one did appear, but was fake, do you say the signature is actually bad
> when the hash corresponds (first two octets), and matches another key on
> your ring?

It is difficult in general to determine the reason when a signature
doesn't verify.  It could be that you've got the wrong key, or it could
be that the data has been altered (or both).  Technically there is no
way to distinguish these.  I don't think moving the keyid into or out
of the hashed region will help with this.

Hal

Date: Thu, 23 Jul 1998 20:07:17 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: KeyId subpackets
Sender: [email-masked]

On Thu, 23 Jul 1998, Hal Finney wrote:

> I had not noticed that the spec required the issuer keyid to be in the
> hashed area.  PGP 5.X has always put it in the unhashed area.  The theory
> is that this is advisory information to help the software find the key
> which issued the signature.  In some applications it may not be necessary,
> such as for an embedded system which has hardwired keys.  There is no
> security reason to put it in the hashed area.
> 
> Can we change this in the draft or is it too late?

I know that many drafts ago, there was nothing that needed to be included,
and I pointed out that the Keyid and Signature Creation time (which are in
all V3 sigs) should be a MUST, and the time MUST be in the hashed area,
But I don't think I said the KeyID needed to be in the hashed area, only
that it needed to be there. 

Though I think someone else pointed out that it might be possible to find
(or generate) a key with the 64 bit ID that when combined might match the
two bytes of hash and the signature or something like that, and instead of
anyone knowledgable investigation, it was decided to move it into the
hashed area.

There are lots of extra things being hashed, so total time is minimally
affected by hashing 8 extra bytes (every uSec is sacred/ every uSec is
great...?) and it is easier to only have to search one area for both time
and key - the system could simply skip over the unhashed area entirely.

I am neutral on the spec change (except that the keyid MUST appear, it may
appear either place).  Technically it doesn't have to appear for 1pass
signatures, but it avoids having to add a memory, and provides a check on
the layering.  Wildcard key support is not a MUST (which would imply a
keyid of zero, not absence, and I think this is for encryption).  If you
remove keyids entirely, you might need to download the entire database
from a keyserver and check each one to see if it matches - not a fast
process. 

It is reasonable to have wildcard keys for encryption since you only have
a small number of secret keys to test.  But for signatures it creates
problems.

Would it be ambiguous if a false keyid appeared in the unhashed section?
If one did appear, but was fake, do you say the signature is actually bad
when the hash corresponds (first two octets), and matches another key on
your ring?

Date: Thu, 23 Jul 1998 10:30:56 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: KeyId subpackets
Sender: [email-masked]

I had not noticed that the spec required the issuer keyid to be in the
hashed area.  PGP 5.X has always put it in the unhashed area.  The theory
is that this is advisory information to help the software find the key
which issued the signature.  In some applications it may not be necessary,
such as for an embedded system which has hardwired keys.  There is no
security reason to put it in the hashed area.

Can we change this in the draft or is it too late?

Hal

From: Ian Brown <[email-masked]>
To: ietf-open-pgp <[email-masked]>
Subject: Length specifiers
Date: Thu, 23 Jul 1998 18:06:35 +0100
Sender: [email-masked]

One tiny change needed in section 4.2.2.4?

"Another length header (of one of the three types -- one octet, two-octet, or partial) follows that portion."

Should this be:

"Another length header (of one of the four types -- one octet, two-octet, five-octet or partial) follows that portion."

Ian.

From: Ian Brown <[email-masked]>
To: ietf-open-pgp <[email-masked]>
Subject: KeyId subpackets
Date: Thu, 23 Jul 1998 16:43:42 +0100
Sender: [email-masked]

I generated the following test V4 private key with PGP 5.5i (passphrase test). The draft says:
--
 5.2.3.4. Issuer

   (8 octet key ID)

   The OpenPGP key ID of the key issuing the signature.

   MUST be present in the hashed area.
--
But PGP seems to have put the key ID subpacket in the unhashed area. Am I just going mad, or does this need to go in the "Implementation nits" section?

Ian.

From: "Cypherlist-Watch Owner" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "William H. Geiger III" <[email-masked]>
Date: Wed, 22 Jul 1998 13:27:38 -0500
Reply-To: "Cypherlist-Watch Owner" <[email-masked]>
Subject: Re: ElGamal Reference Paper
Sender: [email-masked]

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

On Wed, 22 Jul 1998 10:33:30 -0500, William H. Geiger III wrote:

> Does anyone know where I can obtain an online reference paper on 
> ElGamal?

Are these of any use?

T. ElGamal. A public-key cryptosystem and a signature scheme based on
discrete logarithms. IEEE Transactions on Information Theory, 
IT-31: 469-472, 1985
.
T. ElGamal. Commerce on the Internet. Version 1.00, Netscape
Communications Corporation, Mountain View, CA, July 14, 1995.
<http://www.netscape.com/newsref/std/credit.html>

Regards

Mark

From: Christian Kanja <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: nt implementations
Date: Wed, 22 Jul 1998 19:56:31 +0200
Sender: [email-masked]

hi,

does anyone know who is actualy developing an implementation of openPGP
for compiling into a win32-dll for windows nt or to integrate as a
library into own dll's?

if this is not for public intrest, please mail private, i will collect
all information and put it on a web-site.

best regards, christian kanja

==================================================================
 christian kanja (mailto:[email-masked])

 bernardstrasse 112, d-63067 offenbach, germany
 phone +49 69 800706 0, fax +49 69 800706 66
 web http://www.glueckkanja.de

==================================================================
 pgp-key information for secure e-mail (complete key on web-page)  
 id 0x6877B9AF size 2048/1024 type DH/DSS 
 fp C957 9B72 B307 0963 13AD  238A 287C 3BA8 6877 B9AF
==================================================================
 someone is reading your e-mail - use cryptography for protection
==================================================================

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 22 Jul 1998 10:33:30 -0500
To: [email-masked]
Subject: ElGamal Reference Paper
Sender: [email-masked]

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

Hi,

Does anyone know where I can obtain an online reference paper on ElGamal?

I have managed compile a collection of papers for all the algorithms used
in OpenPGP except ElGamal! I have spent all weekend doing various searches
but have yet to be able to find any such documentation.

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: I smashed a Window and saw... OS/2.

Date: Tue, 21 Jul 1998 11:35:13 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Fwd: 42nd IETF-CHICAGO, IL: OPENPGP
Sender: [email-masked]

>Date: Tue, 21 Jul 1998 12:21:41 -0400
>To: "John  W. Noerenberg" <jwn2>
>From: Marcia Beaulieu <[email-masked]>
>Subject: 42nd IETF-CHICAGO, IL: OPENPGP
>Cc: [email-masked], [email-masked]
>Mime-Version: 1.0
>
>This is to confirm one session for OPENPGP as follows:
>
>	Friday, August 28 at 0900-1130
>		other groups scheduled at that time: adslmib, tcpsat
>

Here's our meeting in Chicago.
john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

Date: Mon, 20 Jul 1998 18:02:12 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Sig-only weasel words
Sender: [email-masked]

Here's what I've come up with. This would be the last subsection of section
2 -- section 2.5. If you don't like this, suggest an alternative, or
suggest that we say nothing.

	Jon

.head 2 Signature-Only Applications

OpenPGP is designed for applications that use both encryption and
signatures, but there are a number of problems that are solved by a
signature-only implementation. Although this specification requires both
encryption and signatures, it is reasonable for there to be subset
implementations that are non-comformant only in that they omit encryption.

Date: Mon, 20 Jul 1998 12:15:23 -0700
To: [email-masked], Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: opgp99s.tgz - update, final call
Cc: [email-masked]
Sender: [email-masked]

At 06:57 AM 7/20/98 -0400, [email-masked] wrote:

   And doesn't the new way of computing KeyIDs hash the algorithm ID number
   in with the key material?  Then the same ElGamal key with two different
   AlgIDs would have two different KeyIDs.
   
   So if you mix and match, you will create the same problem with V3 v.s. V4
   RSA keys, or that same keys with different dates will have different IDs.
   
A possible solution is to use the same Elgamal key material in two separate
keys -- an encrypt-only key and an encrypt+sign key. While this adds a bit
of bloat, it will work correctly. As Tom noted above, the two keys will
have different fingerprints.

One of the issues to consider in an implementation is what to permit a key
to do. It is a good idea, in general, to use a given key for encryption or
signing, but not both. I can think of instances where the general case can
be noted, and then we go on to do both, but these are for special-purpose,
embedded systems. A general-purpose system should separate usages, to my mind.

An encrypt+sign Elgamal key *can* be used for both, but that doesn't mean
that it *should* be used for both. Similarly, an RSA key can be used for
both, but it makes sense for an OpenPGP system that wants to use RSA keys
to have a top-level RSA key used only for signing, and an RSA subkey used
only for encryption. I'll even go so far as to opine that an OpenPGP system
ought to use the "key flags" subpacket on all RSA or Elgmal E+S keys to
explicitly state the owner's policy.

	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, 20 Jul 1998 12:22:27 -0700
To: [email-masked], Hal Finney <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: opgp99s.tgz - update, final call
Cc: [email-masked]
Sender: [email-masked]

At 10:51 PM 7/18/98 -0400, [email-masked] wrote:

   If I may suggest, you might want to elaborate on the "implementation nits" 
   section in the spec, particularly with regards to 5.5.  It would be good
   to know what parts of OpenPGP will work with what is already out there and
   what will not.
   
Done. There's a nit that says neither PGP 5.x nor 6.0 handle the EGE+S keys.

	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, 20 Jul 1998 11:32:43 -0700
To: Andrew Bromage <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Corrections in latest draft
Sender: [email-masked]

Corrections made. 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)

Date: Mon, 20 Jul 1998 06:57:24 -0400
From: [email-masked]
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

On Mon, 20 Jul 1998, Werner Koch wrote:

> > alg id in the ESK packet will prevent it from finding your keys.
> 
> Sorry, I noticed myself that it will not work (I should enable my
> brain before posting).  Okay, okay, I'll make 17,16 the default
> algorithms.

And doesn't the new way of computing KeyIDs hash the algorithm ID number
in with the key material?  Then the same ElGamal key with two different
AlgIDs would have two different KeyIDs.

So if you mix and match, you will create the same problem with V3 v.s. V4
RSA keys, or that same keys with different dates will have different IDs.

(Using the hash was a good idea for the new keyid, hashing anything more
than the MPIs probably was not).

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

Date: Mon, 20 Jul 1998 09:54:42 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hal Finney <[email-masked]> writes:

> This won't work with PGP 5.X.  It uses the algorithm identifier in the key
> packet to determine what kind of key it is.  It also uses a combination
> of the key id and the alg id internally to index keys, so changing the

gnupg does the same.

> alg id in the ESK packet will prevent it from finding your keys.

Sorry, I noticed myself that it will not work (I should enable my
brain before posting).  Okay, okay, I'll make 17,16 the default
algorithms.

Werner 

From: Andrew Bromage <[email-masked]>
Subject: Corrections in latest draft
To: [email-masked]
Date: Mon, 20 Jul 1998 17:50:27 +1000 (EST)
Sender: [email-masked]

Section 4.3, page 14:

       14       -- Subkey Packet

should read:

       14       -- Public Subkey Packet
                   ^^^^^^

Section 5.2.3.13, page 24:

                                               Only signatures by the
   target key on user IDs that match the regular expression in the body
   of this packet have trust extended by the trust packet.
                                             ^^^^^^^^^^^^

should read:

                                               Only signatures by the
   target key on user IDs that match the regular expression in the body
   of this packet have trust extended by the trust signature subpacket.
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^

Date: Sun, 19 Jul 1998 07:42:45 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

> The default key is a DSA primary key with an ElGamal key used for
> encryption (but this one has the id 20 and not 16 - so it MAY be used
> for signatures).  Never mind, I#ll put 16 into the encrypted packets
> even for keys which have 20 as algorithm identifier.

This won't work with PGP 5.X.  It uses the algorithm identifier in the key
packet to determine what kind of key it is.  It also uses a combination
of the key id and the alg id internally to index keys, so changing the
alg id in the ESK packet will prevent it from finding your keys.

Hal

Date: Sun, 19 Jul 1998 10:55:53 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> And will your implmentation correctly process all combinations of all
> algorithms?  This is really hard to get right, and it is better not to
> support something than to support it badly or incorrectly.

I#m not talking about ElGamal signatures. But due to the fact that
gnupg ElGamal keys may be used for signatures I assign them the 20.

The default key is a DSA primary key with an ElGamal key used for
encryption (but this one has the id 20 and not 16 - so it MAY be used
for signatures).  Never mind, I#ll put 16 into the encrypted packets
even for keys which have 20 as algorithm identifier.

Werner 

Date: Sat, 18 Jul 1998 22:51:10 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

On Sat, 18 Jul 1998, Hal Finney wrote:

> One of my goals is to prepare a document describing which optional
> OpenPGP features PGP 6.0 will support, in time for the release of that
> product, which will be in some months.
> 
> Hal

If I may suggest, you might want to elaborate on the "implementation nits" 
section in the spec, particularly with regards to 5.5.  It would be good
to know what parts of OpenPGP will work with what is already out there and
what will not.

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

Date: Sat, 18 Jul 1998 22:45:51 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

On Sat, 18 Jul 1998, Werner Koch wrote:

> Hal Finney <[email-masked]> writes:
> 
> > No PGP 5.x version will support "identifier 20" ElGamal keys for
> > decryption or signature verification.  Neither does the forthcoming
>   ^^^^^^^^^^
> 
> So PGP is not able to decrypt a valid OpenPGP message, tsss...

And will your implmentation correctly process all combinations of all
algorithms?  This is really hard to get right, and it is better not to
support something than to support it badly or incorrectly.

One of the reasons there are preferred algorithm lists is to allow for
this type of thing.  RSA is a not a MAY but a SHOULD, but I don't think
every implementation will allow for it.  If you sign with
RIPEMD-160/ElGamal, compress with zip/15bit, encrypt with SAFER/RSA, not a
lot of things are going to be able to read it regardless of whether or not
it is "valid".  You should take a look at what SSL implmementations have
to go through in their negotiation.  And Email doesn't have that luxury.

It doesn't make much sense to implement MAYs before SHOULDs, at least not
if you want to interoperate.  Nor is it reasonable to expect keyservers to
allow for MAY algorithm keys (even if they don't verify the keys
themselves).  Everyone is going to do DSA, and most will do RSA.  And I
hope ElGamal is superceeded by something better, and probably should have
been marked reserved in this spec.  The technical arguments are valid, but
no one proposed any alternatives, and we need an alternative to RSA and
DSA (the former is encumbered, and the latter is restricted in size).

And there are lots of new things which PGP isn't (and probably won't be) 
able to properly handle.  V4 Signatures and V4 RSA keys aren't in the old
PGP, and I don't know what 6.0 is planned to do.  The old one requires
SHA1 for DSA, but the OpenPGP spec would allow for RIPEMD-160. 

Even my implementation which is designed as a library has lots of things
which it won't do without any additions.  This is intentional since
interoperability is the primary goal.

It doesn't make sense for a commercial product to implement everything
possible to implement.  All it does is bloat and complicate the code,
which is bad if code integrity is important.  And it is important in any
privacy software.

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

Date: Sat, 18 Jul 1998 15:07:57 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
> Hal Finney <[email-masked]> writes:
>
> > No PGP 5.x version will support "identifier 20" ElGamal keys for
> > decryption or signature verification.  Neither does the forthcoming
>   ^^^^^^^^^^
>
> So PGP is not able to decrypt a valid OpenPGP message, tsss...

You should not assume that an OpenPGP compliant implementation will
be able to handle all optional features.

One of my goals is to prepare a document describing which optional
OpenPGP features PGP 6.0 will support, in time for the release of that
product, which will be in some months.

Hal

Date: Sat, 18 Jul 1998 16:31:13 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: "John  W. Noerenberg" <[email-masked]>
cc: OpenPGP mailing list <[email-masked]>
Subject: Re: IETF August meeting -- aiming at Friday
Sender: [email-masked]

On Fri, 17 Jul 1998, John  W. Noerenberg wrote:

> Based on the feedback to this note, I'm requesting a slot for Friday
> morning but not to conflict with PGPTicket.  I was going to be there all
> week, anyway...

PGPticket is not a factor. We were refused the BOF request for a number of
reasons (mainly, contention for space by those that are planning on forming
a working group.) However, if anyone involved with PGP is interested in
talking about PGPticket, it might be fun to organize a lunch or dinner
group to discuss it earlier in the week sometime. If there is any interest
by individuals in this group, please email me.

> best,

> john noerenberg
> [email-masked]
>   ----------------------------------------------------------------------
>   --if we are to be saved, it will not be by Romans but by saints.
>   -- Thomas Cahill, "how the Irish Saved Civilization", 1995
>   ----------------------------------------------------------------------

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

Date: Sat, 18 Jul 1998 22:02:55 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hal Finney <[email-masked]> writes:

> No PGP 5.x version will support "identifier 20" ElGamal keys for
> decryption or signature verification.  Neither does the forthcoming
  ^^^^^^^^^^

So PGP is not able to decrypt a valid OpenPGP message, tsss...

Werner        

Date: Sat, 18 Jul 1998 12:21:55 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
> BTW, is there a PGP 5.x version which can cope with 20 (decrypt
> messages which are encrypted with such an ElGamal key)?

No PGP 5.x version will support "identifier 20" ElGamal keys for
decryption or signature verification.  Neither does the forthcoming
PGP 6.0.  I don't know if support will be added to any later version.

Hal

Date: Sat, 18 Jul 1998 13:54:40 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: opgp99s.tgz - update, final call
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> in later).  ElGamal Signatures are DISABLED by default and only processed
> if the Algorithm ID is 20 (16 used to work since this was what was

BTW, is there a PGP 5.x version which can cope with 20 (decrypt
messages which are encrypted with such an ElGamal key)?

Werner

Date: Sat, 18 Jul 1998 00:22:44 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp99s.tgz - update, final call
Sender: [email-masked]

I uploaded this latest version.  It corrects the code to be in sync with
the current (final call) spec as far as I can determine.  HAVAL and TIGER
support have been removed, and algorithms adjusted (they can be added back
in later).  ElGamal Signatures are DISABLED by default and only processed
if the Algorithm ID is 20 (16 used to work since this was what was
assigned if you turned it on in PGP 5.0).  This is the only MAY algorithm
which is disabled by default, but you can read the source if you want to
turn it on, and it may be superceeded in 1.1 - which is why I don't want
it enabled.

PalmIII files have been removed (until I can update that branch and
verify it, and will be in the final release).

This has not been tested except on i386 Linux.

I plan on testing as much as possible before I declare it to be 1.0.  If
anyone else knows of any problems, suggestions, or comments you need to
speak up now.

Date: Fri, 17 Jul 1998 18:13:30 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Sign Only implimenation.
Sender: [email-masked]

>Opinions? I think he's got a good point and am ashamed that I overlooked
>this myself, but is there a way to fix this at this late date?

Not easily, from my reading of the current draft. I think a note at the
beginning saying "this spec requires both signing and encryption
capabilities, but there are likely to be applications that only do one or
the other" is probably the cleanest way to go.

It's not like a signing-only application is going to get rejected because
it is non-conformant because it doesn't encrypt...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 17 Jul 1998 17:48:20 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: IETF August meeting -- aiming at Friday
Sender: [email-masked]

Based on the feedback to this note, I'm requesting a slot for Friday
morning but not to conflict with PGPTicket.  I was going to be there all
week, anyway...

best,

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

Date: Fri, 17 Jul 1998 19:40:05 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Sign Only implimenation.
Sender: [email-masked]

On Fri, 17 Jul 1998, Jon Callas wrote:

> At 10:32 AM 7/17/98 +1000, ? the Platypus {aka David Formosa} wrote:
>    
>    >From my reading the OpenPGP requires both encryption and digital
>    signatures.  However for some applications authenication without
>    encryption is needed, would it be possable to alter the wording to allow
>    signature only implimenations?
>    
> Opinions? I think he's got a good point and am ashamed that I overlooked
> this myself, but is there a way to fix this at this late date?

DH is a MUST implying that encryption is a MUST, though it doesn't
strictly say this.  I could take it as "IF encryption is implemented, DH
is a MUST".  Or just add (in the general section) implementations MUST do
signatures, they SHOULD do encryption.

OTOH, I can see where a compliant implementation MUST do both.  If you
have something like a time stamper, it need not, but that is the
application (i.e. if you linked with my library statically, you would not
pull in the encryption and decryption routines).

It also goes deeper.  There are implicit and explicit preferences.  We
don't have anything that says "CAN'T" for a preferred encryption
algorithm, so how do you create a signature that says this?  (it does say
that zero, the plain text algorithm isn't to be used).  For this reason we
probably don't want to alter the current wording.

An implementation that does no encryption because it is the nature of the
application could be considered compliant.  But I would still consider an
application that was sign/verify-only for something like email as being
non-compliant.  People are free to use an "OpenPGP compatible/compliant"
format even if the implementation as a whole isn't.

So for now, I would want to leave things as they are.  (and maybe start an
Open Pretty-Good-Authentication discussion).

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

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 17 Jul 1998 18:18:40 -0500
To: Jon Callas <[email-masked]>
Cc: ? the Platypus {aka David Formosa} <[email-masked]>, [email-masked]
Subject: Re: Sign Only implimenation.
Sender: [email-masked]

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

In <[email-masked]>, on 07/17/98 
   at 03:22 PM, Jon Callas <[email-masked]> said:

>At 10:32 AM 7/17/98 +1000, ? the Platypus {aka David Formosa} wrote:
>   
>   >From my reading the OpenPGP requires both encryption and digital
>   signatures.  However for some applications authenication without
>   encryption is needed, would it be possable to alter the wording to
>allow
>   signature only implimenations?
>   
>Opinions? I think he's got a good point and am ashamed that I overlooked
>this myself, but is there a way to fix this at this late date?

I don't have a problem with the change, seems logical to me.

- -- 
- ---------------------------------------------------------------
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: He who laughs last uses OS/2.

Date: Fri, 17 Jul 1998 15:22:49 -0700
To: ? the Platypus {aka David Formosa} <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Sign Only implimenation.
Sender: [email-masked]

At 10:32 AM 7/17/98 +1000, ? the Platypus {aka David Formosa} wrote:
   
   >From my reading the OpenPGP requires both encryption and digital
   signatures.  However for some applications authenication without
   encryption is needed, would it be possable to alter the wording to allow
   signature only implimenations?
   
Opinions? I think he's got a good point and am ashamed that I overlooked
this myself, but is there a way to fix this at this late date?

	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: Fri, 17 Jul 1998 14:56:53 -0700
To: Hal Finney <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: What this WG is doing
Sender: [email-masked]

I know somone who started using PGP a couple of years ago, and tried using
the MIT key server, and could not upload their key because of a keyid
collision. This being a new user, they just made a new 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)

Date: Fri, 17 Jul 1998 14:07:42 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

Actually someone has already published an intentionally created 64 bit
keyid collision.  Presumably he did in fact generate about 2^32 keys.
It is made easier by the fact that generating a DSS key is just a matter
of doing g^x mod p for a bunch of different x's.  So in fact you can generate
a series of keys simply by repeatedly multiplying g^x by g to get g^(x+1).
The hash which generates the keyid has the same prefix and so only the
g^x part varies, making the search exceptionally fast.

This will not allow you to make a keyid which matches someone else's, as
that is 2^64 work, a whole nother kettle of fish.  But generating pairs
which have the same 64 bit keyid is very tractable.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 17 Jul 1998 14:10:04 -0500
To: [email-masked]
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

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

In <[email-masked]>, on 07/17/98 
   at 01:08 PM, [email-masked] said:

>>* Lindsay Mathieson wrote:
>>>As far as I understand it, it is impossible to guarantee a unique Key ID &
>>>fingerprint, as they are hash's of the key material, which implies the
>>>possibility of a hash collision, highly unlikely maybe, but still possible.

>I'd call 2**-128 impossible, and 2**-64 birthday collisions close to
>impossible. But 64-bit KeyIDs lead to birthday collisions with about
>2**32 keys, which _will_ happen, and then there's the problem of the user
>interfaces (at least on the key servers) only showing the user 32 bits of
>key instead of 64 (which is not only susceptible to birthday collisions
>but 0xdeadbeef attacks, though they're less useful than they used to be.) 
>Keyservers especially need to be able to cope with duplicates.

>At 02:35 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
>>That's why my proposal causing this controversy was/is to define it not unique.

>Sounds good.

Hi Bill,

Replying to a year old post? Took me a while to dig up the reference
articles :)

I think that it is quite obvious that any large scale PGP DB will need to
implement local UID's for all of the keys and use that for reference. The
only other alternative would be to deny duplicate keyid's into the
database.

Inbound processing is not that much of a problem as one just check all
matching keyid's until one is found that verifies the signature. It would
probably be a good idea to flag any duplicate keyid's in the DB and make
mention of that to the user whenever that key is used.

Where things get interesting is in the outbound processing. :)

The best way to handle this is with the use of a default key table. Now
first off it is my strong opinion that a table is required that links
e-mail addresses to specific keys. This is to resolve conflicts that arise
when:

- -- More than one key has the same userID
- -- e-mail address used is not contained a userID for the corresponding key

I also use this table for listing address that should not be encrypted
ever. This is mostly for mailing list addresses.

I also list addresses where addresses should not be signed. This is mostly
for majordomo's and such that get upset if PGP sigs are in the body of a
message.

I am also working on a remailer interface so I will be adding a flag to
the e-mail addresses where all messages to that address should go through
a remailer chain or should not if the user has his system set to send
everything through a remailer chain.

AFAIK I am the only one who is addressing these issues in their software.

Currently my links between e-mail address and keys are based on the 64bit
keyid as I do not allow duplicate keyid's at this time. This can easily be
expanded to allow the handling of duplicate keyid's by linking to UID's
rather than the KeyID.

I also plan on using this table for allowing the end-user to override the
default flags in the public key self sigs (don't worry this is just for
the power users not the average joe sixpack who are only concerned with
point 'n click).

- -- 
- ---------------------------------------------------------------
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: Turn your 486 into a Gameboy: Type WIN at C:\>

From: [email-masked]
Date: Fri, 17 Jul 1998 11:08:08 -0700
To: [email-masked] (Lutz Donnerhacke), [email-masked]
Original-From: Bill Stewart <[email-masked]>
Subject: Re: What this WG is doing
Sender: [email-masked]

>* Lindsay Mathieson wrote:
>>As far as I understand it, it is impossible to guarantee a unique Key ID &
>>fingerprint, as they are hash's of the key material, which implies the
>>possibility of a hash collision, highly unlikely maybe, but still possible.

I'd call 2**-128 impossible, and 2**-64 birthday collisions close to impossible.
But 64-bit KeyIDs lead to birthday collisions with about 2**32 keys,
which _will_ happen, and then there's the problem of the user interfaces
(at least on the key servers) only showing the user 32 bits of key instead of 64
(which is not only susceptible to birthday collisions but 0xdeadbeef attacks,
though they're less useful than they used to be.)  Keyservers especially
need to be able to cope with duplicates.

At 02:35 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
>That's why my proposal causing this controversy was/is to define it not unique.

Sounds good.

Date: Fri, 17 Jul 1998 10:32:05 +1000 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
To: [email-masked]
Subject: Sign Only implimenation.
Sender: [email-masked]

>From my reading the OpenPGP requires both encryption and digital
signatures.  However for some applications authenication without
encryption is needed, would it be possable to alter the wording to allow
signature only implimenations?

Please excuse my spelling as I suffer from agraphia; see the url. Support NoCeM
http://www.cit.nepean.uws.edu.au/~dformosa/Spelling.html  http://www.cm.org/ 
I'm sorry but I just don't consider 'because its yucky' a convincing argument

Date: Fri, 17 Jul 1998 00:04:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: about MDCs etc (Re: Long Holiday?)
Sender: [email-masked]

Jon writes:
> Signatures are different because there's a meaningful thing to do -- emit
> plaintext, and shrug over the sig -- which is a little different than the
> crypto, or compression, or whatever. But nonetheless, there are many
> failure and partial failure conditions, and an implementation that doesn't
> fail gracefully is broken.

note that pgp2.x suffers from this very problem.  this means that I
get messages from pgp5.x users which decrypt ok, but then fail to
display because of I think a DSS sig, so I have to dig out a unix
command line version of 5.x.

> This spec isn't a how-to-program manual, it's a format specification. By
> necessity it tells you a lot of what to do with the format, but there's a
> lot that this document can't tell an implementor.

just trying to avoid a repeat.

Adam

Date: Thu, 16 Jul 1998 11:03:03 -0700 (PDT)
From: Gene Tsudik <[email-masked]>
To: [email-masked]
Subject: ACM CCCS'98: Preliminary Program and Call for Participation
Sender: [email-masked]

Subject: ACM CCCS'98: Preliminary Program and Call for Participation 

			     
			     Preliminary Program

                          Fifth ACM Conference on
                    Computer and Communications Security

                          San Francisco, California
                             November 2-5, 1998
                           Sponsored by ACM SIGSAC

	For more information visit http://www.research.att.com/~reiter/ccs5

        Launched in 1993, ACM CCCS is the ACM's flagship security conference. 
        CCCS covers a wide range of topics in computer/information security
        and offers a technical as well as a tutorial program. Presentation
	topics are diverse, addressing state-of-the-art results of both 
	practical and theoretical nature (and everything in between).

================================= DAY 0 =================================== 
 
 Monday, November 2, 1998: Tutorials

                    Core Topics                  Emerging Topics

  9:00-12:30 Cryptography: Theory and   Programming Languages and Security
             Applications               Martin Abadi (DEC Systems Research
             Dan Boneh (Stanford        Center, USA) and George Necula
             University, USA)           (Carnegie Mellon University, USA)

 12:30-13:30 Lunch

 13:30-17:00 To Be Determined           Authentication Protocol Verification
                                        and Analysis Jon Millen 
					(SRI International, USA)

================================= DAY 1 =================================== 

 Tuesday, November 3, 1998: Technical sessions

 9:00-10:00 Keynote address
            Risks and challenges in computer-communication infrastructures
            Peter G. Neumann (SRI International, USA)

 10:00-10:30			Break

 10:30-12:00		Group key management

            Communication complexity of group key distribution
            Klaus Becker (R^3 Security Engineering, Switzerland) and Uta
            Wille (IBM Zurich Research Laboratory, Switzerland)

            Key management for encrypted broadcast
            Avishai Wool (Bell Labs, USA)

            Authenticated group key agreement and related protocols
            Giuseppe Ateniese (USC Information Sciences Institute, USA),
            Michael Steiner (IBM Zurich Research Laboratory, Switzerland),
            and Gene Tsudik (USC Information Sciences Institute, USA)

 12:00-13:30			Lunch

 13:30-15:30			Anonymity

            The design, implementation and operation of an email pseudonym server
            David Mazie`res and M. Frans Kaashoek (Massachusetts Institute
            of Technology, USA)

            Panel: Anonymity on the Internet
            Moderator: Paul Syverson (Naval Research Lab, USA)

 15:30-16:00			Break

 16:00-17:00		Mobile code security
            
	    History-based access-control for mobile code
            Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of
            California, Santa Barbara, USA)

            A specification of Java loading and bytecode verification
            Allen Goldberg (Kestrel Institute, USA)

================================= DAY 2 =================================== 

 Wednesday, November 4, 1998: Technical sessions

 9:00-10:30 		 	Cryptography

            A new public key cryptosystem based on higher residues
            David Naccache (Gemplus, France) and Jacques Stern (Ecole
            Normale Superieure, France)

            An efficient non-interactive statistical zero-knowledge proof
            system for quasi-safe prime products
            Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele
            Micciancio (Massachusetts Institute of Technology, USA), and
            Tal Rabin (IBM T.J. Watson Research Center, USA)

            Communication-efficient anonymous group identification
            Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni
            Di Crescenzo (University of California, San Diego, USA)

 10:30-11:00			Break

 11:00-12:00			Invited talk

            The development of public key cryptography
            Martin Hellman

 12:00-13:30			Lunch

 13:30-15:00			Systems

            A security architecture for computational grids
            Ian Foster (Argonne National Laboratory, USA), Carl Kesselman,
            Gene Tsudik (USC Information Sciences Institute, USA), and
            Steven Tuecke (Argonne National Laboratory, USA)

            Design of a high-performance ATM firewall
            Jun Xu and Mukesh Singhal (Ohio State University, USA)

            A practical secure physical random bit generator
            Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs,
            USA) and Ari Juels (RSA Labs, USA)

 15:00-15:30			Break

 15:30-16:30			Invited talk

            Trust in cyberspace? A research roadmap
            Fred Schneider (Cornell University, USA)

================================= DAY 3 =================================== 

 Thursday, November 5, 1998: Technical sessions

 9:00-10:30 		Protocol design and analysis

            A probabilistic poly-time framework for protocol analysis
            Pat Lincoln (SRI International, USA), John Mitchell, Mark
            Mitchell (Stanford University, USA), and Andre Scedrov
            (University of Pennsylvania, USA)

            On using public-key cryptography in password protocols
            Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo
            Krawczyk (Technion, Israel)

            Cryptanalysis of Microsoft's point-to-point tunneling protocol
            Bruce Schneier (Counterpane Systems, USA)

 10:30-11:00			Break

 11:00-12:00			System monitoring

            How to prove where you are
            Eran Gabber and Avishai Wool (Bell Labs, USA)

            Temporal sequence learning and data reduction for anomaly detection
            Terran Lane and Carla E. Brodley (Purdue University, USA)

================== Worst paper award and author lampooning =================== 

 Steering committee chair: Ravi Sandhu, George Mason University
 General chair:            Li Gong, JavaSoft

 Program chair:            Mike Reiter
                           AT&T Labs, Room A269, 180 Park Avenue
                           Florham Park, NJ 07932-0971 USA
                           phone: +973-360-8349

 Awards chair:             Jacques Stern, ENS/DMI
 Publication chair:        Stuart Stubblebine, AT&T Labs
 Publicity chair:          Gene Tsudik, USC ISI

 Program committee:

 Martin Abadi, DEC SRC              David Naccache, Gemplus
 Bill Cheswick, Lucent/Bell Labs    Hilarie Orman, DARPA/ITO
 Carl Ellison, Cybercash            Avi Rubin, AT&T Labs--Research
 Ed Felten, Princeton University    Pierangela Samarati, Universita di Milano
 Paul Karger, IBM T.J. Watson       Gene Tsudik, USC ISI
 Steve Kent, BBN Corporation        Paul Van Oorschot, Entrust Technologies
 Ueli Maurer, ETH Zurich            Bennet Yee, UCSD
 Cathy Meadows, Naval Res. Lab      Moti Yung, CertCo

For more information, visit http://www.research.att.com/~reiter/ccs5

Date: Thu, 16 Jul 1998 11:46:09 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked], [email-masked]
Subject: PGPticket draft
Sender: [email-masked]

A new draft has been posted in the 'Individual Submissions' area of the
ietf web site.

The draft covers a technology called 'PGPticket'. This is NOT directly
related to the work of the OpenPGP group but it does involve PGP
technology. It illustrates a way of using PGP V4 standalone signatures as a
type of authentication mechanism.

Vinnie Moscaritolo of Apple Computer Corp. originated the idea and we have
co-authored this draft. We welcome any comments. The draft should be
discussed on [email-masked] rather than on the ietf-open-pgp list.

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

Date: Tue, 14 Jul 1998 17:35:02 -0700
To: Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: about MDCs etc (Re: Long Holiday?)
Cc: [email-masked]
Sender: [email-masked]

At 07:57 PM 7/14/98 +0100, Adam Back wrote:
   
   I didn't suggest that MDCs go into 1.0 in the last round.  What I
   suggested was that the following be verified:
   
   	that when processing a message containing signatures a 1.0
   	implementation MUST continue to emit plaintext (ie fail
   	gracefully) in the presence of signature algorithms it does
   	not recognise.
   
   this readily allows adding MDCs or other signature algorithms in
   version 1.1, and ensures backwards compatibility is possible.
   
Sure, but I don't think we need to add anything. If someone writes an
implementation that (for instance) bus errors when it receives an algorithm
encrypted with AES (which I pick because we all know it's going to go in,
but it isn't there now), then the implementation is clearly broken. 

Signatures are different because there's a meaningful thing to do -- emit
plaintext, and shrug over the sig -- which is a little different than the
crypto, or compression, or whatever. But nonetheless, there are many
failure and partial failure conditions, and an implementation that doesn't
fail gracefully is broken.

This spec isn't a how-to-program manual, it's a format specification. By
necessity it tells you a lot of what to do with the format, but there's a
lot that this document can't tell an implementor.

	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, 14 Jul 1998 17:26:07 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: One change: 5.2.2
Cc: [email-masked]
Sender: [email-masked]

At 08:11 AM 7/14/98 -0400, [email-masked] wrote:
   in 5.2.2 in the very last paragraph it says:
   
   "DSA signatures SHOULD use hashes with a size of 160 bits, ..."
   
   needs to be changed to
   
   "DSA signatures MUST use hashes with a size of 160 bits, ..."
   
Done.

Also, I got Paul's refernece to RFC 2313 done, and a few typos.

	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, 14 Jul 1998 19:57:04 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: about MDCs etc (Re: Long Holiday?)
Sender: [email-masked]

Jon writes:
> It's too late to get MDCs into OpenPGP 1.0. We're in last call, and as good
> as an idea it is, it's too late. I'm going to have the really, really final
> one out this afternoon (I'm editing it in another window).

I didn't suggest that MDCs go into 1.0 in the last round.  What I
suggested was that the following be verified:

	that when processing a message containing signatures a 1.0
	implementation MUST continue to emit plaintext (ie fail
	gracefully) in the presence of signature algorithms it does
	not recognise.

this readily allows adding MDCs or other signature algorithms in
version 1.1, and ensures backwards compatibility is possible.

> If you can design something that is wholly backwards-compatible, it'll be
> trivial to put it in 1.1 or simple document it as an extension. Not being
> in 1.0 won't be an issue
> 
> If you can't design something backward compatible, then it's too late to go
> in 1.0. Either way, it doesn't make it.

The question of signature handling of unknown signature types is
useful in general to clarify -- it is required for backwards
compatibility if for example a wide hash based variant of DSA is
added, or whatever.

I would presume the above to be a sensible interpretation of the
current spec. in any case, but worth expressing specifically if it is
not already in the current spec, and if there is still time.

If not, well then not.

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, 14 Jul 1998 08:11:42 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: One change: 5.2.2
Sender: [email-masked]

in 5.2.2 in the very last paragraph it says:

"DSA signatures SHOULD use hashes with a size of 160 bits, ..."

needs to be changed to

"DSA signatures MUST use hashes with a size of 160 bits, ..."

Although other hashes could work, nothing in the spec defines how to
truncate longer hashes, or pad shorter hashes.  Since these details aren't
fully defined, you need to change the SHOULD to a MUST.

--- 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-06.txt
Date: Tue, 14 Jul 1998 07:48:19 -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)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-formats-06.txt
	Pages		: 59
	Date		: 13-Jul-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-06.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-06.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-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 13 Jul 1998 19:51:23 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: References nit
Sender: [email-masked]

   [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
   version 1.5, November 1993

should instead point to RFC 2313. If you can't get this in before IESG last
call, certianly put it on the list for changes after that. RSA removes old
versions of the PKCS series when they update them, as they are about to do
for PKCS 1, so version 1.5 will become unavailable soon. That's why we got
the RFCs.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Jul 98 08:59:34 PDT
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: reserved ID allocation procedure
Sender: [email-masked]

Paul Koning wrote:
> At 10:45 PM 7/8/98 +0100, Adam Back wrote:
>    This is necessary because for new algorithms, or new features etc.,
>    there may well be multiple proposals for the same algorithm.  So
>    allocating #12 to the succesful AES candidate is in itself useless,
>    because there may be 2 or 3 incompatible implementations.
>    
> There's something odd about that.
> 
> If there is one AES but 2 incompatible implementations, then either
> the standard is broken, or (at least) one implementation is.  If the
> standard is correctly specified, then implementations will be
> compatible.  
> 
> So it seems to me reasonable to assign a number to "AES" on the
> assumption that the definers of AES will do their job properly.

While I agree that implementations of the same algorithm must
give the same results, there's still a reason for multiple numbers:
AES is defined by NIST to allow different key sizes: 128 bits,
192 bits, and 256 bits.  I suppose we could standardize on the
256-bit version, just for definiteness, but perhaps it makes sense
to allow for all three expected standard sizes.

	Jim Gillogly

Date: Mon, 13 Jul 1998 11:21:19 -0400
From: Paul Koning <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: reserved ID allocation procedure
Sender: [email-masked]

At 10:45 PM 7/8/98 +0100, Adam Back wrote:
   
   It seems to me that allocating #7 for this or that which is not
   implemented yet is a good enough idea, BUT that we need someone who
   offers to act as a central clearling house to avoid collisions in IDs
   for IDs allocated between now and when work on OpenPGP 2.0 starts.
   
   This is necessary because for new algorithms, or new features etc.,
   there may well be multiple proposals for the same algorithm.  So
   allocating #12 to the succesful AES candidate is in itself useless,
   because there may be 2 or 3 incompatible implementations.
   
There's something odd about that.

If there is one AES but 2 incompatible implementations, then either
the standard is broken, or (at least) one implementation is.  If the
standard is correctly specified, then implementations will be
compatible.  

So it seems to me reasonable to assign a number to "AES" on the
assumption that the definers of AES will do their job properly.

	paul

Date: Sat, 11 Jul 1998 03:23:11 +0200 (METDST)
To: [email-masked]
From: [email-masked] (Your Home Town)
Comments: Authenticated sender is <[email-masked]>
Reply-to: [email-masked]
Subject: Your Home Town Provides Everything You Need
Sender: [email-masked]

YOUR HOME TOWN 
WILL DO 100% OF THE WORK FOR YOU

WE OFFER:
You the chance to own your own Home Based Business.

WE OFFER:
To build your Home Based Business for you.

WE OFFER
You financial independence.

WE OFFER:
You life saving and life changing products.

WE OFFER:
You the easiest way we know to, improve your Health, your
Wealth and your Happiness.

For more information Call:

Our toll free 24 hr message center  at 888-771-9338

Our toll free 24 hr recorded message at 888-771-9340.

our research showed you would be interested in this.
If this is not true <a ahref="mailto:[email-masked]">Click Here</a> and enter remove in the subject.
Thank You.

Reference # 10071098
+

Date: Fri, 10 Jul 1998 14:59:48 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Formats doc, -06 rev, ready for viewing
Sender: [email-masked]

Thank you very much, Paul.

As Paul said, he's put up -06 so everyone can look at it while the archive
editors are getting it ready.

I prepared some diffs yesterday, but things I added early in the document
(like the reference to 2119) changed all the page breaks.

This one is it, folks. I can fix typos, but that's about 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: Fri, 10 Jul 1998 14:50:33 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Formats doc, -06 rev, ready for viewing
Sender: [email-masked]

Greetings again. There is a copy of the very latest version of the formats
doc available at <http://www.imc.org/ietf-open-pgp/formats-06.txt>. This is
being posted because it will take a few days for -06 to get into the
official drafts archive.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 10 Jul 1998 14:15:38 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: reserved ID allocation procedure
Sender: [email-masked]

At 10:45 PM 7/8/98 +0100, Adam Back wrote:
   
   It seems to me that allocating #7 for this or that which is not
   implemented yet is a good enough idea, BUT that we need someone who
   offers to act as a central clearling house to avoid collisions in IDs
   for IDs allocated between now and when work on OpenPGP 2.0 starts.
   
   This is necessary because for new algorithms, or new features etc.,
   there may well be multiple proposals for the same algorithm.  So
   allocating #12 to the succesful AES candidate is in itself useless,
   because there may be 2 or 3 incompatible implementations.
   
   Better would be to allocate #12 to Tom Zerucha, #13 to cryptix, and so
   on on demand, and then the variant which is chosen as the standard for
   inclusion in OpenPGP 2.0 can use that ID.
   
   Thoughts?
   
I expect that IANA will be distributing numbers for OpenPGP algorithms much
the way they distribute other numbers. People working on experiments have
11 numbers in each category to use. There are even 4 packet types reserved
for experiments.

I proposed reserving an algorithm number for AES in Washington last
December, and the answer from the working group was to wait until AES is
selected.

	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: Fri, 10 Jul 1998 14:01:35 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: about MDCs etc (Re: Long Holiday?)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

It's too late to get MDCs into OpenPGP 1.0. We're in last call, and as good
as an idea it is, it's too late. I'm going to have the really, really final
one out this afternoon (I'm editing it in another window).

If you can design something that is wholly backwards-compatible, it'll be
trivial to put it in 1.1 or simple document it as an extension. Not being
in 1.0 won't be an issue

If you can't design something backward compatible, then it's too late to go
in 1.0. Either way, it doesn't make 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: Fri, 10 Jul 1998 10:25:35 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: Re: Patents and draft-ietf-smime-x942-00.txt
Sender: [email-masked]

Well, S/MIME's misery may be OpenPGP's misery as well. It would be good if
someone who understands the patents and the D-H variants looks over the
message below and determines whether it also applies to the ElGamal used in
OpenPGP.

--Paul Hoffman, Director
--Internet Mail Consortium

>X-Lotus-FromDomain: CERTICOM
>From: "Paul Lambert" <[email-masked]>
>To: Russ Housley <[email-masked]>
>cc: [email-masked], [email-masked], [email-masked],
>        [email-masked]
>Date: Thu, 9 Jul 1998 14:43:25 -0700
>Subject: Re: Patents and draft-ietf-smime-x942-00.txt
>Sender: [email-masked]
>
>Russ,
>
>>Does anyone, especially anyone from Certicom, have any additional
>>information on this topic?
>
>Yes, the IEEE patent statement is an accurate description of Certicom's
>currently issued and pending patents applicable to IEEE 1363.  Some of the
>pending patents apply to X9.42.
>
>
>Regards,
>
>Paul A. Lambert
>
>VP of Product Management
>Certicom Corp.
>San Mateo California
>(650) 312-7996
>
>
>
>
>
>
>Russ Housley <[email-masked]> on 07/09/98 02:05:52 PM
>
>To:   [email-masked]
>cc:   [email-masked], [email-masked], [email-masked] (bcc: Paul
>      Lambert/Certicom)
>Subject:  Re: Patents and draft-ietf-smime-x942-00.txt
>
>
>
>All:
>
>At the recent IEEE P1363 meeting a letter from Certicom was circulated that
>claimed patent protection on a number of techniques in the P1363 standard.
>X9.42 and P1363 are very highly aligned in the area of Diffie-Hellman.  One
>of these techniques is Public Key Validation, which is described in Section
>2.1.5 of draft-ietf-smime-x942-00.txt.
>
>A copy of the letter can be found at:
>
>http://grouper.ieee.org/groups/1363/letters/Certicom.txt
>
>Does anyone, especially anyone from Certicom, have any additional
>information on this topic?
>
>Russ
>
>
>>> From:  [email-masked]
>>> Sent:  Friday, June 19, 1998 3:52 PM
>>> To:    [email-masked]
>>> Cc:    [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked]
>>> Subject:    Patents and draft-ietf-smime-x942-00.txt
>>>
>>> All:
>>>
>>> The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
>>> variants fron the ANSI X9.42 Draft Standad. This vairant of
>Diffie-Hellman
>>> seems to be clear of IBM's pending patent.
>>>
>>> At this point, I waould like all S/MIME WG members to determine if there
>>> are any other potential patents (pending or otherwise) that might impact
>>> the use of the Diffie-Hellman variant specified in
>>> draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and
>this
>>> query is to avoid any rude surprises.
>>>
>>> Please forward this note to anyone who might offer assistance in the
>quick
>>> resolution of this matter.
>>>
>>> Russ
>>> S/MIME WG Chair
> 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 10 Jul 1998 00:28:14 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: about MDCs etc (Re: Long Holiday?)
Sender: [email-masked]

Hal writes:
> There is no plan to add MAC or other lightweight signatures to PGP 6.0.
> That may go into a future version.

Thanks for the clarification.

I will make a proposal on how I think it ought to be done, for when it
gets done, along the lines of Tom Zerucha's thoughts.

Then I will examine the current draft and suggest any wording (if any)
that needs to be added to the current draft to ensure that openPGP-1.0
implementations won't get upset when they see such a packet.

The most important aspect of this, as Tom suggested, is that
openPGP-1.0 should gracefully cope with this (and other similar)
unknown signature packets, by still emitting plaintext.

I suggest that we consider reserving a packet number for MDC/Integrity
check purposes.

I won't be able to do this until monday, because I am off early am to
CEN/TC251 meetings in France.

I hope this won't be too late for consideration.  If anyone would like
to do this exercise before monday feel free to take the baton.

Part of this process if there is time could be one of the implementors
adding this, and running the results through the other implementations
to see what they currently do.  (sigsegv? refuse to emit plaintext? or
work already).

(I suggest a new signature type, and use of HMAC-HASH( HASH(
session-key ), message ) as the MDC.  For testing purposes a message
digest would do to see what other implementations think of it.)

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: Thu, 9 Jul 1998 15:17:27 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: about MDCs etc (Re: Long Holiday?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

There is no plan to add MAC or other lightweight signatures to PGP 6.0.
That may go into a future version.

Hal

Date: Thu, 9 Jul 1998 20:37:38 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: about MDCs etc (Re: Long Holiday?)
Sender: [email-masked]

Tom writes:
> Unless they do something nonsensical, it would be easy to extend 1.0 - for
> example, a signature algorithm of 0 means the message digest is stored in
> the clear (maybe as a MPI), and leave the rest of the format alone.  Old
> implmentations should fail gracefully with "unknown signature algorithm". 
> The onepass signature header lets the "MAC" be at the end yet insures that
> someone can't just delete the "MAC".

Sounds ok.  

Are you suggesting this for OpenPGP 1.0 or OpenPGP 2.0?

Note that it could be argued that the MAC or MDC (MDC = Modification
Detection Code) would be stronger if it were dependent on something
secret as well as the plaintext (*).  The plaintext itself may not be
secret, eg for a file transfer of suspected file.

Also CFB block encryption of a digest (particularly appended to the
plaintext, which it will be with one pass sigs) may not necessarily be
the most robust MDC one could construct.  For example 
HMAC( session-key, message ), or HMAC( HASH( session-key ), message )
might be stronger.

What you suggest is probably simple enough that it could be added to
OpenPGP 1.0 even.  HMAC stuff I suspect would be better left for
OpenPGP 2.0.  But we need some *input* here PGP Inc people... are you
working on a solution to this for PGP6.x, do you have an thoughts,
etc.

Adam

(*) If I knew what the plaintext was, I would by extension know what
the digest was, using your suggestion of using a plain digest as the
MDC construct.  Then I can use Gary Howlands attack to modify the last
block of PGPs CFB mode bulk cipher, and so modify the (part of) the
MDC.  No immediate attack, but other constructs are likely stronger.

Date: Thu, 9 Jul 1998 14:17:26 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: IMC & OpenPGP (interoperability)
Sender: [email-masked]

On Thu, 9 Jul 1998, Paul Hoffman / IMC wrote:

> Neither. I removed PGP/MIME and OpenPGP from the event because no one
> expressed any interest in testing either at the event. If two or more
> companies want to attend and participate, I'd be happy to put PGP/MIME and
> OpenPGP back in the event.

Is there any list of implementors?  I have one, and GnuPG is a second with
which I verify interoperability.  If I have the code and access to a
platform that runs it I would be willing to do some checking by myself.

I also keep verifying everything against PGP 5.0 (+patches) and PGP 2.6.2. 

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

Date: Thu, 9 Jul 1998 13:41:10 -0400
From: [email-masked]
To: "John W. Noerenberg" <[email-masked]>
cc: Adam Back <[email-masked]>, Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Long Holiday?
Sender: [email-masked]

On Wed, 8 Jul 1998, John  W. Noerenberg wrote:

> At 10:40 PM +0100 7/8/98, Adam Back wrote:
> >The other thing which I raised was MACs (or MDCs) to prevent against
> >Gary Howlands attack first discussed at HIP97.  PGP made statements
> >about fixing it back then.
> >
> >Now I am not particularly arguing that the necessary changes go into
> >this version, because it is rather late in the day and it needs some
> >careful thought, however it would be most nice if implementations of
> >OpenPGP 1.0 could cope with OpenPGP 2.0 messages which did contain
> >MACs without falling over.
> 
> Oh, yes, Adam.  There hadn't been much discussion.  It slipped past me.
> Jon, is Adam's description sufficient for you to write something for -06?
> 
> How much heartache does adding this cause implementors (and if it does, can
> you really afford not to deal with it)?
> john noerenberg
> [email-masked]

I AM NOT PROPOSING THE FOLLOWING, BUT JUST AS AN EXAMPLE:

Unless they do something nonsensical, it would be easy to extend 1.0 - for
example, a signature algorithm of 0 means the message digest is stored in
the clear (maybe as a MPI), and leave the rest of the format alone.  Old
implmentations should fail gracefully with "unknown signature algorithm". 
The onepass signature header lets the "MAC" be at the end yet insures that
someone can't just delete the "MAC".

So there should be upwards compatible ways of preventing the attack.
There are intrusive ways (new packets, new formats), but I think those can
be avoided.

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

Date: Thu, 9 Jul 1998 13:33:44 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: reserved ID allocation procedure
Sender: [email-masked]

On Wed, 8 Jul 1998, Adam Back wrote:

> This is necessary because for new algorithms, or new features etc.,
> there may well be multiple proposals for the same algorithm.  So
> allocating #12 to the succesful AES candidate is in itself useless,
> because there may be 2 or 3 incompatible implementations.

AES will require a single specified base mode for any two AES
implementations to interoperate - much like DES usually refers to the 56
bit ECB mode.  It is implicit that it run using PGP-CFB for OpenPGP.
There should also be a single key setup specified for the same reason.

Things like HAVAL needed further specification since there were several
flavors of "HAVAL" (same for BlowFish).  The ones being reserved are (or
should be in the case of AES) unique, or specify a specific flavor (e.g. 
160 bit 5 round HAVAL).

> Better would be to allocate #12 to Tom Zerucha, #13 to cryptix, and so
> on on demand, and then the variant which is chosen as the standard for
> inclusion in OpenPGP 2.0 can use that ID.

What if I am working on multiple algorithms - I would need a range.
Otherwise these things should be implemented in the experimental range
(100-110) and implmentors can discuss between themselves which one should
be codified into a small number.

Date: Thu, 09 Jul 1998 09:06:21 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IMC & OpenPGP
Sender: [email-masked]

>I was just up on the IMC web site http://www.imc.org and notice that their
>Secure Connect Conference in July is focused on S/MIME with no mention of
>OpenPGP. Has the IMC abandoned OpenPGP officially or is this one of those
>behind the scene decisions?

Neither. I removed PGP/MIME and OpenPGP from the event because no one
expressed any interest in testing either at the event. If two or more
companies want to attend and participate, I'd be happy to put PGP/MIME and
OpenPGP back in the event.

IMC is still a proponent of OpenPGP because some of our members are
committed to it (the same is true for S/MIME for the same reasons). Just
because no one wants to come to an event to test PGP/MIME and OpenPGP
interoperability doesn't mean we don't like them any more.

In the future, feel free to ask me questions about IMC policy directly
instead of sending them to a mailing list. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 09 Jul 1998 08:05:13 -0500
To: [email-masked]
Subject: IMC & OpenPGP
Sender: [email-masked]

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

Hi,

I was just up on the IMC web site http://www.imc.org and notice that their
Secure Connect Conference in July is focused on S/MIME with no mention of
OpenPGP. Has the IMC abandoned OpenPGP officially or is this one of those
behind the scene decisions?

- -- 
- ---------------------------------------------------------------
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: I'm an OS/2 developer...I don't NEED a life!

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 09 Jul 1998 02:56:00 -0500
To: [email-masked]
Subject: One Pass Signatures
Sender: [email-masked]

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

Hello,

Does anyone have any one pass signatures available that I can use for
testing?

Has anyone looked at creating a collection of test message that cover all
the various OpenPGP packet types & algorithms for use in compatiability
testing?

- -- 
- ---------------------------------------------------------------
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: When DOS grows up it wants to be OS/2!

Date: Wed, 8 Jul 1998 16:43:24 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: IETF August meeting
Sender: [email-masked]

We're making good progress on openpgp formats, but not much is happening on
pgp-mime.  I need to reserve time for a WG meeting to discuss this.

But there's a problem.  Crypto '98 (8/23-27) and the Aug IETF meeting
(8/23-28) overlap. Crypto '98 is in Santa Barbara CA, the IETF meeting is
in Chicago IL.

Please reply to this note (preserving the subject) so I can get a sense of
how many will be able to attend a meeting in Chicago.  Let me know if a
meeting on Friday would influence your desire to attend.
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, 8 Jul 1998 16:25:10 -0700
To: Adam Back <[email-masked]>, Jon Callas <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Long Holiday?
Cc: [email-masked]
Sender: [email-masked]

At 10:40 PM +0100 7/8/98, Adam Back wrote:
>The other thing which I raised was MACs (or MDCs) to prevent against
>Gary Howlands attack first discussed at HIP97.  PGP made statements
>about fixing it back then.
>
>Now I am not particularly arguing that the necessary changes go into
>this version, because it is rather late in the day and it needs some
>careful thought, however it would be most nice if implementations of
>OpenPGP 1.0 could cope with OpenPGP 2.0 messages which did contain
>MACs without falling over.

Oh, yes, Adam.  There hadn't been much discussion.  It slipped past me.
Jon, is Adam's description sufficient for you to write something for -06?

How much heartache does adding this cause implementors (and if it does, can
you really afford not to deal with it)?
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, 8 Jul 1998 14:58:11 -0700
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: WG Last call will be extended (was Re: Long Holiday?)
Cc: OpenPGP mailing list <[email-masked]>, Jon Callas <[email-masked]>
Sender: [email-masked]

At 4:37 PM -0400 7/8/98, [email-masked] wrote:
>I think we should see the "final" text on for a couple of days before it
>is submitted, or at least a diff of all the current changes against
>draft-05 to insure nothing else got left out.

I'm amenable.

When Jon posts the -06 draft, we will consider it for one more week.  If
there are no outstanding disputes, I'll declare it to be the consensus of
the WG, and we'll invite the IESG to review it as a Proposed Standard.

Jon and I chatted on the phone.  I expect he will submit -06 in the next
day or two.

Date: Wed, 8 Jul 1998 22:40:37 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Long Holiday?
Sender: [email-masked]

The other thing which I raised was MACs (or MDCs) to prevent against
Gary Howlands attack first discussed at HIP97.  PGP made statements
about fixing it back then.

Now I am not particularly arguing that the necessary changes go into
this version, because it is rather late in the day and it needs some
careful thought, however it would be most nice if implementations of
OpenPGP 1.0 could cope with OpenPGP 2.0 messages which did contain
MACs without falling over.

That is to still return plaintext of the message together with perhaps
a warning that there was an unimplemented-in-this-version
cryptographic checksum which couldn't be checked.

My thoughts of where MACs would fit into the framework is that they
would be a new kind of signature packet (ie one based on symmetric
crypto -- keyed off the session key or other data inside the
encryption envelope).

So could we for example reserve a MAC signature packet ID with a
lenght packet and define that it should be ignored, and otherwise
stepped over by OpenPGP 1.0 implementations.

Also I think it would need a corresponding entry in the one-pass
signature framework.

Would someone at PGP with thoughts on how they are planning to fix
this in PGP6.x like to think of what would be necessary and propose
the few edits required to make sure it will work smoothly when
introduced?

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: Wed, 8 Jul 1998 22:45:59 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: reserved ID allocation procedure
Sender: [email-masked]

It seems to me that allocating #7 for this or that which is not
implemented yet is a good enough idea, BUT that we need someone who
offers to act as a central clearling house to avoid collisions in IDs
for IDs allocated between now and when work on OpenPGP 2.0 starts.

This is necessary because for new algorithms, or new features etc.,
there may well be multiple proposals for the same algorithm.  So
allocating #12 to the succesful AES candidate is in itself useless,
because there may be 2 or 3 incompatible implementations.

Better would be to allocate #12 to Tom Zerucha, #13 to cryptix, and so
on on demand, and then the variant which is chosen as the standard for
inclusion in OpenPGP 2.0 can use that ID.

Thoughts?

Adam

Date: Wed, 8 Jul 1998 16:37:28 -0400
From: [email-masked]
To: "John W. Noerenberg" <[email-masked]>
cc: OpenPGP mailing list <[email-masked]>
Subject: Re: Long Holiday?
Sender: [email-masked]

On Wed, 8 Jul 1998, John  W. Noerenberg wrote:

> Today is the day I set as the conclusion for WG Last Call.  I'm still
> assessing the discussions over the last two weeks, but I haven't seen any
> activity at *all* on the mailing list since last Thursday.  I thought only
> us American's celebrated the 4th of July...
> 
> I'm just rattling the tree to see if any last nuts fall out before we say
> the harvest is done.

The only two changes were the algorithm IDs (Haval becomes #7 and #4 is
reserved for a TBD wide high security hash for the next version), and the
move to "reserved" for a number of the algorithm IDs.

I think there were also a number of typos and similar wordsmithing things
corrected.  There also may have been a few things submitted long ago that
didn't take until this version.

I think we should see the "final" text on for a couple of days before it
is submitted, or at least a diff of all the current changes against
draft-05 to insure nothing else got left out.

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

Date: Wed, 8 Jul 1998 11:29:48 -0700
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Algorithm Decisions
Cc: [email-masked] (Paul Lambert), Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:15 AM -0700 7/8/98, John  W. Noerenberg wrote:
>...in the interest of bringing the discussion to a close, ...

<sigh>

Forgive my lack of clarity.

I'm endorsing Jon's plan to mark algorithm IDs as reserved with an
explanation in notes for algorithms which are under-specified.
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, 8 Jul 1998 10:28:59 -0700
To: Hironobu Suzuki <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Algorithm patents a US only problem?
Cc: "William H. Geiger III" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 2:41 PM +0900 7/3/98, Hironobu Suzuki wrote:
>
> Should we abandon RSA algo from OpenPGP for only 26 months, until
>2000-Sep-19, patent exipre day of RSA in US???? I don't think so.

Putting on my chairman's hat (or ears -- if you recall):

This debate is really quite beside the point.  Not only does Hironobo make
a good point about the short-lived nature of the US patents, our original
aim for OpenPGP was do provide rigor to the existing practice of PGP.  PGP
includes RSA.  We can't leave it out.

best,

john noerenberg
[email-masked]
  --------------------------------------------------------------------
  There is no illusion more dangerous than the belief that the
  progress of science is predictable.
  -- Freeman Dyson, "Six Cautionary Tales for Scientists", 1988
  --------------------------------------------------------------------

Date: Wed, 8 Jul 1998 10:15:22 -0700
To: [email-masked] (Paul Lambert), Jon Callas <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:43 AM -0400 7/1/98, Uri Blumenthal wrote:
>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.

This discussion about the lack of ECC parameters ran off the rails at about
this point.  Paul Lambert suggested he could get some help with the ECC
parameters from some other folks at Certicom.  Paul, Jon, has that happened?

If not, in the interest of bringing the discussion to a close, I suggest we
leave ECC aside for the present.  We have sufficient room to add
identifiers and parameters for it later.
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, 8 Jul 1998 10:05:45 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Long Holiday?
Sender: [email-masked]

Today is the day I set as the conclusion for WG Last Call.  I'm still
assessing the discussions over the last two weeks, but I haven't seen any
activity at *all* on the mailing list since last Thursday.  I thought only
us American's celebrated the 4th of July...

I'm just rattling the tree to see if any last nuts fall out before we say
the harvest is done.
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
  ----------------------------------------------------------------------

To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked]
Subject: Re: Algorithm patents a US only problem? 
Date: Fri, 03 Jul 1998 14:41:21 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

> Anyone who thinks that the patent issues on algorithms only affects
> the US should take a look at what the WIPO is doing and how it will
> affect them.

 It's a kind of "US gov's hope" or "American way", involved Wired
opinion.  Even if "US gov's hope" is railroaded the motion through the
WIPO committee, US gov needs many years for political
negotiation. It's takes 2 or 3 years at least.

 In real, more complex process will be required in WIPO. Because the
patent is a kind of tools for economy war between each well-developed
countries. Perhaps, it is very difficult to apply the patant which was
already issued.

Anyway, my opinion is very simple.

 Should we abandon RSA algo from OpenPGP for only 26 months, until
2000-Sep-19, patent exipre day of RSA in US???? I don't think so.

						--hironobu

Date: Thu, 2 Jul 1998 15:27:51 -0400
From: [email-masked]
To: IETF OpenPGP <[email-masked]>
Subject: Re: undefined MAY algorithm example
Sender: [email-masked]

On Thu, 2 Jul 1998, William H. Geiger III wrote:

> So even if you are overseas you only have two options if you want to sell
> to the US market:
> 
> 1. Don't use RSA or other proprietary algorithms.
> 
> 2. Establish a *physical* presence in the US and hire the staff to
> maintain 2 different code bases for your products.

AFAIK, Stronghold uses SSLeay code in original form including their
implementation of RSA.  Of course licensing it proves to be prohibitive
except for large companies or those whose perserverance would qualify
them for sainthood.  Fortunately this will expire in a few years.

> It might not be a bad idea for an implementor to require that when a
> signature key that is generated/imported is *not* a DSA signature key that
> either one of two thing happen:
> 
> 1. The user already has a DSA key and it is "linked" to the non-DSA key
> for use in parallel signatures with the non-DSA key.
> 
> 2. The user generates a new DSA key to be used in parallel signatures with
> the non-DSA key.
> 
> There is nothing in the specs for doing this type of linking (or any key
> management for that matter) so this will need to be done on the
> application level.

What should happen is that any current RSA keys become (depricated)
subkeys linked to the DSA primary key just like the DH key already is.

The problem is then we need something that is different than a revocation
- you could send the whole glob as sort of a key-integration message.

There is only a signature that allows for stating with certainty the user
ID, but not one that claims that key1 and key2 are the same person (or can
we slip a 0x14 sig type in)?  The signature should always be in the
reverse direction of the superceeding, i.e. the RSA key signs the DSA key
to say to use the DSA keyset from now on.  (not quite, superceeding is
different than wanting to use two different keys but to say they are both
"me" - 0x15?  It is filling rapidly :).

> I would be interested to hear what NAI's plans are for PGP now that they
> have settled with RSADSI. The route they go with thier new releases will
> pretty much shape what everyone else will need to do.

And whether they can use their own RSA code, or will we be stuck with
something limiting the number of bits in the key?

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

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 02 Jul 1998 13:48:54 -0500
To: [email-masked]
Subject: Algorithm patents a US only problem?
Sender: [email-masked]

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

Hi,

Anyone who thinks that the patent issues on algorithms only affects the US
should take a look at what the WIPO is doing and how it will affect them.

http://www.wired.com/news/news/politics/story/1130.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: The best way to accelerate Windows is at escape velocity.

Date: Thu, 2 Jul 1998 19:01:02 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Algorithm Decisions
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> The algorithm IDs for EC, ECDSA, TIGER, HAVAL, X9.42 and whatever else I've
> missed get marked as reserved. I'll add a section in algorithm notes that

Fine.

Hope we can get an OID for TIGER soon; but there is no need for it in
the standard.

Werner

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 02 Jul 1998 09:15:18 -0500
To: Lindsay Mathieson <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Subject: Re: undefined MAY algorithm example
Sender: [email-masked]

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

In <[email-masked]>, on 07/02/98 
   at 11:04 PM, Lindsay Mathieson <[email-masked]> said:

>>Well, considering that the US *is* the computer market anything other
>>than freeware is affected by the RSADSI patents. Add to this that the
>>majority of software is written in the US

>Are you serious ? 

Yes

>While the majority of software may be written in the US, given the
>restrictive us encrytpion regulations the majority of *security* software
>is being written & maintained outside the US.

I would be willing to debate that but in either case the issue is software
markets. Regardless of where it is written as soon as you try to *sell* it
in the US you are up against the RSADSI patents issue or are you content
to only sell your software to non US markets? Will RSADSI even license
it's software to non-US companies? Considering that they mandate that you
only use their software I highly doubt it.

So even if you are overseas you only have two options if you want to sell
to the US market:

1. Don't use RSA or other proprietary algorithms.

2. Establish a *physical* presence in the US and hire the staff to
maintain 2 different code bases for your products.

Of course you can be content to leave the entire US market to NAI. I for
one do not find that an acceptable alternative.

>I though we covered this whole US/rest of the world thing ages ago ... --

Not really and I wouldn't be too smug and cozy about US policies as AU
seems to be going the same route. If you have any doubts I suggest you
take a look at http://jya.com/oz-crypto.htm and the trouble Eric Young and
Tim Hudson are having over Cryptozilla.

Look people my intent here was not to get into a national dick waving
contest. We have an opportunity here to get the proprietary algorithm
monkey off our back. Hell, PGP Inc. has done all the hard work for us by
moving the majority of the user base away from RSA/IDEA to ELGamal/DSS.
All we have to do is not implement the code. Really simple and it doesn't
cost a thing :)

There is an important issue to understand when it comes to a
multi-algorithm standard. If algorithm set A is a MUST and algorithm set B
is a MAY but everyone is *using* algorithm set B, algorithm set B becomes
a defacto MUST. This is due to the unique nature of communication crypto
rather than some form of local crypto (ie file encryption). 

As an example: If 90% of the user base is signing their messages with RSA
sigs and you want to sell a product to communicate with those users you
had best be able to process RSA sigs to (IMHO this is something the S/MIME
group has failed to understand though I am sure RSADSI has). 

Encryption is not as big of an issue as multiple keys can resolve this
issue. Unfortunately outside of the code I have written and one other
freeware product *none* of the e-mail integrations (especially none of the
commercial products) take into account multiple keys with the same userid.

A compromise to this problem would be to have the systems that support RSA
require the user to generate not only a RSA key but an ElGamal/DSS key at
the same time. All 3 keys would be combined into one key with 2 subpackets
(or 3 if you want separate RSA keys for signing & encrypting). Then one
would have their application make use of parallel signatures where the
data is signed with both the RSA and DSS signatures. I believe that this
can be accomplished using the one-pass signature format but I would have
to go back to the specs to check on that.

There are still problems in dealing with the old RSA keys that are not of
this format. The application would need to require that the user generate
an ElGamal/DSS keypair to correspond to the imported RSA key. It would
have to support multiple keys for the same userid and it would still need
the ability to generate parallel signatures.

It might not be a bad idea for an implementor to require that when a
signature key that is generated/imported is *not* a DSA signature key that
either one of two thing happen:

1. The user already has a DSA key and it is "linked" to the non-DSA key
for use in parallel signatures with the non-DSA key.

2. The user generates a new DSA key to be used in parallel signatures with
the non-DSA key.

There is nothing in the specs for doing this type of linking (or any key
management for that matter) so this will need to be done on the
application level.

FWIW I don't have a problem with those who wish to have RSA support for
processing incoming messages for backward compatibility it is the
generating of new messages using RSA that I see as a problem.

I would be interested to hear what NAI's plans are for PGP now that they
have settled with RSADSI. The route they go with thier new releases will
pretty much shape what everyone else will need to do.

- -- 
- ---------------------------------------------------------------
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: I use OS/2 2.0 and I don't care who knows!

Date: Thu, 2 Jul 1998 11:14:25 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Algorithm Decisions
Sender: [email-masked]

On Wed, 1 Jul 1998, Jon Callas wrote:

> How does this sound to people as a solution?
> 
> The algorithm IDs for EC, ECDSA, TIGER, HAVAL, X9.42 and whatever else I've
> missed get marked as reserved. I'll add a section in algorithm notes that
> says why they're reserved.
> 
> 	Jon

Fine with me.  That way they can still be developed outside of compliance
and the next version will be able to define the details (or simply have
OIDS assigned as needed).

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

Date: 2 Jul 1998 23:4:45 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: undefined MAY algorithm example
To: "William H. Geiger III" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>Well, considering that the US *is* the computer market anything other
>than freeware is affected by the RSADSI patents. Add to this that the
>majority of software is written in the US

Are you serious ? 

While the majority of software may be written in the US, given the
restrictive us encrytpion regulations the majority of *security* software
is being written & maintained outside the US.

I though we covered this whole US/rest of the world thing ages ago ...
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on July 2, 1998, in Win95 4.0
	http://www.blackpaw.com/

Date: Wed, 01 Jul 1998 17:14:18 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Algorithm Decisions
Sender: [email-masked]

How does this sound to people as a solution?

The algorithm IDs for EC, ECDSA, TIGER, HAVAL, X9.42 and whatever else I've
missed get marked as reserved. I'll add a section in algorithm notes that
says why they're reserved.

	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: stream ciphers (Re: 128 bit block ciphers)
To: [email-masked] (Paul Koning)
Date: Wed, 1 Jul 1998 20:14:31 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Paul Koning says:
> Hm.  That sounds like practical stream cyphers will always be insecure 
> (to the extent that an unknown stream offset has a significant
> security benefit).

A stream cipher is basically a PRNG generator. You use the PR stream
somewhat similarly to OTP - for example you prefer not to reuse it
(lest you want that what happened to KGB would happen to you, i.e.
"Venona" :-).

Stream ciphers have their place under the Sun...

> An IV can (and should be) random -- all bits unpredictable.

An IV doesn't have to and should not be random.  It doesn't need
to be unpredictable. All it really needs to be is non-repetitive.

> A stream
> offset may be random but it cannot in practice be random in more than
> a modest number of low order bits, so the set of likely values is
> necessarily small.

It can, but as it was said - it would not be very practical. However,
if you utilize only a few KBytes of the stream (for each key :-), you
might be able to live with small offsets... 
["Poor man's James Bond" :-]
-- 
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: Wed, 1 Jul 1998 20:00:51 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> > Similarly to having to remember not to re-use IVs.
> 
> Ah, but you get "remembering" not to re-use IVs for free -- you just
> use random ones, or for some block modes just non-repeating IVs.

True.

> Using random offsets is impractical due to the performance penalty of
> spinning the PRNG by 2^(IV size).

Also true - however limited offsets could be used more or less
safely with small-size plaintexts (say, up to a few KBytes)...

> > > rc4-key-shedule( iv || s2k( passphrase ) )
> > 
> > A possibility. Would need more time to evaluate it...
> 
> It has a sort of precedent, so must (one presumes!) have been looked
> at in that the export versions of SSL cipher suites with RC4
> (RC4-40-RSA-MD5) use the construct...

(:-) So much the better.

> Probably:  	rc4-key-schedule ( s2k( iv || passphrase ) ) 
> would be better as it uses the hash in the s2k for mixing rather than
> relying partly on rc4 key schedule (which the rc4-key-schedule( iv ||
> s2k (passphrase) does ).

Probably...

> Ah, yes, I suspected you were thinking of SEAL in your earlier
> comments on offsets :-) ... SEAL is more than a stream cipher, it is a
> pseudo-random function family, so spinning to arbitrary points comes
> for free with SEAL.  Very nice, agreed.  But that trick doesn't work
> with RC4.

(:-( What can I say... But maybe, just maybe the idea can be [partially]
"ported"...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Wed, 1 Jul 1998 22:52:04 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
Sender: [email-masked]

Uri writes:
> > This has a number of problems/added complexities I think:
> > - you have to remember a current offest to avoid re-using offsets
> >   (adds state to symmetric crypto where there is none currently)
> 
> Similarly to having to remember not to re-use IVs.

Ah, but you get "remembering" not to re-use IVs for free -- you just
use random ones, or for some block modes just non-repeating IVs.
Using random offsets is impractical due to the performance penalty of
spinning the PRNG by 2^(IV size).

> > > For the keys to have a stream offset can mean the difference between
> > > secure and insecure.
> > Another way to do things which avoids some of the problems with
> > offsets is to have a random, or at least non-repeating IV, which is
> > sent in the clear.  Then use the IV as part of the key.  eg.
> > 
> > rc4-key-shedule( iv || s2k( passphrase ) )
> 
> A possibility. Would need more time to evaluate it...

It has a sort of precedent, so must (one presumes!) have been looked
at in that the export versions of SSL cipher suites with RC4
(RC4-40-RSA-MD5) use the construct.  ie they construct a 128 bit RC4
from a 40 bit secret component and a public (sent in the clear) 88 bit
salt, via :

	128bit-key = md5( 88bit-salt || 40bit-key )

(there are some other padding rules, they actually generate two keys,
one for each direction and there are some other values concatenated.)

Probably:

	rc4-key-schedule ( s2k( iv || passphrase ) ) 

would be better as it usees the hash in the s2k for mixing rather than
relying partly on rc4 key schedule (which the rc4-key-schedule( iv ||
s2k (passphrase) does ).

> > you can then recover sk1 xor sk2:
> 
> You might want to take a look at SEAL. It provides the offset VERY
> elegantly. Unfortunately it's patented...

Ah, yes, I suspected you were thinking of SEAL in your earlier
comments on offsets :-) ... SEAL is more than a stream cipher, it is a
pseudo-random function family, so spinning to arbitrary points comes
for free with SEAL.  Very nice, agreed.  But that trick doesn't work
with RC4.

Adam

Date: Wed, 1 Jul 1998 23:08:58 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
Sender: [email-masked]

Paul Koning writes;
>  >> - you incur the performance penalty of spinning the PRNG by the
>  >> offset number of bytes (eg could be 100s of megs).
> 
>  Uri> Possibly, but again, I'm not "inventing" it - just sharing the
>  Uri> crypto rules of using stream ciphers with the list. "Don't blame
>  Uri> the messenger" (:-)
> 
> Hm.  That sounds like practical stream cyphers will always be insecure 
> (to the extent that an unknown stream offset has a significant
> security benefit).

the stream offset doesn't have to be unknown, it just has to be chosen
so that no PRNG output byte used more than once.  (ie just start at 0,
and keep incrementing.)

The reason for the offset is that RC4 (and other stream ciphers) work
by xoring the output of a pseudo random number generator with the
plaintext.  The seed of the PRNG is the stream ciphers key.

So, if we take RC4, and call the PRNG output for byte i and key k
rc4-prng(k,i), you encrypt like this:

ciphertext[i] = plaintext[i] xor rc4-prng(k,i)

So if you use the same key (k), and you still start i at 0, you end up
with leaking the two plaintexts xored together.  

c1 = p1 xor prng, c2 = p2 xor prng => p1 xor p2 = c1 xor c2

leaking two plaintexts xored together is close to leaking the
plaintext outright.

So you just make sure never to reuse bytes from the prng output, ie
first message size 1000 bytes, start with prng output byte 0, and use
up to output byte 999, next message of 1000 bytes start at 1000, use
up to output byte 1999.

> An IV can (and should be) random -- all bits unpredictable.  

That is safe, but for some block-cipher modes a stronger requirement
than strictly necessary.  CFB, and CBC only require unique IVs (not
random ones), so an incrementing variable or timestamp would be
enough.  The stream offset also doesn't need to be random.

Adam

Date: Wed, 1 Jul 1998 17:16:49 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
Sender: [email-masked]

>>>>> "Uri" == Uri Blumenthal <[email-masked]> writes:

 Uri> Adam Back says:
 >> > 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.
 >> 
 >> I presume by a stream offset you mean that you spin the stream
 >> cipher PRNG for the published offset number of bytes, before using
 >> it to encrypt data.

 Uri> Yes, that is not my idea, not any more than using IV for
 Uri> block ciphers - and for precisely the same purpose.

 >> This has a number of problems/added complexities I think: - you
 >> have to remember a current offest to avoid re-using offsets (adds
 >> state to symmetric crypto where there is none currently)

 Uri> Similarly to having to remember not to re-use IVs.

 >> - you incur the performance penalty of spinning the PRNG by the
 >> offset number of bytes (eg could be 100s of megs).

 Uri> Possibly, but again, I'm not "inventing" it - just sharing the
 Uri> crypto rules of using stream ciphers with the list. "Don't blame
 Uri> the messenger" (:-)

Hm.  That sounds like practical stream cyphers will always be insecure 
(to the extent that an unknown stream offset has a significant
security benefit).

An IV can (and should be) random -- all bits unpredictable.  A stream
offset may be random but it cannot in practice be random in more than
a modest number of low order bits, so the set of likely values is
necessarily small.

Did I miss something?

	paul

From: Uri Blumenthal <[email-masked]>
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
To: [email-masked] (Adam Back)
Date: Wed, 1 Jul 1998 16:29:43 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> > 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.
> 
> I presume by a stream offset you mean that you spin the stream cipher
> PRNG for the published offset number of bytes, before using it to
> encrypt data.

Yes, that hat is not my idea, not any more than using IV for block
ciphers - and for precisely the same purpose.

> This has a number of problems/added complexities I think:
> - you have to remember a current offest to avoid re-using offsets
>   (adds state to symmetric crypto where there is none currently)

Similarly to having to remember not to re-use IVs.

> - you incur the performance penalty of spinning the PRNG by the offset
>   number of bytes (eg could be 100s of megs).

Possibly, but again, I'm not "inventing" it - just sharing the crypto
rules of using stream ciphers with the list. "Don't blame the messenger" (:-)

> > For the keys to have a stream offset can mean the difference between
> > secure and insecure.
> Another way to do things which avoids some of the problems with
> offsets is to have a random, or at least non-repeating IV, which is
> sent in the clear.  Then use the IV as part of the key.  eg.
> 
> rc4-key-shedule( iv || s2k( passphrase ) )

A possibility. Would need more time to evaluate it...

> ..... 
> Now you encrypt with rc4 session keys sk1 and sk2 for two separate
> messages m1 and m2, so the SKESK packets contain:
> 
>   skesk1 = rc4-encrypt( rc4key, sk1 ) = rc4out xor sk1
>   skesk2 = rc4-encrypt( rc4key, sk2 ) = rc4out xor sk2

Which is why there must be an offset.

> you can then recover sk1 xor sk2:

You might want to take a look at SEAL. It provides the offset VERY
elegantly. Unfortunately it's patented...

> Leaking of xors of sets of keys means that people can observe which
> keybits are the same on a set of messages.  This seems like a leak you
> would be better off without.

Oh, of course! (:-)
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Wed, 1 Jul 1998 20:42:39 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: stream ciphers (Re: 128 bit block ciphers)
Sender: [email-masked]

Uri writes:
> > 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.

I presume by a stream offset you mean that you spin the stream cipher
PRNG for the published offset number of bytes, before using it to
encrypt data.

This has a number of problems/added complexities I think:

- you have to remember a current offest to avoid re-using offsets
  (adds state to symmetric crypto where there is none currently)

- you incur the performance penalty of spinning the PRNG by the offset
  number of bytes (eg could be 100s of megs).

> 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.

Another way to do things which avoids some of the problems with
offsets is to have a random, or at least non-repeating IV, which is
sent in the clear.  Then use the IV as part of the key.  eg.

rc4-key-shedule( iv || s2k( passphrase ) )

> > 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.

I guess it's not immediately broken, but I don't like it.

Consider:

  rc4key = s2k( passphrase )
  rc4out = rc4-prng( rc4key )

where rc4out is what is xored with the plaintext to encrypt; and that
you're reusing the passphrase.

Now you encrypt with rc4 session keys sk1 and sk2 for two separate
messages m1 and m2, so the SKESK packets contain:

  skesk1 = rc4-encrypt( rc4key, sk1 ) = rc4out xor sk1
  skesk2 = rc4-encrypt( rc4key, sk2 ) = rc4out xor sk2

you can then recover sk1 xor sk2:

  skesk1 xor skesk2 = rc4out xor sk1 xor rc4out xor sk2 = sk1 xor sk2

Leaking of xors of sets of keys means that people can observe which
keybits are the same on a set of messages.  This seems like a leak you
would be better off without.

So, if someone ever recovers one of your sk-n for that passphrase they
can recover all other messages encrypted with that passphrase.

This is problematic for at least 2 reasons:

- you may want to reveal one sk when demanded to by someone

- if multiple SKESKs are used on one document to allow multiple people
  to read the document, anyone you ever shared a document with can
  decrypt all other documents encrypted with that passphrase even if
  they are not on the multiple SKESK list.

Adam

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: undefined MAY algorithm example 
Date: Thu, 02 Jul 1998 00:56:56 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

>>>>> "Werner" == Werner Koch <[email-masked]> writes:
 Werner> RSA is only patented in the U.S.  So there are good reasons
 Werner> to keep it for us Europeans and others.

Yeah. As far as I know, the patent of RSA is not issued in any Asian
countries.

 Werner> I don't like RSA due to the patent but I have a lot of
 Werner> precious key signatures and it may take a while until they
 Werner> are all replaced by DSA or another algo.

If RSA algo is excluded from OpenPGP, OpenPGP users have big problem
not only they have to abandon lots of keys but also they can't handle
to verify and to decrypt lots of old pgped files.

Even if RFC definition exclude RSA algo from OpenPGP, new OpenPGP
based software maybe have RSA algo for compatibility.

It sounds just "double-standards" for me. One is for IETF RFC and
another is for real-software.

I understand that the patent of RSA algo bugs lots of people in US,
but PGP already use RSA for log time and there is no patent problem in
outside of US. To exulude RSA algo is too painful, small gain.

						--hironobu
-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL://www.pp.iij4u.or.jp/~h2np

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 01 Jul 1998 10:32:45 -0500
To: Uri Blumenthal <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

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

In <[email-masked]>, on 07/01/98 
   at 10:54 AM, Uri Blumenthal <[email-masked]> said:

>> The IETF is moving away from the use of encumbered algorithms and I see no
>> reason why we should reverse the trend here.

>Wuld you find me dense if I ask: what is it that you suggest?

Well we are rather stuck with RSA being a MAY algorithm in the spec due to
the userbase issue I manetioned before. I wouldn't mind seeing a MAY NOT
for RSA key generation or at least a reomendation that this is SHOULD NOT
be the default action of an OpenPGP program.

I don't see any need for adding new encumbered algorithms to the spec
without some strong wording to the affect that they should not be used for
public applications. 

Of course if someone can provide a good reason for them to be added I am
willing to change my position. :)

- -- 
- ---------------------------------------------------------------
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 is a TAG-O-Matic
             Multi-line Sample
             Tag 

From: Uri Blumenthal <[email-masked]>
Subject: Re: undefined MAY algorithm example (Re: Question and note)
To: [email-masked] (William H. Geiger III)
Date: Wed, 1 Jul 1998 10:54:14 -0400 (EDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

William H. Geiger III says:
> In <[email-masked]>, on 07/01/98 
>    at 02:43 AM, Uri Blumenthal <[email-masked]> said:
> 
> >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. 
> 
> No, no it's not. RSADSI charges $20,000 to use their algorithms in any
> program other than freeware along with some other rather unacceptable
          ^^^^^^^^^^^^^^^^^^^
> conditions to it's use.

"Other than freeware"? How is it "not" exactly what I said? 

My grief with ECC is that TODAY you cannot have freeware (it appears that
Certicom is going to do something about that, but let's wait and see).

> IMHO the only reason RSA is still in the spec is due to the large user
> base of 2.6.x users.

Probably. Never cared much one way or the other.

> The IETF is moving away from the use of encumbered algorithms and I see no
> reason why we should reverse the trend here.

Wuld you find me dense if I ask: what is it that you suggest?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Wed, 1 Jul 1998 10:19:30 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Undefined and underdefined algorithms
Sender: [email-masked]

>>>>> "dontspam-tzeruch" == dontspam-tzeruch  <[email-masked]> writes:
 dontspam-tzeruch> Maybe I have uncovered another ambiguity

 dontspam-tzeruch> For 3DES I have:

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

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

DES has 56 significant bits in the key plus 8 parity bits that serve
no purpose other than to confuse people.  The normal key
representation with DES is 8 bytes; each byte contains 7 key bits plus 
one parity bit (the LSB).

	paul

Date: Wed, 1 Jul 1998 22:38:39 +1000 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: Uri Blumenthal <[email-masked]>, Paul Lambert <[email-masked]>, [email-masked]
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

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

On Wed, 1 Jul 1998, William H. Geiger III wrote:

[...]

> IMHO the only reason RSA is still in the spec is due to the large user
> base of 2.6.x users.

You are forgetting the International users who are able to make use of RSA
in an unencumbered fashion.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 01 Jul 1998 07:48:26 -0500
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: undefined MAY algorithm example
Sender: [email-masked]

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

In <[email-masked]>, on 07/01/98 
   at 12:23 PM, Werner Koch <[email-masked]> said:

>"William H. Geiger III" <[email-masked]> writes:

>> No, no it's not. RSADSI charges $20,000 to use their algorithms in any
>> program other than freeware along with some other rather unacceptable

>RSA is only patented in the U.S.  So there are good reasons to keep it
>for us Europeans and others.

Well, considering that the US *is* the computer market anything other than
freeware is affected by the RSADSI patents. Add to this that the majority
of software is written in the US the faster we get away from RSA and other
encumbered algorithms the better.

>> The IETF is moving away from the use of encumbered algorithms and I see no

>:-)

>I don't like RSA due to the patent but I have a lot of precious key
>signatures and it may take a while until they are all replaced by DSA or
>another algo.

Well we all have sacrifices to make if we want to see this standard
survive against S/MIME which has some heavy backers. IMHO there will be no
major S/MIME implementations that do not support RSA due to the fact that
the major players have already paid their tithe to RSADSI and there is no
incentive for them to move away from it (and yes they have removed it as a
MUST from the spec but that is irrelevant if everyone is still using it).

This can be a major advantage to us as we can offer an alternative to
perspective software vendors that does not require absorbent up front
payments and royalties to boot. 

- -- 
- ---------------------------------------------------------------
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: Have you crashed your Windows today?

Date: Wed, 1 Jul 1998 12:23:53 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: undefined MAY algorithm example
Mail-Followup-To: [email-masked]
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:

> No, no it's not. RSADSI charges $20,000 to use their algorithms in any
> program other than freeware along with some other rather unacceptable

RSA is only patented in the U.S.  So there are good reasons to keep
it for us Europeans and others.

> The IETF is moving away from the use of encumbered algorithms and I see no

:-)

I don't like RSA due to the patent but I have a lot of precious key
signatures and it may take a while until they are all replaced by DSA
or another algo.

Werner

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 01 Jul 1998 03:42:08 -0500
To: Uri Blumenthal <[email-masked]>
Cc: [email-masked] (Paul Lambert), [email-masked]
Subject: Re: undefined MAY algorithm example (Re: Question and note)
Sender: [email-masked]

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

In <[email-masked]>, on 07/01/98 
   at 02:43 AM, Uri Blumenthal <[email-masked]> said:

>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. 

No, no it's not. RSADSI charges $20,000 to use their algorithms in any
program other than freeware along with some other rather unacceptable
conditions to it's use.

IMHO the only reason RSA is still in the spec is due to the large user
base of 2.6.x users.

The IETF is moving away from the use of encumbered algorithms and I see no
reason why we should reverse the trend here.

- -- 
- ---------------------------------------------------------------
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: How do you spell relief? OS/2!