Subject: Re: Comment packets
From: "William H. Geiger III" <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Date: Thu, 19 Feb 98 18:14:21 -0500

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

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

>RFC1991 says it's never been implemented. If anyone *has* implemented it,
>it will break between OpenPGP and previous versions.

>With Lutz's message, it sounds like he's implemented it. Has anyone else
>implemented it? Does anyone want to argue why it should be there, or pick
>up the argument on eliminating it?

I guess it all depends on what it is being used for. In an earlier reply
to one of my post I was informed that this was not being used so this is
the first I have heard that anyone was using it.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: To whom the gods destroy, they first teach Windows...

Date: Thu, 19 Feb 1998 12:05:15 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Comment packets
Sender: [email-masked]

At the Washington meeting, two related topics came up. One was the marker
packet -- there was a suggestion that the market packet body be allowed to
hold a manufacturer's string; presently, it is mandated to be the string
"PGP". Jeff Schiller pointed out that there is a potential security flaw in
this, that it can be send information that weakens or nullifies the
encryption. He recommended that we make it be a constant to prevent misuse.
I pointed out that there was also the comment packet, which has changed its
opcode number. He recommended that it be eliminated for the same reasons,
and no one objected.

RFC1991 says it's never been implemented. If anyone *has* implemented it,
it will break between OpenPGP and previous versions.

With Lutz's message, it sounds like he's implemented it. Has anyone else
implemented it? Does anyone want to argue why it should be there, or pick
up the argument on eliminating it?

	Jon

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

Date: Thu, 19 Feb 1998 11:09:26 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Modifications of 1991 necessary?
Sender: [email-masked]

At 06:58 AM 2/19/98 GMT, Lutz Donnerhacke wrote:

>This modification was not discussed and is not yet implemented in the
>refernce implementation. I doubt it to be useful. Subkeys can use packet
>version four and must not destroy existing standards in use.
   
I beg your pardon? I'm staring at the standard and it says in section 4.2:

  PGP 2.6.X only uses old format packets.  Thus, software that
  interoperates with those versions of PGP must only use old format
  packets.  If interoperability is not an issue, either format may be
  used.

Section 4.3 says:

  The packet tag denotes what type of packet the body holds.  Note that
  old format packets can only have tags less than 16, whereas new format
  packets can have tags as great as 63.  The defined tags (in decimal)
  are:

What do I need to add to make this more clear? It would certainly be a pity
if your reference implementation did not comply to the spec.

	Jon

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Modifications of 1991 necessary?
Date: 19 Feb 1998 06:58:02 GMT
Organization: IKS GmbH Jena
Lines: 28
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Jon Callas wrote:
>At 08:22 AM 2/18/98 GMT, Lutz Donnerhacke wrote:
>   * Jon Callas wrote:
>   >Personally, I like the old form of packet headers, as they simply denote a
>   >1, 2, or 4-octet length, with no funny stuff. The "new" ones, though, are
>   >useful for doing streaming. 
>   
>   But the old ones does not contain all packet types (esp. CTB_SUBKEY,
>   CTB_SECRET_SUBKEY)
>
>Sure it does. The subkey packet is 14, and the secret subkey is 7. Both of
>these fit within a 4-bit field.

This modification was not discussed and is not yet implemented in the
refernce implementation. I doubt it to be useful. Subkeys can use packet
version four and must not destroy existing standards in use.

>   >There is a difference, in that the old headers only have 4 bits of opcode
>   >for packet types. However, since we've eliminated the comment packet, we
>   >fit into 4 bits. If we wanted room, we could always kill the marker packet
>   
>   You did not eliminate the comment packet. It's in use! Please to not outlaw
>   existing implemetations.
>   
>Uh oh. We're going to have to have a discussion of this. I'll fork it off
>to another thread.

Thnx

Date: Wed, 18 Feb 1998 14:20:42 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Extension to packet lengths
Sender: [email-masked]

At 08:22 AM 2/18/98 GMT, Lutz Donnerhacke wrote:
   * Jon Callas wrote:
   >Personally, I like the old form of packet headers, as they simply denote a
   >1, 2, or 4-octet length, with no funny stuff. The "new" ones, though, are
   >useful for doing streaming. 
   
   But the old ones does not contain all packet types (esp. CTB_SUBKEY,
   CTB_SECRET_SUBKEY)

Sure it does. The subkey packet is 14, and the secret subkey is 7. Both of
these fit within a 4-bit field.

There is nothing magical about the two header types. Each packet is a TLV
(tag-length-value) record. The packet header is the way that the tag and
length are encoded. The "old" headers have 4 bits for the tag, and the
"new" ones have 6. Other than numeric value, there is nothing that forces
use of either format. You can put a packet with a tag of 0-15 in either
header.
   
   >There is a difference, in that the old headers only have 4 bits of opcode
   >for packet types. However, since we've eliminated the comment packet, we
   >fit into 4 bits. If we wanted room, we could always kill the marker packet
   
   You did not eliminate the comment packet. It's in use! Please to not outlaw
   existing implemetations.
   
Uh oh. We're going to have to have a discussion of this. I'll fork it off
to another thread.

	Jon

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

