Sample Twofish message

[[e-mail]]

Here is a sample conventionally-encrypted message using 256 bit Twofish.
Does anyone have an implementation that can verify interoperability?

Note, per the spec, that the message is preceded by 8 random bytes,
then two more bytes which are copies of the last two of these, despite
the fact that the cipher has 16 byte blocks.

Note also that the special CFB "sync" operation (after processing these 10
bytes) is not to be done with block ciphers whose block size is greater
than 8 bytes, hence is not done for Twofish.

Here is the message, which is encrypted using the one-letter passphrase
"x".  It should decrypt to "This is a test input." followed by a newline.

-----BEGIN PGP MESSAGE-----
Version: test

qANQR1DDDQQKAwIUgRhQ3+GF1mDJMx33ZwK+8z7wmDHXZ8HxVkc0y7BPMxlxnpB7
CveN64V1+2pKqD9+ZFysWF9GGUhXSDLcNA==
=iYnA
-----END PGP MESSAGE-----


Hal Finney
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02949 for ietf-open-pgp-bks; Mon, 29 Mar 1999 14:51:05 -0800 (PST)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02945 for <[e-mail]>; Mon, 29 Mar 1999 14:51:04 -0800 (PST)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id OAA03013 for <[e-mail]>; Mon, 29 Mar 1999 14:51:02 -0800 (PST)
Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id OAA04352 for [e-mail]; Mon, 29 Mar 1999 14:41:39 -0800
Date: Mon, 29 Mar 1999 14:41:39 -0800
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Sample Twofish message
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is a sample conventionally-encrypted message using 256 bit Twofish.
Does anyone have an implementation that can verify interoperability?

Note, per the spec, that the message is preceded by 8 random bytes,
then two more bytes which are copies of the last two of these, despite
the fact that the cipher has 16 byte blocks.

Note also that the special CFB "sync" operation (after processing these 10
bytes) is not to be done with block ciphers whose block size is greater
than 8 bytes, hence is not done for Twofish.

Here is the message, which is encrypted using the one-letter passphrase
"x".  It should decrypt to "This is a test input." followed by a newline.

-----BEGIN PGP MESSAGE-----
Version: test

qANQR1DDDQQKAwIUgRhQ3+GF1mDJMx33ZwK+8z7wmDHXZ8HxVkc0y7BPMxlxnpB7
CveN64V1+2pKqD9+ZFysWF9GGUhXSDLcNA==
=iYnA
-----END PGP MESSAGE-----


