From daemon Mon Dec 1 13:01:47 1997 Delivery-Date: Mon, 01 Dec 1997 13:11:04 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA27747 for ietf-123-outbound.10@ietf.org; Mon, 1 Dec 1997 13:01:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA27698; Mon, 1 Dec 1997 13:01:28 -0500 (EST) Message-Id: <199712011801.NAA27698@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-structure-03.txt Date: Mon, 01 Dec 1997 13:01:27 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : Simple Public Key Certificate Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-structure-03.txt Pages : 48 Date : 26-Nov-97 This document specifies a standard form of digital certificate that is both more general and simpler than what is traditionally considered to be a certificate. Since the word ''certificate'' was first used by Loren Kohnfelder in 1978 to refer to a signed record holding a name and a public key, it has been assumed that the only purpose of a certificate has been to bind a public key to a globally unique name and therefore to a person. This binding was assumed both necessary and sufficient for security. The SPKI working group has found that the creation of a globally unique name is neither necessary nor sufficient for Internet security or electronic commerce. In fact, it can lead to a security flaw. Therefore, we define certificate forms for binding local names to keys (to retain security while offering the convenience of meaningful names) and for assigning authorizations to keys (to provide adequate information for real applications). These forms can be used alone or together. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-structure-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-structure-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-structure-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126165136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-structure-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-structure-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126165136.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Mon Dec 1 13:17:57 1997 Delivery-Date: Mon, 01 Dec 1997 13:24:36 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA01541 for ietf-123-outbound.10@ietf.org; Mon, 1 Dec 1997 13:17:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA01502; Mon, 1 Dec 1997 13:17:37 -0500 (EST) Message-Id: <199712011817.NAA01502@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-theory-00.txt Date: Mon, 01 Dec 1997 13:17:36 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Certificate Theory Author(s) : B. Lampson, R. Rivest, B. Frantz, C. Ellison, B. Thomas, Y. Ylonen Filename : draft-ietf-spki-cert-theory-00.txt Pages : 30 Date : 26-Nov-97 The SPKI Working Group has developed a standard form of digital certificate that is both more general and simpler than what is traditionally considered to be a certificate. Since the word ''certificate'' was first used by Loren Kohnfelder in 1978 to refer to a signed record holding a name and a public key, it has been assumed that the only purpose of a certificate has been to bind a public key to a globally unique name and therefore to a person. This binding was assumed both necessary and sufficient for security. The working group has found that the creation of a globally unique name is neither necessary nor sufficient for Internet security or electronic commerce. In fact, use of global names can introduce a security flaw. Therefore, we define certificate forms for binding local names to keys (to retain security while offering the convenience of meaningful names) and for assigning authorizations to keys (to provide adequate information for real applications). These forms can be used alone or together. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-theory-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-theory-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-theory-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126170221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-theory-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-theory-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126170221.I-D@ietf.org> --OtherAccess-- --NextPart-- From postmaster@pad-thai.cam.ov.com Thu Dec 4 14:57:10 1997 Delivery-Date: Thu, 04 Dec 1997 14:57:10 -0500 Return-Path: postmaster@pad-thai.cam.ov.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA24908 for ; Thu, 4 Dec 1997 14:57:09 -0500 (EST) Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18285; Thu, 4 Dec 1997 15:00:03 -0500 (EST) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA01039 for cat-ietf-redist; Thu, 4 Dec 1997 12:39:25 -0500 (EST) Message-Id: <3486EAFD.595E378@Coastek.COM> Date: Thu, 04 Dec 1997 09:40:13 -0800 From: Todd Glassey Organization: Coastek Infosys, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) Mime-Version: 1.0 To: IETF PKIX , www-security@ns2.Rutgers.EDU, aft@socks.nec.com, cat-ietf@mit.edu Cc: spki@c2.net, Michael.Mcneil@mail.coastek.com, dean.seniff@mail.coastek.com, Dave Mills Subject: Adding Certified NTP as a possible standard for portable trust in networking systems Content-Type: multipart/mixed; boundary="------------9735E8D8977AA4CCD8A6913A" Precedence: bulk This is a multi-part message in MIME format. --------------9735E8D8977AA4CCD8A6913A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I want to propose the consideration of using a certified NTP timestamp as the basis of a portable trust model and nonreputiead network timing. We and many others in the associated IETF WG's have long known the value of digital timestamps for fixing a point of reference to an event. Consider the value if the source of the timestamp and it's facility can be verified and proffered as a certified network entity. This is the birth of truly nonrepudiated events and their logging. This capability brings a whole new light to the world of certificates and networking policy. Imagine email with built-in timestamping and nonrepudiated logging. Especially if combined with the automated reply services now proposed for SMTP. This timestamping technology goes a tremendous way to enabling the collapsing of human commerce models into the digital domain. The use models of the NTP supplied timestamps will fit in all groups standards efforts, but especially are of interest to the PKIX WG. These timestamping extensions without any real sweat enable the PKIX #7 Time Extensions directly. Thus the settling on certified NTP as the basis of the timestamp source creates a horizontal technology that is directly applicable to a number of IETF and other Standards Working Groups including those of ANSI, The ABA, and the SEC. All in all it makes sense for everyone in our mind. To this end, Coastek [Glassey and McNeil] and David Mills have collaborated on an extended NTP Spec and an Interoperability Spec for Coastek's variant of SNTP (since most financial systems will mandate stratum-1 sources for security reasons). This first draft is on-file with the IETF as and Individual Contributor at the following URL: ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt The Coastek specific use models draft and a third draft on portable-trust and logging systems will follow in the next two weeks. We apologize for the lateness of these drafts as we intended to have them available pre-meeting but you know how the last minute crunch is. Todd Glassey --------------9735E8D8977AA4CCD8A6913A Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Todd Glassey Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Todd Glassey n: Glassey;Todd org: Coastek Infosys, Inc. adr: 5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA email;internet: Todd.Glassey@Coastek.COM title: Chief Scientist and Principal Founder tel;work: 408.440.0180 tel;fax: 408.438.2979 note: Technologies should support the requirements of Business not the other way 'round! x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------9735E8D8977AA4CCD8A6913A-- From daemon Fri Dec 5 11:28:53 1997 Delivery-Date: Fri, 05 Dec 1997 11:39:53 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA16064 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 11:28:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16029; Fri, 5 Dec 1997 11:28:28 -0500 (EST) Message-Id: <199712051628.LAA16029@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-examples-00.txt Date: Fri, 05 Dec 1997 11:28:28 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Examples Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-examples-00.txt Pages : 9 Date : 04-Dec-97 With the proliferation of public key cryptography on the Internet, there arises a need for certification of keys. In the literature, the word ''certificate'' has generally been taken to mean ''identity certificate'': a signed statement which binds a key to the name of an individual and has the intended meaning of delegating authority from that named individual to the public key. (See, for example, RFC 1422.) This process is designed to copy a relationship between two entities from the physical world into the digital world. The Internet itself changed the world from the one in which identity certificates made sense. We now deal with people we have never met and never will, which makes their names meaningless to us, but we still need to verify whether they are authorized to perform some action, achieve some access, sign some document, etc. SPKI certificates were designed to perform that function by directly specifying the binding which is of interest in the digital world. As merged with SDSI, the current certificate format also allows someone to bind a key to a name in their own private name space. The certificate structure presented here allows permissions to be delegated to SDSI-named individuals or to raw keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-examples-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-examples-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-examples-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971205110709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-examples-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-examples-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971205110709.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 12:01:56 1997 Delivery-Date: Fri, 05 Dec 1997 12:08:13 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA17451 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 12:01:44 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17420; Fri, 5 Dec 1997 12:01:40 -0500 (EST) Message-Id: <199712051701.MAA17420@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-structure-04.txt Date: Fri, 05 Dec 1997 12:01:39 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : Simple Public Key Certificate Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-structure-04.txt Pages : 48 Date : 04-Dec-97 This document specifies a standard form of digital certificate that is both more general and simpler than what is traditionally considered to be a certificate. Since the word ''certificate'' was first used by Loren Kohnfelder in 1978 to refer to a signed record holding a name and a public key, it has been assumed that the only purpose of a certificate has been to bind a public key to a globally unique name and therefore to a person. This binding was assumed both necessary and sufficient for security. The SPKI working group has found that the creation of a globally unique name is neither necessary nor sufficient for Internet security or electronic commerce. In fact, it can lead to a security flaw. Therefore, we define certificate forms for binding local names to keys (to retain security while offering the convenience of meaningful names) and for assigning authorizations to keys (to provide adequate information for real applications). These forms can be used alone or together. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-structure-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-structure-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-structure-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971204163158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-structure-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-structure-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204163158.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 23:44:27 1997 Delivery-Date: Fri, 05 Dec 1997 23:48:22 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id XAA18902 for ietf-outbound.10@ietf.org; Fri, 5 Dec 1997 23:44:17 -0500 (EST) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA18887 for ; Fri, 5 Dec 1997 23:44:13 -0500 (EST) Received: from laser.cps.softex.br (novaware.cps.softex.br [143.106.29.37]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id CAA09145; Sat, 6 Dec 1997 02:45:35 -0200 Date: Sat, 6 Dec 1997 02:45:35 -0200 (EDT) From: Ed Gerck Reply-To: Ed Gerck To: ietf@ns.ietf.org cc: IETF-Announce@ns.ietf.org, spki@c2.net Subject: Re: I-D ACTION:draft-ietf-spki-cert-examples-00.txt In-Reply-To: <199712051628.LAA16029@ns.ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 5 Dec 1997 Internet-Drafts@ns.ietf.org wrote: -> A New Internet-Draft is available from the on-line Internet-Drafts directories. -> This draft is a work item of the Simple Public Key Infrastructure Working Group -> of the IETF. -> -> Title : SPKI Examples -> Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, -> C. Ellison, B. Thomas -> Filename : draft-ietf-spki-cert-examples-00.txt -> Pages : 9 -> Date : 04-Dec-97 -> I think that the document has serious flaws and should be ammended, as well as the document draft-ietf-spki-cert-theory-00.txt (on which it is based and already previously commented). Specifically, my comments are given below for each point. -> With the proliferation of public key cryptography on the Internet, -> there arises a need for certification of keys. In the literature, -> the word ''certificate'' has generally been taken to mean ''identity -> certificate'': a signed statement which binds a key to the name of an -> individual This is wrong. In the technical literature (eg, A. Menezes et al., Handook of Applied Cryptography, CRC Press, New York, 1997), certification is defined as "endorsement of information by a trusted entity", where "endorsement" can take several meanings as defined by a CPS and "information" can be any data, such as a photo, a pseudonym, an alias, a key, a birth name, a X.509 DN, an e-mail, etc. Further, X.509 (and PGP) clearly lay out several purposes besides name binding for certificates, as given by the extensions in X.509v3, including authorizations such as the possibility to be used as a root-cert for signing other certs, etc. Further, X.509 (the standard alluded to as "generally") does not say that "it binds a key to the name of an individual". Here, there are actually three entities and respective bindings: key, name, individual. The definitions of key, name and their binding are handled by X.509, whereas the binding of either with an individual (and the respective qualifications of the individual) are handled by the CA's CPS -- which is outside the scope of X.509. The same happens for PGP. In other words, when X.509 certifies names in DNs, it does not certify "foo real-world" but certifies "foo real-world data" -- where the distinction is that "foo real-world data" has no semantics on the data being valid or not, because the data are just being used as data (ie, copied as received) and as such compared with the DN. Here, X.509 does not attempt to reach behind names to individuals, for example to verify if "foo real-world" and the DN are consistent. That is outside the scope of X.509 and is handled by the CPS. -> and has the intended meaning of delegating authority from -> that named individual to the public key. (See, for example, RFC -> 1422.) This process is designed to copy a relationship between two -> entities from the physical world into the digital world. -> No, the intended meaning (and the design reasoning) of certificates such as X.509 (and PGP) is to provide for a security framework to be reached as a function of the various CPSs and how they are to be interpreted by each verifier. -> The Internet itself changed the world from the one in which identity -> certificates made sense. This is neither new nor an Internet fenomenum. [cf Bohm] Even in those countries where the law requires that every person should have an official name, it is doubtful that any two people would never have the same name, even within one country. And there are many countries, such as the United Kingdom, where people can change their names without formality or official records, and can use several names for different purposes, none of which are more truly theirs than any other. (Authors and entertainers commonly use several names). -> We now deal with people we have never met -> and never will, which makes their names meaningless to us, but we -> still need to verify whether they are authorized to perform some -> action, achieve some access, sign some document, etc. -> -> SPKI certificates were designed to perform that function by directly -> specifying the binding which is of interest in the -> digital world. This is a contradiction. The first paragraph says that we need to verify whether "people" are authorized to perform some action, whereas the second paragraph says that such verification will be performed on a "key". These are two entirely different concepts because for SPKI certificates there is no identity other than the key (there is no entity authentication, just key authentication) and all actions are performed only in the digital world of keys. So, SPKI has no binding between digital world entities and physical world (ie, legal, accountable) entities -- ie, the "people" mentioned in the first paragraph (which are of interest for Net commerce, EDI, bank operations, etc.). To contrast, X.509 allows for such binding to exist and to be defined by each CA under its CPS policies, allowing for miscreants to be legally persecuted. (These problems are not to be solved by SPKI, but by a "subpoena certificate" as Carl Ellison has named it, which is a service to be paid for by the user and which will be treated in the future. Which has nothing to do with the SPKI proposal and which certainly brings up problems of its own.) -> As merged with SDSI, the current certificate format -> also allows someone to bind a key to a name in their own private name -> space. The certificate structure presented here allows permissions -> to be delegated to SDSI-named individuals or to raw keys. -> Use of "their own private name space" means that the SDSI name space is local -- which can be equally accomplished by using the certificate structure of X.509 or PGP, with aliases or pseudonyms. Of course, local names can only be locally meaningful and must be always isolated from any global context (where they may even collide) such as a legal framework -- which makes them useless in a world PKI. Further, permissions delegated to SDSI-named individuals or to raw keys have no legal or accountable meaning to outside parties and could only be useful in a parochial Internet. Yours, Ed ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br http://novaware.cps.softex.br From owner-cat-ietf@pad-thai.cam.ov.com Tue Feb 3 19:27:43 1998 Delivery-Date: Tue, 03 Feb 1998 19:27:49 -0500 Return-Path: owner-cat-ietf@pad-thai.cam.ov.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA19487 for ; Tue, 3 Feb 1998 19:27:42 -0500 (EST) Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12110; Tue, 3 Feb 1998 19:30:11 -0500 (EST) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA03190 for cat-ietf-redist; Tue, 3 Feb 1998 17:39:05 -0500 (EST) Message-Id: <199802031717.JAA01581@basilisk.Eng.Sun.COM> Date: Tue, 3 Feb 1998 09:15:49 -0800 (PST) From: Yahya Al-Salqan Reply-To: Yahya Al-Salqan Subject: Enterprise Security To: ssl-talk@netscape.com, ipsec@tis.com, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-smime@imc.org Cc: ietf-open-pgp@imc.org, aft@socks.nec.com, cat-ietf@mit.edu, dns-security@tis.com, ietf-ssh@clinet.fi, spki@c2.net, ietf-tls@consensus.com, www-security@ns2.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-Md5: s65u0q6BDLuzuKezUo+VGQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by pad-thai.cam.ov.com id RAA03174 Precedence: bulk Dear Colleague, This mail is to direct your attention to the Third International Workshop on Enterprise Security, to be held on June 17-19, 1998 at Stanford University, California, USA. Deadline for paper submissions is February 27, 1998. Please accept my apologies if you receive this message more than once. Enclosed is the Call For Papers. Your help in distributing the CFP to interested parties would be greatly appreciated. ----------------------------------------------------------------------- CALL FOR PAPERS *EXTENSION NOTICE* Submission deadline: February 27, 1998 Third International Workshop on Enterprise Security June 17-19, 1998 Stanford University, California, USA Sponsored by the IEEE Computer Society and CERC at West Virginia University. Hosted by the Center for Design Research, Stanford University. This document is also available in HTML and Postscript formats as http://www.ida.liu.se/labs/iislab/SECWK/cfp.html and http://www.ida.liu.se/labs/iislab/SECWK/cfp.ps 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 availabe at http://iispc2.ida.liu.se/SECWK/ . Submissions should include the title of the paper, the name and affiliation of each author, a 150-word abstract, and no more than 8 keywords. Submissions should not exceed 3000 words in length. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence must be included. A representative selection of accepted papers will published in the workshop post-proceedings. Papers accepted for publication in the proceedings are limited to six pages (about 2000-2500 words) in IEEE format (two columns, single spaced, 10pt Times). Authors are strongly encouraged to adhere to this format also when submitting papers. Detailed information on the IEEE format (together with some templates) is available at http://www.computer.org/cspress/instruct.htm PANEL PROPOSALS --------------- Send six copies of panel proposals to the Program Chair. Include a title, a 150-word scope statement, proposed session chair and panelists and their affiliations, the organizer's affiliation, address, telephone and fax number, and e-mail address. GENERAL CHAIR ------------- Yahya Al-Salqan Sun Microsystems 901 San Antonio Rd Palo Alto, CA 94303 USA E-mail: alsalqan@eng.sun.com PROGRAM CO-CHAIRS ----------------- Nahid Shahmehri Dept. of Computer Science Linköping University S-581 83 Linköping SWEDEN E-mail: nahsh@ida.liu.se Douglas Maughan National Security Agency, R23 9800 Savage Rd. Ft. Meade, Maryland 20755-6000 USA E-mail: wdm@tycho.ncsc.mil WORKSHOP PROGRAM COMMITTEE -------------------------- Takashi Arno, NTT Corp., Japan William Cheng-Chung Chu, Feng Chia University, Taiwan Barbara Davis, Applied Knowledge Group, USA Mourad Debbabi, Laval University, Canada Germano Caronni, Computer Engineering and Networks Laboratory, ETH-Zentrum, Switzerland Dima Hamad, Birzeit University, West Bank Takeo Hamada, Fujitsu, USA Adel Jaber, Certicom, USA Takuro Kubo, NTT America Multimedia Communications Lab, USA Steve Lloyd, Entrust Technologies, Canada Jeff Parrett, PeopleSoft, USA Lisa Pretty, Certicom, Canada Sumitra Reddy, West Virginia University, USA Vipin Samar, Oracle, USA Bill Soley, Sun Microsystems, USA Robert Thomys, BSI (Federal Department of Security in Information Technology), Germany Bradley Wood, Sandia National Lab, USA Felix Wu, North Carolina State University, USA Qun Zhong, HP, UK Tatu Ylönen, SSH Communications Security, Finland Randy Chow, University of Florida, USA IMPORTANT DATES --------------- Papers and panel proposals due February 27, 1998 Authors notified of acceptance April 6, 1998 Advance Registration May 17, 1998 Workshop June 17-19, 1998 Camera ready manuscripts due June 30, 1998 INQUIRIES --------- Pleas send all inquiries regarding this workshop to the General Chair or to one of the co-chairs. For inquires regarding WET ICE in general, contact wetice@cerc.wvu.edu or call (U.S.) +1-304-293-7226. From adm Thu Mar 12 10:56:41 1998 Delivery-Date: Thu, 12 Mar 1998 10:59:53 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA18400 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 10:55:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15447; Thu, 12 Mar 1998 09:44:47 -0500 (EST) Message-Id: <199803121444.JAA15447@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-theory-02.txt Date: Thu, 12 Mar 1998 09:44:36 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Certificate Theory Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-theory-02.txt Pages : 32 Date : 11-Mar-98 The SPKI Working Group has developed a standard form for digital certificates and access control lists. These structures bind either names or authorizations to keys. The binding can be directly to a key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-theory-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-theory-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-theory-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311165956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-theory-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-theory-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311165956.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 11:06:29 1998 Delivery-Date: Thu, 12 Mar 1998 11:10:21 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA18983 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 11:05:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15446; Thu, 12 Mar 1998 09:44:47 -0500 (EST) Message-Id: <199803121444.JAA15446@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-examples-01.txt Date: Thu, 12 Mar 1998 09:44:41 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Examples Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-examples-01.txt Pages : 15 Date : 11-Mar-98 SPKI structures are defined for public keys, hash values, access control list (ACL) entries and certificates. This document gives examples of such structures for real world applications. The examples here are not tied to any specific application and should be taken as informative examples rather than standard formats. However, once applications are fielded using such structures and we have experience with them, we can consider publishing those formats as proposed standards. That effort is considered out of scope for this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-examples-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-examples-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-examples-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311105016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-examples-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-examples-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311105016.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 12:16:29 1998 Delivery-Date: Thu, 12 Mar 1998 12:26:52 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA21665 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 12:15:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15519; Thu, 12 Mar 1998 09:45:58 -0500 (EST) Message-Id: <199803121445.JAA15519@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-examples-01.txt Date: Thu, 12 Mar 1998 09:45:57 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Examples Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-examples-01.txt Pages : 15 Date : 11-Mar-98 SPKI structures are defined for public keys, hash values, access control list (ACL) entries and certificates. This document gives examples of such structures for real world applications. The examples here are not tied to any specific application and should be taken as informative examples rather than standard formats. However, once applications are fielded using such structures and we have experience with them, we can consider publishing those formats as proposed standards. That effort is considered out of scope for this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-examples-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-examples-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-examples-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311105016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-examples-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-examples-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311105016.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 13:36:27 1998 Delivery-Date: Thu, 12 Mar 1998 13:41:30 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA24577 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 13:35:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15681; Thu, 12 Mar 1998 09:47:55 -0500 (EST) Message-Id: <199803121447.JAA15681@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-req-01.txt Date: Thu, 12 Mar 1998 09:47:54 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Requirements Author(s) : C. Ellison Filename : draft-ietf-spki-cert-req-01.txt Pages : 15 Date : 11-Mar-98 The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible. The SPKI WG first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-req-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-req-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-req-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311143133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311143133.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 13:56:34 1998 Delivery-Date: Thu, 12 Mar 1998 13:58:33 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA25401 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 13:55:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15842; Thu, 12 Mar 1998 09:49:17 -0500 (EST) Message-Id: <199803121449.JAA15842@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-theory-02.txt Date: Thu, 12 Mar 1998 09:49:16 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : SPKI Certificate Theory Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-theory-02.txt Pages : 32 Date : 11-Mar-98 The SPKI Working Group has developed a standard form for digital certificates and access control lists. These structures bind either names or authorizations to keys. The binding can be directly to a key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-theory-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-theory-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-theory-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311165956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-theory-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-theory-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311165956.I-D@ietf.org> --OtherAccess-- --NextPart-- From cclark Fri Mar 13 21:30:11 1998 Delivery-Date: Fri, 13 Mar 1998 21:34:28 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id VAA06026 for ietf-outbound.10@ietf.org; Fri, 13 Mar 1998 21:30:02 -0500 (EST) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA06005 for ; Fri, 13 Mar 1998 21:29:55 -0500 (EST) Received: (from egerck@localhost) by laser.cps.softex.br (8.8.7/8.8.7) id XAA07959; Fri, 13 Mar 1998 23:29:27 -0300 Date: Fri, 13 Mar 1998 23:29:27 -0300 Message-Id: <199803140229.XAA07959@laser.cps.softex.br> From: "E. Gerck" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Blaze Cc: spki@c2.net, mab@crypto.com, angelos@dsl.cis.upenn.edu, jf@research.att.com, ietf@ns.ietf.org Subject: KeyNote draft available In-Reply-To: <199803132139.QAA28008@nsa.research.att.com> References: <199803132139.QAA28008@nsa.research.att.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Matt Blaze writes: > We have just released a new internet draft describing KeyNote, a trust > management system designed to support PKI applications. KeyNote is > based on PolicyMaker, with simplfied features optimized specifically > for the PKI problem. We believe KeyNote provides a simple mechanism > that addresses many of the issues of concern to the SPKI group. We'll > be presenting KeyNote in L.A. > I think this document has serious flaws and should be recalled. When KeyNote considers delegation of trust and its management it follows the earlier model of "Decentralized Trust Management" -- which ignores the properties of trust (cf http://www.mcg.org.br/trustprop.txt) and instead follows an ad hoc concept of "trust" and its properties. Such concept, which has little to do with the meaning that the word trust would have in a linguistic or social context, is not self-consistent either. In particular, the notion of delegation of trust is flawed, as evidenced by the following paragraph: The TRUST-PREDICATE expression is evaluated. If the result is boolean TRUE, and the key expression in the KEY-PREDICATE field is also true, the request is approved. Otherwise, it is rejected. which highlights the use of boolean expressions to evaluate TRUST-PREDICATE... however, trust does NOT follow a boolean algebra, as is well known in certificate and security applications (see also the reference given above). Further, when the document says: TRUST-PREDICATE: (($app_domain="NUKE") && ($action="launch") && ($delivery_system="missile") && (($target="moscow") || ($target="london"))) then we see that what the document calls "trust-predicate" has little to do with what one would call a predicate of trust in any meaningful way. Thus, the document is misleading in its use of the word trust and should either be changed throughout so that "trust" reads authorization (for example) and correcting other logical problems or should not be submitted to the IETF. In any case, it should be recalled as it is. Cheers, Ed ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br --- Visit the Meta-Certificate Group at http://mcg.org.br --- From cclark Fri Mar 13 22:20:25 1998 Delivery-Date: Fri, 13 Mar 1998 22:23:47 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id WAA06626 for ietf-outbound.10@ietf.org; Fri, 13 Mar 1998 22:20:02 -0500 (EST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id WAA06598 for ; Fri, 13 Mar 1998 22:19:11 -0500 (EST) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Mar 13 22:15:58 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Fri Mar 13 22:18:50 EST 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA04706; Fri, 13 Mar 1998 22:18:51 -0500 (EST) Message-Id: <199803140318.WAA04706@postal.research.att.com> To: "E. Gerck" cc: Matt Blaze , spki@c2.net, mab@crypto.com, angelos@dsl.cis.upenn.edu, jf@research.att.com, ietf@ns.ietf.org Subject: Re: KeyNote draft available Date: Fri, 13 Mar 1998 22:18:51 -0500 From: Steve Bellovin I think this document has serious flaws and should be recalled. ... Thus, the document is misleading in its use of the word trust and should either be changed throughout so that "trust" reads authorization (for example) and correcting other logical problems or should not be submitted to the IETF. In any case, it should be recalled as it is. As a procedural matter, anyone can submit a draft on more or less anything to the IETF. Drafts that purport to be from a working group have a name beginning 'draft-ietf-'; these, in general, require the assent of the chair, which in turn is based on a number of factors, including the status and direction of the working group. This particular draft is 'draft-angelos-spki-keynote-00.txt'; as such, it's an individual contribution. Over time, it may or may not become a working group product; in any event, eventual publication depends on approval by the IESG. It's certainly relevent enough to spki to discuss on this mailing list and/or at IETF meetings. For now, it's quite premature to speak of recalling the document; Blaze et al. are certainly entitled to their own opinions. Speaking as the co-chair of spki, --Steve Bellovin From cclark Fri Mar 13 22:30:14 1998 Delivery-Date: Fri, 13 Mar 1998 22:33:36 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id WAA08440 for ietf-outbound.10@ietf.org; Fri, 13 Mar 1998 22:30:03 -0500 (EST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id WAA07724 for ; Fri, 13 Mar 1998 22:27:09 -0500 (EST) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Mar 13 22:23:57 EST 1998 Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Fri Mar 13 22:25:50 EST 1998 Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id WAA01905; Fri, 13 Mar 1998 22:25:48 -0500 (EST) Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id WAA28702; Fri, 13 Mar 1998 22:24:41 -0500 (EST) Message-Id: <199803140324.WAA28702@nsa.research.att.com> To: "E. Gerck" cc: spki@c2.net, angelos@dsl.cis.upenn.edu, jf@research.att.com, ietf@ns.ietf.org Subject: Re: KeyNote draft available In-reply-to: Your message of "Fri, 13 Mar 1998 23:29:27 -0300." <199803140229.XAA07959@laser.cps.softex.br> Date: Fri, 13 Mar 1998 22:24:36 -0500 From: Matt Blaze I must confess that I don't quite understand your point. You seem to be objecting to the use of the term "trust" in conjunction with predicates that delegate from one key to another the permission to perform specific security actions. While I would be the first to agree that the word "trust" can be used to describe concepts other than this, we use the word "trust" as a technical term. It is not at all unusual for words to have a meaning as a technical term-of-art that are rather different from their connotations in informal or non-technical language. Indeed, computer science is full of such terms; consider "reliable," "trivial," "large, and "fair," for starters. Here, we use "trust" in a technical sense, not in a social or political sense. In particular, we use the word in the sense of "trusted system", and, especially, "trust management," a term we introduced in our original PolicyMaker paper to refer to the problem of describing (and containing) the extent to which other parties are permitted to perform security-critical actions. You suggest the term "authorization," which is also a good word, but we used "trust management" because that phrase is beginning to be fairly widely understood by the technical community (there has been at least one conference on the subject, and it has appeared in several calls-for-papers, for example). In any event, we think KeyNote provides a very simple mechanism that is flexible enough to addresses many of the issues of concern to the SPKI charter, and we hope to stimulate discussion on our direction. -matt From cclark Fri Mar 13 23:50:17 1998 Delivery-Date: Fri, 13 Mar 1998 23:53:42 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id XAA15050 for ietf-outbound.10@ietf.org; Fri, 13 Mar 1998 23:50:02 -0500 (EST) Received: from memorex.co.jp (funky.memorex.co.jp [202.224.145.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA14950 for ; Fri, 13 Mar 1998 23:41:06 -0500 (EST) From: wbenton@NWS.MEMOREX.CO.JP Received: from nws.memorex.co.jp ([192.168.1.9]) by funky.memorex.co.jp with SMTP id <131714-1>; Sat, 14 Mar 1998 13:35:10 +0900 Received: from ccMail by nws.memorex.co.jp (ccMail Link to SMTP R6.0) id AA889850255; Sat, 14 Mar 98 13:37:41 +0900 Message-Id: <9803148898.AA889850255@nws.memorex.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 14 Mar 1998 13:39:23 +0900 To: , Cc: , , , , Subject: Re: KeyNote draft available MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit I can't agree with your objections: The word "trust" as you have tried to explain below implies "relying" on some external system to do something. That does not mean that there are not unreliable trusts, but that you are "relying" on an outside source to perform something for you. Whether it gets done properly or not is outside of the context. Basically, you're passing the buck and you better be sure that where ever you pass it to will do the job properly. Thus reliability of trusts becomes an issue that needs to be contended with. But, back to the word "trust" doesn't imply anything else. Your quoted example TRUST-PREDICATE: (($app_domain="NUKE") && only implies that you are trusting on the application domain "NUKE" to launch the missile to the desired target. Whether it actually launches it or not means nothing. You are trusting the "NUKE" application domain to perform the task that you sent it and nothing more. It must also "trust" you to send it valid operations as well. Thus trust relationships are born. FWIW Walter Benton ___________________________________ $BJV?.(B _______________________________________ $B7oL>(B: KeyNote draft available $BAw?. at &NWS-Internet $BF|IU(B: 98/03/14 11:29 Matt Blaze writes: > We have just released a new internet draft describing KeyNote, a trust > management system designed to support PKI applications. KeyNote is > based on PolicyMaker, with simplfied features optimized specifically > for the PKI problem. We believe KeyNote provides a simple mechanism > that addresses many of the issues of concern to the SPKI group. We'll > be presenting KeyNote in L.A. > I think this document has serious flaws and should be recalled. When KeyNote considers delegation of trust and its management it follows the earlier model of "Decentralized Trust Management" -- which ignores the properties of trust (cf http://www.mcg.org.br/trustprop.txt) and instead follows an ad hoc concept of "trust" and its properties. Such concept, which has little to do with the meaning that the word trust would have in a linguistic or social context, is not self-consistent either. In particular, the notion of delegation of trust is flawed, as evidenced by the following paragraph: The TRUST-PREDICATE expression is evaluated. If the result is boolean TRUE, and the key expression in the KEY-PREDICATE field is also true, the request is approved. Otherwise, it is rejected. which highlights the use of boolean expressions to evaluate TRUST- PREDICATE... however, trust does NOT follow a boolean algebra, as is well known in certificate and security applications (see also the reference given above). Further, when the document says: TRUST-PREDICATE: (($app_domain="NUKE") && ($action="launch") && ($delivery_system="missile") && (($target="moscow") || ($target="london"))) then we see that what the document calls "trust-predicate" has little to do with what one would call a predicate of trust in any meaningful way. Thus, the document is misleading in its use of the word trust and should either be changed throughout so that "trust" reads authorization (for example) and correcting other logical problems or should not be submitted to the IETF. In any case, it should be recalled as it is. Cheers, Ed ______________________________________________________________________ Dr. rer.nat. E. Gerck egerck@novaware.cps.softex.br http:// novaware.cps.softex.br --- Visit the Meta-Certificate Group at http://mcg.org.br --- From cclark Sat Mar 14 00:20:57 1998 Delivery-Date: Sat, 14 Mar 1998 00:21:59 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id AAA15351 for ietf-outbound.10@ietf.org; Sat, 14 Mar 1998 00:20:50 -0500 (EST) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA15254 for ; Sat, 14 Mar 1998 00:11:09 -0500 (EST) Received: (from egerck@localhost) by laser.cps.softex.br (8.8.7/8.8.7) id CAA08635; Sat, 14 Mar 1998 02:11:06 -0300 Date: Sat, 14 Mar 1998 02:11:06 -0300 Message-Id: <199803140511.CAA08635@laser.cps.softex.br> From: "E. Gerck" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Blaze Cc: "E. Gerck" , spki@c2.net, angelos@dsl.cis.upenn.edu, jf@research.att.com, ietf@ns.ietf.org Subject: Re: KeyNote draft available In-Reply-To: <199803140324.WAA28702@nsa.research.att.com> References: <199803140229.XAA07959@laser.cps.softex.br> <199803140324.WAA28702@nsa.research.att.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Matt Blaze writes: > I must confess that I don't quite understand your point. You seem to > be objecting to the use of the term "trust" in conjunction with > predicates that delegate from one key to another the permission to > perform specific security actions. My point is simple. I object to let a word be used in technical situations where the word's intended usage diverges from its usual technical understanding -- which frontally speaks agains any hope for standardization. Such was the case for the word "trust" in this work, hence my objection. It is technically understood that "trust is not transitive" since PGP questioned the PEM model several years ago and stated a well-known comparison which I will rephrase as "The fact that I trust my brother to drive my car does not mean that I must trust the friends he trusts to do the same". It is also technically understood and so *implemented* in softeware in wide use today -- such as Apache/SSL -- that trust is not transitive and so trust chains should stop at depth one, lest it becomes leap of faith chains... It has also been published -- and NOT contested, rather reaffirmed -- since July 8th, 1997 that trust (in the technical sense in communication protocols and certification) is actually neither transitive, nor distributive, nor symmetric [http://www.mcg.org.br/trustprop.txt]. Further, it was discussed in this forum last year the consequences of such technical security constraints, as well as currently, which will be exemplified below. > > While I would be the first to agree that the word "trust" can be used > to describe concepts other than this, we use the word "trust" as a > technical term. As above, it is exactly as a technical term in the context of security protocols that trust has been shown NOT to follow boolean algebra. However, the use of trust or trust predicates in the proposed work RELIES UPON boolean expressions such as: TRUST-PREDICATE: (($app_domain="NUKE") && ($action="launch") && ($delivery_system="missile") && (($target="moscow") || ($target="london"))) and several other boolean constructs, which are simply not warranted if you want to call that trust... but, which may be correct and indeed useful if you call it something else that would obey a boolean algebra -- such as authorization or delegation -- and so properly explained. >It is not at all unusual for words to have a meaning > as a technical term-of-art that are rather different from their > connotations in informal or non-technical language. Indeed, computer > science is full of such terms; consider "reliable," "trivial," "large, > and "fair," for starters. > You are right to the limited extent that it is academically valid to define anything as anything, however as cited above the word trust in the context of security protocols is not too much overly-variable, even though there are indeed differences in the fine aspects of different technical definitions -- but none that diverge so much as your intended use. To exemplify the technical feeling for such subject, just a few days ago the following text from Phill was cited by myself here -- as written in 1994 but very on the mark regarding your comment above: "We have two options either we can attempt to define wonderfull academic forms of trust model de novo. Or we can observe the real world and attempt to model the trust mechanisms that allow it to function. Since we do not see a hierarchical trust model it is not the solution. We do not see anarchy either, or at least in places where it has taken hold it is disaster.What we see is binary interpersonal relationships heavily qualified in manyways. The approach that has always seemed most promising to me is to replicate those relationships allowing them full colour with respect to the areas for which trust is granted (finacial, notarial, reliability etc), the extent of such trust and the confidence with which that trust is allowed." In the almost four years (an eternity in Internet time) that passed since that comment which was contextually based on PGP, such view has in fact consolidated itself as I commented above to the extent that it is rather common nowadays to consider that trust is not transitive -- hence not boolean. Regarding the other properties of trust already mentioned (not distributive and not symmetric), I would also add that technical trust cannot be regarded as objective either (as implied in your work I am commenting on) but has to be treated as inter-subjective [http://www.mcg.org.br/augustine.txt] if one wants to represent real-world perceptions of it. These three further properties of trust add several other non-boolean properties to technical trust -- which further invalidates the proposed methodology. > Here, we use "trust" in a technical sense, not in a social or > political sense. In particular, we use the word in the sense of > "trusted system", and, especially, "trust management," a term we > introduced in our original PolicyMaker paper to refer to the problem > of describing (and containing) the extent to which other parties are > permitted to perform security-critical actions. As above, your use of the technical word trust in the text and in the boolean expressions of the proposed methodology is not concordant with its use in widely disseminated security protocols such as PGP and in security software such as Apache/SSL or in other works. The fact that is not concordant either with semantics derived from standard linguistics is a further indication that it cannot be taken as a de novo definition either (to the fair sense that everything else would be wrong). > You suggest the term > "authorization," which is also a good word, but we used "trust > management" because that phrase is beginning to be fairly widely > understood by the technical community (there has been at least one > conference on the subject, and it has appeared in several > calls-for-papers, for example). Herein lies the danger of impregnating the word trust with overloaded meanings. The technical concept of trust -- and trust management -- will become an (eventually transparent) foundation for most of our communications, and with this transparency will come a degree of complacency with the technical/linguist/social/political implications of the policies and assumptions that underly its operations. (cf today's msg from Tony). The fact that a past use was not precise and is being further developed -- with conflicting basic mathematical properties such as which algebra it obeys to -- is certainly one more reason to correct the course now, since no one would care to correct something that had no value. So, if you pls re-read my former msg you will see that I did not dismiss it (even though I mentioned without exemplifying that some logical problems would have to be corrected). Rather, I clearly and objectively targeted and exemplified its overloaded use of the word trust -- which contradicted not only earlier accepted technical understandings and properties of trust in security systems, but also its linguistic/social use. I think it must be axiomatic that if a technical concept obeys algebra A and has properties B, being designated by word XYZ -- then if another concept does NOT obey algebra A and does NOT have properties B, it should NOT be called XYZ either.... > > In any event, we think KeyNote provides a very simple mechanism that > is flexible enough to addresses many of the issues of concern to the > SPKI charter, and we hope to stimulate discussion on our direction. > It could well be but by calling trust what is NOT trust, your proposal calls upon it three different nemesis: 1. It is inconsistent with previous technical use of the term trust in security systems in general (though consistent with some of your own previous work), 2. It is inconsistent with and not needed by SPKI, when it states: The first purpose of SPKI certificates is to address the issue of "trust" by avoiding the term and instead concentrating on asking what a given keyholder is permitted or authorized to do. 3. It is irrevocably mathematically at odds with anything else that will treat trust as trust, such as not being boolean for example. That's why -- not to be just a technical criticism but also as a fruitful discussion between colleagues -- that I suggested the word "authorization" or "authorization management" if you prefer or "delegation", which avoid the three problems above and may allow your paper to be viewed under a coherent technical light now and in the future, also within current SPKI texts. Cheers, Ed ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br --- Visit the Meta-Certificate Group at http://mcg.org.br --- From cclark Sat Mar 14 00:40:16 1998 Delivery-Date: Sat, 14 Mar 1998 00:41:34 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id AAA15716 for ietf-outbound.10@ietf.org; Sat, 14 Mar 1998 00:40:03 -0500 (EST) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA15675 for ; Sat, 14 Mar 1998 00:33:56 -0500 (EST) Received: (from egerck@localhost) by laser.cps.softex.br (8.8.7/8.8.7) id CAA08714; Sat, 14 Mar 1998 02:33:55 -0300 Date: Sat, 14 Mar 1998 02:33:55 -0300 Message-Id: <199803140533.CAA08714@laser.cps.softex.br> From: "E. Gerck" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Bellovin Cc: "E. Gerck" , Matt Blaze , spki@c2.net, mab@crypto.com, angelos@dsl.cis.upenn.edu, jf@research.att.com, ietf@ns.ietf.org Subject: Re: KeyNote draft available In-Reply-To: <199803140318.WAA04706@postal.research.att.com> References: <199803140318.WAA04706@postal.research.att.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Steve Bellovin writes: > Ed Gerck wrote: > > I think this document has serious flaws and should be recalled. > > ... > > Thus, the document is misleading in its use of the word trust and > should either be changed throughout so that "trust" reads > authorization (for example) and correcting other logical problems or > should not be submitted to the IETF. In any case, it should be > recalled as it is. > > As a procedural matter, anyone can submit a draft on more or less > anything to the IETF. Drafts that purport to be from a working group > have a name beginning 'draft-ietf-'; these, in general, require > the assent of the chair, which in turn is based on a number of factors, > including the status and direction of the working group. This > particular draft is 'draft-angelos-spki-keynote-00.txt'; as such, it's > an individual contribution. Over time, it may or may not become > a working group product; in any event, eventual publication depends > on approval by the IESG. It's certainly relevent enough to spki > to discuss on this mailing list and/or at IETF meetings. For now, > it's quite premature to speak of recalling the document; Blaze et al. > are certainly entitled to their own opinions. > I agree 100% with your words above but my objection did not intend at any moment to target or rate the draft's usefullness, relevance or right to be submitted. Rather, it very specifically actually aimed at preserving the draft from early dismissal, by observing that a *single* flaw disallowed the paper's methodology -- which could be corrected by a preciser technical choice of words. So much was clearly written. The draft gives the impression that it calculates trust predicates -- which would ban the use of boolean logic -- while the draft is based on boolean logic. Hence, it is not self-consistent and is misleading in its current form. In fact, it is also not consistent with the current terminology used in the very work it aims to support -- SPKI. Thus, without any semantic evaluation of it, I suggested that the draft could be made self-consistent (also in relationship to SPKI, cf other msgs) if that single flaw would be eliminated. Thus, my suggestion that the draft be recalled was not a negation of its submission rights but actually supportive of its right to be eventually useful. Cheers, Ed ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br --- Visit the Meta-Certificate Group at http://mcg.org.br --- From cclark Sat Mar 14 03:10:16 1998 Delivery-Date: Sat, 14 Mar 1998 03:11:51 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id DAA21762 for ietf-outbound.10@ietf.org; Sat, 14 Mar 1998 03:10:01 -0500 (EST) Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id DAA21710 for ; Sat, 14 Mar 1998 03:05:23 -0500 (EST) Received: from nma.com by paris.ics.uci.edu id ab26076; 14 Mar 98 0:01 PST Received: from paris.ics.uci.edu by norn.nma.com id aa17134; 13 Mar 98 23:34 PST To: spki@c2.net, ietf@ns.ietf.org Subject: Re: KeyNote draft available In-reply-to: Your message of "Sat, 14 Mar 1998 02:33:55 -0300." <199803140533.CAA08714@laser.cps.softex.br> Reply-to: ietf@ns.ietf.org From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17130.889860893.1@nma.com> Date: Fri, 13 Mar 1998 23:34:54 -0800 Message-ID: <17132.889860894@nma.com> Sender: stef@nma.com I suspect that the term "recalled" is a problem here, when in fact what I think Ed is asking for is a rapid replacement with a revised version to cover up the current flawed version with a better version. This process is not unusual in any case, and perhaps this manner of speaking about it will diffuse the disagreement;-)... Cheers...\Stef >From your message Sat, 14 Mar 1998 02:33:55 -0300: } }Steve Bellovin writes: } > Ed Gerck wrote: } > } > I think this document has serious flaws and should be recalled. } > } > ... } > } > Thus, the document is misleading in its use of the word trust and } > should either be changed throughout so that "trust" reads } > authorization (for example) and correcting other logical problems or } > should not be submitted to the IETF. In any case, it should be } > recalled as it is. } > } > As a procedural matter, anyone can submit a draft on more or less } > anything to the IETF. Drafts that purport to be from a working group } > have a name beginning 'draft-ietf-'; these, in general, require } > the assent of the chair, which in turn is based on a number of factors, } > including the status and direction of the working group. This } > particular draft is 'draft-angelos-spki-keynote-00.txt'; as such, it's } > an individual contribution. Over time, it may or may not become } > a working group product; in any event, eventual publication depends } > on approval by the IESG. It's certainly relevent enough to spki } > to discuss on this mailing list and/or at IETF meetings. For now, } > it's quite premature to speak of recalling the document; Blaze et al. } > are certainly entitled to their own opinions. } > } }I agree 100% with your words above but my objection did not intend at }any moment to target or rate the draft's usefullness, relevance or }right to be submitted. Rather, it very specifically actually aimed at }preserving the draft from early dismissal, by observing that a }*single* flaw disallowed the paper's methodology -- which could be }corrected by a preciser technical choice of words. So much was clearly }written. } }The draft gives the impression that it calculates trust predicates }-- which would ban the use of boolean logic -- while the draft is }based on boolean logic. Hence, it is not self-consistent and is }misleading in its current form. In fact, it is also not consistent }with the current terminology used in the very work it aims to support }-- SPKI. } }Thus, without any semantic evaluation of it, I suggested that the draft }could be made self-consistent (also in relationship to SPKI, cf other }msgs) if that single flaw would be eliminated. } }Thus, my suggestion that the draft be recalled was not a negation of }its submission rights but actually supportive of its right to be }eventually useful. } }Cheers, } }Ed } }______________________________________________________________________ }Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br }http://novaware.cps.softex.br } --- Visit the Meta-Certificate Group at http://mcg.org.br --- } From cclark Sat Mar 14 11:51:20 1998 Delivery-Date: Sat, 14 Mar 1998 11:58:12 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA25251 for ietf-outbound.10@ietf.org; Sat, 14 Mar 1998 11:50:01 -0500 (EST) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25227 for ; Sat, 14 Mar 1998 11:49:08 -0500 (EST) Received: (from egerck@localhost) by laser.cps.softex.br (8.8.7/8.8.7) id NAA11232; Sat, 14 Mar 1998 13:49:04 -0300 Date: Sat, 14 Mar 1998 13:49:04 -0300 Message-Id: <199803141649.NAA11232@laser.cps.softex.br> From: "E. Gerck" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf@ns.ietf.org Cc: spki@c2.net Subject: Re: KeyNote draft available In-Reply-To: <17132.889860894@nma.com> References: <199803140533.CAA08714@laser.cps.softex.br> <17132.889860894@nma.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Einar Stefferud writes: > I suspect that the term "recalled" is a problem here, when in fact > what I think Ed is asking for is a rapid replacement with a revised > version to cover up the current flawed version with a better version. > Exactly, thanks Einar. I was perhaps clearer in my rejoinders to Steve and Matt, for example when I mentioned at the end of the msg to Matt: That's why -- not to be just a technical criticism but also as a fruitful discussion between colleagues -- that I suggested the word "authorization" or "authorization management" if you prefer or "delegation", which avoid the three problems above and may allow your paper to be viewed under a coherent technical light now and in the future, also within current SPKI texts. Further, the same point of rapidly correcting the drafts to avoid an out of context declaration which leads to a misleading reading was present in my comments on the msg Re: I-D ACTION:draft-ietf-spki-cert-req-01.txt: At 03:17 PM 3/12/98 -0300, E. Gerck wrote: > > The IETF Simple Public Key Infrastructure [SPKI] Working Group is > > tasked with producing a certificate structure and operating procedure > > to meet the needs of the Internet community for trust management in > > as easy, simple and extensible a way as possible. > > > >To be coherent with the text, and to the other announced texts, the last >sentence above should delete the word "trust" and use "authorization" >instead. to which Carl has already agreed to. Thank you, Ed > This process is not unusual in any case, and perhaps this manner of > speaking about it will diffuse the disagreement;-)... > > Cheers...\Stef > > >From your message Sat, 14 Mar 1998 02:33:55 -0300: > } > }Steve Bellovin writes: > } > Ed Gerck wrote: > } > > } > I think this document has serious flaws and should be recalled. > } > > } > ... > } > > } > Thus, the document is misleading in its use of the word trust and > } > should either be changed throughout so that "trust" reads > } > authorization (for example) and correcting other logical problems or > } > should not be submitted to the IETF. In any case, it should be > } > recalled as it is. > } > > } > As a procedural matter, anyone can submit a draft on more or less > } > anything to the IETF. Drafts that purport to be from a working group > } > have a name beginning 'draft-ietf-'; these, in general, require > } > the assent of the chair, which in turn is based on a number of factors, > } > including the status and direction of the working group. This > } > particular draft is 'draft-angelos-spki-keynote-00.txt'; as such, it's > } > an individual contribution. Over time, it may or may not become > } > a working group product; in any event, eventual publication depends > } > on approval by the IESG. It's certainly relevent enough to spki > } > to discuss on this mailing list and/or at IETF meetings. For now, > } > it's quite premature to speak of recalling the document; Blaze et al. > } > are certainly entitled to their own opinions. > } > > } > }I agree 100% with your words above but my objection did not intend at > }any moment to target or rate the draft's usefullness, relevance or > }right to be submitted. Rather, it very specifically actually aimed at > }preserving the draft from early dismissal, by observing that a > }*single* flaw disallowed the paper's methodology -- which could be > }corrected by a preciser technical choice of words. So much was clearly > }written. > } > }The draft gives the impression that it calculates trust predicates > }-- which would ban the use of boolean logic -- while the draft is > }based on boolean logic. Hence, it is not self-consistent and is > }misleading in its current form. In fact, it is also not consistent > }with the current terminology used in the very work it aims to support > }-- SPKI. > } > }Thus, without any semantic evaluation of it, I suggested that the draft > }could be made self-consistent (also in relationship to SPKI, cf other > }msgs) if that single flaw would be eliminated. > } > }Thus, my suggestion that the draft be recalled was not a negation of > }its submission rights but actually supportive of its right to be > }eventually useful. > } > }Cheers, > } > }Ed > } > }______________________________________________________________________ > }Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br > }http://novaware.cps.softex.br > } --- Visit the Meta-Certificate Group at http://mcg.org.br --- > } -- ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br --- Visit the Meta-Certificate Group at http://mcg.org.br --- From adm Tue Mar 17 11:06:29 1998 Delivery-Date: Tue, 17 Mar 1998 11:11:33 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA05435 for ietf-123-outbound.10@ietf.org; Tue, 17 Mar 1998 11:05:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02034; Tue, 17 Mar 1998 10:14:21 -0500 (EST) Message-Id: <199803171514.KAA02034@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: spki@c2.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-spki-cert-structure-05.txt Date: Tue, 17 Mar 1998 10:14:16 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Public Key Infrastructure Working Group of the IETF. Title : Simple Public Key Certificate Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas Filename : draft-ietf-spki-cert-structure-05.txt Pages : 40 Date : 16-Mar-98 This document specifies a standard form for digital certificates and access control lists. These structures bind either names or authorizations to keys or names that resolve to keys. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. These structures are also known under the name SDSI 2.0. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-spki-cert-structure-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spki-cert-structure-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-spki-cert-structure-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316133157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-spki-cert-structure-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-spki-cert-structure-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316133157.I-D@ietf.org> --OtherAccess-- --NextPart-- From cclark Wed May 27 09:11:27 1998 Delivery-Date: Wed, 27 May 1998 09:20:06 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id JAA00541 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 09:10:02 -0400 (EDT) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA00149 for ; Wed, 27 May 1998 08:54:28 -0400 (EDT) Received: by relay.hq.tis.com; id IAA15643; Wed, 27 May 1998 08:50:48 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma015610; Wed, 27 May 98 08:49:55 -0400 Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA11159; Wed, 27 May 1998 08:44:44 -0400 (EDT) Message-Id: <199805271244.IAA11159@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 27 May 1998 08:52:07 -0400 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com From: "David M. Balenson" Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99) Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_896287927==_" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" C A L L F O R P A P E R S The Internet Society 1999 Network and Distributed System Security Symposium (NDSS'99) Where: Catamaran Resort, San Diego, California When: February 3-5, 1999 GOAL: The symposium will foster information exchange among hardware and software developers of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing 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. Topics for the symposium include, but are not limited to, the following: * Security in malleable systems: mobile code, mobile agents, active networks, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals such as efficiency, usability, reliability, interoperability, resource sharing, and cost. * Integrating security services with system and application security facilities and with application protocols, including message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. * Fundamental services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification infrastructures, audit, and intrusion detection. * Telecommunications security, especially for emerging technologies -- very large systems, e.g., the Internet, high-speed systems, e.g., the gigabit testbeds, wireless systems, personal communication systems, and large-scale, heterogeneous distributed systems. * Controls: firewalls, packet filters, application gateways * Object security and security objects * Network information resources and tools such as World Wide Web (WWW), Gopher, archie, and WAIS. * Electronic commerce: payment services, fee-for-access, EDI, notary services; endorsement, licensing, bonding, and other forms of assurance; rights management and other forms of intellectual property protection * Implementation and management of network security policy * Security for voice over IP * Security for routing GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CHAIRS: Stephen Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute TUTORIAL CHAIR: Doug Maughan, National Security Agency PROGRAM COMMITTEE: David Balenson, TIS Labs at Network Associates Steve Bellovin, AT&T Labs -- Research Matt Bishop, University of California at Davis Bob Blakley, IBM Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, Sun Microsystems Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Michael Roe, Cambridge University Jeffrey Schiller, MIT Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market Jonathan Trostle, Cisco 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 technical papers and panel proposals, for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be 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 each panelist. 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, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 31 July 1998, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions must arrive well before 31 July. All submissions and program related correspondence (only) should be directed to the program chair: Stephen Kent c/o BBN Technologies 70 Fawcett Street Cambridge, Mass. 02138 Email:sndss99-submissions@bbn.com Phone: +1 (617) 873-1996 FAX: +1 (617) 873-4086 Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/ndss99. 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 18 September 1998. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 16 October 1998. --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 --=====================_896287927==_-- From cclark Wed May 27 15:02:56 1998 Delivery-Date: Wed, 27 May 1998 15:12:37 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA08044 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 15:00:02 -0400 (EDT) Received: from mole.slip.net (mole.slip.net [207.171.193.16]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08010 for ; Wed, 27 May 1998 14:58:57 -0400 (EDT) Received: from eb-pm2-19-83.dialup.slip.net ([207.171.198.83] helo=207.171.198.83) by mole.slip.net with smtp (Exim 1.90 #1) id 0yelOM-0007FF-00; Wed, 27 May 1998 11:57:38 -0700 Message-ID: <356C63A5.61CC@ccnet.com> Date: Wed, 27 May 1998 12:04:05 -0700 From: Kurt Stammberger X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com Subject: RSA'99 Deadline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave's NDSS note reminded me to remind y'all: D E A D L I N E ! D E A D L I N E ! The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). For more information, or to propose a talk or submit a paper for presentation, visit www.rsa.com/conf99 Questions? E-mailez-moi. Kurt Stammberger Conference Director RSADSI From cclark Wed May 27 15:41:34 1998 Delivery-Date: Wed, 27 May 1998 15:51:01 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA08642 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 15:40:03 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA08513 for ; Wed, 27 May 1998 15:30:00 -0400 (EDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA17338; Wed, 27 May 1998 12:25:41 -0700 Received: from basilisk.Eng.Sun.COM (basilisk.Eng.Sun.COM [129.144.49.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA01991; Wed, 27 May 1998 12:25:35 -0700 Received: from alquds by basilisk.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA21067; Wed, 27 May 1998 12:25:31 -0700 Message-Id: <199805271925.MAA21067@basilisk.Eng.Sun.COM> Date: Wed, 27 May 1998 12:25:35 -0700 (PDT) From: Yahya Al-Salqan Reply-To: Yahya Al-Salqan Subject: Call for participation (FYI) To: firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com Cc: ssl-talk@netscape.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SCk4v9pjCPXd6BFIFnKHgg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Today is the deadline for the early registration ... take advantage of it. My appology if you receive this e-mail more than once! ================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop will be held June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and healthcare), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop held in conjunction with other WETICE workshops: "Web-based infrastructure for collaborative Enterprises," "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems ------------- End Forwarded Message ------------- ------------- End Forwarded Message -------------