Date: Tue, 17 Feb 1998 19:16:55 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: non-standard CFB (Re: Lutz formal spec / ROT-13 persists)
Cc: [email-masked], [email-masked]
Content-MD5: Int/SNISg/Y7ybvBW0TqGg==
Sender: [email-masked]

At 12:26 AM 2/13/98 GMT, Adam Back wrote:
   
   Werner Koch <[email-masked]> writes:
   > By the way, is is really required that PGP's strange CFB mode is
   > required for other ciphers that IDEA?
   
   I argued against earlier on list, and argued for the non-standard CFB
   to be depracated for all ciphers.  However I think pgp5.x already is
   deployed with non-standard CFB for CAST (and I presume 3DES also).
   
We're stuck with the non-standard CFB (which is used for all ciphers) until
OpenPGP v2. It's needed for backwards compatibility. Sorry.

	Jon

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Extension to packet lengths
Date: 18 Feb 1998 08:22:10 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Jon Callas wrote:
>Personally, I like the old form of packet headers, as they simply denote a
>1, 2, or 4-octet length, with no funny stuff. The "new" ones, though, are
>useful for doing streaming. 

But the old ones does not contain all packet types (esp. CTB_SUBKEY,
CTB_SECRET_SUBKEY)

>There is a difference, in that the old headers only have 4 bits of opcode
>for packet types. However, since we've eliminated the comment packet, we
>fit into 4 bits. If we wanted room, we could always kill the marker packet

You did not eliminate the comment packet. It's in use! Please to not outlaw
existing implemetations.

Date: Tue, 17 Feb 1998 19:16:55 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: non-standard CFB (Re: Lutz formal spec / ROT-13 persists)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:26 AM 2/13/98 GMT, Adam Back wrote:
   
   Werner Koch <[email-masked]> writes:
   > By the way, is is really required that PGP's strange CFB mode is
   > required for other ciphers that IDEA?
   
   I argued against earlier on list, and argued for the non-standard CFB
   to be depracated for all ciphers.  However I think pgp5.x already is
   deployed with non-standard CFB for CAST (and I presume 3DES also).
   
We're stuck with the non-standard CFB (which is used for all ciphers) until
OpenPGP v2. It's needed for backwards compatibility. Sorry.

	Jon

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

Date: Tue, 17 Feb 1998 19:16:54 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Extension to packet lengths
Sender: [email-masked]

I'd like to note that you can use either type of packet header at will.

Personally, I like the old form of packet headers, as they simply denote a
1, 2, or 4-octet length, with no funny stuff. The "new" ones, though, are
useful for doing streaming. 

There is a difference, in that the old headers only have 4 bits of opcode
for packet types. However, since we've eliminated the comment packet, we
fit into 4 bits. If we wanted room, we could always kill the marker packet
now, and look at reusing it for later. If we expect to have more packet
types, and we don't like the "new" header format, then we have a problem.

	Jon

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

Date: Fri, 13 Feb 1998 00:26:32 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: non-standard CFB (Re: Lutz formal spec / ROT-13 persists)
Content-MD5: Int/SNISg/Y7ybvBW0TqGg==
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
> By the way, is is really required that PGP's strange CFB mode is
> required for other ciphers that IDEA?

I argued against earlier on list, and argued for the non-standard CFB
to be depracated for all ciphers.  However I think pgp5.x already is
deployed with non-standard CFB for CAST (and I presume 3DES also).

Adam

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Extension to packet lengths
Date: 17 Feb 1998 07:34:19 GMT
Organization: IKS GmbH Jena
Lines: 52
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Bill Stewart wrote:
>to keep them short.  The question is how to phase out the old stuff
>as fast as possible without abandoning users of older software.

No problem. Old software will crash on the new packet frame using old or new
semantics. So...

>(Incompatibility has, of course, really annoyed a lot of users.)
>My recommendation is to adopt the proposed 0xFF + 4-byte-length
>with some kind of flag mechanism for initial transition, and
>deprecate the old stuff, using the new indication whenever possible --

...flagging does not help.

>One of the most serious problems with the hokey number formats
>is that it increases the parsing code size and work level
>on every user of PGP - this is a pain for smartcards and

Exactly. I do not see any need for this new packet length format.
Hal, (again) why?

>What kinds of lengths need to be dealt with?  How common are they?

Your recomments are fine for OpenPGPv2, but not for our current work.

>0) Zero - is this needed anywhere?

Yes. There are some cases I like to have zero length packets. In such cases
the existence of the packet (signature subpacket) is sufficient to signal
something.

>i) Indefinite - critical for one-pass transactions; series of
>	blocks of some reasonable size like 8KB or 1MB or whatever
>	followed by a smaller block at the end (or padding) are fine.
>	They don't add a high percentage of size, though they
>	make things non-even multiples of disk block size, which
>	is annoying for efficiency.

Indefinite should never used. Parsing syntax on the base of semantics ist a
BAD(TM) thing. Continuing package frames are a fine solution.

>1) Small - lengths of packets in key records and certifications.
>	Has anybody at PGP done a study of the existing certs
>	in the existing key servers to determine what size packets
>	are used?  For instance, how often is 192 enough?
>	What fraction of them overflow into 83xx?

At the moment no certificate is that long. But the free form extentions are
likely to break the limit.

The rest of your cases can be solved using the current format. There is no
need for a four octet length!

