Enterprise Security

Dear Colleague, 

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 
submissions is February 27, 1998. 

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

Enclosed is the Call For Papers. Your help in distributing the 
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

Current version of formal draft

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)

announcing E-CARM, a new mailing list

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:

Re: proposed edit (Re: OpenPGP WG meeting minutes)

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                                  jon <at> pgp.com
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)

REMINDER: ISOC 1998 Network and Distributed System Security Symposium

----------------------------------------------------------------------------
David M. Balenson, AR&E Cryptographic Technologies Group
Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738  USA
balenson <at> tis.com; 301-854-5358; fax 301-854-5363

REMINDER: ISOC 1998 Network and Distributed Security Symposium

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

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

Extension to packet lengths

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

Lutz formal spec / ROT-13 persists

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

Re: proposed edit (Re: OpenPGP WG meeting minutes)

Jon Callas <jon <at> pgp.com> 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

PRZ style CFB mode description preferences

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