Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000)

From: "David M. Balenson" <[email-masked]>
Date: Tue, 26 Oct 1999 16:46:23 -0400 (EDT)

R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 2000

The 7th annual NDSS 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 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: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- Intrusion Detection Research, Instructor TBD

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: +1-703-326-9880         Fax: +1-703-326-9881
  E-mail: [email-masked]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at +1-703-326-9880 or send e-mail to [email-masked].

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

Date: Tue, 26 Oct 1999 16:46:23 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000)
Sender: [email-masked]

                  R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 2000

The 7th annual NDSS 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 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: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- Intrusion Detection Research, Instructor TBD

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: +1-703-326-9880         Fax: +1-703-326-9881
  E-mail: [email-masked]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at +1-703-326-9880 or send e-mail to [email-masked].

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

Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 26 Oct 1999 22:12:46 +0200 (CEST)
From: Eurocrypt 2000 <[email-masked]>
To: [email-masked]
Subject: Eurocrypt 2000 submission deadline: November 3, 1999
Sender: [email-masked]

-------------------------------------------------------------
                  E U R O C R Y P T    2 0 0 0
                         May 14-18, 2000
                    Bruges (Brugge), Belgium

     http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
-------------------------------------------------------------

This is a reminder that the submission deadline for 
Eurocrypt 2000 is November 3, 1999. 

Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ 
for more information.

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

From: [email-masked]
Date: Sun, 24 Oct 1999 14:18:38 -0700
To: "Jacques Exelrud" <[email-masked]>
Subject: Re: PGP X GPG
Sender: [email-masked]

At 7:07 PM -0300 1999-10-23, Jacques Exelrud wrote:
>Any pgp user here ?
>What I must keep in mind if I will be using PGP and GPG with the same
>keys ?
>Which one is the one I should use to generate the keys ?

Hi Jacques,

The short answer is: watch out for expired subkeys generated in PGP
that are used in GPG.

An IETF working group's list is not an appropriate place these kinds
of questions but it's a good question for
<[email-masked]>.

    dave

From: "Jacques Exelrud" <[email-masked]>
To: <[email-masked]>
Subject: PGP X GPG
Date: Sat, 23 Oct 1999 19:07:36 -0300
Sender: [email-masked]

    Any pgp user here ?
    What I must keep in mind if I will be using PGP and GPG with the
same keys ?
    Which one is the one I should use to generate the keys ?
    Jacques

    Join us at the largest compute on Earth
    http://www.distributed.net    Team #198
    http://www.iGive.com/html/ssi.cfm?cid=1098&mid=3257
    http://www.thehungersite.com

From: [email-masked]
To: [email-masked]
Date: Fri, 22 Oct 99 14:31:36 EST
Subject: Your Web Page
Sender: [email-masked]

Increase your Web Site visiblity !

Try out :

*** Proven Web Page Optimisation Software ***
>> Audited results 55% Number 1  90% top 5 <<

*** Macro Media Web Page Design Software ****
  >>> Make your Web Pages sparkle <<<<

**** Accept checks from your Web Site *****
 >>>> Improve your margins & Cashflow <<<<

 Go to :  
http://www.pcpages.com/bizzinews/

 ++++ Sender & Remove Instructions ++++
Free Business Links
Bevere Close
Worcester
Tel 121 643 2448
Email : [email-masked]
++++++++++++++++++++++++++++++++++++

Date: Mon, 18 Oct 1999 18:41:12 -0700
To: Jon Callas <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: Moving forward
Cc: Werner Koch <[email-masked]>, [email-masked], Thomas Roessler <[email-masked]>
Sender: [email-masked]

At 10:58 PM -0700 1999-10-17, Jon Callas wrote:
>[...]
>A summary of the problem is that that 2440 does not cover the case where
>a clear-signed message does not end with a CRLF or is of length zero.
>
>My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
>just declare that that's bad? If a clear-signed message isn't
>CRLF-terminated, add one. This also handles the zero-length case, because
>that just becomes a single blank line.
>
>I admit that it never occurred to me that you COULD have a clear-signed
>message with no CRLF.

My memory may be faulty, but I believe that both RFC 1991 and our
OpenPGP/MIME draft simply implicitly assume that you can't have a
length-zero message, because it makes no sense to provide a digital
signature on _nothing_. You can't even use such a zero-length message
to verify someone's ownership of a _key_, which you could do with a
one-byte (i.e. one char) clearsigned message.
>This just strikes me as aesthetically bad that the END header could
>dangle at the end of a line, and contrary to the intent of
>cleartext, if not its stated or implied definition. This seems to me
>to hinge on the definition of "canonical text-mode" text, and I
>always thought that canonical text-mode text always ended with a
>line end. Am I wrong on this?             [...]

No, the armoured footer line should (always) be preceded by a CRLF.
You're right that it's an imperative for implementors to ensure this.

    dave

___________________________________________________________________________
The Shortest Correspondence on Record, sent by a 19th C. writer on vacation
via telegraph to his Publisher, inquiring about sales of his new novel: "?"
The answer came back shortly, also by Morse Code: "!"

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 5168DF202; Tue, 19 Oct 1999 12:03:38 +0200 (MEST)
Date: Tue, 19 Oct 1999 12:03:37 +0200
From: Thomas Roessler <[email-masked]>
To: Dave Del Torto <[email-masked]>
Cc: Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, [email-masked]
Subject: Re: Moving forward
Message-ID: <[email-masked]>
Mail-Followup-To: Dave Del Torto <[email-masked]>, Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, [email-masked]
References: <[email-masked]> <v04210129b42acfba01e3@[63.73.97.169]> <v04220706b4317946db90@[204.179.136.37]>
Mime-Version: 1.0
User-Agent: Mutt/0.96.8i
In-Reply-To: <v04220706b4317946db90@[204.179.136.37]>; from [email-masked] on Mon, Oct 18, 1999 at 06:41:17PM -0700
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-ID: <ietf-open-pgp.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