Date: Sun, 15 Feb 1998 17:40:24 -0800
To: Hal Finney <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Extension to packet lengths
Sender: [email-masked]

The whole system is pretty hokey, though there's definitely some value
in tight-packed formats within key certification handling blocks
to keep them short.  The question is how to phase out the old stuff
as fast as possible without abandoning users of older software.
(Incompatibility has, of course, really annoyed a lot of users.)
My recommendation is to adopt the proposed 0xFF + 4-byte-length
with some kind of flag mechanism for initial transition, and
deprecate the old stuff, using the new indication whenever possible --
but _only_ when possible.  (Is it possible to shoehorn into PGP 6.0?)
Actually, if you're using a flag, you _could_ perhaps skip the 0xFF.

One of the most serious problems with the hokey number formats
is that it increases the parsing code size and work level
on every user of PGP - this is a pain for smartcards and
other limited-memory environments.  Perhaps a flag approach
would let us replace _all_ the hokey packed number formats?
I suppose processing time isn't _that_ important, given that
parsing silly number formats is much faster than RSA or DH.
Is there a corresponding _advantage_ to using usually-short
numbers in 16-bit processing environments?

What kinds of lengths need to be dealt with?  How common are they?
In particular, is 4 bytes enough, or if we're extending anyway
should we just do 8 bytes?
0) Zero - is this needed anywhere?
i) Indefinite - critical for one-pass transactions; series of
	blocks of some reasonable size like 8KB or 1MB or whatever
	followed by a smaller block at the end (or padding) are fine.
	They don't add a high percentage of size, though they
	make things non-even multiples of disk block size, which
	is annoying for efficiency.
1) Small - lengths of packets in key records and certifications.
	Has anybody at PGP done a study of the existing certs
	in the existing key servers to determine what size packets
	are used?  For instance, how often is 192 enough?
	What fraction of them overflow into 83xx?
2) Text messages - many ASCII email messages fit into 8KB,
	so the 2-byte format does save 2 bytes over a 4-byte,
	but that's guaranteed to be <~ 1% of message size,
	and probably averages about 0.1% - 0.05%, given the
	typical 1KB of headers and 1 page of text in ASCII email.
3) Word-processor documents, GIFs, and small programs
	Microsoft email programs traditionally choke on
	ASCII bigger than 30KB, and MS encourages you to attach
	semi-bloated word-processor documents or really-bloated
	PowerPoint pictures, or to use semi-bloated rich-text formats.
	This is all bigger than 8KB, and often bigger than 64KB,
	but probably isn't bigger than 16 MB very often.
4) < 2-4GB - Almost any document except some MPEGs,
	CDROMs (until DVD replaces them), 
	ZIP and JAZ drives (until they get bigger than 2GB), 
	file system backups (starting to get bigger, and tape
	drives have been over 2GB for a while).
5) >2-4GB - DVD, bigger disk drives - while you usually
	would use a file system encryptor rather than PGP,
	PGP is still an interesting format for encrypted backups,
	and people _are_ going to do this sort of thing,
	especially as DVD lets them make high-res encrypted movies.
	On the other hand, operating systems often get cranky
	about allocating memory bigger than 2GB or 4GB, and 
	code with 32-bit integers often gets cranky about it,
	and using indefinite-length formats for files
	bigger than this increases your size by 10**-9,
	and is mainly annoying because things aren't
	even powers of 2 or multiples of 1KB.

	

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

Date: Sun, 15 Feb 1998 18:25:45 -0400
To: (Recipient list suppressed)
From: Robert Vinet <[email-masked]>
Subject: Electronic Commerce Press Release
Sender: [email-masked]

New Electronic Commerce Site Takes the Hassle Out of Finding the Latest
ECommerce News

allECommerce -- The most comprehensive source of electronic commerce news,
resources and business strategy available anywhere.