Hal Finney
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15761 for ietf-open-pgp-bks; Fri, 26 Mar 1999 08:58:30 -0800 (PST)
Received: from broncho.ucok.edu (broncho.ucok.edu [192.206.65.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15750; Fri, 26 Mar 1999 08:58:27 -0800 (PST)
Received: from england.com ([196.40.0.38]) by broncho.ucok.edu (AIX4.2/UCB 8.7/8.7) with SMTP id KAA41558; Fri, 26 Mar 1999 10:41:22 -0600 (CST)
Message-Id: <[e-mail]>
Date: Sat, 27 Mar 99 00:03:49 EST
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Subject: STOCKS ON THE MOVE!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PDC Innovative Industries Inc. (Symbol PDCI), OTC Boulletin Board is
prepared for a big move saids stock market analysts. Recently reverse
split 40 for 1 currently trading at 4 Dollars per share. If the stock hits
pre split level the price could easily hit 10 to 12 Dollars per share. PDCI
recently announces major news concerning production and sales
projections. Medical Stock Analyst see PDC's steri-pro invention as mayor
winner. For more info check Dow Jones Historical news.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA00209 for ietf-open-pgp-bks; Thu, 25 Mar 1999 03:29:02 -0800 (PST)
Received: from chrysler.hypnotech.no ([e-mail] [194.248.33.228]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00205 for <[e-mail]>; Thu, 25 Mar 1999 03:28:58 -0800 (PST)
Received: from woolworth (woolworth.hypnotech.no [194.248.33.243]) by chrysler.hypnotech.no (8.9.3/8.9.3) with SMTP id MAA02126; Thu, 25 Mar 1999 12:35:47 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 25 Mar 1999 12:37:57 +0100
To: Jon Callas <[e-mail]>
From: Stale Schumacher Ytteborg <[e-mail]>
Subject: Re: OpenPGP Book
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 16:05 16.03.99 -0800, Jon Callas wrote:

>I've produced a book with Tom Zerucha's OpenPGP implementation and a copy
>of 2440 in it. It is in the scannable format used by NAI and the EFF. I
>know that no one outside the US has been able to look at his reference
>implementation, and this means that they can.
>
>It is "OpenPGP Specification and Sample Code" edited by Jonathan D. Callas,
>ISBN 1-58368-014-4.

I've now ordered a copy. Look for it on http://www.cryptoscan.org/ in a
week or two.


Cheers,

  .
Stale Schumacher Ytteborg
-----------------------------------------------------------------------
Hypnotech AS          Phone: [phone]   http://www.hypnotech.no/
Nedre vaskegang 6     Cell : [phone]
N-0186 Oslo, Norway   Fax  : [phone]   http://stale.ytteborg.com/



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28720 for ietf-open-pgp-bks; Wed, 24 Mar 1999 18:20:20 -0800 (PST)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28715 for <[e-mail]>; Wed, 24 Mar 1999 18:20:18 -0800 (PST)
Received: from paris.public.uni-hamburg.de (max2-211.public.uni-hamburg.de [134.100.45.211]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id DAA82738 for <[e-mail]>; Thu, 25 Mar 1999 03:27:28 +0100
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10Pz1N-0003bDC; Thu, 25 Mar 99 02:33 +0100
Message-Id: <[e-mail]>
Subject: Re: subkey signatures
To: [e-mail]
Date: Thu, 25 Mar 1999 02:33:20 +0100 (+0100)
In-Reply-To: <[e-mail]> from "[e-mail]" at Mar 24, 99 10:54:58 am
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From looking at the source code, the RFC accurately describes how
> PGP works.

Right. I don't know what went wrong while I was trying this with PGP.
It is only a bug in GnuPG; I have sent Werner a problem description.

Sorry for the confusion.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22636 for ietf-open-pgp-bks; Wed, 24 Mar 1999 11:43:35 -0800 (PST)
Received: from roll.mentat.com ([192.88.122.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22632 for <[e-mail]>; Wed, 24 Mar 1999 11:43:29 -0800 (PST)
Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id LAA29779; Wed, 24 Mar 1999 11:48:42 -0800 (PST)
Received: from zendia.mentat.com by leo.mentat.com (SMI-8.6/SMI-4.1) id LAA02796; Wed, 24 Mar 1999 11:48:41 -0800
Received: from acm.org by zendia.mentat.com (SMI-8.6/SMI-SVR4) id LAA25696; Wed, 24 Mar 1999 11:47:47 -0800
Message-ID: <[e-mail]>
Date: Wed, 24 Mar 1999 11:47:47 -0800
From: Jim Gillogly <[e-mail]>
Reply-To: [e-mail]
Organization: Banzai Institute
X-Mailer: Mozilla 4.06 [en] (X11; U; SunOS 5.6 i86pc)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DSA signatures
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hal wrote:
> A forged signature using a weak hash algorithm is no good.  Ideally an
> implementation will not implement weak public key or hash algorithms.
> If it does, it should display to the end user the public key and hash
> algorithms used in a signature, so that he can judge the strength of
> the signature.

In the world we're aiming at, most individual users of OpenPGP
implementations will not be able to judge the strength even given
that information.  They will rely on the designers of the package
to give them default systems that are strong enough for their needs,
whatever those may be.  For this reason I strongly endorse Hal's
"Ideally" sentence -- if there are weak algorithms, someone will
use them for some purpose and get burned.  That's why I was strongly
opposed to having ROT-N defined, even for testing-only purposes.

If something gets broken we should deprecate it in the strongest
terms as soon as possible, and developers should issue updates
that no longer support the broken algorithms for producing
new messages.

-- 
	Jim Gillogly
	2 Astron S.R. 1999, 19:40
	12.19.6.0.17, 12 Caban 10 Cumku, Eighth Lord of Night


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22184 for ietf-open-pgp-bks; Wed, 24 Mar 1999 11:01:08 -0800 (PST)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22180 for <[e-mail]>; Wed, 24 Mar 1999 11:01:08 -0800 (PST)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id LAA07667; Wed, 24 Mar 1999 11:06:03 -0800 (PST)
Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id KAA22881; Wed, 24 Mar 1999 10:57:45 -0800
Date: Wed, 24 Mar 1999 10:57:45 -0800
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DSA signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In general, a signature is only as strong as the weaker of the
public key algorithm and the hash algorithm that is used to make it.
A forged signature using a weak hash algorithm is no good.  Ideally an
implementation will not implement weak public key or hash algorithms.
If it does, it should display to the end user the public key and hash
algorithms used in a signature, so that he can judge the strength of
the signature.

Hal

[e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=) writes:
>
> Did it ever occur to anyone that allowing different hash algorithms
> with DSA reduces security rather than increasing it?
>
> In DSA signatures, hash algorithm selector is secured only with the
> selected hash algorithm itself. So, if SHA-1 is insecure, you can
> forge signatures even if the key owner never uses SHA-1. If SHA-1 is
> secure, but any other permissible hash algorithm is insecure, you can
> also forge signatures. That would not be the case if OpenPGP had
> followed the DSS.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22154 for ietf-open-pgp-bks; Wed, 24 Mar 1999 10:58:33 -0800 (PST)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA22150 for <[e-mail]>; Wed, 24 Mar 1999 10:58:31 -0800 (PST)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id LAA07322; Wed, 24 Mar 1999 11:03:16 -0800 (PST)
Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id KAA22873; Wed, 24 Mar 1999 10:54:58 -0800
Date: Wed, 24 Mar 1999 10:54:58 -0800
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: subkey signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From looking at the source code, the RFC accurately describes how
PGP works.  What do you think gets hashed on public subkey packets,
if not 0x99, a two octet length, and the packet body?

[e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=) writes:
> According to RFC 2440, if a four-octet length Public Subkey Packet
> is bound to a key, the signature is computed over a packet with a
> two-octet length field.
>
> In violation of the RFC, both PGP and GnuPG reject such signatures.
>
> (Section 5.2.4: "When a signature is made over a key, the hash data
> starts with the octet 0x99, followed by a two-octet length of the key,
> and then body of the key packet. (Note that this is an old-style
> packet header for a key packet with two-octet length.) A subkey
> signature (type 0x18) then hashes the subkey, using the same format as
> the main key.").

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21886 for ietf-open-pgp-bks; Wed, 24 Mar 1999 10:30:58 -0800 (PST)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21881 for <[e-mail]>; Wed, 24 Mar 1999 10:30:54 -0800 (PST)
Received: from paris.public.uni-hamburg.de (max1-020.public.uni-hamburg.de [134.100.43.20]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id TAA51678 for <[e-mail]>; Wed, 24 Mar 1999 19:38:00 +0100
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10PsMT-0003bDC; Wed, 24 Mar 99 19:26 +0100
Message-Id: <[e-mail]>
Date: Wed, 24 Mar 99 19:26 +0100
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [e-mail]
Subject: subkey signatures
Newsgroups: ulf.open-pgp
In-Reply-To: <[e-mail]>
Organization: HR13
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

According to RFC 2440, if a four-octet length Public Subkey Packet
is bound to a key, the signature is computed over a packet with a
two-octet length field.

In violation of the RFC, both PGP and GnuPG reject such signatures.

(Section 5.2.4: "When a signature is made over a key, the hash data
starts with the octet 0x99, followed by a two-octet length of the key,
and then body of the key packet. (Note that this is an old-style
packet header for a key packet with two-octet length.) A subkey
signature (type 0x18) then hashes the subkey, using the same format as
the main key.").


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21879 for ietf-open-pgp-bks; Wed, 24 Mar 1999 10:30:45 -0800 (PST)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21875 for <[e-mail]>; Wed, 24 Mar 1999 10:30:41 -0800 (PST)
Received: from paris.public.uni-hamburg.de (max1-020.public.uni-hamburg.de [134.100.43.20]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id TAA28080 for <[e-mail]>; Wed, 24 Mar 1999 19:37:46 +0100
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10PsWB-0003bDC; Wed, 24 Mar 99 19:36 +0100
Message-Id: <[e-mail]>
Date: Wed, 24 Mar 99 19:36 +0100
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [e-mail]
Subject: DSA signatures
In-Reply-To: <[e-mail]>
Organization: HR13
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Did it ever occur to anyone that allowing different hash algorithms
with DSA reduces security rather than increasing it?

In DSA signatures, hash algorithm selector is secured only with the
selected hash algorithm itself. So, if SHA-1 is insecure, you can
forge signatures even if the key owner never uses SHA-1. If SHA-1 is
secure, but any other permissible hash algorithm is insecure, you can
also forge signatures. That would not be the case if OpenPGP had
followed the DSS.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01782 for ietf-open-pgp-bks; Mon, 22 Mar 1999 08:58:39 -0800 (PST)
Received: from relay.gw.tislabs.com ([e-mail] [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01778 for <[e-mail]>; Mon, 22 Mar 1999 08:58:37 -0800 (PST)
Received: by relay.gw.tislabs.com; id MAA15107; Mon, 22 Mar 1999 12:15:24 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma015095; Mon, 22 Mar 99 12:15:18 -0500
Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id MAA19609; Mon, 22 Mar 1999 12:04:09 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 22 Mar 1999 12:04:28 -0500
To: [e-mail]
From: "David M. Balenson" <[e-mail]>
Subject: CFP: ISOC Year 2000 Network & Distr. System Security (NDSS 2000)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000


IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

  This symposium aims to foster information exchange among researchers
  and practitioners of network and distributed system security
  services.  The intended audience includes those who are interested
  in practical aspects of network and distributed system security,
  with the focus on actual system design and implementation, rather
  than theory. A major goal of the symposium is to encourage and
  enable the Internet community to apply, deploy, and advance the
  state of available security technology.  The proceedings of the
  symposium will be published by the Internet Society.

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base
    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal

    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most two pages and should describe the topic, identify
  the panel chair, explain the format of the panel, and list three
  to four potential panelists.  Technical papers will appear in
  the proceedings. A description of each panel will appear in the
  proceedings, and may -- at the discretion of the panel chair --
  include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: [e-mail]
        TEL: [phone] ext 329
        FAX: [phone] 

  Dates, final call for papers, advance program, and registration
  information will be available soon at the URL: httl//www.isoc.org/ndss2000.

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified
  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.


----------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738  USA
[e-mail]; 443-259-2358; fax [phone]
pgp fingerprints FD53 918E 097A 2579 C1A8  34F8 E05D E74F AC1D E184 (DSS/DH)
                 D43B 565B 2C0E 90F4  38BB D9EA 1454 3264 (RSA)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18998 for ietf-open-pgp-bks; Sun, 21 Mar 1999 09:08:02 -0800 (PST)
Received: from bradley.bradley.edu ([e-mail] [136.176.5.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18905; Sun, 21 Mar 1999 09:03:09 -0800 (PST)
Received: from Sports (npuntarenas1-a25.racsa.co.cr [196.40.11.154]) by bradley.bradley.edu (8.6.12/8.6.12) with SMTP id KAA16175; Sun, 21 Mar 1999 10:56:07 -0600
Message-Id: <[e-mail]>
Date: Sun, 21 Mar 99 10:50:43 EST
From: "Sports" <[e-mail]>
To: [e-mail]
Subject: Sports
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

BASEBALL & BASKETBALL SEASON PROMOTIONS

We give you a 10% bonus on your initial deposit (minimum $500 deposit -
$50 minimum bet - no maximum.) Though Western Union cash only.

We give you a FREE SPORTS PAGER
(It has injury reports, scores, weather and everything you need to know)
with $1000 or more or get the 10% bonus.

15% Match play for Friend Referral.

20% Match play on your losses every 6 months!

THAT'S 45% BONUSES JUST FOR YOU !!

1-800-973-1514 ext. 7373

Great off shore sports book that really pays out if you win!



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07005 for ietf-open-pgp-bks; Fri, 19 Mar 1999 14:47:10 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06999 for <[e-mail]>; Fri, 19 Mar 1999 14:47:08 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA18964 for <[e-mail]>; Fri, 19 Mar 1999 14:53:08 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Mar 1999 14:44:22 -0800
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: rfc2440
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA07002
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:18 AM 3/19/99 +0100, Ulf Möller wrote:
|Why doesn't RFC 2440 reference the Digital Signature Standard?
|

Because we neglected to do that.

	Jon


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA13153 for ietf-open-pgp-bks; Thu, 18 Mar 1999 18:00:24 -0800 (PST)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA13149 for <[e-mail]>; Thu, 18 Mar 1999 18:00:22 -0800 (PST)
Received: from paris.public.uni-hamburg.de (max2-192.public.uni-hamburg.de [134.100.45.192]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id DAA88110 for <[e-mail]>; Fri, 19 Mar 1999 03:07:00 +0100
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10NnvL-0003bDC; Fri, 19 Mar 99 02:18 +0100
Message-Id: <[e-mail]>
Date: Fri, 19 Mar 99 02:18 +0100
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [e-mail]
Subject: rfc2440
In-Reply-To: <[e-mail]>
Organization: HR13
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Why doesn't RFC 2440 reference the Digital Signature Standard?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28945 for ietf-open-pgp-bks; Wed, 17 Mar 1999 10:29:13 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA28941 for <[e-mail]>; Wed, 17 Mar 1999 10:29:12 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 17 Mar 1999 10:58:05 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 17 Mar 1999 08:16:56 -0700
From: "Ed Reed" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Text on PGP directory requirements
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA28942
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter -

Thank you for your very useful summary of PGP requirements.  I see
you've taken into account several new approaches for dealing
flexibly with such more complex data representations.  It makes
my job considerably easier having your summary of requirements
to work from.

I'm sorry more work hasn't taken place since Florida, and re-commit
myself to progressing this effort before Oslo. 

Ed

>>> Peter Gietz <[e-mail]> 03/16/99 12:22PM >>>

Hi folks,

Since [e-mail] has been quiet since the December IETF
meeting, I thought providing a text as a basis for discussion would be a
Good Thing. The text gives arguments for the importance of a directory
storage model for PGP public keys and states the requirements for such a
model.
The arguments I put forward are a bit provocative to promote discussion.

Sorry for crossposting this to ietf-open-pgp and pgp-keyserver-folks, but I
wanted to invite the members of these lists to the discussion as well.
Since the to be writen ID is supposed to be discussed on the openPGP list
anyway  and since the here attached document discusses the need for a third
generation of PGP keyserver, I considered it appropriate to crosspost. The
discussion should IMO take place on the dedicated mailinglist pgp-directory
though.

Any comments are welcome. 

Cheers,
Peter




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21319 for ietf-open-pgp-bks; Wed, 17 Mar 1999 00:37:52 -0800 (PST)
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21263; Wed, 17 Mar 1999 00:34:31 -0800 (PST)
Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5)  with ESMTP id JAA17405; Wed, 17 Mar 1999 09:40:04 +0100 (MET)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 17 Mar 1999 09:40:04 +0100 (MET)
From: "CMS'99" <[e-mail]>
To: [e-mail]
Subject: Communications and Multimedia Security '99
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Apologies if you receive this more than once]

NEW DEADLINE FOR THE CMS'99 CONFERENCE: 

April 2nd, 1999

The call for papers can be found at 
http://www.esat.kuleuven.ac.be/cosic/cms99/





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28023 for ietf-open-pgp-bks; Tue, 16 Mar 1999 16:01:29 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28019 for <[e-mail]>; Tue, 16 Mar 1999 16:01:28 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA23838 for <[e-mail]>; Tue, 16 Mar 1999 16:07:31 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 16 Mar 1999 16:05:33 -0800
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: OpenPGP Book
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've produced a book with Tom Zerucha's OpenPGP implementation and a copy
of 2440 in it. It is in the scannable format used by NAI and the EFF. I
know that no one outside the US has been able to look at his reference
implementation, and this means that they can.

It is "OpenPGP Specification and Sample Code" edited by Jonathan D. Callas,
ISBN 1-58368-014-4.

You can get it from Printers Inc. <http://www.pibooks.com>. Their phone
number is [phone] in the US, or [phone].

	Jon



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25011 for ietf-open-pgp-bks; Tue, 16 Mar 1999 11:14:50 -0800 (PST)
Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA25007 for <[e-mail]>; Tue, 16 Mar 1999 11:14:48 -0800 (PST)
Received: from nt10 (actually host nt10.dante.org.uk) by alpha.dante.org.uk  with SMTP (MMTA) local; Tue, 16 Mar 1999 19:20:33 +0000
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 16 Mar 1999 19:22:15 +0000
To: PGP-Directory mailing list <[e-mail]>
From: Peter Gietz <[e-mail]>
Subject: Text on PGP directory requirements
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;	boundary="=====================_106109807==_"
Message-ID: <"alpha.dante.:115230:990316192036"@dante.org.uk>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Hi folks,

Since [e-mail] has been quiet since the December IETF
meeting, I thought providing a text as a basis for discussion would be a
Good Thing. The text gives arguments for the importance of a directory
storage model for PGP public keys and states the requirements for such a
model.
The arguments I put forward are a bit provocative to promote discussion.

Sorry for crossposting this to ietf-open-pgp and pgp-keyserver-folks, but I
wanted to invite the members of these lists to the discussion as well.
Since the to be writen ID is supposed to be discussed on the openPGP list
anyway  and since the here attached document discusses the need for a third
generation of PGP keyserver, I considered it appropriate to crosspost. The
discussion should IMO take place on the dedicated mailinglist pgp-directory
though.

Any comments are welcome. 

Cheers,
Peter


--=====================_106109807==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="PG 99-007v2 PGP directory.txt"

Requirements for storing PGP keys in the Directory

PG 99-007v2
16.03.99


Abstract

PGP is developing into one of the main public key infrastructures (PKI) in the Internet. This 
paper argues that Directory support of PGP infrastructure can help overcome some of the 
drawbacks of this PKI. It also states some general requirements for a storage model for PGP 
keys. 


Status of this document

This is not an Internet Draft. It is a statement intended to further the discussion on an 
Internet Draft on a Directory storage model for public PGP keys. The term Directory as 
used in this document refers to X.500 [1] as well as to LDAP [2]. All of its content is open 
to discussion and amendments. Any comments are therefore most welcome. The discussion 
should take place at the open mailing list [e-mail]. A final version of this 
draft will be published on the Web.


About PGP

PGP is developing into one of the main public key infrastructures in the Internet [3]. It is 
used for signing, integrity certification and/or encryption of email and other text 
documents, as well as source code and database requests. It is also capable of doing this with 
any other types of data as for instance multimedia data and of course for the certification of 
the PGP public keys. PGP was recently used as authentication mechanism in the RIPE 
database [4]. The X.509 model of strong authentication is also implementable with PGP 
technology.

The newest standard PGP message format has been defined by the IETF openPGP WG [5]. 
It contains several enhancements, e.g., the subkey concept which gives a greater flexibility in 
terms of what to sign, but simultaneously creates a greater complexity. The new key format 
also contains more detailed information on the issuer of a certificate including the user ID 
of the signing key, signature expiration date etc.


Drawbacks of PGP and Directory as solution

The currently applied trust model, the so-called "web of trust", where the PGP users certify 
the keys of other PGP users, has some inherent problems. One is that some user may take 
signing of another's key too lightly, i.e. sign without having proved the identity. Again a 
PGP user has to belong to a big group, that sign each other's key to make a certification 
path probable. In fact up to now we don't have a "web of trust", but rather "groups of 
trust" and even "hermitages of trust", which can be seen from statistics on public keys [6]. 
[Note: these data are quite old, Dec 1997; are there any newer statistics?]
Some other disadvantages are in terms of manageability (e.g. revocation management) and 
of verifying certificates, caused by the missing possibility to delete information in a once 
published public key in combination with the high probability that some keys in the web of 
trust loose their trustworthiness.

The "web of trust" model could be easily replaced by a hierarchical trust model, involving 
"Trusted Third Parties" or Certification Authorities (CA). There is no reason why PGP 
couldn't be deployed with such a trust model. Such an approach has been followed, e.g., in 
the UK [7] and in Germany [8]. One means to implement the publication of CA signed 
PGP keys would be the Directory that fits in perfectly because of its hierarchical structure. 

In the face of the new concept of subkeys, again the hierarchical model of the Directory has 
its advantages.

A further drawback of the current PGP technology lies in the non-distributedness of the 
current PGP public key server concept [9]. If the increase of numbers of PGP users 
continues, this server concept will soon or later become obsolete, because it is not scalable 
up to much more than 2 million keys. New keyserver concepts, e.g. its integration into the 
DNS haven't been followed up.

The distribution concept of the Directory makes this technology again an ideal tool 
providing a scalable and fast responding public key server. The simple protocol for PGP 
client and public key server communication is easily realisable with directory technology 
combined with email and HTTP interfaces. These interfaces should not only be able to 
simulate the key server to PGP client communication, but also the keyserver to keyserver 
communication, for replication with standard key servers. Both are described in [9].

The usage of the Directory as public key server as used by the current applications is not the 
only thinkable usage though. For other applications it might be more feasible to store a 
public key directly inside or below a person entry instead of collecting the keys in one part 
of the DIT dedicated as key server space. 


Requirements for a storage model

The only prerequisite to store PGP keys in the Directory is the definition of appropriate  
object classes and attributes, which could be used in X.500, as well as in LDAP directories. 
There already has been an initiative to define such object classes, the long expired Internet 
Draft  draft-ietf-asid-pgp-02.txt [10], which failed to provide a solution for multiple PGP 
keys of one person, since it defined several attributes, to be included in one person entry. 
Since there is no definite order for multiple values of one attribute, the affiliation between 
the values of the different attribute couldn't be stated. Hence a more flexible approach is 
needed. A new Directory concept the Family of Entries, developed parallel in the IETF [11] 
and in the ITU [12], which defines a hierarchical structure inside a Directory entry, could 
provide a solution for the requirements stated below.

Since not all future usage of PGP technology can be foreseen, a major requirement for the 
storage model is that it is open enough to reflect the flexibility of PGP technology. We need 
an abstract enough model together with a flexible way to point to public key information. 

The storage model should be able to map:

- Several independent PGP public keys for one person entry or Role occupant entry.
- Several user Ids per public key belonging to one person or roles.
- Several user Ids per public key belonging to different persons or roles.
- Several subkeys in one key which themselves have the same flexibility as the whole key. 

It should include:

- Several searchable fields of information necessary for a keyserver implementation, such as 
  keyID, userID, fingerprint, key creation date, etc. in addition to the ASCII armoured 
  key itself.
- Other searchable fields of information necessary for CA implementations, such as 
  pointer to the certificate issuing key, key expiration date, signature status, revocation 
  status and certificate revocation lists, etc.
- Other usefull information such as key size, public key algorithm, key server preference,  
  validity, etc.


Both scenarios, the PGP key stored in or below a person entry, as well as stored among 
other PGP keys in a dedicated PGP key subtree, should be implementable with the storage 
model.

The storage model should take concern about the signature included in keys. It should 
provide the means for a CA to publish the keys signed by it. Applications should be able to 
retrieve a certification path from the information in the Directory.

Although it is reasonable to concentrate on one technology the possibility of likewise 
storing public keys of other infrastructures than PGP should be kept in mind. The concept 
of the storage model should therefore be as PKI technology independent or adaptable as 
possible.



References

[1] ITU-T Rec. X.501, "The Directory: Models",1993. 

[2] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 
2251, December 1997 

[3] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 
1991, August 1996

[4] Bukowy, M and J. Snabb, "RIPE NCC Database documentation update to support 
RIPE DB ver. 2.2.1", RIPE189, January 1999

[5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", 
RFC 2440, November 1998

[6] McBurnet, N., "PGP Web of Trust Statistics", 
http://bcn.boulder.co.us/~neal/pgpstat/

[7] University College of London, http://www.cs.ucl.ac.uk/research/ice-
tel/pgp/pgp_pca/index.html 

[8] DFN-PCA, http://www.pca.dfn.de/eng/dfnpca/

[9] Horrowitz, M, "A PGP Public Key Server", 
http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html

[10] Hedberg, R., "Definition of X.500 Attribute Types and a Object Class to Hold public 
PGP keys", draft-ietf-asid-pgp-02.txt, February 1996 (expired draft)

[11] Chadwick, D.W., "Families of entries", draft-ietf-ldapext-families-00.txt, December 
1998 (work in progress)

[12] PDAMs to ISO/IEC 9594 Parts 1, 2, 3, 4, 5, 6, 7 and 9 to support the ITU-T Rec. 
F.510 "Automated Directory Assistance, White Pages Service Definitions", Collaborative 
ITU-T/SG7/Q15 and JTC1/SC6/WG7 OSI Directory Meeting 16-23 September 1998, 
Beijing, China, 
ftp://ftp.dante.net/pub/flowservices/NameFLOW/mirror/OSIdirectory/BeijingVancou
ver98Output/F510PDAMv12.pdf, Appendix 1 - Families



Author's Address

Peter Gietz
DANTE 
Francis House
112 Hills Road
Cambridge CB2 1PQ
United Kingdom

Phone [phone]
Email: [e-mail]
DN: cn=Peter Gietz, o=DANTE, c=GB

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

________________________________________________________________

       * *      Karl-Peter Gietz   -   Applications Engineer
     *    *
    *           Francis House       [e-mail]
   *            112 Hills Road           Tel [phone]
   *            Cambridge CB2 1PQ        Fax [phone]
D A N T E       United Kingdom      WWW http://www.dante.net
________________________________________________________________

--=====================_106109807==_--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA11934 for ietf-open-pgp-bks; Mon, 15 Mar 1999 03:16:18 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [194.221.90.36]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA11930 for <[e-mail]>; Mon, 15 Mar 1999 03:16:16 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.9.3/8.9.2) id MAA25249 for [e-mail]; Mon, 15 Mar 1999 12:22:34 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: key flags -- what do they mean?
Date: 15 Mar 1999 11:22:34 GMT
Organization: IKS GmbH Jena
Lines: 14
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: slrn (0.9.5.2 UNIX)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* Adam Back wrote:
>We have 3 flags (two are just variations on encryption):
>
>1) CA
>2) sign
>3) encrypt
>
>Jon said just now:
>| constraints." These are ways that the CA can describe its
>| certification.  Lutz, for example, needs these for his CA business

To clear this: CA means 'Certification', such a key is allowed to sign other
keys. 'sign' mean 'Signature creation', such a key is allowed to sign non
key material.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13769 for ietf-open-pgp-bks; Thu, 11 Mar 1999 14:09:51 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13763 for <[e-mail]>; Thu, 11 Mar 1999 14:09:19 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA14437; Thu, 11 Mar 1999 14:13:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 11 Mar 1999 14:10:11 -0800
To: Adam Back <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: key flags -- what do they mean?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:37 AM 3/11/99 GMT, Adam Back wrote:

|xx01 you can use this cert in the calcuation of validity for
|certification purposes but not for document signatures; odd because
|certifation is generally considered a more security critical operation
|than document signature.
|

Not if it's a key to be used for certification only. If someone were to
make a CA, that might be a reasonable thing to do. I just searched
certserver.pgp.com for all keys with the word "certification" in them. It
maxed out and sent me only 48 keys. 

|Overall the flags seem to be very CA centric.  The certify flag (when
|set to zero) has negative impact on the WoT, though perhaps a CA might
|be interested to use them to prevent people who had not paid the CA
|for a cetificate having their WoT connectivity strengthened by the
|CA's efforts.  As the user of a key so certified, one derives more
|security (better WoT connections) by ignoring the fact that the flag
|is set to zero).

There's a reason they are CA-centric. They were requested by people
building CAs.

I'll say it again. There is no web of trust in OpenPGP. There is no
mandated trust model in OpenPGP. The working group EXPLICITLY shot down the
notion that there should be a trust model, and that the semantic mechanisms
be left to the discretion of the implementer.

|
|The sign flag (when set to zero, which only makes sense to do if the
|certify flag set to one) is a bit odd.  As the user of a key so
|certified, one derives more security (better WoT connections) by
|ignoring the fact that the key is set to zero!
|

I agree with you completely that there will be many cases where third-party
statements will be ignored, or even met with derisive laughter. If we look
at Alice making statements about Bob's key, unless I know who Alice is (she
may be just a 64-bit keyid to me), and actually care, I'm not likely to
even look at the contents of her signature, let alone try to interpret it.

I also agree that in the vast majority of cases, third-party statements are
silly. We haven't even discussed the other two defined flags -- the "secret
shared" flag and the "ecrowed" flag. However, there are cases in which
these are useful. Let me give an example:

The Aluminum Bavariati, a secret society of 144,000 members, wants all its
members to use OpenPGP. The AB secret masters will sign each Bavariati
member's keys so that other members will know they're dealing with a fellow
Bavariatus. The Bavariati policy, though, is that they believe the
organization should use single-key RSA keys, and a separate key for comm
encryption, storage encryption, and signatures. They don't want any of
those keys used for key signing. They don't care which keys you use for
what on non-Bavariati business. These flags are exactly what the society
needs. You and I don't need them, but they serve a purpose that can't be
served without them.

	Jon


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07973 for ietf-open-pgp-bks; Wed, 10 Mar 1999 20:18:08 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA07444; Wed, 10 Mar 1999 20:13:26 -0800 (PST)
Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27909; Wed, 10 Mar 1999 20:18:56 -0800 (PST)
Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id UAA15042; Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Date: Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Message-Id: <[e-mail]>
From: Clifford Neuman <[e-mail]>
To: [e-mail]
Subject: Workshop on Countering Cyber-Terrorism
Reply-to: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

		      Countering Cyber-Terrorism
			      June 22-23
		      Marina del Rey, California
      A workshop sponsored by the Information Sciences Institute
	       of the University of Southern California

			Call for Participation

Recent studies warn of Cyber-Terrorism and the vulnerability of our
computer systems and infrastructure to attack. These reports identify
damage that determined, knowledgeable, and well-financed adversaries
could inflict on commercial, government, and military systems.  Such
attacks would have severe consequences for the public, and in
particular the economy, which has become dependant on computers and
communications infrastructure.

The objective of this workshop is to identify things that should be
done to improve our ability to detect, protect against, contain,
neutralize, mitigate the effects of, and recover from cyber-terrorist
attacks.  Participants are sought from the computer security,
electronic commerce and banking, network infrastructure, military, and
counter-terrorism communities, as well as those with experience of
cyber-terrorist attacks.  Recommendations may suggest research and
development or operational measures that can be taken.  The workshop
is NOT a forum for presentation of the latest security systems,
protocols or algorithms.  The workshop will address the strategies,
framework, and infrastructure required to combine and incrementally
deploy such technologies to counter the cyber-terrorist threat.

Attendance will be limited to approximately 25 participants.
Participants will be selected on the basis of submitted position
papers that raise issues for the workshop to discuss, identify threats
or countermeasures, or propose strategies or infrastructure to counter
the threat of cyber-terrorism. Position papers should be four pages or
less in length.  Submissions should be sent in e-mail in Word or PDF
format, or as ASCII text to [e-mail].

Please check the web page http://www.isi.edu/cctws for more
information, including a position paper from the organizers which will
be available two weeks prior to the submission deadline.

Important Dates:

  Organizer's Paper Available              April  5, 1999
  Position Papers Due                      April 19, 1999
  Notification of Acceptance               May 1, 1999
  Revised Position Papers Due              May 28, 1999
  Position Papers Available on Web         June 9
  Workshop Dates                           June 22-23

Organizing Committee:

   Bob Balzer, Information Sciences Institute, [e-mail]
   Thomas Longstaff, CERT Coordination Center, [e-mail]
   Don Faatz, the MITRE Corporation, [e-mail] 
   Clifford Neuman, Information Sciences Institute, [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA11910 for ietf-open-pgp-bks; Wed, 10 Mar 1999 16:34:13 -0800 (PST)
Received: from mail11.svr.pol.co.uk (mail11.svr.pol.co.uk [195.92.193.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA11905 for <[e-mail]>; Wed, 10 Mar 1999 16:34:11 -0800 (PST)
Received: from modem-36.dexfenfluramine.dialup.pol.co.uk ([62.136.62.36] helo=server.eternity.org) by mail11.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10KtW9-0006FU-00; Thu, 11 Mar 1999 00:40:05 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA07619; Thu, 11 Mar 1999 00:37:17 GMT
Date: Thu, 11 Mar 1999 00:37:17 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Jon Callas on Tue, 09 Mar 1999 17:33:39 -0800)
Subject: Re: key flags -- what do they mean?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the clarifications, I think we are getting close to
unambigous now.  My understanding of the semantics now leads me to the
conclusion that the flags are not that useful, or constructive.

To tally we have semantics of the following flags when used in a
certificate signature

       0x01 - This key may be used to certify other keys.

Jon:
> If the flags subpacket is present in the signature Alice made, the
> "certification" flag is interesting only when it is 0. [...] If it is
> zero, Alice is asking you not to propagate trust from her key to Bob's
> key to some other key. 

I'll come back to discussion of this below, but we now have a defined
and clear semantics.

       0x04 - This key may be used to encrypt communications.
       0x08 - This key may be used to encrypt storage.

Jon:
> If the top-level key is a signing-only key (e.g. DSA), then the
> certifier doesn't get to make any meaningful statements about
> encryption.
> [...]
> it's not been anyone's intent to do that [use encryption flags on
> certification signatures], and no one has implemented code to do
> that.

So 0x04 and 0x08 are meaningless in the context of certificates.

       0x02 - This key may be used to sign data.

This flag is of limited value also.  If we tabulate the possible
values, we have:

0x8 encrypt storage.	x	x	x	x
0x4 encrypt comms.	x	x	x	x
0x2 sign		0	1	0	1
0x1 certify		0	0	1	1

(encrypt are x = don't care because they have no meaning).

we can see that:

xx00 has no meaning as it is a null certificate (can't sign, can't
certify = no value!)

xx11 is redundant because it is the same as missing off the key flag

xx01 you can use this cert in the calcuation of validity for
certification purposes but not for document signatures; odd because
certifation is generally considered a more security critical operation
than document signature.

xx10 you can sign but not certify.

Now the discussion of the certify flag.

Overall the flags seem to be very CA centric.  The certify flag (when
set to zero) has negative impact on the WoT, though perhaps a CA might
be interested to use them to prevent people who had not paid the CA
for a cetificate having their WoT connectivity strengthened by the
CA's efforts.  As the user of a key so certified, one derives more
security (better WoT connections) by ignoring the fact that the flag
is set to zero).

The sign flag (when set to zero, which only makes sense to do if the
certify flag set to one) is a bit odd.  As the user of a key so
certified, one derives more security (better WoT connections) by
ignoring the fact that the key is set to zero!

So both use of either of these flags seems to detract from the WoT,
and the best thing a client could do from a security perspective is to
ignore both of them.

Comments?

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA04408 for ietf-open-pgp-bks; Wed, 10 Mar 1999 12:00:18 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04404 for <[e-mail]>; Wed, 10 Mar 1999 12:00:16 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA19050 for <[e-mail]>; Wed, 10 Mar 1999 15:06:24 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA19046 for <[e-mail]>; Wed, 10 Mar 1999 15:06:23 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA11527 for <[e-mail]>; Wed, 10 Mar 1999 15:04:52 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA11176 for <[e-mail]>; Wed, 10 Mar 1999 15:04:05 -0500 (EST)
Message-Id: <[e-mail]>
Date: Wed, 10 Mar 1999 15:04:05 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: key flags -- what do they mean?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: GeaeDVoFKSqFeiVRR1vxyA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "William H. Geiger III" <[e-mail]>
> 
> Perhaps I am a little slow here but this does not make sense. My
> understanding on an Identity CA like Verisign is to verify and certify the
> identity of a keyholder not what he is going to do with the key. If
> Verisign signs my key certifying that the holder of public key 0xFFFFFFFF
> is William H. Geiger III what difference does it make what I am doing with
> that key?? If Verisign want's to sign keys signifying more than that then
> they should have a separate signing key to do so (one key to certify
> identity, a separate key to certify someone as a CA).
> 
> It seems that there is an attempt to push PGP down the same ugly path that
> X.509 has gone down. Using the key as a payload for dynamic data opens up
> a whole list of problems that PGP does not need to be saddled with.


Equating VeriSign with X.509 is too narrow a view.  In an environment
where the CAs are not third parties, but part of the user's security
domain, it sometimes makes sense to carry privileges in certificates
which also certify an identity.  And sometimes it doesn't.  X.509
supports the following three scenarios (along with others which may
be less useful):

 1) binding a digital signature public key to a name only.  The name
     can then be used on access control lists.
 2) binding an encryption public key to a name and a set of roles,
     privileges, and categories.
 3) binding a set of roles/privileges/categories to another (base)
     certificate, using an "attribute certificate" which contains
     no public key at all.
     
Instead of saying "here's a technology, what can we do with it", it
makes more sense to say "here's our problem, how can we use technology
to solve it".  The public key certification problems I see usually boil
down to the three X.509 scenarios above: long term (multiple years)
identity, medium term (1 year) categories such as nationality or
security clearances, and locally-administered access to information,
which may range from hours or days up to a year.  The problems faced by
web site operators and addressed by third party CAs such as VeriSign
may differ, so the ways they choose to use X.509 may also differ.
The problems of grass-roots trust establishment are different
still, and PGP has evolved to satisfy them.

What do you mean by "ugly path"?  And is it a result of business
drivers you may not necessarily agree with, rather than a feature or
limitation of a particular technology?  If there is "an attempt to push
PGP ...", perhaps the attempt is motivated by a specific real-world
problem or business scenario.  And perhaps those with the ugly problem
would be better served by X.509, rather than by pushing PGP in an
unnatural direction.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04218 for ietf-open-pgp-bks; Wed, 10 Mar 1999 11:34:37 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04214 for <[e-mail]>; Wed, 10 Mar 1999 11:34:36 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA04170; Wed, 10 Mar 1999 11:39:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 10 Mar 1999 11:31:55 -0800
To: Thomas Roessler <[e-mail]>, Lutz Donnerhacke <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: key flags -- what do they mean?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:13 AM 3/10/99 +0100, Thomas Roessler wrote:
|On 1999-03-09 17:33:39 -0800, Jon Callas wrote about CA flags:

|I don't understand this.  Is it possible that you are confusing
|recommendations and "usual" certificates here?
|

I don't believe that I'm confusing things. What I'm saying is that since a
"normal" PGP key can be used for any purpose, a key that has no key flags
on it obviously is equivalent to these flags being 1. (That byte also
contains some other flags that are obviously zero if not present. If
there's a flaw in the definition, I think it's here.)

|We have well-defined recommendations ("trust signatures") in the
|spec. It would thus be silly to assume that a plain (user-id, key)
|certification implies any recommendation about the signee.  This
|means that the CA flag would just be a no-op on any certificates,
|and completely useless for actual CA use.
|

I disagree. If a CA wants to explicitly state that a signature is a "leaf
certificate" it puts a zero certification flag on its signature. That's
about the only real use for third-party key flags.

|The only reasonable interpretation would be that the "default" CA
|flag (i.e., the meaning of no such sub-packet) should be 0, i.e.,
|"don't pass trust".  This is actually consistant with the phrasing
|in the spec which says that "missing" flags should default to 0.
|

Given that the standard PGP way of dealing with key signatures is that the
user may pass trust any old way they choose (by setting introducers, etc.),
I have to disagree that that's the *only* reasonable interpretation.

Throughout the life of PGP, there has been a grand, unanswered question:
what does it mean to sign someone else's key? Many people have their own
opinions, but there's no agreement on it.

I know people who refuse to sign other people's keys because they believe
that it exposes them to liability. I don't understand this, but hey. One of
the reasons "local" signatures were created was that these people never
signed any keys whatsoever, and it kinda made the web of trust hard to work
with when all the keys someone dealt with were considered invalid.

There are other people who don't mind signing other people's keys, but
don't want their signatures used in further validity calculations. (Alice
is willing to sign Bob's key, but Alice doesn't want to imply that she
thinks Bob is at all competant to sign.) All this flag does is allow Alice
to say that.

|To put it short: The key flag spec is seriously flawed.  We may wish
|to revise this in a future version.

I disagree completely. It's a subtle concept, but it is the solution to a
flaw that exists without it.

	Jon



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA25197 for ietf-open-pgp-bks; Wed, 10 Mar 1999 01:20:54 -0800 (PST)
Received: from orange.easynet.co.uk (orange.easynet.co.uk [193.131.248.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA25189 for <[e-mail]>; Wed, 10 Mar 1999 01:20:52 -0800 (PST)
Received: from mail.context.co.uk ([195.40.43.131] helo=exchange.context.co.uk) by orange.easynet.co.uk with esmtp (Exim 2.11 #1) id 10KfGG-0002Jz-00 for [e-mail]; Wed, 10 Mar 1999 09:26:44 +0000
Received: by EXCHANGE with Internet Mail Service (5.5.2232.9) id <GTVYFVV5>; Wed, 10 Mar 1999 09:32:52 -0000
Message-ID: <11A8F53414D6D211820B0000E8E430683C8E@EXCHANGE>
From: Yurong  Lin <[e-mail]>
To: [e-mail]
Subject: sign off
Date: Wed, 10 Mar 1999 09:32:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	sign off


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22659 for ietf-open-pgp-bks; Wed, 10 Mar 1999 00:09:22 -0800 (PST)
Received: from riemann.iam.uni-bonn.de ([e-mail] [131.220.223.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22648 for <[e-mail]>; Wed, 10 Mar 1999 00:09:16 -0800 (PST)
Received: from sobolev.rhein.de ([e-mail] [131.220.223.84]) by riemann.iam.uni-bonn.de (8.8.8/8.8.8/Debian/GNU) with ESMTP  id JAA26372 ; Wed, 10 Mar 1999 09:14:55 +0100
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id JAA13897 ; Wed, 10 Mar 1999 09:13:28 +0100
Date: Wed, 10 Mar 1999 09:13:28 +0100
From: Thomas Roessler <[e-mail]>
To: Jon Callas <[e-mail]>, Lutz Donnerhacke <[e-mail]>
Cc: [e-mail]
Subject: Re: key flags -- what do they mean?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.1i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 1999-03-09 17:33:39 -0800, Jon Callas wrote about CA flags:

> If the flags subpacket is present in the signature Alice made, the
> "certification" flag is interesting only when it is 0. If it is 1,
> it's the same thing as Alice not putting it there at all. If it is
> zero, Alice is asking you not to propagate trust from her key to
> Bob's key to some other key.

I don't understand this.  Is it possible that you are confusing
recommendations and "usual" certificates here?

We have well-defined recommendations ("trust signatures") in the
spec. It would thus be silly to assume that a plain (user-id, key)
certification implies any recommendation about the signee.  This
means that the CA flag would just be a no-op on any certificates,
and completely useless for actual CA use.

The only reasonable interpretation would be that the "default" CA
flag (i.e., the meaning of no such sub-packet) should be 0, i.e.,
"don't pass trust".  This is actually consistant with the phrasing
in the spec which says that "missing" flags should default to 0.

To put it short: The key flag spec is seriously flawed.  We may wish
to revise this in a future version.

tlr
-- 
http://home.pages.de/~roessler/


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA20723 for ietf-open-pgp-bks; Tue, 9 Mar 1999 23:51:22 -0800 (PST)
Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA20717 for <[e-mail]>; Tue, 9 Mar 1999 23:51:20 -0800 (PST)
Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id BAA10537; Wed, 10 Mar 1999 01:55:38 -0600 (CST)
Received: from sji-ca43-110.ix.netcom.com(209.111.209.110) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma010488; Wed Mar 10 01:55:03 1999
X-Sender: [e-mail]
Message-Id: <v03110706b30bc44c4e53@[209.111.209.137]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 9 Mar 1999 23:44:39 -0700
To: Adam Back <[e-mail]>, [e-mail]
From: Bill Frantz <[e-mail]>
Subject: Re: key flags -- what do they mean?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:13 PM -0700 3/9/99, Adam Back wrote:
>Jon said just now:
>
>| CAs need something that they call in the X.509 world "basic
>| constraints." These are ways that the CA can describe its
>| certification.  Lutz, for example, needs these for his CA business
>| (and he was the main advocate of them). The most important one of
>| those flags for a CA is the certification flag. This is how that CA
>| states that the certification is a "leaf certificate" and not a
>| sub-CA that can further certify people.
>
>I understand Jon to be saying that if key A certifies another key B
>with the CA flag enabled, this indicates that A is delegating ability
>to certify *on A's behalf*.
>
>This sounds useful.  If I want to do something fancy with my keys,
>such as:
>
>- delegate trust from a securely stored key to other keys
>  which are used on a day to day basis
>...
>
>etc. I can use the CA flag to designate by sub-signature keys.
>
>So if we examine Bob's key and it has a signature from Alice's key A2
>and Alice's key A2 has a CA signature from Alice's key A1, that means
>we can categorise the three identities: A2 and A1 are the same person.
>B is someone else who A chose to certify the identity of.
>
>This is useful in that if we trust A1, A1 is telling us to trust A2 to
>the same level.

Of course, the level of trust is unlikely to be the same.  A daily use key
is more likely to be compromised than a securely stored key.  People may
place more trust in my 1024 bit DSA key than in my 768 bit RSA key, which
are cross signed.  (Or they my put more trust in RSA than in DSA.)


-------------------------------------------------------------------------
Bill Frantz       | Macintosh: Didn't do every-| Periwinkle -- Consulting
[phone]     | thing right, but did know  | 16345 Englewood Ave.
[e-mail] | the century would end.     | Los Gatos, CA 95032, USA




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19982 for ietf-open-pgp-bks; Tue, 9 Mar 1999 23:33:56 -0800 (PST)
Received: from unix1.seitz.de (unix1.seitz.de [193.102.72.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA19975 for <[e-mail]>; Tue, 9 Mar 1999 23:33:55 -0800 (PST)
Received: from pfo_ws058.seitz.de ([193.155.165.114]) by unix1.seitz.de (Netscape Messaging Server 3.54)  with ESMTP id AAA473C for <[e-mail]>; Wed, 10 Mar 1999 08:38:44 +0100
Message-ID: <001301be6ac9$2694a880$72a59bc1@pfo_ws058.seitz.de>
Reply-To: "=?iso-8859-1?Q?Michael_B=FCrkle?=" <[e-mail]>
From: "Michael Buerkle" <[e-mail]>
To: <[e-mail]>
Date: Wed, 10 Mar 1999 08:39:35 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BE6AD1.8701BDE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01BE6AD1.8701BDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

sign off

------=_NextPart_000_0010_01BE6AD1.8701BDE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>sign off</FONT></DIV></BODY></HTML>

------=_NextPart_000_0010_01BE6AD1.8701BDE0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23159 for ietf-open-pgp-bks; Tue, 9 Mar 1999 17:30:20 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23155 for <[e-mail]>; Tue, 9 Mar 1999 17:30:19 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id RAA27442; Tue, 9 Mar 1999 17:34:37 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 09 Mar 1999 17:33:39 -0800
To: Adam Back <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: key flags -- what do they mean?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:13 AM 3/10/99 GMT, Adam Back wrote:
|
|I understand Jon to be saying that if key A certifies another key B
|with the CA flag enabled, this indicates that A is delegating ability
|to certify *on A's behalf*.

I'm sorry I was unclear. I actually meant quite the opposite.

If any of those flags is set, it means exactly the same thing as if the
flags subpacket is not present. That's what I meant by it being a "negative
sense" flag, and by them being limitations of scope. It's assumed that if
no flags are present, the key can be used for any purpose (modulo technical
considerations, of course). Nonetheless, you're right, this allows you to
do fancy things with your keys.

|
|This sounds useful.  If I want to do something fancy with my keys,
|such as:
|
|- delegate trust from a securely stored key to other keys 
|  which are used on a day to day basis
|- start a time-stamping service, with extra time-stamping key
|- operate a CA with multiple keys for different purposes
|
|etc. I can use the CA flag to designate by sub-signature keys.
|
|I think this means that an implementation SHOULD NOT issue CA
|certificates for other peoples keys.  Or in other words the CA flag is
|for organisation of ones own keys.
|
|So if we examine Bob's key and it has a signature from Alice's key A2
|and Alice's key A2 has a CA signature from Alice's key A1, that means
|we can categorise the three identities: A2 and A1 are the same person.
|B is someone else who A chose to certify the identity of.
|
|This is useful in that if we trust A1, A1 is telling us to trust A2 to
|the same level.

Well, there's no such thing as a CA signature. There are "certification
signatures" (types 0x10 through 0x13) and mathematically, the issuer of a
certification signature is a CA. The traditional PGP term for this person,
though is an "introducer."

If the flags subpacket is present in the signature Alice made, the
"certification" flag is interesting only when it is 0. If it is 1, it's the
same thing as Alice not putting it there at all. If it is zero, Alice is
asking you not to propagate trust from her key to Bob's key to some other
key. That's all it means. You're free to ignore Alice. That's the essence
of the PGP model -- the user gets to say "so what?" to a CA.

|
|Jon also explained how the trust flag can be used to do something
|similar:
|
|| Here's an aside -- the "trust signature" is also a way to designate
|| a sub-CA, and this is the mechanism that NAI's PGP products use for
|| their "meta-introducers." 
|
|I am unclear here on what the difference is.  Why have two competing
|mechanisms to achieve the same thing?  The trust signature seems to be
|the more general mechanism, what is the CA flag adding?
|

They aren't the same thing. They are similar, but not at all the same
thing. Again, my apologies for rambling. The "trust signature" subpacket
allows an issuer to delegate validity signatures. Let's suppose that I set
Alice as a fully trusted introducer. Let us suppose that Alice has signed
Bob's key with a "trust signature" subpacket with depth of 1. This means
that I will accept as valid any key Bob as signed. If the depth was 2, then
any key signed by someone signed by Bob. And so on.

I will also note that when issued in pairs (Alice signs Bob and Bob signs
Alice) these function as "cross certification" signatures in X.509. I
discovered this in the course of some long discussions with some Entrust
people. 

|eg. Say the CA has a root key used for delegating roles to it's other
|keys.  It delegates the role of certifying client's keys with a
|signature with the CA flag.  It delegates the role of document signing
|to another key with a siganture with the CA and sign flags.

It should delegate that role by issuing a trust signature subpacket, not
with the flags.

|
|It would seem that the signature flag would be able to certify
|encryption sub-keys directly, so the encryption flag applied to
|certificates would be redundant under this speculated semantics.
|

It might seem that way, but it's not been anyone's intent to do that, and
no one has implemented code to do that. This is why we say that OpenPGP is
"escrow-surly." One certifies only the top-level key, and the keyholder can
play with subkeys to their delight.

|If key flags were intended to be used in the certificates the CA hands
|out to it's clients, I would really like to hear Lutz or someone
|explain what the CA requirement is for this, and what the semantics of
|the result is.  What would the certificates mean in the PGP WoT model
|where there is nothing but peer to peer certifcation, and where
|everyone is a CA.

The requirement, as explained to me, is to have a way to explicitly say, "I
take no responsibility for any certifications this key makes." I'll also
note again that OpenPGP has no trust model. PRZ has agreed to write an
informational RFC describing the WoT, but no one is required to use any
trust model.

|
|I think that the trust model can not be quite agnostic.  The two trust
|models (CA based, and WoT based) have to after all interoperate, or we
|risk fragmenting the interoperability between PGP users.
|
|So I think that the trust model necessarily has to be the WoT model,
|with the CA model being included via the definition that a CA is just
|another user in the PGP WoT with no special status.
|
|The semantics of the use of signature and encryption key flags in
|certificates are bizarre and out of sync with the properties of the
|WoT model I think are necessary for interoperability.
|

I'll write another note on this. I disagree, and I think it deserves its
own discussion. There are existing implementations that do just fine. They
don't implement key flags yet, but they will.

	Jon


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22480 for ietf-open-pgp-bks; Tue, 9 Mar 1999 16:16:03 -0800 (PST)
Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22476 for <[e-mail]>; Tue, 9 Mar 1999 16:16:01 -0800 (PST)
Received: from modem-122.samarium.dialup.pol.co.uk ([62.136.30.250] helo=server.eternity.org) by mail2.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10KWkv-0005iP-00; Wed, 10 Mar 1999 00:21:49 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA09940; Wed, 10 Mar 1999 00:13:32 GMT
Date: Wed, 10 Mar 1999 00:13:32 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: key flags -- what do they mean?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hal writes that certification is about making assertions that "this
key belongs to this person":

> In effect, the key flags are an attempt to take away some of the meaning
> of the certification.  The signer is trying to say, "I certify that
> this key belongs to this person, but I want you to pretend that I never
> said any such thing if the key is being used for a purpose not on my
> approved list."
>
> Why would I, as a third party who sees his certification, ever want to
> discard information in this manner?  He's plainly stated that he has
> certified the binding of the key to the user.  If I believe that he is
> honest and diligent, then this adds to my belief that the key is valid.
> Just because the key may be later used in a manner he would frown on,
> that doesn't make it invalid.  The binding between userid and key is
> valid independently of use.

It is in security terms I agree, and security is all certification is
about.

All rfc2440 says is "certification is for that use":

   [...] for example, a certification signature that has the "sign data"
   flag is stating that the certification is for that use.

We have 3 flags (two are just variations on encryption):

1) CA
2) sign
3) encrypt

Working through these with CA first:

1) CA

Jon said just now:

| CAs need something that they call in the X.509 world "basic
| constraints." These are ways that the CA can describe its
| certification.  Lutz, for example, needs these for his CA business
| (and he was the main advocate of them). The most important one of
| those flags for a CA is the certification flag. This is how that CA
| states that the certification is a "leaf certificate" and not a
| sub-CA that can further certify people.

I understand Jon to be saying that if key A certifies another key B
with the CA flag enabled, this indicates that A is delegating ability
to certify *on A's behalf*.

This sounds useful.  If I want to do something fancy with my keys,
such as:

- delegate trust from a securely stored key to other keys 
  which are used on a day to day basis
- start a time-stamping service, with extra time-stamping key
- operate a CA with multiple keys for different purposes

etc. I can use the CA flag to designate by sub-signature keys.

I think this means that an implementation SHOULD NOT issue CA
certificates for other peoples keys.  Or in other words the CA flag is
for organisation of ones own keys.

So if we examine Bob's key and it has a signature from Alice's key A2
and Alice's key A2 has a CA signature from Alice's key A1, that means
we can categorise the three identities: A2 and A1 are the same person.
B is someone else who A chose to certify the identity of.

This is useful in that if we trust A1, A1 is telling us to trust A2 to
the same level.

Jon also explained how the trust flag can be used to do something
similar:

| Here's an aside -- the "trust signature" is also a way to designate
| a sub-CA, and this is the mechanism that NAI's PGP products use for
| their "meta-introducers." 

I am unclear here on what the difference is.  Why have two competing
mechanisms to achieve the same thing?  The trust signature seems to be
the more general mechanism, what is the CA flag adding?

2) Sign

As the key flags on certificates were requested by Lutz for CA use, as
Jon wrote:

| Lutz, for example, needs these for his CA business (and he was the
| main advocate of them).

I will try to speculate what use a CA might have for a sign flag.
Perhaps these flags are for more CA-internal key delegation.

eg. Say the CA has a root key used for delegating roles to it's other
keys.  It delegates the role of certifying client's keys with a
signature with the CA flag.  It delegates the role of document signing
to another key with a siganture with the CA and sign flags.

It would seem that the signature flag would be able to certify
encryption sub-keys directly, so the encryption flag applied to
certificates would be redundant under this speculated semantics.

However key flags applied to certificates seem redundant.  Surely the
same function could be achieved with the trusted signature flag, and
self signatures with the relevant flags.  The trust signature flag
allows one to delegate trust, and the self siganture flags allow the
holder of the private key to define usage preferences.  This would be
better, as Thomas Roessler points out that putting key flags in
certificates restricts the key usage to applying to the userid only.

: Quoting from 5.2.3.2:
: 
:    Subpackets that appear in a certification self-signature apply to
:    the username, and subpackets that appear in the subkey
:    self-signature apply to the subkey. Lastly, subpackets on the
:    direct key signature apply to the entire key.
: 
: This means that a CA could only make a statement about key usage for
: a specific user-id.  Such a statement doesn't make too much sense.

If key flags were intended to be used in the certificates the CA hands
out to it's clients, I would really like to hear Lutz or someone
explain what the CA requirement is for this, and what the semantics of
the result is.  What would the certificates mean in the PGP WoT model
where there is nothing but peer to peer certifcation, and where
everyone is a CA.

Hal writes:
> This is the problem that I have with this use of the key flags.  There is
> no logical connection between how the key signer's hopes for how the key
> would be used, and the certification of validity which the signer makes.
> By trying to make these completely independent and orthogonal concepts
> become dependent on each other, the key flags are not consistent with
> the other semantics of our key signatures.

I agree.  The concept of one WoT user telling another WoT user that a
certificate is to be included in trust calculations for signatures
only and not for encryption is strange:

- Firstly only the signature keys are involved in the WoT anyway as
encryption sub-keys have trust delegated to them by the key owner, so
the "not for encryption" is meaningless if taken literally.  

- However, if one included in the semantics of "not for encryption"
that if the flag were applied to a signature key, the trust
transferred by the signature should be discounted if the key is used
to make a self signature, the signature provider has the ability to
mount a minor denial of service attack in ensuring that he does not
contribute to the ability of third parties to communicate
confidentially with the owner of the certified key.

- Jon already gave a semantics for a CA flag as a way for a CA to
organise it's own keys.  A CA flag can't be both for CA delegation and
for denying users ability to certify, unless one posits that no users
are allowed to certify (which is the X.509 model), which can not be
due to the WoT anyone a CA model.

etc.  

Jon wrote:

| OpenPGP is completely silent on trust model. You can use the
| traditional PGP model, a PKIX one, or any other trust model. I'll
| note that this isn't really straying from the original PGP
| philosophy. The PGP philosophy is that trust, validity, and all of
| that other stuff is in the eye of the beholder.  It comes from
| below, from the actual users, rather than being imposed from
| above. The no-mandated-model decision merely took that agnosticism
| one level higher.

I think that the trust model can not be quite agnostic.  The two trust
models (CA based, and WoT based) have to after all interoperate, or we
risk fragmenting the interoperability between PGP users.

So I think that the trust model necessarily has to be the WoT model,
with the CA model being included via the definition that a CA is just
another user in the PGP WoT with no special status.

The semantics of the use of signature and encryption key flags in
certificates are bizarre and out of sync with the properties of the
WoT model I think are necessary for interoperability.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21794 for ietf-open-pgp-bks; Tue, 9 Mar 1999 14:48:58 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21790 for <[e-mail]>; Tue, 9 Mar 1999 14:48:55 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA26631; Tue, 9 Mar 1999 14:53:47 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 09 Mar 1999 14:49:11 -0800
To: Adam Back <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: (fwd) Re: key flags -- what do they mean?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:25 PM 3/9/99 GMT, Adam Back wrote:
|
|Thomas Roessler sent me the below interpretation of key flags to
|certification in email.  Forwarded to the list with permission.
|
|Comments?
|

I agree completely with Thomas.

	Jon




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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21692 for ietf-open-pgp-bks; Tue, 9 Mar 1999 14:36:40 -0800 (PST)
Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21688 for <[e-mail]>; Tue, 9 Mar 1999 14:36:38 -0800 (PST)
Received: from modem-7.promethium.dialup.pol.co.uk ([62.136.30.7] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10KVCs-0001ne-00 for [e-mail]; Tue, 9 Mar 1999 22:42:35 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id WAA09581; Tue, 9 Mar 1999 22:25:05 GMT
Date: Tue, 9 Mar 1999 22:25:05 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
Subject: (fwd) Re: key flags -- what do they mean?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thomas Roessler sent me the below interpretation of key flags to
certification in email.  Forwarded to the list with permission.

Comments?

Adam

------- Start of forwarded message -------
Date: Mon, 8 Mar 1999 07:28:46 +0100
From: Thomas Roessler <[e-mail]>
To: Adam Back <[e-mail]>
Subject: Re: key flags -- what do they mean?
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96i
In-Reply-To: <[e-mail]>

On 1999-03-08 00:05:51 +0000, Adam Back wrote:

> So the question is does this mean that it is possible to say that a
> key may not be used for certification?

As I read this, the key's owner can say that a key should not be
used for certification (whatever this means), but a CA can't, and a
CA can't make sure the user doesn't change his mind.

Quoting from 5.2.3.2:

   Subpackets that appear in a certification self-signature apply to
   the username, and subpackets that appear in the subkey
   self-signature apply to the subkey. Lastly, subpackets on the
   direct key signature apply to the entire key.

This means that a CA could only make a statement about key usage for
a specific user-id.  Such a statement doesn't make too much sense.

Alternatively, a user could put a statement like this one into a key
self-signature.  Since this self-signature is not part of the
information signed by the CA, it's worthless from the British govt's
point of view - the user could change his mind and generate a new
self-signature.

Additionally, the standard doesn't mandate implementations to
implement the specific signature subpacket we are talking about.  In
5.2.3.1, you can read the following:

   An evaluator may "recognize" a subpacket, but not implement it. The
   purpose of the critical bit is to allow the signer to tell an
   evaluator that it would prefer a new, unknown feature to generate an
   error than be ignored.

   Implementations SHOULD implement "preferences".

Regards, tlr
- -- 
http://home.pages.de/~roessler/
------- End of forwarded message -------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21209 for ietf-open-pgp-bks; Tue, 9 Mar 1999 13:44:56 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21205 for <[e-mail]>; Tue, 9 Mar 1999 13:44:55 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id NAA26197; Tue, 9 Mar 1999 13:50:14 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 09 Mar 1999 13:48:13 -0800
To: "Simpson, Sam" <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: RE: A question on Twofish / AES / PGP
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:38 AM 3/9/99 +0000, Simpson, Sam wrote:
|Is there a document somewhere detailing the selection criteria or
|was it a "gut-feel"?  (Not that "gut-feels" are totally a bad
|thing...)
|

It was gut feel.

	Jon



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10277 for ietf-open-pgp-bks; Tue, 9 Mar 1999 02:34:04 -0800 (PST)
Received: from mia.co.uk (mail.mia.co.uk [195.152.234.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10272 for <[e-mail]>; Tue, 9 Mar 1999 02:34:02 -0800 (PST)
Received: from viruswall.mia.co.uk ([10.1.1.9]) by gateway.mia.co.uk with SMTP id <17031>; Tue, 9 Mar 1999 10:38:27 +0000
Received: from 10.1.1.2 by viruswall.mia.co.uk (InterScan E-Mail VirusWall NT)
Received: by mail.mia.co.uk with Internet Mail Service (5.0.1460.8) id <XJFPKFGS>; Tue, 9 Mar 1999 10:38:42 -0000
Message-ID: <[e-mail]>
From: "Simpson, Sam" <[e-mail]>
To: [e-mail]
Subject: RE: A question on Twofish / AES / PGP
Date: Tue, 9 Mar 1999 10:38:40 +0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Many thanks to all the people who replied (and set me straight on
several issues).

I won't reply individually to save list bandwidth, but I have a
few comments:


William H. Geiger III wrote:

> Well IMHO we have enough good symetric cyphers in there right
now:

I agree totally!  There is no (IMHO) rush to add algorithms.  I
am not convinced that Twofish is special enough (sorry Bruce!) to
make an exception to add it to the OpenPGP standard at this
point.


Jon Callas wrote:
> Two groups of developers, the NAI/PGP group and the GNU Privacy
Guard
> group, have each said that they want to put Twofish into their
> implementations.[...]

Is there a document somewhere detailing the selection criteria or
was it a "gut-feel"?  (Not that "gut-feels" are totally a bad
thing...)

> If you disagree strongly, and believe that the consensus has 
> gone the wrong way, keep arguing!

I do disagree with the special status that's being given to
Twofish (or rather, I'd like to know the rationale), but since
I'm new to this forum I'm not going to upset people on an issue
that this has been previously discussed and agreed upon.

I agree totally with your point that the "receiver chooses the
algorithms" - but will users have the sense not to switch Twofish
on (or switch it off if it's going to be on by default) -
especially in view of the "trendy" status of Twofish.


Werner Koch wrote:

> According to Schneier, we should replace
> Blowfish by Twofish right now because he (and others too)
trusts
> Thwofish more.

This appears to be contra advice given by Schneier in sci.crypt,
but anyway.....



Again, many thanks for your thoughtful & polite replies.  It is
my intention to remain subscribed to this list, so I look forward
to speaking to you all more in future.


Fond regards,

Sam Simpson
Communications Analyst
- -- http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components.  PGP Keys available at the
same site. 


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBNuT6Wu0ty8FDP9tPEQJMsACfVbeP3heeppDm5neEvKfFPTe7hu4AnRa7
i3BN4E9XXGaf9ayDB53tXim8
=rDPo
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA23583 for ietf-open-pgp-bks; Mon, 8 Mar 1999 20:54:07 -0800 (PST)
Received: from pompano.pcola.gulf.net ([e-mail] [198.69.72.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23578 for <[e-mail]>; Mon, 8 Mar 1999 20:54:06 -0800 (PST)
Received: from whgiii (seiwhale43.pcola.gulf.net [208.22.198.58]) by pompano.pcola.gulf.net (8.9.1a/8.9.1) with SMTP id WAA14610; Mon, 8 Mar 1999 22:59:57 -0600 (CST)
Received: from whgiii by whgiii (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id WAA012.00; Mon, 8 Mar 1999 22:59:53 -0600
Message-Id: <199903090459.WAA012.00@whgiii>
From: "William H. Geiger III" <[e-mail]>
Date: Mon, 08 Mar 1999 22:51:45 -0600
To: Jon Callas <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: key flags -- what do they mean?
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.60 b60 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In <[e-mail]>, on 03/08/99 
   at 07:44 PM, Jon Callas <[e-mail]> said:

>An example is in order. Suppose that I have signed Joe Blow's key with
>key flags for encryption, but not signing. You have me as a fully trusted
>introducer. If you're going to encrypt a message to Joe, you consider his
>key valid, because I have signed it. If you are validating a signature
>that key has made, you don't consider it valid because your validity
>calculation extends from my certification signature, which doesn't
>include signatures. 

Perhaps I am a little slow here but this does not make sense. My
understanding on an Identity CA like Verisign is to verify and certify the
identity of a keyholder not what he is going to do with the key. If
Verisign signs my key certifying that the holder of public key 0xFFFFFFFF
is William H. Geiger III what difference does it make what I am doing with
that key?? If Verisign want's to sign keys signifying more than that then
they should have a separate signing key to do so (one key to certify
identity, a separate key to certify someone as a CA).

It seems that there is an attempt to push PGP down the same ugly path that
X.509 has gone down. Using the key as a payload for dynamic data opens up
a whole list of problems that PGP does not need to be saddled with.

- -- 
- ---------------------------------------------------------------
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
- ---------------------------------------------------------------
 
Tag-O-Matic: Don't be held back by yesterday's DOS!  Try today's OS/2!

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i OS/2 for non-commercial use
Comment: Registered_User_E-Secure_v1.1b1_ES000000
Charset: cp850

wj8DBQE25KrGlHpjA6A1ypsRAlirAJ9hFAzrVHMMlIS/DYK26NbQv8W5xQCgx/Sw
WCg4CL3U1wzvovltaF8wT4s=
=zClR
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA22076 for ietf-open-pgp-bks; Mon, 8 Mar 1999 20:33:15 -0800 (PST)
Received: from pompano.pcola.gulf.net ([e-mail] [198.69.72.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA22069 for <[e-mail]>; Mon, 8 Mar 1999 20:33:14 -0800 (PST)
Received: from whgiii (seiwhale43.pcola.gulf.net [208.22.198.58]) by pompano.pcola.gulf.net (8.9.1a/8.9.1) with SMTP id WAA10522; Mon, 8 Mar 1999 22:39:01 -0600 (CST)
Received: from whgiii by whgiii (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id WAA011.80; Mon, 8 Mar 1999 22:38:55 -0600
Message-Id: <199903090438.WAA011.80@whgiii>
From: "William H. Geiger III" <[e-mail]>
Date: Mon, 08 Mar 1999 22:23:52 -0600
To: [e-mail]
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: key flags -- what do they mean?
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.60 b60 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In <[e-mail]>, on 03/08/99 
   at 08:52 PM, [e-mail] said:

>This is the problem that I have with this use of the key flags.  There is
>no logical connection between how the key signer's hopes for how the key
>would be used, and the certification of validity which the signer makes.
>By trying to make these completely independent and orthogonal concepts
>become dependent on each other, the key flags are not consistent with the
>other semantics of our key signatures.

Well I have been doing quite a bit of studying/thought on the use of PGP
in an e-comm environment and the more I look at it the more I am convinced
that using the public key as a payload for information is the wrong
approach.

While the WOT is a convenient mechanism for individuals to "certify" a key
and a user's identity it is a poor mechanism for a CA (this expands past
just the simple identity CA's we see today). At most a CA should sign a
key signifying that they have some data relating to the key in their data
base. Any additional information should be retrieved *directly* from the
CA using the public key as a "token" linking the owner of the key to the
records in the database. The problem we have here is trying to attach
dynamic data (data that can change at any time) in a static format
(attached to a public key that the signer may or may not be able to change
when the data changes).

Don't feel bad though the underlying format is good, this is just an
implementation problem (we are much better off than the X.509 crowd <g>).

- -- 
- ---------------------------------------------------------------
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
- ---------------------------------------------------------------
 
Tag-O-Matic: Program call to load Windows- "Here_piggy_piggy_piggy"

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i OS/2 for non-commercial use
Comment: Registered_User_E-Secure_v1.1b1_ES000000
Charset: cp850

wj8DBQE25KXclHpjA6A1ypsRAo9kAKCCXm7u/m40V8NG2rUihiMlvSe8aQCgyyjk
5+/1U1X7XTLZm/enk7oRKs0=
=r/yC
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA15744 for ietf-open-pgp-bks; Mon, 8 Mar 1999 17:55:12 -0800 (PST)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA15740 for <[e-mail]>; Mon, 8 Mar 1999 17:55:11 -0800 (PST)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id SAA02056 for <[e-mail]>; Mon, 8 Mar 1999 18:01:03 -0800 (PST)
Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id RAA04964 for [e-mail]; Mon, 8 Mar 1999 17:52:28 -0800
Date: Mon, 8 Mar 1999 17:52:28 -0800
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: key flags -- what do they mean?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My concern is that these key flags carry implications which are
inconsistent with other aspects of the spec.

What does a certification mean?  Let us focus on a certification without
any special flags or subpackets.  It is a simple binding, by the signer,
between key and userid.  It is an assertion that "this key belongs to
this person".

Now with the key flags, we have a new element.  The idea is that the
signer can turn on some flags and turn off others, and request that his
certification be ignored if the key is being used for a purpose not in
the listed set of flags.

In effect, the key flags are an attempt to take away some of the meaning
of the certification.  The signer is trying to say, "I certify that
this key belongs to this person, but I want you to pretend that I never
said any such thing if the key is being used for a purpose not on my
approved list."

Why would I, as a third party who sees his certification, ever want to
discard information in this manner?  He's plainly stated that he has
certified the binding of the key to the user.  If I believe that he is
honest and diligent, then this adds to my belief that the key is valid.
Just because the key may be later used in a manner he would frown on,
that doesn't make it invalid.  The binding between userid and key is
valid independently of use.

This is the problem that I have with this use of the key flags.  There is
no logical connection between how the key signer's hopes for how the key
would be used, and the certification of validity which the signer makes.
By trying to make these completely independent and orthogonal concepts
become dependent on each other, the key flags are not consistent with
the other semantics of our key signatures.

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA15203 for ietf-open-pgp-bks; Mon, 8 Mar 1999 17:07:45 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA15199 for <[e-mail]>; Mon, 8 Mar 1999 17:07:44 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id RAA18350; Mon, 8 Mar 1999 17:12:09 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Mar 1999 17:11:24 -0800
To: "Simpson, Sam" <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: A question on Twofish / AES / PGP
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 04:48 PM 3/8/99 +0000, Simpson, Sam wrote:

|It has previously been mentioned that Twofish would be added to
|PGP before completion of the AES process.  I think everyone would
|agree that the move to a 128-bit block, 128/192/256-bit key
|cipher is a Good Thing, but the point of this message is to ask
|"why the choice of Twofish?"

That's an over-simplification of what has happened.

Two groups of developers, the NAI/PGP group and the GNU Privacy Guard
group, have each said that they want to put Twofish into their
implementations. If there was only one group who wanted to do this, the
proper thing for them to do is use the experimental/private range. (By the
bye, this was my opinion at NAI.) However, when two groups want to do the
same thing, and they both come to the working group, the working group
should do something.

We exist as a working group to foster interoperability between
implementors. If two groups of implementors want Twofish, we ought to
oblige them. Or at least consider it. 

As part of that consideration, one thing to remember is that in OpenPGP, we
spcifically designed the protocol so that the receiver decides which
algorithms they accept. When we did that, we didn't have all the new AES
algorithms as examples of tempting, but controversial algorithms. I pushed
the point myself with the ROT-N algorithm. OpenPGP is safe from
controversial algorithms because of the algorithm negotiation procedure. If
you don't want to use Twofish, you don't have to. It's that simple.

|Even worse there was the comment (I'm not going to publish e-mail
|addresses to save embarrassment!): "I suggest *replacing*
|Blowfish with Twofish. If you trust one, why not the other?"

Well, that suggestion didn't make the consensus. Thanks for agreeing with
consensus.

By the bye, thanks for your observations. They're quite lucid, and provide
a good analysis of why an individual might not want to use Twofish.
However, it's still attractive enough of an algorithm to have some
groundswell behind it, and it's that support the working group responds to.
It is indeed possible that in a year we will deprecate the identifier.
(Heck, it's possible that in two weeks we'll deprecate it.) But it does
seem like a reasonable thing to permit, here in the early part of 1999. If
you disagree strongly, and believe that the consensus has gone the wrong
way, keep arguing! It's not too late to change people's minds. We're
listening.

	Jon



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15059 for ietf-open-pgp-bks; Mon, 8 Mar 1999 16:50:02 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15055 for <[e-mail]>; Mon, 8 Mar 1999 16:50:01 -0800 (PST)
Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA18266 for <[e-mail]>; Mon, 8 Mar 1999 16:55:24 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 08 Mar 1999 16:44:20 -0800
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: key flags -- what do they mean?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The key flags are there for a variety of purposes. The two broadest
categories, though, are in self-signatures, and in key certification
signatures.

In self-signatures, they are a statement of what the user wants them to be
used for. For example, there are many people who are old-time PGP users who
have a username that says something like "Joe Blow <[e-mail]> [Document
Signing Key]". Informally, I know (because I'm an intelligent person) that
if I see a certification signature made with that key, I should ignore it.
In effect, Joe is asking the world never to set that key as an introducer.
Secondarily, Joe is asking the world not to encrypt to that key. Note that
there are also the deprecated key types for sign-only RSA and encrypt-only
RSA. These were done by ViaCrypt, for the obvious reasons. However, it's
silly to have three numbers reserved for every general-purpose algorithm we
come up with. It's bad enough that we have two for Elgamal. The proper way
to scope-limit a key is to use flags like this. This is their primary
purpose, for the owner of the certificate to scope-limit any of the keys in
the key bundle.

The other category is that of signing someone else's key -- making a
certification signature. It has been said of PGP (and I'm on of the people
who has said it), that PGP democratizes the CA; anyone can be a CA. In the
mathematical sense of what a CA is, any certification issuer is a CA. In
the legal sense, there's more to it, and I'm not going to go there, quite
yet. Remember that OpenPGP is a format specification, not a law.
Nonetheless, CAs need something that they call in the X.509 world "basic
constraints." These are ways that the CA can describe its certification.
Lutz, for example, needs these for his CA business (and he was the main
advocate of them). The most important one of those flags for a CA is the
certification flag. This is how that CA states that the certification is a
"leaf certificate" and not a sub-CA that can further certify people. Here's
an aside -- the "trust signature" is also a way to designate a sub-CA, and
this is the mechanism that NAI's PGP products use for their
"meta-introducers." Nonetheless, Lutz and other people building PGP CAs
felt very strongly about needing this mechanism for basic constraints.

There is a question, though, about what these third-party statements mean.
I believe that for encrypting and signing, they are nothing more than a way
that the certifier can state whether they want their signature added into a
validity calculation. 

An example is in order. Suppose that I have signed Joe Blow's key with key
flags for encryption, but not signing. You have me as a fully trusted
introducer. If you're going to encrypt a message to Joe, you consider his
key valid, because I have signed it. If you are validating a signature that
key has made, you don't consider it valid because your validity calculation
extends from my certification signature, which doesn't include signatures. 

Note that it is perfectly reasonable for different certifiers to have
different opinions about their certifications. It may be *my* policy that I
never certify a key for both encryption and signatures. That's well and
good, but Joe is free to do what he wants. Some other certifier may have a
different policy, and that's their right. It's an issue on which
gentlepersons can disagree. When I sign a key for encryption but not
signing, I am in effect saying, "I make no warranties about the validity of
a signature made with this key." Someone else may choose to make warranties
(including the key owner).

The certification flag is, of course, a little trickier. OpenPGP is
completely silent on trust model. You can use the traditional PGP model, a
PKIX one, or any other trust model. I'll note that this isn't really
straying from the original PGP philosophy. The PGP philosophy is that
trust, validity, and all of that other stuff is in the eye of the beholder.
It comes from below, from the actual users, rather than being imposed from
above. The no-mandated-model decision merely took that agnosticism one
level higher.

That being said, all of these usage flags are negative-sense. I mean by
that that they only say something if they are off. If they are on, then
it's equivalent to the flags not being there at all. So, if a certifier
turns off that flag, they are saying, "Don't use my certification in any
further validity calculations." And that is all they are saying. Ideally,
that if you set Joe Blow's trust up to fully trusted, and the only validity
path for his key is my certification, nothing further will happen. No keys
in your world will now become valid because Joe signed them. The reason is
that my signature is the only one that makes that key valid. If there are
other paths that make that key valid (like your own signature), that's
different. My signature simply contains in it a limitation of scope.

Another way to think of this is that it is a statement that limits the
certifier's liability. If I certify Joe Blow's key for encryption, and he
uses it for signatures, my hands are clean. That's all it means.


The question that Adam and Ian were bringing up was whether this enables a
repressive government policy -- one in which certifying an encryption key
obligates the certifier to hold a copy of it. There are a number of reasons
why OpenPGP does *not* enable this. First, in OpenPGP, the typical use is
that a certifier only certifies the top-level key. The enhanced key
structure (Chapter 11 of 2440) *only* specifies certifications of the
top-level key. If the top-level key is a signing-only key (e.g. DSA), then
the certifier doesn't get to make any meaningful statements about encryption.

But also, let's suppose I ask you to sign my key. Let's also suppose that
it is illegal for you to sign my key as being valid for encryption unless I
give you my secret key. I'm not going to do that, I'm not daft, so just
sign it as being valid for signing, please. I'm sorry your government is
being stupid (but also secretly releived that for once it isn't mine being
stupid). I understand. Just sign it for what you legally can. If you'd
like, I'll sign yours.

Behind this, though, there is another issue, and that is the issue I
mentioned above about the mathematical and legal definitions of a CA.
Mathematically, a CA is the same things as an issuer. All key signers are
CAs. But legally, there are *policies* that CAs follow, and an issuer is
not a CA simply because they do some funny math. If some government makes
it illegal to be an issuer unless the issuer follow some policies (CA
policies), that's a bad situation, but not a protocol issue.

	Jon



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12101 for ietf-open-pgp-bks; Mon, 8 Mar 1999 11:42:11 -0800 (PST)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12097 for <[e-mail]>; Mon, 8 Mar 1999 11:41:55 -0800 (PST)
Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA04336 for [e-mail]; Mon, 8 Mar 1999 20:47:35 +0100 (MET)
Received: (qmail 25765 invoked from network); 8 Mar 1999 19:25:15 -0000
Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 8 Mar 1999 19:25:15 -0000
Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10K5fO-0000Qh-00; Mon, 8 Mar 1999 20:26:18 +0100
Date: Mon, 8 Mar 1999 20:26:18 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: A question on Twofish / AES / PGP
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <199903081831.MAA006.38@whgiii>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.96i
In-Reply-To: <199903081831.MAA006.38@whgiii>; from William H. Geiger III on Mon, Mar 08, 1999 at 12:23:06PM -0600
X-URL: http://www.d.shuttle.de/isil
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"William H. Geiger III" <[e-mail]> writes:

> should go. Unfortunately if NAI decides to start using ID #10 for twofish
> there is very little the rest of us can do about it (as seen with the
> PhotoID). I have asked several times for us to establish a formal

These are different stories.  We discussed Twofish here on my request
and agreed to use id 10 for it.  

How the PhotoID or the split key mechanism works has not been
discussed here (afaik). 


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11561 for ietf-open-pgp-bks; Mon, 8 Mar 1999 10:45:24 -0800 (PST)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11557 for <[e-mail]>; Mon, 8 Mar 1999 10:45:16 -0800 (PST)
Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id TAA00203 for [e-mail]; Mon, 8 Mar 1999 19:50:57 +0100 (MET)
Received: (qmail 25621 invoked from network); 8 Mar 1999 18:37:44 -0000
Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 8 Mar 1999 18:37:44 -0000
Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10K4vP-0007cg-00; Mon, 8 Mar 1999 19:38:47 +0100
Date: Mon, 8 Mar 1999 19:38:47 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: A question on Twofish / AES / PGP
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.96i
In-Reply-To: <[e-mail]>; from Simpson, Sam on Mon, Mar 08, 1999 at 04:48:04PM +0000
X-URL: http://www.d.shuttle.de/isil
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Simpson, Sam" <[e-mail]> writes:

> cipher is a Good Thing, but the point of this message is to ask
> "why the choice of Twofish?"

Twofish has not been chossen as the AES algorithm for OpenPGP but 
just as another optional algorithm.  The only required algorithm
is 3DES - all others are optional.  Leaving out CAST5, there are only
two other algorithms:  IDEA which can't be used due to patent
restrictions and Blowfish which has a someone strange design but is
much faster than 3DES.  According to Schneier, we should replace
Blowfish by Twofish right now because he (and others too) trusts
Thwofish more.  The algorithm identifiers for AES are still reserved.

Anayway it it optional and noone is required to implement it.  The
preference system gives every user/implementor a chance to disallow
optional algorithms. 

> My main concern is that naive users will see "Twofish" &
> "Schneier" and create keys specifying this algorithm.  Sure, the

How can a user create keys?  The symmetric ciphers are only used for 
session keys and if you have the requirement for really secure
encryption you won't use PK but use 2 symmetric algorithms in turn
with 2 randomly created passphrases.

More on AES in 2 weeks.

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11390 for ietf-open-pgp-bks; Mon, 8 Mar 1999 10:26:17 -0800 (PST)
Received: from pompano.pcola.gulf.net ([e-mail] [198.69.72.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11386 for <[e-mail]>; Mon, 8 Mar 1999 10:26:15 -0800 (PST)
Received: from whgiii (vaquita12.pcola.gulf.net [208.22.198.123]) by pompano.pcola.gulf.net (8.9.1a/8.9.1) with SMTP id MAA09138; Mon, 8 Mar 1999 12:32:02 -0600 (CST)
Received: from whgiii by whgiii (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id MAA006.38; Mon, 8 Mar 1999 12:31:59 -0600
Message-Id: <199903081831.MAA006.38@whgiii>
From: "William H. Geiger III" <[e-mail]>
Date: Mon, 08 Mar 1999 12:23:06 -0600
To: "Simpson, Sam" <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: A question on Twofish / AES / PGP
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.60 b60 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In <[e-mail]>, on 03/08/99 
   at 11:48 AM, "Simpson, Sam" <[e-mail]> said:

>I don't want to "throw a Sternlight" on this point - but frankly I am
>concerned.

Well IMHO we have enough good symetric cyphers in there right now:

 9.2. Symmetric Key Algorithms 
 
        ID           Algorithm 
        --           ---------
        0          - Plaintext or unencrypted data 
        1          - IDEA [IDEA]
        2          - Triple-DES (DES-EDE, as per spec - 
                     168 bit key derived from 192)
        3          - CAST5 (128 bit key, as per RFC 2144)
        4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
        5          - SAFER-SK128 (13 rounds) [SAFER]
        6          - Reserved for DES/SK
        7          - Reserved for AES with 128-bit key 
        8          - Reserved for AES with 192-bit key 
        9          - Reserved for AES with 256-bit key 
        100 to 110 - Private/Experimental algorithm.
 
    Implementations MUST implement Triple-DES. Implementations SHOULD 
    implement IDEA and CAST5.Implementations MAY implement any other 
    algorithm.
 
 
But then again everyone has their pet algorithm that they want to put into
the code. Code ranges from 100 to 110 are reserved for
private/experimental algorithms and that is where twofish and the rest
should go. Unfortunately if NAI decides to start using ID #10 for twofish
there is very little the rest of us can do about it (as seen with the
PhotoID). I have asked several times for us to establish a formal
mechanism for assigning ID numbers, as it stands now it is first come
first serve.

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10457 for ietf-open-pgp-bks; Mon, 8 Mar 1999 08:43:34 -0800 (PST)
Received: from mia.co.uk (mail.mia.co.uk [195.152.234.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10453 for <[e-mail]>; Mon, 8 Mar 1999 08:43:30 -0800 (PST)
Received: from viruswall.mia.co.uk ([10.1.1.9]) by gateway.mia.co.uk with SMTP id <17029>; Mon, 8 Mar 1999 16:47:47 +0000
Received: from 10.1.1.2 by viruswall.mia.co.uk (InterScan E-Mail VirusWall NT)
Received: by mail.mia.co.uk with Internet Mail Service (5.0.1460.8) id <XJFPK1L7>; Mon, 8 Mar 1999 16:48:08 -0000
Message-ID: <[e-mail]>
From: "Simpson, Sam" <[e-mail]>
To: [e-mail]
Subject: A question on Twofish / AES / PGP
Date: Mon, 8 Mar 1999 16:48:04 +0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(hmmm. This isn't good etiquette, start reading a list one minute
and posting the next - but hopefully you'll all agree this is
'on-topic' for this list?).

First a mesage I sent (earlier today to the PGP-Users mailing
list):

It has previously been mentioned that Twofish would be added to
PGP before completion of the AES process.  I think everyone would
agree that the move to a 128-bit block, 128/192/256-bit key
cipher is a Good Thing, but the point of this message is to ask
"why the choice of Twofish?"

Is strength (or "expected strength" at this stage) the criteria? 
If you're going to select a cipher from the x candidates (many of
which, including Twofish, have only had 8 months peer-review)
then surely you would go for the most ultra-conservative design? 
Even better, wouldn't you select a cipher which has been analysed
for a longer period?

Is speed a selection criteria for block ciphers in PGP (if so why
3DES <g>)?

Is heritage the criteria?  If so, there are other candidates with
a similar heritage: MARS (Coppersmith) , RC6 (Rivest), Serpent
(Anderson, Biham & Knudsen), Rijndael (Daemen & Rijmen), DFC
(Vaudenay), CAST-256 (Adams) etc.

Are patent issues part of the criteria?  We would expect so (in
view of IETF views on this matter and the OpenPGP standard). 
This potentially discounts RC6 & MARS and one or two others.

Are some of the more obscure (and of little practical importance
in PGP?) criteria being considered?  For example: key agility,
resistance to timing / power analysis, smart card / hardware
implementation, scalability to 64-bit architectures.


I am a great fan of Bruce Schneier (and Twofish actually) - but
isn't it to soon jump on the bandwagon?  One notes that Twofish
has received some criticism in AES Conference II papers:

  1) "Report on the AES Candidates" by Vaudenay et al.  Points
out that S-Boxes should "no longer be called key-dependant". Also
says "consists of a collection of patches" & "we do not think
this design comes from deep investigation".  Of course, this
paper is written by the authors of another AES candidate.

  2) "An observation on the Key Schedule of Twofish" by Mirza &
Murphy (RHBNC), points out several deficiencies with the key
schedule.  Implications unknown, but it does directly contradict
implicit claims in the original Twofish paper.


*None* of the candidates escaped criticism from a "cryptographic
security" point of view, but if one wanted to objectively select
an AES candidate by any combination of the above criteria, would
we logically select Twofish at the moment?

My main concern is that naive users will see "Twofish" &
"Schneier" and create keys specifying this algorithm.  Sure, the
User Manual will no doubt state "Twofish is new blah blah blah"
but, in my experience, users never RTFM anyway.

I hope NAI employees don't see this is as a criticism of them (I
have nothing but respect for you guys).  Rather, I suspect I'm
missing something quite obvious...


Then someone pointed me to your archives and I had a read through
the posts referring to Twofish.... So my follow-up is:

I'm even less convinced now.  The Twofish topic seems to have
started with the comment "because Twofish is one of most
promising candidates for AES".  People don't seem to have
challenged this statement (or even discussed it!).  Is Twofish
one of the most promising?  By what metric?  Is it that much
better than all of the other candidates that you should run with
it now?  Really?  Even after the recent AES Conference II papers?

Even worse there was the comment (I'm not going to publish e-mail
addresses to save embarrassment!): "I suggest *replacing*
Blowfish with Twofish. If you trust one, why not the other?"

Extremely naive!  Blowfish and Twofish are radically different
(ok - they are both BFN etc and the key schedule consists of
iterations of a function used in encryption, but come on!). 
Years of analysis and faith in Blowfish certainly does not carry
forward to Twofish.

Small changes in block ciphers can move a cipher from "thought to
be secure" to "trivially" broken.


I don't want to "throw a Sternlight" on this point - but frankly
I am concerned.




Please be gentle with replies :-)

Sam Simpson
Communications Analyst
- -- http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components.  PGP Keys available at the
same site. 

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBNuP/cO0ty8FDP9tPEQKoqwCeIfOWlbKgecjIQ0U+cR/n9jDaGxAAoPTY
QobcM6dKr6xkAsClFyybjMI4
=ELZ2
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA02755 for ietf-open-pgp-bks; Sun, 7 Mar 1999 23:24:53 -0800 (PST)
Received: from stax05.cubis.de (wks1.cubis.de [194.112.101.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA02707; Sun, 7 Mar 1999 23:18:24 -0800 (PST)
Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id IAA25676; Mon, 8 Mar 1999 08:13:00 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 08 Mar 1999 08:10:05 +0000
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[e-mail]>
Organization: Secunet GmbH - The Trust Company
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Call for Papers: CQRE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA02708
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(As some of you have problems with the html-version of the CFP
you will find the full version below. Sorry for this inconvenience.)


***************************************************************
                     Call for Papers
            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.
---------------------------------------------------------------
 Deadline for submission of extended abstracts: May 14, 1999
website: http://www.secunet.de/forum/cqre.html
mailing-list: send mailto:[e-mail] 
(where the subject is "subscribe" without paranthesis)
***************************************************************

The "CQRE - secure networking" provides a new international
forum giving a close-up view on information security in the context
of rapidly evolving economic processes. The unprecedented
reliance on computer technology transformed the previous technical
side- issue "information security'' to a management problem
requiring decisions of strategic importance. Hence, the targeted
audience represents decision makers from government, industry,
commercial, and academic communities. If you are developing
solutions to problems relating to the protection of your country’s
information infrastructure or a commercial enterprise, consider
submitting a paper to the "CQRE - secure networking" conference.

We are looking for papers and panel discussions covering:
. electronic commerce
 - new business processes
 - secure business transactions
 - online merchandising
 - electronic payment / banking
 - innovative applications

. network security
 - virtual private networks
 - security aspects in internet utilization
 - security aspects in multimedia-
   applications
- intrusion detection systems

. legal aspects
 - digital signatures acts
 - privacy and anonymity
 - crypto regulation
 - liability

. corporate security
 - access control
 - secure teleworking
 - enterprise key management
 - IT-audit
 - risk / disaster management
 - security awareness and training
 - implementation, accreditation, and
   operation of secure systems in a
   government, business, or industry
   environment

. security technology
 - cryptography
 - public key infrastructures
 - chip card technology
 - biometrics

. trust management
 - evaluation of products and systems
 - international harmonization of security
   evaluation criterias
. standardization
. future perspectives

Any other contribution addressing the involvement of IT security in
economic processes will be welcome. Authors are invited to submit
an extended abstract of their contribution to the program chair.
The submissions should be original research results, survey
articles or ``high quality'' case studies and position papers.
Product advertisements are welcome for presentation, but will not
be considered for the proceedings. Manuscripts must be in English,
and not more than 2.000 words. The extended abstracts should be in
a form suitable for anonymous review, with no author names,
affiliations, acknowledgements or obvious references. Contributions
must not be submitted in parallel to any conference or workshop
that has proceedings. Separately, an abstract of the paper with no
more than 200 words and with title, name and addresses (incl. an
E-mail address) of the authors shall be submitted. In the case of
multiple authors the contacting author must be clearly identified.
We strongly encourage electronic submission in Postscript format.
The submissions must be in 11pt format, use standard fonts or
include the necessary fonts. Proposals for panel discussions should
also be sent to the program chair. Panels of interest include those
that present alternative/controversial viewpoints or those that
encourage lively discussions of relevant issues. Panels that are
collections of unrefereed papers will not be considered. Panel
proposals should be a minimum of one page describing the subject
matter, the appropriateness of the panel for this conference and
should identify participants and their respective viewpoints.

mailing list/ web-site:
-----------------------
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
[e-mail]. You will find this call for papers and further
information at http://www.secunet.de/forum/cqre.html .

important dates:
----------------
deadline for submission of extended abstracts May 14, 1999
deadline for submission of panel proposals    June 1, 1999
notification of acceptance                   June 25, 1999
deadline for submission of complete papers   July 30, 1999

program chair:
--------------
secunet - Security Networks GmbH
c/o Rainer Baumgart 
Weidenauer Str. 223 - 225
57076 Siegen
Germany
Tel.: [phone]
Fax:  [phone]
[e-mail]


program committee:
------------------
Johannes Buchmann   (TU Darmstadt)
Dirk Fox            (Secorvo)
Walter Fumy         (Siemens)
Rüdiger Grimm       (GMD)
Helena Handschuh    (ENST/Gemplus)
Thomas Hoeren       (Uni Muenster)
Pil Joong Lee       (POSTECH)
Alfred Menezes      (U.o.Waterloo/Certicom)
David Naccache      (Gemplus)
Clifford Neumann    (USC)
Mike Reiter         (Bell Labs)
Matt Robshaw        (RSA)
Richard Schlechter  (EU-comm.)
Bruce Schneier      (Counterpane)
Tsuyoshi Takagi     (NTT)
Yiannis Tsiounis    (GTE Labs)
Michael Waidner     (IBM)
Moti Yung           (CERTCO)
Robert Zuccherato   (Entrust)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24477 for ietf-open-pgp-bks; Sun, 7 Mar 1999 16:01:52 -0800 (PST)
Received: from mail3.svr.pol.co.uk (mail3.svr.pol.co.uk [195.92.193.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24473 for <[e-mail]>; Sun, 7 Mar 1999 16:01:50 -0800 (PST)
Received: from modem-15.neodymium.dialup.pol.co.uk ([62.136.29.143] helo=server.eternity.org) by mail3.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10Jna5-0000vu-00 for [e-mail]; Mon, 8 Mar 1999 00:07:37 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA04566; Mon, 8 Mar 1999 00:05:51 GMT
Date: Mon, 8 Mar 1999 00:05:51 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
Subject: key flags -- what do they mean?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ian Brown commented recently on the key flag section of the draft.
This got us wondering about how close the key flag was to an X.509 key
usage flag.

5.2.3.20. Key Flags

   (Octet string)

   This subpacket contains a list of binary flags that hold information
   about a key. It is a string of octets, and an implementation MUST NOT
   assume a fixed size. This is so it can grow over time. If a list is
   shorter than an implementation expects, the unstated flags are
   considered to be zero. The defined flags are:

       First octet:

       0x01 - This key may be used to certify other keys.

       0x02 - This key may be used to sign data.

       0x04 - This key may be used to encrypt communications.

       0x08 - This key may be used to encrypt storage.

[...]

So the question is does this mean that it is possible to say that a
key may not be used for certification?  ie if one has a certificate
from a third party, or from a CA which gives key flag 0x2 and 0x4 only
would this mean that PGP 5.x or 6.x, or other OpenPGP complaint
implementations software might consider that the key is only allowed
to sign and encrypt data and refuse to use it to certify, or that
receiving implementations might consider a certification invalid when
given by a key so marked?

Enciphering minds want your consider opinions and interpretations.

Being technically unable to mark keys as 'not for certification' is a
big win in the government key escrow argument.  Eg. the current Uk
government drive is to legislate that ISPs must (I quote):

> Annex A III: "An applicant will need to demonstrate that the
> certificates it issues have all the following information... an
> unambiguous statement that the certificate must not be used to validate
> a key being used to secure the confidentiality of information"

ie that concept that a CA can restrict your ability to use a signature
key for certification.  Unfortunately this wedge works rather well
against S/MIME the way most vendors implement it.  The clients can't
even certify *anything*, plus the keyUsage flag allows the not for CA
use to be specified, and many of the clients honor this flag.

The other text in RFC2440 below this says:

   Usage notes:

   The flags in this packet may appear in self-signatures or in
   certification signatures. They mean different things depending on who
   is making the statement -- for example, a certification signature
   that has the "sign data" flag is stating that the certification is
   for that use. On the other hand, the "communications encryption" flag
   in a self-signature is stating a preference that a given key be used
   for communications. Note however, that it is a thorny issue to
   determine what is "communications" and what is "storage." This
   decision is left wholly up to the implementation; the authors of this
   document do not claim any special wisdom on the issue, and realize
   that accepted opinion may change.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07207 for ietf-open-pgp-bks; Wed, 3 Mar 1999 07:06:33 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA07203 for <[e-mail]>; Wed, 3 Mar 1999 07:06:24 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA18901; Wed, 3 Mar 1999 07:11:17 -0800
Received: from basilisk.Eng.Sun.COM (basilisk.Eng.Sun.COM [129.144.152.185]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id HAA13182; Wed, 3 Mar 1999 07:11:16 -0800 (PST)
Received: from JaffaGate by basilisk.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id HAA03710; Wed, 3 Mar 1999 07:11:05 -0800
Message-ID: <002f01be6588$fabe84a0$e83c9c81@JaffaGate>
Reply-To: "Yahya Al-Salqan" <[e-mail]>
From: "Yahya Al-Salqan" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Fw: 1999 WET-ICE Enterprise Security Workshop
Date: Wed, 3 Mar 1999 07:17:32 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0518.4
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4
X-MIME-Autoconverted: from 8bit to quoted-printable by Eng.Sun.COM id HAA13182
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA07204
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Colleague,

This mail is to remind you of the upcomming deadline for submissions
the Fourth International Workshop on Enterprise Security, to be held
as a part of IEEE WET-ICE '99 on June 16-18, 1999 at Stanford
University, California, USA. Deadline for paper submissions is March
22, 1999.

Electronic submissions are accepted. Please see the workshop web
page http://www.ida.liu.se/conferences/WETICE/SECWK/ for more
details.

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.


Sincerely,

Nahid Shahmehri
Program Co-Chair

Dept. of Computer and Information Science
Linköping University
SE-581 83 Linköping
Sweden

-Cut here--------------------------------------------------------------

     FINAL CALL FOR  PAPERS

      Submission deadline: March 22, 1999

      Fourth International Workshop on Enterprise Security
     a WET-ICE '99 workshop
June 16-18, 1999
      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,
PostScript and PDF formats from

http://www.ida.liu.se/conferences/WETICE/SECWK/




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.


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 available at http://mir7.ida.liu.se:8080/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


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

Send six copies of panel proposals to the General 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: [e-mail]


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

Nahid Shahmehri
Dept. of Computer Science
Linköping University
S-581 83 Linköping
SWEDEN
E-mail: [e-mail]

Mourad Debbabi
Computer Science Department
Laval University
Ste-Foy, Quebec, G1K 7P4
CANADA
E-mail: [e-mail]




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

Dominique Bolignano, INRIA, France
Germano Caronni, ETH-Zentrum, Switzerland
Michael Geva, Java Security Group, USA
Jean Goubault, Gie Dyade, France
Dima Hamad, Birzeit University, West Bank
Douglas Maughan, National Security Agency, USA
Steve Lloyd, Entrust, Canada
Gary McGraw, Reliable Software Technologies Inc., USA
Aravindan Ranganathan, Sun Microsystems, USA
Sumitra Reddy, CERC, West Virginia University, USA
Vipin Samar, Oracle, USA
Bill Soley, Sun Microsystems, USA
Robert Thomys, BSI, Germany
Mark Vandenwauver, K.U. Leuven, Belgium
Wu Wen, NASA Ames Research Center, USA
Tatu Ylönen, SSH Communications Security, Finland
Nick Zhang, Trans Enterprise Technologies Inc., USA
Qun Zhong, HP Extend Enterprise Lab, USA



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

Papers and panel proposals due  March 22, 1999
Authors notified of acceptance  April 26, 1999
Workshop                        June 16-18, 1999
Camera ready manuscripts due    June 30, 1999



INQUIRIES
---------

For further information, please contact one of the Chairs,
or visit the workshop web pages:
  http://www.ida.liu.se/conferences/WETICE/SECWK/

For inquires regarding WET ICE in general, contact
[e-mail] or call (U.S.) [phone], or
visit
  http://www.ida.liu.se/conferences/WETICE/










Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20092 for ietf-open-pgp-bks; Tue, 2 Mar 1999 08:39:54 -0800 (PST)
Received: from stax05.cubis.de (wks1.cubis.de [194.112.101.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19997; Tue, 2 Mar 1999 08:34:01 -0800 (PST)
Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id RAA09899; Tue, 2 Mar 1999 17:26:55 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 02 Mar 1999 17:24:10 +0000
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[e-mail]>
Organization: Secunet GmbH - The Trust Company
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Call For Papers: CQRE [Secure]
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<HTML>
(Sorry if you receive multiple mailings)

<P>***********************************************
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CQRE [Secure] Congress &amp; Exhibition
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Duesseldorf, Germany, Nov. 30
- Dec. 2 1999
<BR>---------------------------------------------------------------
<BR>provides a new international forum covering most aspects of
<BR>information security with a special focus to the role of
<BR>information security in the context of rapidly evolving economic
<BR>processes.
<BR>---------------------------------------------------------------
<BR>&nbsp;Deadline for submission of extended abstracts: May 14, 1999
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<A HREF="http://www.secunet.de/forum/cqre.html">http://www.secunet.de/forum/cqre.html</A>
<BR>***********************************************

<P>If you are interested in receiving subsequent CFP's, registration-
<BR>and exhibitor-information, you may subscribe to the
<BR>&nbsp;<A HREF="mailto:[e-mail]?subject=subscribe">CQRE-Mailing-List</A>&nbsp;
.

<P>Please distribute this mail to interested collegues.

<P>Best regards
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Detlef Huehnlein
<BR>&nbsp;&nbsp;&nbsp;&nbsp; CQRE-team
<BR>&nbsp;
<BR>&nbsp;</HTML>