On 1999-10-18 18:41:17 -0700, Dave Del Torto wrote:

> At 10:58 PM -0700 1999-10-17, Jon Callas wrote:

> >A summary of the problem is that that 2440 does not cover the case where
> >a clear-signed message does not end with a CRLF or is of length zero.

As I read the text, it does (RFC 2440, 7.1):

|   As with binary signatures on text documents, a cleartext
|   signature is calculated on the text using canonical <CR><LF> line
|   endings.  The line ending (i.e. the <CR><LF>) before the
|   '-----BEGIN PGP SIGNATURE-----' line that terminates the signed
|   text is not considered part of the signed text.

Actually, the construction is analogous to what MIME does with
multipart separator lines, see RFC 2046 section 5.1.1:

|   NOTE: The CRLF preceding the boundary delimiter line is
|   conceptually attached to the boundary so that it is possible to
|   have a part that does not end with a CRLF (line break).  Body
|   parts that must be considered to end with line breaks, therefore,
|   must have two CRLFs preceding the boundary delimiter line, the
|   first of which is part of the preceding body part, and the second
|   of which is part of the encapsulation boundary.

That is, OpenPGP implementations MUST add

		  <cr><lf><delimiter line><cr><lf>

when creating cleartext signatures, and MUST calculate the signature
over the text PRECEDING the <cr><lf> sequence which starts the
separator.

Thus, a "-----BEGIN PGP SIGNATURE-----" delimiter without a
preceding CRLF is just nonsense, and possibly part of signed text.

A quick test with pgp 2.6.3in, gpg 0.9.8a-snap1999-06-30, and pgp5
("PGP for Personal Privacy Version: unix50i1b") indicates that at
least these implementations actually seem to be working the way
suggested by the text and the analogy with MIME.

More precisely, I generated a simple text file which lacked the
final new line character.  I clearsigned it with pgp 2.6.3in.  The
signature was correctly verified by pgp2, gpg, and pgp5.  Then, I
added another new line in front of the delimiter line, and all
implementations correctly warned me that this was a bad signature.

> My memory may be faulty, but I believe that both RFC 1991 and our
> OpenPGP/MIME draft simply implicitly assume that you can't have a
> length-zero message, because it makes no sense to provide a digital
> signature on _nothing_.

In the PGP/MIME draft, we don't really have to deal with this, since
we just take what MIME gives us, make sure MIME line endings are
correct (namely CRLF), and pass the rest to PGP.  

Additionally, with PGP/MIME, there is always at least one CRLF to be
signed: A multipart/signed MIME body MUST have two subparts, the
first of arbitrary type, the second of type
application/pgp-signature.  Since the signature is calculated over
the MIME representation of the first body part, our worst case is an
empty text/plain body part, including headers.  This can (worst case
again) be represented by one empty line which terminates
the (empty) MIME header.

Example:

| From: Thomas Roessler <[email-masked]>
| To: Thomas Roessler <[email-masked]>
| Subject: stupid test message
| Message-ID: <[email-masked]>
| Mime-Version: 1.0
| Content-Type: multipart/signed; micalg=pgp-md5;
| 	protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q"
|
| 
| --Q68bSM7Ycu6FN28Q
| 
| 
| --Q68bSM7Ycu6FN28Q
| Content-Type: application/pgp-signature
| 
| -----BEGIN PGP MESSAGE-----
| Version: 2.6.3in
| 
| iQEVAwUBOAxAbNImKUTOasbBAQGcxQf+KhjjzhxUo2RTCauKm+5znAXFWOtZAyVe
| 3mxuRJvJPDTjocEo/aDwHzekhqssLhPI0LD62R96LvKHM6nbYRJyG4pByf8VH2lI
| C2bWpSw7QFqBjJgBC8Z6+qD/hAdvdNbduNJ2kUPiX8npuVdj8RyWNDJ3xyk+TPQh
| vTbnGjwAeIgnygstZpKW8feBMFLi3SZ57qlc1Gen5r1srruNPYykPUoqpmjROe9j
| r6U4P17V1aKUzJts/b4RF+MKiO3ebQf5NbplWkMVvqdR0VNOYpddDZiqzYMkoIYb
| 3TcMUAzGcp1iRetd5mIezcJKJ6bIgPwdaZyvbuAW8lQ8LhZkn5uqqg==
| =37F7
| -----END PGP MESSAGE-----
| 
| --Q68bSM7Ycu6FN28Q--

Date: Mon, 18 Oct 1999 18:41:17 -0700
To: Jon Callas <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: Moving forward
Cc: Werner Koch <[email-masked]>, [email-masked], Thomas Roessler <[email-masked]>
Sender: [email-masked]

At 10:58 PM -0700 1999-10-17, Jon Callas wrote:
>[...]
>A summary of the problem is that that 2440 does not cover the case where
>a clear-signed message does not end with a CRLF or is of length zero.
>
>My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
>just declare that that's bad? If a clear-signed message isn't
>CRLF-terminated, add one. This also handles the zero-length case, because
>that just becomes a single blank line.
>
>I admit that it never occurred to me that you COULD have a clear-signed
>message with no CRLF.