Fredericton, NB Canada -- February 16, 1998 -- V-Networks, Inc. announces
allECommerce (http://www.allEC.com), the most comprehensive source of
Internet-based electronic commerce news, resources and business strategy,
on or off the web. allEC.com is designed to enlighten electronic commerce
professionals in every aspect of electronic commerce.

As the amount of content on the Internet explodes, the electronic commerce
industry insiders are turning to allECommerce to eliminate information
overload, increase productivity, and obtain a sharp competitive advantage
by staying informed.

allECommerce keeps its readers current on all aspects of the electronic
commerce arena. Updated daily, allECommerce provides original content and
provides a collection of time sensitive links to current ECommerce news
stories. The archives provide links to previous stories with stories dating
back to January 1, 1998.

The allEC.com web site offers a comprehensive and easy to navigate site
providing the most up to date electronic commerce:
=B0 Alerts=20
=B0 News=20
=B0 Solutions=20
=B0 Issues=20
=B0 Articles=20
=B0 Products=20
=B0 Research=20
=B0 Updates=20
=B0 Evaluation tools=20
=B0 Links to hundreds of electronic commerce vendors and products=20

The allEC.com Electronic Commerce Resource Centre provides visitors with
hundreds of valuable descriptions and links to consultants, suppliers,
facilitators and other companies working in the electronic commerce domain.

allEC.com reviews and lists electronic commerce related books with direct
links to the Computer Literacy=92s order page, where visitors can order book=
s
at great discount.

The ECommerce Calendar of Events lists trade shows and conferences that are
of interest to the electronic commerce professional.

Thousands of EC industry insiders rely on the allECommerce web site to keep
them current, and visit the site daily.

"allECommerce=92s goal is to provide a single source for anyone wanting to
keep abreast of the burgeoning electronic commerce arena. At allEC.com you
will find the latest news stories from around the world along with links to
the companies that sell products and services to carry out ECommerce on the
Net," boasted Robert Vinet, publisher of allEC.com. "Our popular web site
continues to gain thousand of new and repeat visitors each month. It was
recently updated to add even more features and improved navigation
techniques. Visitors can also participate in the online forum."

Visitors gain free access to allECommerce, without the need to register.
allEC.com is advertiser supported.

To keep its web site as 'open' to all as possible, the editors at allEC.com
chose not to use features that may restrict access through browser choice,
operating system, access speed and so forth.

V-Networks, Inc. is a privately held corporation managed by a team of
web-savvy entrepreneurs.
V-Networks, Inc. is base in Fredericton, New Brunswick, Canada.

Robert Vinet
Publisher
allECommerce
c/o V-Networks, Inc.
527 Beaverbrook Court, Suite 205
Fredericton, NB E3B 1X6
Canada
506 454 7145
[email-masked]
http://www.allEC.com

Date: Fri, 13 Feb 1998 00:26:32 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: non-standard CFB (Re: Lutz formal spec / ROT-13 persists)
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
> By the way, is is really required that PGP's strange CFB mode is
> required for other ciphers that IDEA?

I argued against earlier on list, and argued for the non-standard CFB
to be depracated for all ciphers.  However I think pgp5.x already is
deployed with non-standard CFB for CAST (and I presume 3DES also).

Adam

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Lutz formal spec / ROT-13 persists
Date: 13 Feb 1998 08:31:41 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Black Unicorn wrote:
>At 06:52 PM 2/12/98 GMT, Adam Back wrote:
>>I would suggest in the interests of security that it be removed from
>>the formal spec also.
>
>I was under the impression it was left in for debugging?

So do I.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Extension to packet lengths
Date: 13 Feb 1998 08:30:19 GMT
Organization: IKS GmbH Jena
Lines: 45
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
>> Presently, a length byte of 0xff is interpreted as a partial-length
>> byte with length 2^31 or 2 GB.  We would eliminate this interpretation

>Yes.  Use your approach of prefix of 0xff followed by 4 byte length
>field.  Deprecate all other length field types (except for unknown
>length?)

Yep, this is the comment, but it does not make that sense to me. Hal, what's
the reason behind? Complexity of the parser or laziness of the programmer?

int get_v4len(struct Packet_Frame * pframe, LEXER lexer) {
   int c;

   if((c=(*lexer)(NULL)) != OCTET)  return c;
   
   if((yylval.octet & 0xe0) == 0xe0) {

      pframe->len = 1ul << (yylval.octet & 0x1f); /* 2^0 ... 2^31 */
      pframe->final = 0;	       /* there are more packets */

   } else if((yylval.octet & 0xe0) == 0xc0) {

      pframe->len = (yylval.octet & 0x1f) << 8;

      if((c=(*lexer)(NULL)) != OCTET)  return c;

      pframe->len += yylval.octet + 192;/* 192 ... 8383 */
      pframe->final = 1;	       /* last packet */

   } else if((yylval.octet & 0xc0) == 0x80) {

      pframe->len = 128 + (yylval.octet & 0x3f); /* 128 ... 191 */
      pframe->final = 1;	       /* last packet */

   } else if((yylval.octet & 0x80) == 0x00) {

      pframe->len = yylval.octet & 0x7f;/* 0 ... 127 */
      pframe->final = 1;	       /* last packet */

   }
   
   return OCTET;		       /* successful */
}

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Extension to packet lengths
Date: 13 Feb 1998 08:25:03 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>It is awkward that packets of size greater than 8383 must be broken up
>into pieces and have partial-length bytes inserted into them.  This
>requires reassembly on the receiving end, with the partial-length bytes
>being snipped out.

There is no problem with. A parser is very simple. No I do not see any
reason for complicating this.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: proposed edit ARR
Date: 13 Feb 1998 08:23:30 GMT
Organization: IKS GmbH Jena
Lines: 37
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
> [Declare it reserved.]

I don't like this. I prefer a clear semantics who to deal with:

 10 - symmetric key recovery key (REQUIRED)

      This option consits of a class octet, a asymmetric cryptosystem
      identifier octet, and twenty octets of the fingerprint. The last eight
      octets are the key ID. So only keys of the packet format four or
      higher can be used. This is found on a self-signature.

      The class octet is one, if the use of this recovery key is required.
      If it is zero, the use of this recovery key is up to the user. If data
      is encrypted to such a key, it MUST/MAY (depending on the class octet)
      be encrypted to each recovery key, too.

      Keys containing this subpacket are local storage keys only. They MUST
      NOT be used in communication. They SHOULD be droped from keyrings
      outside the desired storage enviroment to avoid message key recovery.
      They MUST NOT occur on public keyservers. If such a key arrives over
      the Internet, a warning MUST be produced and the key MUST be droped
      (prefered) or disabled locally.

or:

   If the subpacket exists, the key SHOULD be droped, keyservers MUST NOT
   accept the key. If a user likes to respond he MUST get a warning and MAY
   choose from one of the following options:
     - Ignore the request (default/MUST, if no user interaction)
     - Fake a session key matching the IV and padding tests of the
       policy enforcer (which is possible *evil grin*)
     - Use it as requested.

Furthermore I request to reinclude the older proposals key usage, URL,
finger, ... (texts avail)

Date: Fri, 13 Feb 1998 13:33:34 +1100 (EST)
From: David Formosa <[email-masked]>
To: Adam Back <[email-masked]>
cc: [email-masked]
Subject: Re: Lutz formal spec / ROT-13 persists
Sender: [email-masked]

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

On Thu, 12 Feb 1998, Adam Back wrote:

> I that the inclusion of ROT-N was a joke on the part of Jon Callas,
> and that it had been removed from the draft.

I beleave that as ROT-N has the property of being able to calculated in
side a persons head it should be retained for debugging.  

> I would suggest in the interests of security that it be removed from
> the formal spec also.

As ROT-N is a MAY requiremnt, just an entery on a table I do not beleave
that it would reduce security.  If you are afread that it would be used in
production code perhaps we should inculde a warning in the RFC about
its use.

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

Date: Thu, 12 Feb 1998 18:00:55 -0600
To: Adam Back <[email-masked]>, [email-masked]
From: Black Unicorn <[email-masked]>
Subject: Re: Lutz formal spec / ROT-13 persists
Sender: [email-masked]

At 06:52 PM 2/12/98 GMT, Adam Back wrote:
>
>I noticed as a result of Lutz quoting a section from his OpenPGP
>formal spec to cypherpunks that it still refers to ROT-13 (he refers
>to ROT-N).
>
>I that the inclusion of ROT-N was a joke on the part of Jon Callas,
>and that it had been removed from the draft.
>
>I would suggest in the interests of security that it be removed from
>the formal spec also.

I was under the impression it was left in for debugging?

Date: Thu, 12 Feb 1998 23:08:52 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Lutz formal spec / ROT-13 persists
Sender: [email-masked]

Adam Back <[email-masked]> writes:

> I noticed as a result of Lutz quoting a section from his OpenPGP
> formal spec to cypherpunks that it still refers to ROT-13 (he refers
> to ROT-N).

So what about replacing it by Blowfish with 160 bit key ?

Lutz told me that he votes against this, because we can't have values
for each key length.  I know that the keylength can be derived from the
DEK but there is no way to do this when using the cipher e.g. for secring
protection.

By the way, is is really required that PGP's strange CFB mode is required
for other ciphers that IDEA?

-- 
Werner       

                                 G10 key at ftp.guug.de/pub/gcrypt/pubring.g10
              fingerprint = 8489 6CD0 1851 0E33 45DA  CD67 036F 11B8 FF3E AA0B

Date: Thu, 12 Feb 1998 20:19:53 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Extension to packet lengths
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> We would add an optional four-byte length encoding, which would be
> indicated by having the first byte be 0xff.  When this is the first
> byte of the length field, it would mean that the following four
> bytes would be the length of the packet.
> 
> Presently, a length byte of 0xff is interpreted as a partial-length
> byte with length 2^31 or 2 GB.  We would eliminate this interpretation
> in favor of the new one.  This is only a small loss of functionality,
> since if partial-length packets are being used, the pieces will
> probably be much smaller than 2 GB.
> 
> Comments?

Yes.  Use your approach of prefix of 0xff followed by 4 byte length
field.  Deprecate all other length field types (except for unknown
length?)

Adam

Date: Thu, 12 Feb 1998 18:49:39 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: proposed edit (Re: OpenPGP WG meeting minutes)
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> Adam Back At 12:53 AM 1/30/98 GMT, wrote:
>    Would it help if some one wrote a few sentences of specific wording to
>    put in there?
>    
> Yes, please. It is *always* better to provide a few sentences or a
> paragraph, because then I don't have to guess.

[Editing note: lines prefixed with '-' indicate deletion, prefixed
with '+' indicate addition, and '!' indicate leave as is].

OK, here we go, I propose replacing signature subpacket 10 which is
currently listed as:

-           10 = additional recipient request,

with:

+           10 = reserved,

and replacing this text:

-     Additional recipient request (1 octet of class, 1 octet of algid, 
-                                   20 octets of fingerprint) (Hashed)
- 
- Key holder requests encryption to additional recipient when data is
- encrypted to this username.  If the class octet contains 0x80, then the
- key holder strongly requests that the additional recipient be added to
- an encryption.  Implementing software may treat this subpacket in any
- way it sees fit. This is found only on a self-signature.

with:

+     Reserved
+
+ This subpacket is reserved for historic reasons.  The critical bit if
+ set should be ignored for this subpacket.  This stipulation is to
+ assure interoperability.

and adding after this text:

! Bit 7 of the subpacket type is the "critical" bit.  If set, it implies
! that it is critical that the subpacket be one which is understood by
! the software.  If a subpacket is encountered which is marked critical
! but the software does not understand, the handling depends on the
! relationship between the issuing key and the key that is signed.

+ Note the critical bit should be ignored for signature subpacket 10.
+ See section 5.2.2.2.

Are there any other references which need to be fixed to tie in?

> In this particular case, I don't understand the problem that we're trying
> to solve, nor what the solution is.

The problem we are trying to solve is PGP Inc's ARR packet.  A
document describing the security and political problems with the ARR
subpacket can be found here:

	http://www.dcs.ex.ac.uk/~aba/cdr/

Or you consult the archives for the volumes of previous discussions,
or I am sure we go over the discussion again if required.

Adam

Date: Thu, 12 Feb 1998 20:14:00 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PRZ style CFB mode description preferences
Sender: [email-masked]

Some time ago Hal asked which of two descriptions for the CFB mode
Phil Zimmermann invented were preferred.  (The CFB mode in summary
does not use a fixed feedback length in bits, as is normal, but varies
that feedback length at semantic boundaries in the plaintext).

My preference is greatly for the description referring to the bulk of
the data encryption as CFB-64, and the re-syncs as having CFB-16
applied to them.  (Or CFB-whatever).

Adam

Date: Thu, 12 Feb 1998 18:52:39 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: Lutz formal spec / ROT-13 persists
Sender: [email-masked]

I noticed as a result of Lutz quoting a section from his OpenPGP
formal spec to cypherpunks that it still refers to ROT-13 (he refers
to ROT-N).

I that the inclusion of ROT-N was a joke on the part of Jon Callas,
and that it had been removed from the draft.

I would suggest in the interests of security that it be removed from
the formal spec also.

(Hal suggested this comment be reposted here, as the discussion was in
cypherpunks, and some may not read cypherpunks).

Adam

Date: Thu, 12 Feb 1998 10:30:07 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Extension to packet lengths
Sender: [email-masked]

Currently we have two mechanisms for expressing the lengths of packets,
described in section 4.2 of the spec.

The "old" method, from PGP 2.X, uses a length-of-length field in the
low order two bits of the CTB.  This field tells whether the following
one, two, or four bytes contain the length of the packet (or whether
the packet is indefinite-length, meaning that it occupies all remaining
space in the input).

The "new" method, introduced in PGP 5.0 to free up bits in the CTB and
to support one-pass processing, uses a self-delimiting length value.
If the length is less than 192, it is expressed as one byte.  If it is
from 192 to 8383, it is expressed as two bytes with a certain
encoding.  Packets of length 8384 bytes and up, along with packets for
which the length is not known in advance, are divided into pieces
which are powers of two, and each piece is preceded by a partial-length
byte, which is 0xe0 plus the log base 2 of the size of the piece.

It is awkward that packets of size greater than 8383 must be broken up
into pieces and have partial-length bytes inserted into them.  This
requires reassembly on the receiving end, with the partial-length bytes
being snipped out.

I propose that we modify the new encoding slightly so that we can easily
express packet lengths larger than 8383 bytes.  We would add an optional
four-byte length encoding, which would be indicated by having the first
byte be 0xff.  When this is the first byte of the length field, it would
mean that the following four bytes would be the length of the packet.

Presently, a length byte of 0xff is interpreted as a partial-length
byte with length 2^31 or 2 GB.  We would eliminate this interpretation
in favor of the new one.  This is only a small loss of functionality,
since if partial-length packets are being used, the pieces will
probably be much smaller than 2 GB.

Comments?

Hal Finney
PGP, Inc.
[email-masked]

Date: Wed, 11 Feb 1998 00:00:23 -0500
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: REMINDER: ISOC 1998 Network and Distributed Security Symposium
Sender: [email-masked]

--=====================_887191223==_
Content-Type: text/plain; charset="us-ascii"

Ok, now that I got your attention, here's the missing text ...

--=====================_887191223==_
Content-Type: text/plain; charset="us-ascii"

1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
March 11-13, 1998
Catamaran Resort Hotel
San Diego, California
Sponsored by the Internet Society
Program Chairs:  Matt Bishop, University of California at Davis
		 Steve Kent, BBN Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss98
EARLY REGISTRATION DISCOUNT DEADLINE:  February 13, 1998

This 5th annual Symposium brings together researchers, implementers,
and users of network and distributed system security technologies
to discuss today's important security issues and challenges.  The
Symposium provides a mix of technical papers and panel presentations
that describe promising new approaches to security problems that
are practical and, to the extent possible, have been implemented.
NDSS'98 fosters the exchange of technical information and encourages
the Internet community to deploy available security technologies
and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security 
Products Group at Bell Laboratories, Lucent Technologies

THIS YEAR'S TOPICS INCLUDE:
- Internet and Intranet security
- Implementation issues for electronic commerce
- All-optical networks security
- Secure single login
- Timestamping protocols
- Remote password protocols
- Mobile agent systems security
- Java security
- Trust management
- Traffic analysis of TCP gateways
- Secure bootstrapping
- Firewalls and IP security

NEW THIS YEAR!  PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Kerberos  (Jeffrey I. Schiller, MIT)
- Internet Security with Firewalls  (Fred Avolio, TIS)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)

FOR MORE INFORMATION contact the Internet Society:
     Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
     Phone: +1 703 648 9888
     Fax: + 1 703 648 9887
     E-mail: [email-masked]
     URL: http://www.isoc.org/ndss98/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn P. Brazell at the Internet Society
at +1 703 648 9888 or send e-mail to [email-masked].  
Sponsorship Chair: George Conrades, GTE Internetworking

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

--=====================_887191223==_--

Date: Tue, 10 Feb 1998 18:33:29 -0500
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: REMINDER: ISOC 1998 Network and Distributed System Security Symposium
Sender: [email-masked]

----------------------------------------------------------------------------
David M. Balenson, AR&E Cryptographic Technologies Group
Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363

Date: Mon, 09 Feb 1998 11:23:28 -0800
To: Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: proposed edit (Re: OpenPGP WG meeting minutes)
Cc: [email-masked]
Sender: [email-masked]

I accidentally did a reply instead of reply-all. This is a resend, sorry.

At 12:53 AM 1/30/98 GMT, you wrote:
   
   Otherwise would the active editor of said document be interested to
   amend the document appropriately and post the suggested ammendment for
   approval.
   
   Would it help if some one wrote a few sentences of specific wording to
   put in there?
   
Yes, please. It is *always* better to provide a few sentences or a
paragraph, because then I don't have to guess.