My memory may be faulty, but I believe that both RFC 1991 and our
OpenPGP/MIME draft simply implicitly assume that you can't have a
length-zero message, because it makes no sense to provide a digital
signature on _nothing_. You can't even use such a zero-length message
to verify someone's ownership of a _key_, which you could do with a
one-byte (i.e. one char) clearsigned message.
>This just strikes me as aesthetically bad that the END header could
>dangle at the end of a line, and contrary to the intent of
>cleartext, if not its stated or implied definition. This seems to me
>to hinge on the definition of "canonical text-mode" text, and I
>always thought that canonical text-mode text always ended with a
>line end. Am I wrong on this?             [...]

No, the armoured footer line should (always) be preceded by a CRLF.
You're right that it's an imperative for implementors to ensure this.

    dave

___________________________________________________________________________
The Shortest Correspondence on Record, sent by a 19th C. writer on vacation
via telegraph to his Publisher, inquiring about sales of his new novel: "?"
The answer came back shortly, also by Morse Code: "!"

Date: Tue, 19 Oct 1999 10:34:40 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Moving forward
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> I'm starting the task of updating 2440. I need to find an uninterrupted day
> or two to do it properly. However, the main thing the working group really

That is good news.  Hope you will find the time.

> me that is loathe to rush on with mods to 2440 presently. I'd rather see
> 2440 become a standard than slow the whole process down by adding features,

So do I.

> A summary of the problem is that that 2440 does not cover the case where a
> clear-signed message does not end with a CRLF or is of length zero.
> 
> My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
> just declare that that's bad? If a clear-signed message isn't

This is okay for me.  If it is in the standard I have an easy answer
to those bug reports.  A clear signed message is not intended to be
in the first place machine readable but for humans and they don´t care
about an appended blank line.

> hinge on the definition of "canonical text-mode" text, and I always thought
> that canonical text-mode text always ended with a line end. Am I wrong on
> this?

No. 

> * One hash algorithm or many? My opinion is one, and that should be SHA-1.
> We don't need the full capability of the hash algorithm the way signatures

Go ahead and specify SHA-1 as the only one hash algorithm to be used.

I even give up on my request to add a version number to the new
packet.  The only thing I'd really like is to have the hash prefixed
with some bytes which can be interpreted as a packet (new type or
a signature packet of version 0) and the length of the encrypted 
packet given without this hash.  This way an implementor can choose
between:

  a) assume this is one packet (simply adding the fixed size of
     the hash packet to the length given in the header or reading
     these additional bytes in case of a partial length header).

  b) handle them as 2 packets with no need to defer the hashing of
     the encrypted packet by the length of the hash.

> Consequently, in spite of the fact that I have no particular love for
> PGP-CFB mode, I say we just run with it, in the interests of simplicity and
> speed.

I agree.

> The best thing to do would be for someone to write a PGP-CFB mode wrapper
> that could be applied to a number of ciphers. Ideally, this would be

I am not sure whether I understand this correct:  Do you mean a thing
to decrypt PGP-CFB and encrypt it using standard CFB?

> * We have to design an Optional Features Subpacket. This is a subpacket
> that goes in a self-signature that states that the certholder would
> understand an MDC message should one be sent to them. It's not really that

Should it go as a hashed subpacket?  This would put a burden on the user to
update his self-signature - no big issue but it can't be automatized
by a new version of an implementation.  So in addition to this feature
subpacket (which is a good idea), what about a requirement (we already
discussed this) that for cipher algorithms with a blocksize other than
64 bit the use of the new MDC packet is a SHOULD (or MUST).  This will
be a good thing for the AES algorithm and Twofish.  It won't do any
harm.

> To show that I'm an equal-opportunity ox-gorer in the name of simplicity,
> do we need the large signature packet? Do we need it now? My opinion is

No we don't need them.  I still don't thing that huge signatures are a
good thing - it makes a lot of trouble to handle them the same way as
usual signatures; the signed stuff should better go into a literal
data packet.  And yes, I know that there is the PGP ticket project but
we shouldn't discuss this now.

> that we need it, but not now. It's far more important that we get
> implementations to support 2440 than anything else. I'm willing to put it

Another thing for the optional feature packet ;-)

> close. Tom Zerucha's reference implementation, and GnuPG. The main thing I
> can think of for us to do is to show that they implement 2440, and
> interoperate.

How can we do this?  Do we need to meet physically and if, does it need to
happen in the U.S. (due to export control rules)?  Is someone still
working on a check list?

> >  - Do we have a way to specify private extensions for the S2K
> >    (I am thinking about hardware tokens).
> >
> No, we do not. Do we need them? Do you want to suggest an architecture?
> Should I issue a plea for simplicity?

I think it is a good idea to reserve some IDs for experiments, as we
did for ciphers etc. - In case such experimental packets have leaked
out and later revisions of the standard use the same IDs for another
purpose a user has not a good chance to identify this problem.

So I'd suggest to add just this:

3.6.1.4. Reserved S2K Identifiers

   Identifiers with a first octet in the range [0x64, 0x64] are
   reserved for private/experimental S2K algorithms.  

  Werner

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

Date: Tue, 19 Oct 1999 10:37:45 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Moving forward
Sender: [email-masked]

Tom Zerucha <[email-masked]> writes:

> Alternately, say these new packets MUST use the old format CTBs, so the
> length is in the header, so I can subtract 20.

No! Please don't even thing about this.  We would loose the ability to
encrypt a stream directly.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

Date: Mon, 18 Oct 1999 23:09:42 -0400 (EDT)
From: Tom Zerucha <[email-masked]>
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Moving forward
Sender: [email-masked]

On Sun, 17 Oct 1999, Jon Callas wrote:

> The best thing to do would be for someone to write a PGP-CFB mode wrapper
> that could be applied to a number of ciphers. Ideally, this would be
> open-sourced. And no, I don't mean GPLed. I mean true open source, where
> anyone could do anything with it.

my opgp has such a wrapper routine and has no usage restrictions (and the
only modification restriction is that it must be documented or
disassociated).

> The MDC packet looks exactly like the encrypted data packet, but it has 20
> bytes of SHA-1 at the end. I've described the feature subpacket above.

As long as the 20 bytes are appended to the packet (i.e. are outside), not
the data.

I want a virtual EOF when I come to the end of encrypted data.

Alternately, say these new packets MUST use the old format CTBs, so the
length is in the header, so I can subtract 20.

Date: Mon, 18 Oct 1999 07:55:06 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked], Jon Callas <[email-masked]>
cc: Werner Koch <[email-masked]>
Subject: Re: Moving forward
Sender: [email-masked]

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

On Sun, 17 Oct 1999, Jon Callas wrote:

> At 10:19 AM +0200 10/12/99, Werner Koch wrote:
> 
> >the list is very quite for a long time now.  So I want to raise some
> >issues again which are still unsolved:
> 
> I'm starting the task of updating 2440. I need to find an uninterrupted day
>...

Along these lines...

At the request of John Noerenberg, I had created a 'Laundry List' of
features to work on for OpenPGP (v1.1). The list was discussed in Orlando
and some items were dropped. I have not updated the list since its original
creation last year.

Now that we are talking about new features, etc. Is there a need to
maintain this web page? If so, I will get on with updating it based on what
I have seen on the list in the past couple of days. For anyone who is
interested, the list is at:

http://hardees.rutgers.edu/~mione/ietf/OpenPGPv11LaundryList.html

Please indicate if I should make an attempt to bring this up to date.

> 	Jon

Take care.

Tony Mione                          Phone: +1 732-445-0605 FAX: +1 732-445-2968
Manager, TD Network Services                 W3: http://noc.rutgers.edu/~mione/
RUCS Telecommunications Division        PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall ** Rom 10:9-11 **

Date: Sun, 17 Oct 1999 22:58:44 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Moving forward
Sender: [email-masked]

At 10:19 AM +0200 10/12/99, Werner Koch wrote:

>the list is very quite for a long time now.  So I want to raise some
>issues again which are still unsolved:

I'm starting the task of updating 2440. I need to find an uninterrupted day
or two to do it properly. However, the main thing the working group really
needs to do is get implementations up to 2440-compliance. There's a part of
me that is loathe to rush on with mods to 2440 presently. I'd rather see
2440 become a standard than slow the whole process down by adding features,
as much as I like them, and believe that they're desirable. I would rather
see 2440 go to Standard   (or merely replace it with buffing of unclear
places) than see OpenPGP get bogged down in featuritis.

>  - There is a problem with dash-escaped text
>    (see my mail from Sep 15th)
>

I've read through your mail, Werner, and have another suggestion for the
problem.

A summary of the problem is that that 2440 does not cover the case where a
clear-signed message does not end with a CRLF or is of length zero.

My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
just declare that that's bad? If a clear-signed message isn't
CRLF-terminated, add one. This also handles the zero-length case, because
that just becomes a single blank line.

I admit that it never occurred to me that you COULD have a clear-signed
message with no CRLF. This just strikes me as aesthetically bad that the
END header could dangle at the end of a line, and contrary to the intent of
cleartext, if not its stated or implied definition. This seems to me to
hinge on the definition of "canonical text-mode" text, and I always thought
that canonical text-mode text always ended with a line end. Am I wrong on
this?

>  - What happened to the MDC?
>    Silently ignoring this issue is not good - we had a lot of
>    discussion on this topic and some proposals.  If we don't
>    come to a conclusion we should agree on a way to solve it.
>

Here's what has happened with it: many people seem to believe this is a
good idea. We've settled that out. However, the details of a design have
not been hashed out.

Remaining things to do are:

* One hash algorithm or many? My opinion is one, and that should be SHA-1.
We don't need the full capability of the hash algorithm the way signatures
do. SHA-1 is already required, and the contents of the hash are protected
by the cipher. Additionally, there are a number of subtle complexities that
get added if this is an option. We already have a hash-preferences packet,
but if there is an option on MDC packets, then the sender must not only
find a suitable cipher that the receivers speak, but also a suitable hash
algorithm. There's also the issue of what happens if an attacker attacks
the field that specifies the hash algorithm. I cannot help but believe that
all that will happen is that a lot of code will be executed that ends up
deciding to use SHA-1, the MUST-implement hash. I'll also note that even if
there's an option, the simplest thing for an implementation to do is just
plop down SHA-1 and not even give the user an option. I think I could even
write up an argument for why an implementation SHOULD just use SHA-1. I
think the correct thing to do is just plop 20 bytes of SHA-1 at the end of
the data.

* What cipher mode? I think we all agree that PGP-CFB mode is kinda hokey.
There is nothing wrong with it cryptographically, but no one else uses it.
There's a good argument that we should use standard CFB mode or even CBC
mode. However, I'm going to argue against that:

(1) CBC mode gives no more security than any of the other modes. It adds
complexity to the design, and complexity lowers security. There's a small
lure that possibly a CBC packet could be made to interoperate with S/MIME,
but the S/MIME people aren't interested in interoperating with us. We've
made several overtures to them to work together, and been rebuffed every
time. The last one required only that they change a MUST to a SHOULD on a
certificate specifier, and they refused. I have zero interest in lowering
our security by adding two code paths through the ciphers to interoperate
with people who don't want to interoperate with us. After all, it's in
*their* charter that they need to work with us, not ours.