In this particular case, I don't understand the problem that we're trying
to solve, nor what the solution is.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 555 Twin Dolphin Drive
Network Associates, Inc.                    Suite 570
(415) 596-1960                              Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 4 Feb 1998 10:39:25 -0500 (EST)
From: Judie Mulholland <[email-masked]>
To: [email-masked]
Subject: announcing E-CARM, a new mailing list
Sender: [email-masked]

Our apologies for any cross posting, but we are anxious to get the word
out asap :)

----------------------------------------------------------------------	
	      Announcing the creation of a new mailing list:

	     ***E-COMMERCE AND RIGHTS MANAGEMENT (E-CARM)***
		                    
----------------------------------------------------------------------

This mailing list has been established to foster and support an on-line
discussion forum where we can:

	* debate (non) technical, administrative and managerial issues
   	  pertaining to: secure transactions, competing rights management 
	  models (e.g. ECMS, PICS, certificates, FIRM, etc.), evolving
	  standards, supporting technologies and other approaches for
	  enabling electronic commerce;
	* inform each other about upcoming conferences, workshops, etc.
	* point to online papers, resources/links, new apps, web
	  sites, etc.
	* identify the critical factors relevant to design, development
	  and implementation of a rights management infrastructure;
	* raise questions, share problems, relate concerns;
	* share success/horror stories;
	* and much, much more ...