(2) Regular CFB mode gives no more security than PGP-CFB mode. Adding in
another mode means more code, more things to review, more chances for an
error. If we have only one mode, there's only one thing to check out, and
all implementations are smaller. I'm mildly irked that PGP has to have its
own mode, but that's history. It works, it's secure. Eccentricity is not in
and of itself a bad thing. PGP-CFB mode is not there because the original
designers felt the need to be different, it's there because there was no
consensus at the time on how modes should be implemented, and PGP-CFB mode
has a genuine benefit -- it's easy to tell if you've used the wrong key on
a message, with errors at 2**-16. (And yes, yes, I know this sword has two
edges.)

Consequently, in spite of the fact that I have no particular love for
PGP-CFB mode, I say we just run with it, in the interests of simplicity and
speed.

The best thing to do would be for someone to write a PGP-CFB mode wrapper
that could be applied to a number of ciphers. Ideally, this would be
open-sourced. And no, I don't mean GPLed. I mean true open source, where
anyone could do anything with it.

* We have to design an Optional Features Subpacket. This is a subpacket
that goes in a self-signature that states that the certholder would
understand an MDC message should one be sent to them. It's not really that
big a deal. I see it as a vector of bytes, each denoting a feature. Feature
1 is MDC. Reserve feature FF as a tag, in case (perish the thought) we need
more optional features.

Here's my opinion:

The MDC packet looks exactly like the encrypted data packet, but it has 20
bytes of SHA-1 at the end. I've described the feature subpacket above.

>  - Other issues like large signature packets, new packet types
>    (non private ones) that PGP is now using should also be
>    discussed.
>

To show that I'm an equal-opportunity ox-gorer in the name of simplicity,
do we need the large signature packet? Do we need it now? My opinion is
that we need it, but not now. It's far more important that we get
implementations to support 2440 than anything else. I'm willing to put it
on the back burner for post-standard revisions of OpenPGP. Does anyone
object?

>  - There are some open tasks from the last Oslo meeting.
>

What are they? I know we're supposed to move ourselves along, and come up
with a list of things that an implementation has to do, so we can show we
have at least two interoperable versions. I think we have two that are
close. Tom Zerucha's reference implementation, and GnuPG. The main thing I
can think of for us to do is to show that they implement 2440, and
interoperate.

>  - Do we have a way to specify private extensions for the S2K
>    (I am thinking about hardware tokens).
>
No, we do not. Do we need them? Do you want to suggest an architecture?
Should I issue a plea for simplicity?

	Jon

Date: Fri, 15 Oct 1999 18:29:44 -0700
To: Michael Elkins <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: Moving forward
Cc: [email-masked], Thomas Roessler <[email-masked]>
Sender: [email-masked]

At 4:27 PM -0700 1999-10-13, Michael Elkins wrote:
>On Tue, Oct 12, 1999 at 01:15:57PM -0500, William H. Geiger III wrote:
>   >Any word on what's going on with PGP/MIME? Last I heard a couple of
>   >people here were working on some issues but I haven't heard anything
>   >since then.
>   >
>   >I am interested in seeing parallel signatures being added to the
>   >protocol. I am not sure if this should be on the PGP/MIME level or
>   >the OpenPGP.
>
>IMO, the parallel signature should be left out of PGP/MIME and
>OpenPGP. Where it belongs is in an update of RFC1847 (Security
>Multiparts) since this is a generic encapsulation of multiple
>signatures.
>
>That being said, an update of PGP/MIME would likely only reference
>the new specification (RFC2440) instead of RFC1991. Given that
>PGP/MIME only specifies what you sign, not the format of the
>signature, it is fairly neutral with respect to which spec you are
>talking about.

Sorry I've been so distracted by other things since Oslo... nice to 
hear from you, ME.

I'm trying hard to be unbiased about parallel sigs (having written 
it) but how about if we (Thomas & I, last I checked) split parallel 
sigs into a new, separate RFC and we also reference them in the new? 
OpenPGP/MIME RFC instead?

    dave

Date: Wed, 13 Oct 1999 16:27:13 -0700
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: Moving forward
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Oct 12, 1999 at 01:15:57PM -0500, William H. Geiger III wrote:
> Any word on what's going on with PGP/MIME? Last I heard a couple of people
> here were working on some issues but I haven't heard anything since then.
> 
> I am interested in seeing parallel signatures being added to the protocol.
> I am not sure if this should be on the PGP/MIME level or the OpenPGP.

IMO, the parallel signature should be left out of PGP/MIME and OpenPGP.  Where
it belongs is in an update of RFC1847 (Security Multiparts) since this is a
generic encapsulation of multiple signatures.

That being said, an update of PGP/MIME would likely only reference the new
specification (RFC2440) instead of RFC1991.  Given that PGP/MIME only specifies
what you sign, not the format of the signature, it is fairly neutral with
respect to which spec you are talking about.

me

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 12 Oct 1999 13:15:57 -0500
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Moving forward
Sender: [email-masked]

In <[email-masked]>, on 10/12/99 
   at 10:19 AM, Werner Koch <[email-masked]> said:

>Hi,

>the list is very quite for a long time now.  So I want to raise some
>issues again which are still unsolved:

>  - There is a problem with dash-escaped text 
>    (see my mail from Sep 15th)

>  - What happened to the MDC?
>    Silently ignoring this issue is not good - we had a lot of
>    discussion on this topic and some proposals.  If we don't
>    come to a conclusion we should agree on a way to solve it.

>  - Other issues like large signature packets, new packet types
>    (non private ones) that PGP is now using should also be 
>    discussed.

>  - There are some open tasks from the last Oslo meeting.

>  - Do we have a way to specify private extensions for the S2K
>    (I am thinking about hardware tokens).
>	

Any word on what's going on with PGP/MIME? Last I heard a couple of people
here were working on some issues but I haven't heard anything since then.

I am interested in seeing parallel signatures being added to the protocol.
I am not sure if this should be on the PGP/MIME level or the OpenPGP.

Another issue I would like to see addressed for a long time now is UserID
revocation. IMHO this is something that is much needed. 

>I see more and more demand for S/MIME applications.  To make OpenPGP a
>success we should really agree on some topics and move forward to get
>OpenPGP into draft standard state.

I have always been of the opinion that the way to get this done is for PGP
to be integrated into other protocol. Netscape & RSADSI are involved in
nearly every area where Inet security is involved and they are pushing
S/MIME X.509 protocols.

NAI has the resources to make just as big if not bigger push for the
OpenPGP protocols but they are not.

-- 
---------------------------------------------------------------
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
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

Date: Wed, 13 Oct 1999 15:31:01 +0100
From: Detlef =?iso-8859-1?Q?H=FChnlein?= <[email-masked]>
Organization: Secunet AG - The Trust Company
To: [email-masked]
Subject: CQRE'99 - Call for Participation
Sender: [email-masked]

Dear Listmembers! 

Sorry for crossposting. The Call for Participation below
might be of interest for you. To register, please visit
http://www.cqre.net . You might want to note that the 
early bird registration period already expires on Oct. 22, 
which is less than two weeks from now. 

I would be looking forward to seeing you at CQRE. 

Best regards

	Detlef Huehnlein

***************************************************************
                  Call for Participation 
            CQRE [Secure] Congress & Exhibition
        Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving 
economic processes.
---------------------------------------------------------------
Part I covers stratecial issues of IT-Security while Part II
will discuss more technical issues, like 

- SmartCard Technology / Security
- Public Key Infrastructures
- Network Security
- Mobile Security
- Intrusion Detection
- Enterprise Security
- Security Design
- Electronic Payment
- Electronic Commerce
- Cryptography
- Espionage
- Interoperability
- Biometrics 
- Risk Management
- Signature Laws 
- Training / Awareness

for example.
----------------------------------------------------------------
                       CQRE-PROGRAM:
----------------------------------------------------------------
Part I - Strategical Aspects
Tuesday, November 30, 1999
----------------------------------------------------------------
09.30 Opening: Chairman Paul Arlman, Federation of European 
Stock Exchange 
09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG
"A corporate group in transition - how Deutsche Telekom is 
preparing for the digital economy."
10.15 Keynote Jean-Paul Figer, Cap Gemini S.A
"Brave Digital World? The balance between chances and 
risks for the information society."
10:45 Coffee
11:15 Five parallel Workshops:
Workshop 1 - "Values & standards"   (Prof.Dr. Gertrud Höhler)
Workshop 2 - "Law & regulation"     (Klaus-Dieter Scheurle)  
Workshop 3 - "Strategy & success" 
Workshop 4 - "Role of technology"   (Karl-Heinz Streibich)
Workshop 5 - "Monitoring & control" (Piet van Reenen)
12.45 Lunch
14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon
"Network Citizen - what does the networked citizen and 
consumer stand to gain and lose?"
15.15 Workshop results (Moderator Paul Arlman) 
15.45 Coffee
16.00 Summary / 10-point-programme 
17.00 Happy Hour
18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF)
----------------------------------------------------------------
Part II - Technical Aspects:
Wednesday, December 1, 1999
----------------------------------------------------------------
09.00 R.Baumgart: Welcome 
09.15 B.Schneier: "Attack trees - a novel methodology 
        for risk management."
10.00 Refreshments 
10.15 Four parallel tracks:
I. Risk Management:
      D.Povey: "Developing Electronic Trust Policies 
        Using a Risk Management Model"
      J.Hopkinson: "Guidelines for the Management
        of IT-Security"
II. Security Design:
      L.Romano, A.Mazzeo and N.Mazzocca: "SECURE:
        a simulation tool for PKI design"
      D.Basin: "Lazy Infinite State Analysis 
        of Security Protocols"
III. Enterprise Security:
      P.Kunz: "The case for IT-Security"
      W.Wedl: "Integrated Enterprise Security - Examples 
        conducted in large European Enterprises"
      B.Esslinger: "The PKI development of Deutsche Bank"
IV. Tutorial:
      H.Handschuh: "Cryptographic SmartCards"
11.45 Lunch
13.15 S.Senda: "Electronic Cash in Japan"
14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi:
      "Panel: Electronic payments where do we go 
      from here?"
15.00 Four parallel tracks:
I. SmartCard Issues
      R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based 
        Personal Card Assistant"
      M.Nyström, J.Brainard: "An X.509-Compatible 
        Syntax for Compact Certificates"
II. Applications
      D.Hühnlein, J.Merkle: "Secure and cost efficent
        electronic stamps"
      K.Sako: "Implementation of a Digital 
        Lottery Server on WWW"
III. PKI-experiences
      J.Lopez, A.Mana, J.J.Ortega: "CerteM: 
        Certification System Based on Electronic 
      Mail Service Structure"
        K.Schmeh: "A method for developing PKI models"
      J.Hughes: "The Realities of PKI Inter-Operability
IV. Tutorial
      S.Kent: "How many Certification Authorities 
        are Enough?"
16.45 J.J.Quisquater: "Attacks on SmartCards 
        and Countermeasures"
17.00 M.Kuhn: "How tamper-resistant are 
        todays SmartCards?"