If you are interested in subscribing to this list, please send a message
to:

<[email-masked]>

with the following line in body of the message (NOT the subject):

subscribe e-carm "FirstName LastName" (without the quotation marks)

and after you are notified that you have been subbed, we would ask that
you send a short note to the list, briefly introducing yourself and your
interests in e-commerce and rights management so that we can begin to come
together as a community of shared interest(s).

E-CARM is intended to be a member-driven, open, collaborative mailing
list. However, its success in creating a viable on-line forum will
depend on individual contributions. As a step in this direction, we
encourage you to share this announcement with other mailing lists or
anyone who may be interested in getting involved.

Looking forward to seeing all of you on E-CARM,

Judie Mulholland
Rajiv Kaushik

List Moderators

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Current version of formal draft
Date: 3 Feb 1998 18:53:39 GMT
Organization: IKS GmbH Jena
Lines: 32
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

Some of you noticed, that the formal version is under constant development.
I made some special changes, that's why I droped this note. Please feel free
to discuss it here.

1998-02-03:
  Removed PGP5 workaround, published a format converter instead.
  Simplified the lexer. It returns only tokens.
  Added Literal Data semantics.
  Started with compressed data (included zlib)

1998-01-30:
  Removed "debugging" output
  Finished public key packet

1998-01-28:
  Added a switch for PGP5 handling. Will be removed in the final version.
  Added more "debugging" output and worked on signature subpackets.

1998-01-27:
  First public edition.
  Complete rewrite of the lexer (removing the stateful all-in-one lexer)

1997-12-0?:
  Phoned with John W. Noerenberg:
    Got his ACK for writing a formal specification containing a syntax and
    semantic definition in a machine readable format.
  This specification will be a reference implementation:
    - not fast
    - proofable correct (necessary for CA and gouvernmental use
                         by European (German) laws)
  If a specification and a program are nearly the same, the formal proof
  of correctness and termination is much easier.

Date: Tue, 3 Feb 1998 09:15:49 -0800 (PST)
From: Yahya Al-Salqan <[email-masked]>
Reply-To: Yahya Al-Salqan <[email-masked]>
Subject: Enterprise Security
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-MD5: s65u0q6BDLuzuKezUo+VGQ==
Sender: [email-masked]

Dear Colleague,=20

This mail is to direct your attention to the Third International
Workshop on Enterprise Security, to be held on June 17-19, 1998
at Stanford University, California, USA. Deadline for paper=20
submissions is February 27, 1998.=20

Please accept my apologies if you receive this message more than once.