18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann: 
        "Secure SmartCards - Fact or Fiction"
19.00 Get-together with music (4 to the bar)
        and CQRE - Speakers corner - rump session
----------------------------------------------------------------
Part II - Technical Aspects:
Thursday, December 2, 1999
----------------------------------------------------------------
09.00 R.Baumgart : Good morning 
09.15 P.Landrock: Mobile Commerce
10.15 Four parallel tracks:
I. Mobile Security
      M.Borchering: "Mobile Security - an
        Overview of GSM, SAT and WAP"
      S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of
        Authentication Data in Third Generation Mobile
        Phone Networks"
II. Cryptography
      J.P. Seifert, N.Howgrave: "Extending Wiener`s 
        attack in the Presence of many decrypting
        exponents"
      S.Micali, L.Reyzin: "Improving The Exact 
        Security of Fiat-Shamir Signature Schemes"

III. Network Security
      C.Yuen-yan: "On Privacy Issues of Internet 
        Access Services via Proxy Servers"
      Jorge Davila, Javier Lopez and Rene Peralta: 
        "VPN solutions in diverse layers of the 
         TCP/IP stack"
      B.Schneier, Mudge, D.Wagner: "Cryptanalysis of
        Microsofts PPTP Authentification Extensions
       (MS-CHAPv2)"
IV. Tutorial
      I.Winkler: "How to fight the inner enemy"
12.00 J.S. Coron: "On the security of RSA padding"
12.45 Lunch
14.15 Four parallel tracks:
I. PKI
      A.Young, M.Yung: "Auto-Recoverable 
       Auto-Certifiable Cryptosystems (a survey)"
II. Intrusion Detection
      D.Bulatovic, D.Velasevic: "A Distributed Intrusion 
       Detection System based on Bayesian Alarm
       Networks"
III. Espionage
      M.Fink: "Espionage - State of the Art and 
        Countermeasures"
      W.Haas: "Informational Self Defense"
IV.  Tutorial
      A.Philip: "Secure E-business"
15.00 S.Kent: "Security for Certification Authorities 
        - A system approach"
16.00 Four parallel tracks: 
I. Interoperability
      S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters: 
        "Interopreability Characteristics of S/MIME
         Products"
      M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA 
         Project: The Solution to the Interoperability 
         Problems between the X.509 and EDIFACT Public 
         Key Infrastructures"
II. Biometrics 
      H.Arendt: "Biometrics - State of the Art"
      A.P.Gonzales-Marcos, C.Sanchez-Avila,
        R.Sanchez-Reillo: "Multiresolution Analysis and
        Geometric Measure for Biometric Identification"
III. Signature Laws 
      Workshop - Leader, K.Keus: "German Signature Act -
        Expiriences made for Europe?"
IV. Tutorial
      J.Massey: "Cryptography at a glance"
17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi:
      "Panel: Perspectives for a global signature law"
18.30 R.Baumgart: Closing Remarks

Date: Tue, 12 Oct 1999 10:19:08 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Moving forward
Sender: [email-masked]

Hi,

the list is very quite for a long time now.  So I want to raise some
issues again which are still unsolved:

  - There is a problem with dash-escaped text 
    (see my mail from Sep 15th)

  - What happened to the MDC?
    Silently ignoring this issue is not good - we had a lot of
    discussion on this topic and some proposals.  If we don't
    come to a conclusion we should agree on a way to solve it.

  - Other issues like large signature packets, new packet types
    (non private ones) that PGP is now using should also be 
    discussed.

  - There are some open tasks from the last Oslo meeting.

  - Do we have a way to specify private extensions for the S2K
    (I am thinking about hardware tokens).

I see more and more demand for S/MIME applications.  To make OpenPGP
a success we should really agree on some topics and move forward to
get OpenPGP into draft standard state.

  Werner

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

Date: Wed, 6 Oct 1999 13:02:25 -0400
To: Recipient List Suppressed:;
From: Robert Hettinga <[email-masked]>
Subject: Brands' book - quick review
Sender: [email-masked]

--- begin forwarded text

Date: Wed, 6 Oct 1999 08:07:19 -0400 (AST)
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Brands' book - quick review
Reply-To: [email-masked]
Sender: <[email-masked]>
List-Subscribe: <mailto:[email-masked]>

Whilst on the topic of enhanced digital certificates, Stefan
Brands book,

      _Rethinking Public Key Infrastructures
      and Digital Certificates - Building in Privacy_,
      4th September, 1999,

is now in its first printing, published by Brands himself.
The contents are at http://www.xs4all.nl/~brands .

I've spent some time on the first chapter, and it represents a
useful survey of the pitfalls of PKI in the Verisign flavour.
I wouldn't say it is a comprehensive catalogue of the failings,
as it avoids the legal side such as JKW's attack, and doesn't go
so much into the efficiency attack of Dan Geer.  Regardless, it
appears to be a definitive starting place for any investigation
into this area as it covers the revocation debate, smart cards,
and privacy very well.

The book's main contents are way beyond me, as they contain
maths of cryptographic nature.  But, in private conversations
I've had with Brands, I'm of the understanding that his book
goes way beyond the techniques of Chaum.  I await with interest
to see if this claim is awarded by history.

Brands is highly critical of Chaumian certificates, which may
or may not indicate that he has a better scheme :)  For example,
whilst his list of cons for nymous certificates runs to 6 bullets,
the Chaumian proponents get hit with 12 bullets.  CAs in the
current sense don't really measure up, they appear to be so full
of lead that there's no counting.

All in all, I predict this will become required reading by
cryptoplumbers and cryptographers in the Financial Cryptography
community.  Be quick in getting your copy, as I hear two thirds
of the first printing are already sold.

iang

--- end forwarded text

-----------------
Robert A. Hettinga <mailto: [email-masked]>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

From: "Peter Lewis" <[email-masked]>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: From Firewall to IPSec VPNs
Date: Mon, 4 Oct 1999 15:13:23 +0200
Organization: Upperside
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01BF0E7B.004129A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

------=_NextPart_000_0021_01BF0E7B.004129A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV>Security services and protection mechanisms<BR>IPv6 promises =
regarding=20
IPSec<BR>Certification infrastructure<BR>Standardization update<BR>Case =
Studies:=20
ISPs, carriers, private networks<BR>AH and ESP protocols =
description<BR>Possible=20
future extensions and modifications of the IKE =
protocol<BR>Complementarity=20
between IPSec and firewalls<BR>Global Site-to-Site IPSec VPN's with =
End-to-End=20
SLA's<BR>Managing widespread IPSEC virtual private networks<BR>Solving =
IPSec=20
VPNs scalability<BR>Results of some interoperability tests<BR>IPSec=20
architectures and non-standardized aspects of IPSec<BR>Adding IPSec VPN=20
functions in an existing router network<BR>Impact of fragmentation on =
the=20
performance of IPSec coding<BR><BR>IPSEC 99 Conference<BR>From Firewall =
to IPSec=20
VPNs<BR><BR>October 26, 27, 28, 29, 1999<BR>Paris - France<BR><BR>More =
infos: <A=20
href=3D"http://www.upperside.fr/baipsec.htm">www.upperside.fr/baipsec.htm=
</A></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0021_01BF0E7B.004129A0--

From: "Salzman, Noah" <[email-masked]>
To: Matthew Sherborne <[email-masked]>
Cc: Open PGP Mailing List <[email-masked]>
Subject: RE: e-mail programs
Date: Fri, 1 Oct 1999 10:42:59 -0700 
Sender: [email-masked]

Two MUAs that natively build-in PGP:

http://www.ritlabs.com/the_bat/  (The Bat, for Windows)

http://www.southsoft.com/products.html  (PMMail98, Windows and OS/2)

Here's another one, where PGP is built in on the server (Exchange, Lotus,
POP) but is not built in on the client.

http://www.gficomms.com/mesindex.htm

--Noah--

-----Original Message-----
From: Matthew Sherborne [mailto:[email-masked]]
Sent: Friday, October 01, 1999 4:30 AM
To: Open PGP Mailing List
Subject: e-mail programs

Does anyone know of any e-mail programs that incorporate PGP ?

Matthew Sherborne
Senior Programmer
Dataworks Design International

Portable e-mail for everyone -> www.eze-mail.net

Date: Fri, 1 Oct 1999 09:27:33 -0700
To: Werner Koch <[email-masked]>, Open PGP Mailing List <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: e-mail programs
Sender: [email-masked]

At 2:42 AM -0700 10/1/99, Werner Koch wrote:
>Most other Unix MUAs have pgp support too.  I know that there is a
>plug-in for Eudora but I have some reports of frequent crashes (but
>you may blame MS-Windows) for this.

I have used the PGP plugin for Eudora both on Windows/NT and Macintosh.  I
have not had crashing problems with it.

-------------------------------------------------------------------------
Bill Frantz       | Macintosh: Didn't do every-| Periwinkle -- Consulting
(408)356-8506     | thing right, but did know  | 16345 Englewood Ave.
[email-masked] | the century would end.     | Los Gatos, CA 95032, USA

From: [email-masked]
Date: Fri, 1 Oct 1999 08:44:46 -0400 (EDT)
Subject: Re: e-mail programs
Apparently-To: <[email-masked]>
Sender: [email-masked]

Matthew Sherborne <[email-masked]> wrote on 1 Oct 1999:

 >Does anyone know of any e-mail programs that incorporate PGP ?

There are of course the standard PGP plugins (MS exchange,
Outlook, Outlook Express, Eudora etc.)

For our own e-mail program (KT-MAIL, details see
"www.redtenbacher.de/info/"), I had to choose a different
approach, however:

Many of our customers are city administrations (in South-Western
Germany). These want to have secure e-mail connections via the
Internet, without having to teach their many employees anything
about cryptography or key management.

So, we created a component for the mailserver PC in a LAN where
receipients can be registered for automatic encryption/signature,
and any incoming mail is automatically decrypted before being
passed on to the mail clients. (This is, of course, only possible
because the city administrations need no true end-to-end-security
but just a city-to-city-security.)

We made our life easy by doing the actual encryption/decryption
via calling a command line version of PGP 5.0i. (This could be
changed to any other OpenPGP conforming implementation, of
course.)

In this way, thousands of city employees utilize PGP encryption
while only the LAN administrator needs to know anything about
PGP or key management.

- Wolfgang Redtenbacher

-----------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
-----------------------------------------------------------------

Date: Fri, 1 Oct 1999 11:42:26 +0200
From: Werner Koch <[email-masked]>
To: Open PGP Mailing List <[email-masked]>
Subject: Re: e-mail programs
Sender: [email-masked]

Matthew Sherborne <[email-masked]> writes:

> Does anyone know of any e-mail programs that incorporate PGP ?

  ftp.mutt.org

Mutt (which is the successor of elm) has *really* good support for
PGP2, PGP5 and GnuPG.  And it is a fully MIME aware.

Most other Unix MUAs have pgp support too.  I know that there is a
plug-in for Eudora but I have some reports of frequent crashes (but
you may blame MS-Windows) for this.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013