Enclosed is the Call For Papers. Your help in distributing the=20
CFP to interested parties would be greatly appreciated.

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

                           CALL FOR  PAPERS
                          *EXTENSION NOTICE*
                Submission deadline: February 27, 1998

         Third International Workshop on Enterprise Security
                           June 17-19, 1998
                 Stanford University, California, USA

       Sponsored by the IEEE Computer Society and CERC at West
    Virginia University. Hosted by the Center for Design Research,
                         Stanford University.

  This document is also available in HTML and Postscript formats as
           http://www.ida.liu.se/labs/iislab/SECWK/cfp.html
                                and
            http://www.ida.liu.se/labs/iislab/SECWK/cfp.ps

Enterprises are becoming increasingly dependent on their information
systems to support their business and workflow activities.  There is a
need for universal electronic connectivity to support interaction and
cooperation between multiple organizations. This makes enterprise
security and confidentiality more important but at the same time more
difficult to achieve, as the multiple organizations may have
differences in their security policies and may have to interact via an
insecure Internet.

These inter-organizational enterprise systems may be very large,
efficient tools, techniques and methodologies are therefore needed to
support the specification, analysis and implementation of security.
This workshop will focus on the problems and challenges relating to
enterprise security in inter-organizational systems. We aim to bring
together principal players from both the internetwork and the
enterprise security community and will provide plenty of time for
discussion.

Topics to be discussed include:
-------------------------------
Internet security:
* Security protocols for the Internet
* The work and efforts of IETF security groups
* Global key infrastructures

Distribution:
* Distributed database security
* Secure transactions
* Inter- and intra-organizational security
* Security of collaborative applications

Secure infrastructures:
* Secure applications and environments
* Object-oriented and CORBA Security
* Secure enterprise infrastructures
* Security algorithms
* Public key infrastructures

Security management:
* Role-based access control
* Enterprise security policies
* Security in workflow processes

The program committee welcomes both papers and panel proposals
covering these topics. =20

SUBMISSIONS
-----------

Authors should submit six copies of an original paper (not submitted
or published elsewhere) to one of the Program Co-Chairs. Electronic
submissions are also accepted via the World Wide Web. Instructions
and forms are availabe at http://iispc2.ida.liu.se/SECWK/ .

Submissions should include the title of the paper, the name and
affiliation of each author, a 150-word abstract, and no more than 8
keywords. Submissions should not exceed 3000 words in length.  The
name, position, address, telephone number, and if possible, fax number
and e-mail address of the author responsible for correspondence must
be included.

A representative selection of accepted papers will published in the
workshop post-proceedings. Papers accepted for publication in the
proceedings are limited to six pages (about 2000-2500 words) in IEEE
format (two columns, single spaced, 10pt Times). Authors are strongly
encouraged to adhere to this format also when submitting
papers. Detailed information on the IEEE format (together with some
templates) is available at http://www.computer.org/cspress/instruct.htm=20

PANEL PROPOSALS
---------------

Send six copies of panel proposals to the Program Chair. Include a
title, a 150-word scope statement, proposed session chair and
panelists and their affiliations, the organizer's affiliation,
address, telephone and fax number, and e-mail address.

GENERAL CHAIR
-------------

Yahya Al-Salqan
Sun Microsystems
901 San Antonio Rd
Palo Alto, CA 94303
USA
E-mail: [email-masked]

PROGRAM CO-CHAIRS
-----------------

Nahid Shahmehri
Dept. of Computer Science
Link=F6ping University
S-581 83 Link=F6ping
SWEDEN
E-mail: [email-masked]

Douglas Maughan
National Security Agency, R23
9800 Savage Rd.
Ft. Meade, Maryland 20755-6000
USA
E-mail: [email-masked]

WORKSHOP PROGRAM COMMITTEE
--------------------------

Takashi Arno, NTT Corp., Japan
William Cheng-Chung Chu, Feng Chia University, Taiwan
Barbara Davis, Applied Knowledge Group, USA
Mourad Debbabi, Laval University, Canada
Germano Caronni, Computer Engineering and Networks Laboratory,=20
                 ETH-Zentrum, Switzerland
Dima Hamad, Birzeit University, West Bank
Takeo Hamada, Fujitsu, USA
Adel Jaber, Certicom, USA
Takuro Kubo, NTT America Multimedia Communications Lab, USA
Steve Lloyd, Entrust Technologies, Canada
Jeff Parrett, PeopleSoft, USA
Lisa Pretty, Certicom, Canada
Sumitra Reddy, West Virginia University, USA
Vipin Samar, Oracle, USA
Bill Soley, Sun Microsystems, USA
Robert Thomys, BSI (Federal Department of Security in=20
               Information Technology), Germany
Bradley Wood, Sandia National Lab, USA
Felix Wu, North Carolina State University, USA
Qun Zhong, HP, UK
Tatu Yl=F6nen, SSH Communications Security, Finland
Randy Chow, University of Florida, USA

IMPORTANT DATES
---------------

Papers and panel proposals due  February 27, 1998
Authors notified of acceptance  April 6, 1998
Advance Registration            May 17, 1998
Workshop                        June 17-19, 1998
Camera ready manuscripts due    June 30, 1998

INQUIRIES
--------- =20

Pleas send all inquiries regarding this workshop to the General=20
Chair or to one of the co-chairs.

For inquires regarding WET ICE in general, contact=20
[email-masked] or call (U.S.) +1-304-293-7226.