Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19994; 1 May 94 16:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19990; 1 May 94 16:50 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa26941; 1 May 94 16:50 EDT Received: from chipcom.com (chipcom.com [192.41.247.9]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA03267 for ; Sun, 1 May 1994 16:32:54 -0400 Received: from atmguru.stealth ([151.104.20.62]) by chipcom.com (4.1/SMI-4.0) id AA11571; Sun, 1 May 94 16:31:04 EDT Received: by atmguru.stealth (4.1/SMI-4.1) id AA04133; Sun, 1 May 94 16:31:33 EDT Date: Sun, 1 May 94 16:31:33 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andreas Bovopoulos Message-Id: <9405012031.AA04133@atmguru.stealth> To: cat-ietf-request@mit.edu, cipso-request@wdl1.wdl.loral.com, ietf-aac-request@isi.edu, ipsec-request@ans.net, nas-req@merit.edu, pem-dev-request@tis.com Subject: subscribe Hi, Could you please add my name in the mailing list? Thank you very much Dr. Andreas D. Bovopoulos Principal Engineer Chipcom Corporation 118 Turnpike Road Southborough, MA 01772-1886 tel:(508) 490-5602 fax:(508) 490-5873 e-mail:abovopou@chipcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15040; 2 May 94 21:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15036; 2 May 94 21:03 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa26777; 2 May 94 21:03 EDT Received: by relay.tis.com; id AA15893; Mon, 2 May 94 20:53:16 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma015884; Mon May 2 20:53:03 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19266; 2 May 94 20:45 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19261; 2 May 94 20:42 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06751; Mon, 2 May 94 20:41:47 EDT Received: by relay.tis.com; id AA15812; Mon, 2 May 94 20:43:11 EDT Received: from fitmail.fit.qut.edu.au(131.181.2.1) by relay via smap (V1.3mjr) id sma015806; Mon May 2 20:42:56 1994 Received: (from rhys@localhost) by fitmail.fit.qut.edu.au (8.6.7/8.6.6) id KAA03457; Tue, 3 May 1994 10:42:33 +1000 Date: Tue, 3 May 1994 10:07:06 +1000 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mr Rhys Weatherley Subject: Enveloping messages in mail spools To: pem-dev@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's a novel use of PEM-based encryption I've been thinking of, and would like to discuss, especially in its relationship to MIME-PEM. It may sometimes be useful for sites to run a "secure mail environment" where all mailboxes are routinely encrypted to protect users from each others snooping, and from snooping by a cracked root account. This is even more important in primary and high school environments where the mail system is likely to be running on a DOS LAN rather than a more secure Unix system, and proto-crackers abound. It is simply not enough to rely on users to encrypt their messages when they send them, especially since PEM software is not very wide-spread at present, and even those who use it don't routinely encrypt everything they send. It needs to be built into the code which writes to the user's mailbox. i.e. as each new message comes in, it is encrypted with the user's public key and added to the mailbox. It should be fairly easy to integrate something like this with existing Unix mail systems with a few sendmail hacks. Other systems may require a little more work. The main question is: what kind of tagging information can the mail system add to say "the real message is inside this encryption envelope, so strip this off first before displaying the message"? i.e. some kind of multipart which is identical to the normal MIME-PEM encryption multipart constructs, but which says "I am here for local privacy only: I am not part of the original message". Some of you may argue that this is a "local matter", and really shouldn't be part of the PEM standard. If so, then just a little guideance on a good tag to use would be appreciated. This has arisen in my quest for a "Next Generation Windows UUCP" system which is not only easier to install and use, but also has security built in at the bottom-most level rather than being tacked on afterwards. This includes things like: (a) encrypted mailboxes as above; (b) encrypted newsgroups so teachers can discuss things without students snooping; (c) encrypted client-server interactions to securely transmit a student's message to the school server; and (d) anything else I can think of :-) . By building some of these things into the transport, I hope to increase the level of security while maintaining backwards-compatibility with existing PEM-aware client software. Then, by hacking the client software, make the added security as invisible to users as possible. Just a few random thoughts. If anyone wants to discuss some of the other security aspects of my ideas that don't relate directly to PEM, then give me a holler offline. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15360; 2 May 94 21:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15342; 2 May 94 21:43 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa27447; 2 May 94 21:43 EDT Received: by relay.tis.com; id AA16302; Mon, 2 May 94 21:34:38 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa16290; Mon May 2 21:34:10 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19346; 2 May 94 21:28 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19332; 2 May 94 21:24 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA08483; Mon, 2 May 94 21:24:04 EDT Message-Id: <9405030124.AA08483@tis.com> To: Mr Rhys Weatherley Cc: pem-dev@tis.com Subject: Re: Enveloping messages in mail spools In-Reply-To: Your message of "Tue, 03 May 94 10:07:06 +1000." Date: Mon, 02 May 94 21:23:53 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker Rhys, Not a bad idea. We've done some work on the dual: encrypt everything headed out as it passes the gateway. It's interesting to see the variations that develop from different assumptions about whether the local or external environment is more hazardous. I don't think there's any inherent conflict. The agent which encrypts can choose not to sign it. If it signs the message, it should say it's the incoming gateway. Our implementation of MIME-PEM will have a mode for retaining annotating the decrypted, signature-verified message with the names of the relevant parties. The annotations will distinguish between unsigned messages and signed messages so as to prevent possible spoofs. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15902; 2 May 94 22:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15898; 2 May 94 22:42 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa28314; 2 May 94 22:42 EDT Received: by relay.tis.com; id AA16912; Mon, 2 May 94 22:37:08 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa16892; Mon May 2 22:36:21 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19486; 2 May 94 22:21 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19482; 2 May 94 22:20 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10307; Mon, 2 May 94 22:19:34 EDT Received: by relay.tis.com; id AA16763; Mon, 2 May 94 22:20:57 EDT Received: from fitmail.fit.qut.edu.au(131.181.2.1) by relay via smap (V1.3mjr) id sma016749; Mon May 2 22:20:36 1994 Received: (from rhys@localhost) by fitmail.fit.qut.edu.au (8.6.7/8.6.6) id MAA05025; Tue, 3 May 1994 12:20:44 +1000 Date: Tue, 3 May 1994 11:53:39 +1000 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mr Rhys Weatherley Subject: Re: Enveloping messages in mail spools To: Stephen D Crocker Cc: pem-dev@tis.com In-Reply-To: <9405030124.AA08483@tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 May 1994, Stephen D Crocker wrote: > Not a bad idea. We've done some work on the dual: encrypt everything > headed out as it passes the gateway. It's interesting to see the > variations that develop from different assumptions about whether the > local or external environment is more hazardous. It's also interesting to note that a high school may be very hesitant to install a package which will encrypt all of the student's messages so the teachers can't tell if the students are simply chatting, or swapping assignment solutions. :-) Six in one hand, half a dozen in the other. > I don't think there's any inherent conflict. The agent which encrypts > can choose not to sign it. If it signs the message, it should say > it's the incoming gateway. Our implementation of MIME-PEM will have a > mode for retaining annotating the decrypted, signature-verified > message with the names of the relevant parties. The annotations will > distinguish between unsigned messages and signed messages so as to > prevent possible spoofs. Sounds pretty much what I wanted. My question was mainly intended to see if there is a documented way to automatically identify any locally-added privacy/signature enveloping so that when a message is saved, forwarded, etc, the extra stuff is removed, and the original message is used instead. It's a question of knowing when to stop so that remotely-added enveloping is not removed unless the user really wants it removed. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17159; 2 May 94 23:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17155; 2 May 94 23:19 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa28787; 2 May 94 23:19 EDT Received: by relay.tis.com; id AA17178; Mon, 2 May 94 23:08:21 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma017166; Mon May 2 23:07:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19571; 2 May 94 22:51 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19567; 2 May 94 22:50 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA11044; Mon, 2 May 94 22:49:48 EDT Message-Id: <9405030249.AA11044@tis.com> To: Mr Rhys Weatherley Cc: pem-dev@tis.com Subject: Re: Enveloping messages in mail spools In-Reply-To: Your message of "Tue, 03 May 94 11:53:39 +1000." Date: Mon, 02 May 94 22:49:37 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker > Sounds pretty much what I wanted. My question was mainly intended to see > if there is a documented way to automatically identify any locally-added > privacy/signature enveloping so that when a message is saved, forwarded, > etc, the extra stuff is removed, and the original message is used instead. > It's a question of knowing when to stop so that remotely-added enveloping > is not removed unless the user really wants it removed. I think the trick is to know the signatures of the local agents so they can be discarded as not having any value outside the local environment. If is a message m signed by u, then > symbolizes a message signed first by a remote user and then by a local agent. If the local user forwrds this to someone and he or his software recognizes ulocal, then it would incorporate only into the forwarded message. On the other hand, if it sees >, where uendorser is some signature the local user can't dismiss, the local user will forward the entire doubly-signed message. The paper analogy is a document with a cover note. If the cover note is generated internally, e.g. from a boss or a subordinate, it's reasonable to strip it off before sending it outside the organization. But there are other circumstances in which the entire chain of actions needs to be recorded, so it's at least partly a policy issue and not merely one of mechanics. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24126; 3 May 94 0:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24122; 3 May 94 0:48 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa00278; 3 May 94 0:48 EDT Received: by relay.tis.com; id AA17925; Tue, 3 May 94 00:39:03 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma017917; Tue May 3 00:38:22 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19785; 3 May 94 0:33 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19781; 3 May 94 0:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13739; Tue, 3 May 94 00:30:33 EDT Received: by relay.tis.com; id AA17872; Tue, 3 May 94 00:31:56 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma017865; Tue May 3 00:31:46 1994 Received: by atc.boeing.com (5.57) id AA04455; Mon, 2 May 94 21:31:39 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DC5D395@ct.si.cs.boeing.com>; Mon, 02 May 94 21:31:17 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Harris, Richard L." To: 'pem-dev' Subject: Re: Enveloping messages in mail spools Date: Mon, 02 May 94 21:28:00 PDT Message-Id: <2DC5D395@ct.si.cs.boeing.com> Encoding: 89 TEXT X-Mailer: Microsoft Mail V3.0 Steve Crocker and Rhys started a discussion about extending PEM-MIME constructs and functionality beyond the interactive user - mail transport focused scope of PEM (as is). Rhys suggested extended uses most interestingly involve signed and/or encrypted storage, protecting against a hacked system (at a later time than storage/receipt time), and for enabling restricted discussions within the mail system between local users. Steve brings up policy driven (automatic & outside of user control?) protection of 'external' mail via non-user requested use of PEM mechanisms. I like the functionalities. Both start to raise a lot of questions I don't remember being discussed for the current PEM. My first question though is if you encrypt with the public key and the mail system, hopefully, doesn't have the secret key around all of the time, how do you get the system to do anything with the mail unless the user is on-line and supplies access to the key? I can think of a couple of additional and somewhat related things to explore as extended PEM uses. In general they strain my understanding of the extensibilities of PEM 'as-is'.; - Signing or encrypting not just spooled but stored or saved mail. - Long... term storage of signed or encrypted mail. - Recoverable archives or backups of some or all encrypted or signed mail. - Updating spooled or stored mail signatures or seals as new certificates or revocations are received. - Forwarding protected mail to a portable or other remote user agent where either the remote host or the communications channel inbetween is insecure or untrustworthy (,and may be only intermittently connected). - Portable or remote hosts with user agents that share or divide mail folders, such as duplicated inboxes, that need updating and alignment. - The much maligned, but much used, secretaries privileges to receive, receipt, forward, and/or answer someone elses mail when delegated. - The delay (mucho processing time) needed when changing certificates on everything stored that's analogous to decrypting/reencrypting disks or directories when an encryption password is changed. - And of course the combinations of the above. Perhaps none of these requires anything new. Perhaps nobody wants to work on them. If they do though need agreements about or extensions to PEM 'as-is' then is attacking a short prioritized list best or is it worth looking at a more exhaustive list to seek common functionality requirements. And yes, I know that I haven't really listed functionality requirement. This is just a quick idea list of scenarios for mail usages where I don't understand how they are enabled by present PEM. Most of these are things that I have or want in my current 'unsecure' mail. Rich Harris, M/S 7L-15 rharris@atc.boeing.com Boeing Computer Services/ Computing Security Technology PO Box 24346 / Seattle WA 98124 phone 206-865-4922 fax 206-865-6903 ---------- From: pem-dev-request To: Stephen D Crocker Cc: pem-dev Subject: Re: Enveloping messages in mail spools Date: Tuesday, May 03, 1994 11:53AM On Mon, 2 May 1994, Stephen D Crocker wrote: > Not a bad idea. We've done some work on the dual: encrypt everything > headed out as it passes the gateway. It's interesting to see the > variations that develop from different assumptions about whether the > local or external environment is more hazardous. It's also interesting to note that a high school may be very hesitant to install a package which will encrypt all of the student's messages so the teachers can't tell if the students are simply chatting, or swapping assignment solutions. :-) Six in one hand, half a dozen in the other. > I don't think there's any inherent conflict. The agent which encrypts > can choose not to sign it. If it signs the message, it should say > it's the incoming gateway. Our implementation of MIME-PEM will have a > mode for retaining annotating the decrypted, signature-verified > message with the names of the relevant parties. The annotations will > distinguish between unsigned messages and signed messages so as to > prevent possible spoofs. Sounds pretty much what I wanted. My question was mainly intended to see if there is a documented way to automatically identify any locally-added privacy/signature enveloping so that when a message is saved, forwarded, etc, the extra stuff is removed, and the original message is used instead. It's a question of knowing when to stop so that remotely-added enveloping is not removed unless the user really wants it removed. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00906; 3 May 94 6:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00902; 3 May 94 6:54 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa02871; 3 May 94 6:54 EDT Received: by relay.tis.com; id AA20437; Tue, 3 May 94 06:42:19 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma020430; Tue May 3 06:41:59 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa20470; 3 May 94 6:40 EDT Received: from sol.tis.com by magellan.TIS.COM id aa20450; 3 May 94 6:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20335; Tue, 3 May 94 06:13:43 EDT Received: by relay.tis.com; id AA20266; Tue, 3 May 94 06:15:06 EDT Received: from punch.ic.ac.uk(155.198.5.4) by relay via smap (V1.3mjr) id sma020257; Tue May 3 06:14:57 1994 Received: from sg1.cc.ic.ac.uk by punch.ic.ac.uk with SMTP (PP) id <18424-0@punch.ic.ac.uk>; Tue, 3 May 1994 11:13:29 +0100 Received: by cscmgb.cc.ic.ac.uk (920330.SGI/4.0) id AA14810; Tue, 3 May 94 11:13:58 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: p.churchyard@ic.ac.uk Message-Id: <9405031013.AA14810@cscmgb.cc.ic.ac.uk> Subject: Re: Enveloping messages in mail spools To: Mr Rhys Weatherley Date: Tue, 3 May 94 11:13:57 bst Cc: pem-dev@tis.com In-Reply-To: ; from "Mr Rhys Weatherley" at May 3, 94 10:07 am This is already done my PC systems such as cc:Mail from Lotus. All the users email is stored in one large database where each users email is encrypted to stop casual snooping. Pete.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02477; 3 May 94 8:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02473; 3 May 94 8:53 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa05078; 3 May 94 8:53 EDT Received: by relay.tis.com; id AA21594; Tue, 3 May 94 08:42:50 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma021583; Tue May 3 08:42:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa22577; 3 May 94 8:35 EDT Received: from sol.tis.com by magellan.TIS.COM id aa22573; 3 May 94 8:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25149; Tue, 3 May 94 08:33:18 EDT Received: by relay.tis.com; id AA21500; Tue, 3 May 94 08:34:41 EDT Received: from dingo.cc.uq.oz.au(130.102.2.14) by relay via smap (V1.3mjr) id sma021492; Tue May 3 08:34:32 1994 Received: from localhost by dingo.cc.uq.oz.au with SMTP id AA16787 (5.67a/IDA-1.5 for ); Tue, 3 May 1994 22:33:38 +1000 Date: Tue, 3 May 1994 22:33:31 +1000 (GMT+1000) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Stuart Subject: Joining pem-dev mailing list To: pem-dev@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello pem-dev, We are currently investigating the possibility of developing a PEM system that complies with RFC1421-24 for the Prentice Centre, University of Queensland. This software will be made publicly available at no charge, once it is completed. As it is to become available in this way, we are trying to minimise the costs and time involved by obtaining any relevant public domain code. Do you know of any available source code, of any relevance to this project -- e.g. encryption code, header parsers, canonical conversion -- we don't want to reinvent the wheel. We would also like to contact other people currently implementing a PEM system who may be able to help us. We will acknowledge any contributions you can make to our effort. Also, if you would like any other information about this project, please feel free to contact us. Also we would like to join the pem-dev mailing list, preferably as R.Stuart@cc.uq.oz.au and R.Cockburn@cc.uq.oz.au separately. Thanks for your time, R. Cockburn & R. Stuart PEM Investigation Team ------------------------------------------------------------------------ PEM Investigation Team | pem@cc.uq.oz.au | Prentice Centre | Team: R. Cockburn R.Cockburn@cc.uq.oz.au The University Of Queensland | R. Stuart R.Stuart@cc.uq.oz.au Australia | ------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03336; 3 May 94 9:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03332; 3 May 94 9:29 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa06016; 3 May 94 9:29 EDT Received: by relay.tis.com; id AA22141; Tue, 3 May 94 09:19:22 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smab22127; Tue May 3 09:19:00 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa23105; 3 May 94 9:07 EDT Received: from sol.tis.com by magellan.TIS.COM id aa23089; 3 May 94 9:05 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA26405; Tue, 3 May 94 09:05:21 EDT Message-Id: <9405031305.AA26405@tis.com> To: Robert Stuart Cc: pem-dev@tis.com Subject: Re: Joining pem-dev mailing list In-Reply-To: Your message of "Tue, 03 May 94 22:33:31 +1000." Date: Tue, 03 May 94 09:05:09 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker Robert, Your project sounds like it will be a fine addition for the community. You should be aware that the PEM specs are undergoing revision, so it would be useful to read the internet draft as well as the existing RFCs. The principal changes are: o integration of MIME and PEM o opening up of the naming system to accommodate email addresses and other strings as identifiers in PEM o separation of mechanism and policy with respect to the certification of bindings between names and keys. With respect to the first point, MIME provides boundary and transfer encoding mechanisms, so that aspect of 1421 will not appear in the new spec. Signature and encryption are now entirely independent, and the protected text is now kept separate from the "pem headers." Signatures come after the body. (To facilitate one pass processing, the identifier for the signature algorithm is at the top.) Good luck. We, and others on this list, will be delighted to test interoperability with you. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09710; 3 May 94 18:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09706; 3 May 94 18:15 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa17458; 3 May 94 18:15 EDT Received: by relay.tis.com; id AA28903; Tue, 3 May 94 18:09:02 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma028894; Tue May 3 18:08:09 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25841; 3 May 94 18:05 EDT Received: from sol.tis.com by magellan.TIS.COM id aa25824; 3 May 94 17:53 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10507; Tue, 3 May 94 17:52:27 EDT Received: by relay.tis.com; id AA28756; Tue, 3 May 94 17:53:51 EDT Received: from fitmail.fit.qut.edu.au(131.181.2.1) by relay via smap (V1.3mjr) id sma028747; Tue May 3 17:52:57 1994 Received: (from rhys@localhost) by fitmail.fit.qut.edu.au (8.6.7/8.6.6) id HAA12813; Wed, 4 May 1994 07:52:57 +1000 Date: Wed, 4 May 1994 07:47:28 +1000 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mr Rhys Weatherley Subject: Re: Enveloping messages in mail spools To: p.churchyard@ic.ac.uk Cc: pem-dev@tis.com In-Reply-To: <9405031013.AA14810@cscmgb.cc.ic.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 May 1994 p.churchyard@ic.ac.uk wrote: > This is already done my PC systems such as cc:Mail from Lotus. All the > users email is stored in one large database where each users email > is encrypted to stop casual snooping. Anyone know any details on this? i.e. do they keep a list of public keys on the server to write to the database; something based on the user's password; or use some (yuk!) proprietry scheme? Does "casual snooping" mean "viewing the file with more" or "applying a cryptanalytic attack to get the contents"? Always good to check out what the opposition is up to, so we can "borrow" the good ideas. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09992; 3 May 94 18:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09988; 3 May 94 18:45 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa17880; 3 May 94 18:45 EDT Received: by relay.tis.com; id AA29139; Tue, 3 May 94 18:30:22 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa29126; Tue May 3 18:29:32 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25887; 3 May 94 18:26 EDT Received: from sol.tis.com by magellan.TIS.COM id aa25883; 3 May 94 18:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11380; Tue, 3 May 94 18:23:53 EDT Received: by relay.tis.com; id AA29093; Tue, 3 May 94 18:25:18 EDT Received: from fitmail.fit.qut.edu.au(131.181.2.1) by relay via smap (V1.3mjr) id sma029085; Tue May 3 18:24:46 1994 Received: (from rhys@localhost) by fitmail.fit.qut.edu.au (8.6.7/8.6.6) id IAA13066; Wed, 4 May 1994 08:24:37 +1000 Date: Wed, 4 May 1994 07:55:35 +1000 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mr Rhys Weatherley Subject: Re: Enveloping messages in mail spools To: "Harris, Richard L." Cc: 'pem-dev' In-Reply-To: <2DC5D395@ct.si.cs.boeing.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 May 1994, Harris, Richard L. wrote: > My first question though is if you encrypt with the public key and the mail > system, hopefully, doesn't have the secret key around all of the time, how > do you get the system to do anything with the mail unless the user is > on-line and supplies access to the key? There's two cases where encryption comes into the picture (there could be others I haven't identified yet): (a) Encrypting an incoming plaintext message and writing it to the user's mailbox. (b) Sending a plaintext message to a server in an encrypted fashion for it to be processed and forwarded onwards. Case (a) requires the server to keep a list of public keys for all users on the system. Since this isn't highly protected information, it doesn't matter if it is compromised (except for the usual certificate validation stuff of course). Case (b) requires the clients to have a copy of the server's public key, and for the server to somehow have its private key embedded. There is a chance of compromise if the server system is insecure, because either a user will need to enter a passphrase every time a message is processed by the server, or the passphrase is entered once at startup and the unencrypted private key is kept in the server's memory space. Not exactly the most secure system, but could be made more secure with smart cards and the like. Just to give a little more information on the system I'm thinking of: I envisage that when a user submits a message, it will be encrypted with the server's public key and transmitted to the server. The server will decrypt it, look up the user's public key (if any), encrypt it, and write it to the user's mailbox. In my DOS LAN based system, the messages will be transmitted to the server in a publicly accessible directory, hence the need for encryption of that step. This is the default behaviour. If the user wishes to add extra encryption layers to protect themselves from snoops on the server system, they can do so using normal PEM mechanisms. I'm also thinking of using similar methods to encrypt UUCP mail and news batches that are transmitted between systems. e.g. the user submits a message to the server which is destined for a remote system. The server decrypts it as before, and then re-encrypts it with the remote system's public key before tossing it into the spool. This way, the clients do not need to have full knowledge of the routing algorithms used by the server to add the required enhancements themselves. To them, they are submitting a plaintext message which just happens to be automatically processed to add any privacy enhancements that the sysadmin deems necessary. Further gadgetry such as Steve's automatic user-level encryption could also be added to the server. > - Forwarding protected mail to a portable or other remote user agent where > either the remote host or the communications channel inbetween is insecure > or untrustworthy (,and may be only intermittently connected). > - Portable or remote hosts with user agents that share or divide mail > folders, such as duplicated inboxes, that need updating and alignment. These could probably be handled by bolting encryption extensions onto the POP3 and IMAP protocols, and maybe also SMTP. I don't know of any work in this area. > - The delay (mucho processing time) needed when changing certificates on > everything stored that's analogous to decrypting/reencrypting disks or > directories when an encryption password is changed. With a public key based system, 99% of the time it will be the passphrase that changes which won't affect previously encrypted disks. If the key pair changes, then only the session key header blocks on each file will need to be changed to decrypt with the old key pair, and then encrypt with the new key pair. Not really a PEM problem, although providing this as an option on stored PEM messages would certainly be useful. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25863; 6 May 94 9:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25859; 6 May 94 9:13 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa02330; 6 May 94 9:13 EDT Received: by relay.tis.com id AA11091; Fri, 6 May 94 08:59:25 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma011084; Fri May 6 08:59:09 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa20529; 6 May 94 8:57 EDT Received: from sol.tis.com by magellan.TIS.COM id aa20525; 6 May 94 8:53 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05364; Fri, 6 May 94 08:52:46 EDT Received: by relay.tis.com id AA11046; Fri, 6 May 94 08:53:23 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma011034; Fri May 6 08:52:22 1994 Received: from harvey.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA13610; Fri, 6 May 1994 08:53:40 -0400 Received: from wotan.gte.com by harvey.gte.com (5.65c+/Ultrix3.0-C) id AA26799; Fri, 6 May 1994 08:52:16 -0400 Message-Id: <199405061252.AA26799@harvey.gte.com> Date: Fri, 06 May 94 09:50:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jueneman%wotan@gte.com Subject: Telecommuting security To: pem-dev@tis.com Reply-To: "Jueneman, Robert R." Priority: Security: I'm involved in a task force that is looking at establishing an official policy re telecommuting for GTE Labs. (We've been doing it unofficially for some time, but inconsistantly across departments.) One of the issues of course is security, including privacy, integrity, and access to resources. Initially, we willpresumably use dial-up lines with high-speed modems. Eventually, ISDN, frame relay, and/or other technologies might come into use. Although I trust that some day we will have a useable version of PEM to handle e-mail securely, not all problems can be solved that way. Some people need FTP, others will want Telnet, X-windows or other interactive protocols. Certainly a secure FAX capability would be nice, as well as secure remote printing. In general, we would want employees to be able to access computing facilities as though they were at work, rather than through awkward firewalls. Other requirements are that the system be cheap (preferably smartcard based), that it include heavy-duty compression before encryption (since the compression built into modems won't work on encrypted data), that it support effective rates of 128Kbps or higher using 28.4 kbps modems, and that it be available on Macs, PCs, Sun, and DEC platforms. Although Kerberos or similar systems could be used, I'd really like to see a public-key based system that used triple-DES. (Export control is not an issue here.) Ful period link encryption is one possibility, and X.25 or IP packet encryption is another, with various pros and cons. Is anyone aware of anything being done along these lines, either in a secure modem or as an modification to SLIP, PPP, or mobile IP? If not, would anyone be interested in working on the problem? (BTW- I'd be interested in hearing privately from anyone who has gone through this exercise and established a formal telecommuting policy -- lessons learned, rocks and shoals to avoid, etc.) Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05419; 6 May 94 14:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05415; 6 May 94 14:44 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10712; 6 May 94 14:44 EDT Received: by relay.tis.com id AA13464; Fri, 6 May 94 14:32:18 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma013460; Fri May 6 14:31:56 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa22547; 6 May 94 14:27 EDT Received: from sol.tis.com by magellan.TIS.COM id aa22543; 6 May 94 14:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01458; Fri, 6 May 94 14:23:39 EDT Received: by relay.tis.com id AA13405; Fri, 6 May 94 14:24:16 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma013401; Fri May 6 14:23:50 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18083; Fri, 6 May 94 11:16:45 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA10954; Fri, 6 May 1994 14:18:38 -0400 Message-Id: <9405061818.AA10954@skidrow.lkg.dec.com> To: "Jueneman, Robert R." Cc: pem-dev@tis.com Subject: Re: Telecommuting security In-Reply-To: Your message of "Fri, 06 May 94 09:50:19 EDT." <199405061252.AA26799@harvey.gte.com> Date: Fri, 06 May 94 14:18:38 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Bob, There are lots of application level efforts but I think what you want is IP network/transport level security. There is an ipsec working group looking into this. The mailing list is ipsec@ans.net. The charter for the WG, etc., can be accessed in the usual ways. Donald From: jueneman%wotan@gte.com To: pem-dev@tis.com Reply-To: "Jueneman, Robert R." >... > >Although I trust that some day we will have a useable >version of PEM to handle e-mail securely, not all problems >can be solved that way. Some people need FTP, others >will want Telnet, X-windows or other interactive protocols. >Certainly a secure FAX capability would be nice, as well >as secure remote printing. In general, we would want >employees to be able to access computing facilities >as though they were at work, rather than through awkward >firewalls. > >... > >Ful period link encryption is one possibility, and X.25 or IP >packet encryption is another, with various pros and cons. >Is anyone aware of anything being done along these lines, >either in a secure modem or as an modification to SLIP, PPP, >or mobile IP? If not, would anyone be interested in working >on the problem? > >(BTW- I'd be interested in hearing privately from anyone who >has gone through this exercise and established a formal >telecommuting policy -- lessons learned, rocks and shoals to >avoid, etc.) > >Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06175; 6 May 94 15:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06171; 6 May 94 15:16 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa11444; 6 May 94 15:16 EDT Received: by relay.tis.com id AA13767; Fri, 6 May 94 15:03:24 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma013759; Fri May 6 15:03:16 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa22645; 6 May 94 14:56 EDT Received: from sol.tis.com by magellan.TIS.COM id aa22641; 6 May 94 14:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03704; Fri, 6 May 94 14:53:43 EDT Received: by relay.tis.com id AA13664; Fri, 6 May 94 14:54:21 EDT Received: from ns.broadvision.com(198.211.204.2) by relay via smap (V1.3mjr) id sma013661; Fri May 6 14:54:12 1994 Received: from broadvision.com (galaxy.broadvision.com) by nebula (4.1/SMI-4.1) id AA15272; Fri, 6 May 94 11:53:02 PDT Received: from echo.broadvision.com by broadvision.com (5.0/SMI-SVR4) id AA13275; Fri, 6 May 1994 11:50:13 +0800 Received: by echo.broadvision.com (5.0/SMI-SVR4) id AA02815; Fri, 6 May 1994 11:50:09 +0800 Date: Fri, 6 May 1994 11:50:09 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wayne Yamamoto Message-Id: <9405061850.AA02815@echo.broadvision.com> To: rsaref@rsa.com, pem-dev@tis.com Subject: RSA freeware X-Sun-Charset: US-ASCII Content-Length: 132 I'm interested in the RSA's technology and products. Please send me the reference version of RSA's developer's kit. Thanks Wayne   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08707; 7 May 94 14:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08703; 7 May 94 14:37 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa09409; 7 May 94 14:37 EDT Received: by relay.tis.com id AA00346; Sat, 7 May 94 14:35:43 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smab00339; Sat May 7 14:35:16 1994 Received: by magellan.TIS.COM id ac25574; 7 May 94 14:32 EDT Received: from magellan.tis.com by magellan.TIS.COM id aa25532; 7 May 94 14:23 EDT Received: from sol.tis.com by magellan.TIS.COM id aa25525; 7 May 94 14:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00277; Sat, 7 May 94 13:55:00 EDT Received: by relay.tis.com id AA00146; Sat, 7 May 94 13:55:40 EDT Received: from unknown(132.197.8.9) by relay via smap (V1.3mjr) id sma000122; Sat May 7 13:54:39 1994 Received: from harvey.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA22963; Sat, 7 May 1994 13:42:37 -0400 Received: from wotan.gte.com by harvey.gte.com (5.65c+/Ultrix3.0-C) id AA13664; Sat, 7 May 1994 13:41:12 -0400 Message-Id: <199405071741.AA13664@harvey.gte.com> Date: Sat, 07 May 94 14:39:14 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jueneman%wotan@gte.com Subject: Re: Telecommuting security To: pem-dev@tis.com Reply-To: "Jueneman, Robert R." I am somewhat amazed by the interest this subject has spawned. Six people responded within a day, including people from Bellcore, Motorola, Georgia Tech, Fischer International, and DEC. Gordon Wishon suggested that perhaps a private mail list be formed to address this topic. That might be very useful and helpful, but perhaps someone who reads more of the rest of the various news groups than I would know whether such a group already exists? Donald Eastlake suggested that there is an ipsec group looking at the technical solutions for IP security, but the level of interest seems to go further than that, including addressing issues as disposing of proprietary trash and who services your hard drive when it is full of proprietary information. If there continues to be a signifcant amount of interest amount of interest in this subject and a suitable group does not already exist, I'll investigate setting up such a mail list. Bob There are lots of application level efforts but I think what you want is IP network/transport level security. There is an ipsec working group looking into this. The mailing list is ipsec@ans.net. The charter for the WG, etc., can be accessed in the usual ways. Donald   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02393; 11 May 94 7:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02389; 11 May 94 7:57 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa03984; 11 May 94 7:57 EDT Received: by relay.tis.com id AA16035; Wed, 11 May 94 07:49:21 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa16029; Wed May 11 07:49:05 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06476; 11 May 94 7:14 EDT Received: from sol.tis.com by magellan.TIS.COM id aa06472; 11 May 94 7:11 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01745; Wed, 11 May 94 07:11:34 EDT Received: by relay.tis.com id AA15918; Wed, 11 May 94 07:12:19 EDT Received: from sprintf.merit.edu(35.1.1.62) by relay via smap (V1.3mjr) id sma015916; Wed May 11 07:11:45 1994 Received: from sprint.com by sprintf.merit.edu (8.6.5/merit-1.0) id HAA29165; Wed, 11 May 1994 07:11:33 -0400 Received: from sprintf.merit.edu by sprintf.merit.edu with SMTP (PP); Wed, 11 May 1994 07:11:22 -0400 Received: from atlas.arc.nasa.gov by sprintf.merit.edu (8.6.5/merit-1.0) id HAA29154; Wed, 11 May 1994 07:11:21 -0400 Message-Id: <199405111111.HAA29154@sprintf.merit.edu> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Wed, 11 May 1994 04:11:20 -0700 To: a <"/RFC-822=pem-dev(a)tis.com/PRMD=internet/ADMD=TELEMAIL/C=US/"@sprint.com> Subject: DES export from USA Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: /S=williams/OU=atlas/O=NASA/PRMD=ARC/ADMD=TELEMAIL/C=US/@atlas.arc.nasa.gov Privacy: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 May 1994 04:11:18 -0700 X-Orig-Sender: williams@atlas.arc.nasa.gov Anyone have any arguments for or against the removal of US DES export controls for software implementations?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07013; 11 May 94 11:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07009; 11 May 94 11:58 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa11787; 11 May 94 11:58 EDT Received: by relay.tis.com id AA17676; Wed, 11 May 94 11:45:41 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma017668; Wed May 11 11:45:25 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08262; 11 May 94 11:35 EDT Received: from sol.tis.com by magellan.TIS.COM id aa08258; 11 May 94 11:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17212; Wed, 11 May 94 11:32:57 EDT Received: by relay.tis.com id AA17568; Wed, 11 May 94 11:33:41 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma017553; Wed May 11 11:32:44 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27711; Wed, 11 May 94 08:27:41 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA06514; Wed, 11 May 1994 11:29:39 -0400 Message-Id: <9405111529.AA06514@skidrow.lkg.dec.com> To: /S=williams/OU=atlas/O=NASA/PRMD=ARC/ADMD=TELEMAIL/C=US/@atlas.arc.nasa.gov Cc: dee@skidrow.lkg.dec.com, Privacy Encrusted Mail Deveopment Subject: Re: DES export from USA In-Reply-To: Your message of "Wed, 11 May 94 04:11:18 PDT." <199405111111.HAA29154@sprintf.merit.edu> Date: Wed, 11 May 94 11:29:39 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Yes but I think you would be better off contacting the EFF or CPSR (try poking around with fpt to eff.org and cpsr.org) for information on this. There are also a variety of USENET newgroups periodically filled with debate on the subect. Donald PS: Too bad you are stuck someplace where you have one of those incredibly painful X.400 addresses instead of something reasonable. From: /S=williams/OU=atlas/O=NASA/PRMD=ARC/ADMD=TELEMAIL/C=US/@atlas.arc.nasa.gov To: a <"/RFC-822=pem-dev(a)tis.com/PRMD=internet/ADMD=TELEMAIL/C=US/"@sprint.com(a)(a)(a)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: williams@atlas.arc.nasa.gov >Anyone have any arguments for or against the removal of >US DES export controls for software implementations?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14620; 11 May 94 17:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14614; 11 May 94 17:39 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa22345; 11 May 94 17:39 EDT Received: by relay.tis.com id AA20893; Wed, 11 May 94 17:28:16 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma020885; Wed May 11 17:27:23 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09819; 11 May 94 17:24 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09815; 11 May 94 17:21 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19463; Wed, 11 May 94 17:21:29 EDT Received: by relay.tis.com id AA20827; Wed, 11 May 94 17:22:14 EDT Received: from indial1.io.com(198.4.60.11) by relay via smap (V1.3mjr) id sma020823; Wed May 11 17:22:00 1994 Received: from localhost by indial1.io.com (8.6.5/PERFORMIX-0.9/08-16-92) id QAA10197; Wed, 11 May 1994 16:19:37 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Terry Ritter Message-Id: <199405112119.QAA10197@indial1.io.com> Subject: Estimating Population Summary To: pem-dev@tis.com Date: Wed, 11 May 1994 16:19:36 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 7557 Summary of: Estimating Population from Repetitions in Accumulated Random Samples In the latest (April 1994) issue of Cryptologia, I describe the development of a new technique for the statistical estimation of population. An example of such a problem would be estimating the number of different values or codes produced by a physically- random number generator. Background This work is an outgrowth of a sci.crypt discussion in early 1992 in which Nico de Vries promoted as "physically-random" a computer program which made use of variations between software and "IBM PC" hardware timing. It was difficult to know how one could determine the amount of "state" (and, thus, the limit of "randomness") in such a mechanism. Ross Anderson suggested measurement using the "birthday paradox." The Experimental Procedure The experimenter will obtain a value from the RNG and save it, repeating this for some fixed number of random samples, a "trial." Each new sample must be compared to all previous samples to see if there is a match or "exact double." (The birthday paradox does not apply to those statistical RNG's which are designed to produce a sequence without value repetition.) A trial contains enough samples if, on average, it produces a few doubles. About 2.5 or 3 Sqrt(N) samples will be needed, given population N, but N is the value we wish to measure. Producing and saving N samples may not be trivial. Exact Repetitions In a single trial, if we find two occurrences of some value, we have a single level-two "repetition"; this is an "exact" repetition count. But if we then find another occurrence of the same value, we have a level-three repetition and no level-two repetitions. Note how increased information (another occurrence) results in reduced effectiveness in the level-two measurement statistic. Expectations Classical binomial equations can predict the number of expected exact repetitions for a given population and number of samples. But these equations are extremely difficult to reverse for use in predicting population. Trying to use these equations with numerical root-finding techniques produces ambiguous results, as there are generally multiple roots. Equations which _estimate_ the probability of repetitions are well known, but it was not previously clear how accurate these would be, how they could be used effectively, what they would mean in random sampling distribution, or how they could be generalized to higher repetition levels. Augmented Repetitions I have found a new, simple, exact, and easily-reversed combinatoric relationship between population and a value which I call "augmented repetitions." An "augmented double" consists of the number of exact doubles (exactly two samples which have the same value), _plus_ contributions from exact triples, exact quads, etc. An exact triple may be seen as three doubles: There are three ways in which an exact triple may produce exact doubles. Therefore, for augmentation purposes, a triple should count as three augmented doubles. Similarly, a quad or exact 4-rep may be 4 seen as ( ) or 6 doubles, the number of combinations of four 2 things taken two at a time. When we do this, we find that simple equations predict the result _exactly_. Thus, the number of augmented repetitions at the kth level (k = 2 means doubles), given r exact repetitions at level i is: i n i ar = SUM ( ) r . k i=1 k i (This is equation 2.3 which very unfortunately was printed incorrectly in the article.) That is, we multiply the number of exact matches at each level by the effective number of matches each could produce at the lower level, and accumulate an overall sum. Augmented Doubles and Population Given population N, the expected number of augmented doubles Ead found in s samples is _exactly_: s (s - 1) Ead(N,s) = --------- . 2 N Given population N = 10,000 (so Sqrt(N) = 100), we can show the expected number of augmented doubles for various numbers of samples: s Ead ----------- 100 0.495 150 1.118 200 1.990 250 3.113 300 4.485 400 7.980 The formula implies, of course, that the population N is related to augmented doubles ad and samples s as: s (s - 1) Nad(s,ad) = --------- 2 ad which is the desired simple form for estimating population. Distribution A major issue in population measurement is the fact that the number of augmented doubles varies greatly over similar trials on the exact same population. Thus, a single trial is essentially meaningless for estimating population. Experiments indicate that various numbers of augmented doubles occur in Poisson distribution over different trials, a result which also has theoretical support. Therefore, we should develop an arithmetic mean or expected value which is the Poisson parameter. The Poisson distribution is asymmetric, and changes radically for different expected values. In general it will be necessary to perform tens or hundreds of separate trials to develop an accurate mean for population estimation. It is worthwhile to accumulate the entire distribution (rather than just a simple mean), and compare that shape with the ideal shape of the Poisson distribution for the given mean. The Poisson distribution also gives us a way to talk about the probability of finding augmented doubles Ead: -Ead Pd(N,s) = 1 - e . So, for population N = 10,000: s Ead Pd ------------------ 100 0.495 0.39 150 1.118 0.67 200 1.990 0.86 250 3.113 0.96 300 4.485 0.99 400 7.980 0.9997 It is often stated that the birthday paradox predicts a match with the sample size s = Sqrt(N), but this value is actually a little small; the expected number of augmented doubles for s = Sqrt(N) is 0.5 (and there are at least as many augmented doubles as exact doubles). Thus, if we want one augmented double on average, we need something like s = 1.5 Sqrt(N) samples. But it is beneficial to move the Poisson distribution toward a symmetric Normal curve, so 2.5 Sqrt(N) or 3 Sqrt(N) are reasonable experimental minimums. The Advance A new statistically-exact combinatoric relationship has been found between population and value repetition in random trials. Since previous well-known estimates could be used for rough estimates, it is not clear that this is a breakthrough in practice. However, the identification of an applicable _exact_ relationship, and its expected distribution in random trials, is important in that it clarifies what we can expect to see in actual use. The paper starts with simple probability, limits itself to algebra and statistics, discusses the existing techniques for exact and other repetitions, and develops general expressions for augmented repetitions. It also has tables of all possible trials for some tiny populations, whose resulting repetition values correspond to predictions exactly. The paper also has some nice graphs of experimental results on larger populations, which show a real Poisson distribution in action, and tables show the effect of estimating population from the experimental results. --- Terry Ritter ritter@io.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07124; 17 May 94 13:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07120; 17 May 94 13:21 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa12402; 17 May 94 13:21 EDT Received: by relay.tis.com id AA08055; Tue, 17 May 94 13:08:36 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma008051; Tue May 17 13:08:12 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06410; 17 May 94 13:00 EDT Received: from sol.tis.com by magellan.TIS.COM id aa06406; 17 May 94 12:56 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25919; Tue, 17 May 94 12:55:57 EDT Received: by relay.tis.com id AA07972; Tue, 17 May 94 12:56:34 EDT Received: from unknown(128.173.14.71) by relay via smap (V1.3mjr) id sma007970; Tue May 17 12:55:58 1994 Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id MAA19456; Tue, 17 May 1994 12:55:55 -0400 Message-Id: <199405171655.MAA19456@black-ice.cc.vt.edu> To: pem-dev@tis.com Subject: PEM 6.1 and MH 6.8 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 May 1994 12:55:55 +22306356 X-Orig-Sender: valdis@black-ice.cc.vt.edu Before I go and beat up on the code significantly, does anybody have patches for PEM to make it work with MH 6.8 as per the latest PEM-MIME RFC's? I hate re-inventing the wheel - I'll settle for "mostly done needs work" code. Valdis Kletnieks Computer Systems Engineer Virginia Tech   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07674; 17 May 94 13:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07670; 17 May 94 13:49 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa12929; 17 May 94 13:49 EDT Received: by relay.tis.com id AA08262; Tue, 17 May 94 13:37:39 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma008253; Tue May 17 13:37:06 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06498; 17 May 94 13:35 EDT Received: from sol.tis.com by magellan.TIS.COM id aa06494; 17 May 94 13:33 EDT Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64) id AA28381; Tue, 17 May 94 13:33:30 EDT Message-Id: <9405171733.AA28381@tis.com> To: Valdis.Kletnieks@vt.edu Cc: pem-dev@tis.com, feldman@tis.com Subject: Re: PEM 6.1 and MH 6.8 In-Reply-To: Your message of "Tue, 17 May 1994 12:55:55." <199405171655.MAA19456@black-ice.cc.vt.edu> Date: Tue, 17 May 94 13:33:04 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark S Feldman -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,06 MIC-Info: RSA-MD5,RSA,AKFXUWw7qdKhVzplRApR4z33jp+gn9iCQGiFjaMSqye YNpJCI0nhAMfT/Xl7e6Jo/V1f2fCtzDlBVoYXeH4ky1hxB6wX+2gp2BDbczlshMF uQCk4uPHAoYcMXlR/oWE2 > Before I go and beat up on the code significantly, does anybody have > patches for PEM to make it work with MH 6.8 as per the latest PEM-MIME > RFC's? I hate re-inventing the wheel - I'll settle for "mostly done > needs work" code. Hi, Valdis. An awfully large distribution for that question (pem-dev is the mailing list for all PEM developers and other interested parties). Feel free to use tispem-support or tispem-users if you want to narrow your audience. Beating up on poor, defenseless TIS/PEM 6.1 to make if follow the new standard probably isn't worth your time. We are working on a new, considerably changed version that will follow the new MIME-PEM integration standard and integrate with MH6.8 with only one source file changed (mhn.c). The new version is much more modular, with individual programs to create signatures, add encryption, generate certificate/CRL chains, verify signatures, remove encryption, and save certificate/CRL chains. This should make it much easier to integrate TIS/PEM with other user agents with little more than a bit of shell script glue. We will be beta-testing the new version as soon as we have all the necessary functionality. Shouldn't be too long. If anyone is interested in more info, beta-testing, or anything else TIS/PEM-related, send your mail to tispem-info@tis.com. Mark -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08703; 24 May 94 13:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08699; 24 May 94 13:06 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10707; 24 May 94 13:06 EDT Received: by relay.tis.com id AA12048; Tue, 24 May 94 12:48:03 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma012038; Tue May 24 12:47:16 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07553; 24 May 94 12:43 EDT Received: from sol.tis.com by magellan.TIS.COM id aa07549; 24 May 94 12:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26173; Tue, 24 May 94 12:38:13 EDT Received: by relay.tis.com id AA11971; Tue, 24 May 94 12:39:00 EDT Received: from pad-thai.aktis.com(192.231.148.11) by relay via smap (V1.3mjr) id sma011968; Tue May 24 12:38:34 1994 Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP id ; Tue, 24 May 1994 11:51:07 -0400 Received: by winkl.aktis.com (4.1/4.7) id AA10380; Tue, 24 May 94 11:51:05 EDT Message-Id: <9405241551.AA10380@winkl.aktis.com> To: pem-dev@tis.com Subject: Why have backward compatibility support for 1113 but not 1421? Date: Tue, 24 May 1994 11:51:05 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Linn This I-D announcement (based on the abstract) seems to offer a useful compatibility facility. Given that 1113 (previous version of PEM) is explicitly supported, is there a reason why 1421 can't also be supported in the same fashion? --jl ------- Forwarded Message Received: from IETF.nri.reston.VA.US by pad-thai.aktis.com (8.6.8/) with SMTP id ; Tue, 24 May 1994 11:30:38 -0400 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06152; 24 May 94 11:01 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06114; 24 May 94 11:01 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ;@IETF-Announce Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-borenstein-mailcap-00.txt, .ps Date: Tue, 24 May 94 11:01:28 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405241101.aa06114@IETF.CNRI.Reston.VA.US> - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A User Agent Configuration Mechanism For Multimedia Mail Format Information Author(s) : N. Borenstein Filename : draft-borenstein-mailcap-00.txt, .ps Pages : 16 Date : 05/23/1994 This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined by RFC's 821, 822, 934, 1049, 1113, and the Multipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system. This is a minor update to RFC 1524. Differences are detailed in Appendix E. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-borenstein-mailcap-00.txt". Or "get draft-borenstein-mailcap-00.ps". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-borenstein-mailcap-00.txt". Or "FILE /internet-drafts/draft-borenstein-mailcap-00.ps". For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19940523133959.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-borenstein-mailcap-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-borenstein-mailcap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940523133959.I-D@CNRI.Reston.VA.US> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03144; 25 May 94 10:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03132; 25 May 94 10:35 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa06779; 25 May 94 10:35 EDT Received: by relay.tis.com id AA17144; Wed, 25 May 94 10:15:08 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma017133; Wed May 25 10:14:34 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa13791; 25 May 94 10:08 EDT Received: from sol.tis.com by magellan.TIS.COM id aa13787; 25 May 94 10:04 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08504; Wed, 25 May 94 10:04:17 EDT Received: by relay.tis.com id AA17056; Wed, 25 May 94 10:05:05 EDT Received: from mwunix.mitre.org(128.29.154.1) by relay via smap (V1.3mjr) id sma017054; Wed May 25 10:04:07 1994 Return-Path: shireytm@smiley.mitre.org Received: from smiley.mitre.org.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id KAA18470 for ; Wed, 25 May 1994 10:03:53 -0400 Received: from Mac-mailer (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA03772; Wed, 25 May 94 10:03:38 EDT Message-Id: <9405251403.AA03772@smiley.mitre.org.sit> Date: Wed, 25 May 94 10:05:07 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" To: pem-dev@tis.com Subject: NII Privacy Principles Reply-To: shirey@mitre.org Tm-Text: Hard Disk:(1355)Privacy WG Draft Members of the pem WG of the IETF and members of the PSRG of the IRTF may be interested in submitting comments to the U.S. Government on the attached draft "Principles for Providing and Using Personal Information". Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA The following file is posted at the request of the Information Infrastructure Task Force's Privacy Working Group, chaired by Robert Veeder, Office of Management and Budget ************************************************************ Request for Comments on the draft Principles for Providing and Using Personal Information and their Commentary. The draft Principles for Providing and Using Personal Information and the associated Commentary are the first work product of the Information Infrastructure Task Force's Working Group on Privacy. They are intended to update the Code of Fair Information Practices that was developed in the early 1970s. While many of the Code's principles are still valid, the Code itself was developed in an era when paper records were the norm. The advent of the National Information Infrastructure has caused two things to change dramatically. No longer is information usage bound by the limitations of paper -- the seamless web of networks linking us to each other is creating an interactive environment in which all of the participants must share certain responsibilities. Moreover, non-governmental usage rivals the government's, and is largely unregulated. The following Principles were developed with the goal of providing guidance to all participants in this new interactive world. The Working Group recognizes that the Principles cannot apply uniformly to all sectors. They must be carefully adapted to specific circumstances. Nevertheless, the developers believe that the responsibilities and relationships the Principles describe are basic ones. As such, they are intended to assist legislators, regulators, and companies as they develop codes of practice. The Working Group invites public comment on the Principles and Commentary. We are especially interested in understanding how the Principles would work in this new interactive electronic environment and particularly in non- governmental settings. Are they workable? How, if at all, should they be changed? We hope that those who obtain the Principles for review and comment will also share them as widely as possible with others who might be interested in them. The Comment period will close on June 13, 1994. Comments should be sent to the Working Group on Privacy c/o the NII Secretariat, National Telecommunications and Information Administration, US Department of Commerce, Room 4892, Washington, D.C. 20230. The Principles and Commentary can be downloaded from the IITF Gopher/Bulletin Board System: 202-501- 1920. The IITF Gopher/Bulletin Board can be accessed through the Internet by pointing your Gopher Client to iitf.doc.gov or by telnet to iitf.doc.gov and login as gopher. Electronic comments may be sent to nii@ntia.doc.gov. ***************************************************************** DRAFT: April 21, 1994 Principles for Providing and Using Personal Information Preamble The United States is committed to building a National Information Infrastructure (NII) to meet the information needs of its citizens. This infrastructure, essentially created by advances in technology, is expanding the level of interactivity, enhancing communication, and allowing easier access to services. As a result, many more users are discovering new, previously unimagined uses for personal information. In this environment, we are challenged to develop new principles to guide participants in the NII in the fair use of personal information. Traditional fair information practices, developed in the age of paper records, must be adapted to this new environment where information and communications are sent and received over networks on which users have very different capabilities, objectives and perspectives. Specifically, new principles must acknowledge that all members of our society (government, industry, and individual citizens), share responsibility for ensuring the fair treatment of individuals in the use of personal information, whether in paper or electronic form. Moreover, the principles should recognize that the interactive nature of the NII will empower individuals to participate in protecting information about themselves. The new principles should also make it clear that this is an active responsibility requiring openness about the process, a commitment to fairness and accountability, and continued attention to security. Finally, principles must recognize the need to educate all participants about the new information infrastructure and how it will affect their lives. These "Principles for Providing and Using Personal Information" recognize the changing roles of government and industry in information collection and use. Thus they are intended to be equally applicable to public and private entities that collect and use personal information. However, these Principles are not intended to address all information uses and protection concerns for each segment of the economy or function of government. Rather, they should provide the framework from which specialized principles can be developed. I. General Principles for the National Information Infrastructure A. Information Privacy Principle 1. Individuals are entitled to a reasonable expectation of information privacy. B. Information Integrity Principles Participants in the NII rely upon the integrity of the information it contains. It is therefore the responsibility of all participants to ensure that integrity. In particular, participants in the NII should, to the extent reasonable: 1. Ensure that information is secure, using whatever means are appropriate; 2. Ensure that information is accurate, timely, complete, and relevant for the purpose for which it is given. II. Principle for Information Collectors (i.e. entities that collect personal information directly from the individual) A. Collection Principle Before individuals make a decision to provide personal information, they need to know how it is intended to be used, how it will be protected, and what will happen if they provide or withhold the information. Therefore, collectors of this information should: 1. Tell the individual why they are collecting the information, what they expect it will be used for, what steps they will take to protect its confidentiality and integrity, the consequences of providing or withholding information, and any rights of redress. III. Principles for Information Users (i.e. Information Collectors and entities that obtain, process, send or store personal information) A. Acquisition and Use Principles Users of personal information must recognize and respect the stake individuals have in the use of personal information. Therefore, users of personal information should: 1. Assess the impact on personal privacy of current or planned activities before obtaining or using personal information; 2. Obtain and keep only information that could reasonably be expected to support current or planned activities and use the information only for those or compatible purposes; 3. Assure that personal information is as accurate, timely, complete and relevant as necessary for the intended use; B. Protection Principle Users of personal information must take reasonable steps to prevent the information they have from being disclosed or altered improperly. Such users should: 1. Use appropriate managerial and technical controls to protect the confidentiality and integrity of personal information. C. Education Principle The full effect of the NII on both data use and personal privacy is not readily apparent, and individuals may not recognize how their lives can be affected by networked information. Therefore, information users should: 1. Educate themselves, their employees, and the public about how personal information is obtained, sent, stored and protected, and how these activities affect others. D. Fairness Principles Because information is used to make decisions that affect individuals, those decisions should be fair. Information users should, as appropriate: 1. Provide individuals a reasonable means to obtain, review, and correct their own information; 2. Inform individuals about any final actions taken against them and provide individuals with means to redress harm resulting from improper use of personal information; 3. Allow individuals to limit the use of their personal information if the intended use is incompatible with the original purpose for which it was collected, unless that use is authorized by law. IV. Principles for Individuals who Provide Personal Information A. Awareness Principles While information collectors have a responsibility to tell individuals why they want information about them, individuals also have a responsibility to understand the consequences of providing personal information to others. Therefore, individuals should obtain adequate, relevant information about: 1. Planned primary and secondary uses of the information; 2. Any efforts that will be made to protect the confidentiality and integrity of the information; 3. Consequences for the individual of providing or withholding information; 4. Any rights of redress the individual has if harmed by improper use of the information. B. Redress Principles Individuals should be protected from harm resulting from inaccurate or improperly used personal information. Therefore, individuals should, as appropriate: 1. Be given means to obtain their information and be provided opportunity to correct inaccurate information that could harm them; 2. Be informed of any final actions taken against them and what information was used as a basis for the decision; 3. Have a means of redress if harmed by an improper use of their personal information. ***************************************************************** Draft - April 21, 1994 PRINCIPLES FOR PROVIDING AND USING PERSONAL INFORMATION Commentary 1. With the initiation and expansion of the National Information Infrastructure (NII), the information age is clearly upon us. The ability to access, collect, store, analyze, and disseminate data at an acceptable cost has never been greater, and continuing advances in computer and telecommunications technologies, especially interactive applications, will serve to ensure that the amount of electronically stored personal information and transactional data will continue to grow at a healthy pace. 2. Cost is, of course, the overriding factor. Continually decreasing hardware, software and networking costs allow individuals and organizations to use data in ways that were previously, in a non-electronic world, cost-prohibitive. For example, if someone were interested in building a dossier on a citizen who had lived in four different states, that dossier could have been built "manually" by travelling from state to state (or hiring individuals in each state) to compile public records pertaining to that individual's birth, motor vehicle registration, driver's license, real property holdings, voting, etc. This would have required, however, filling out forms, paying fees, and perhaps waiting in long lines for record searches at various state and local office buildings. In short, it could be done, but it would have been a time-consuming and costly exercise; thus, it would not be done unless the reward for building this dossier were considerable. If the ultimate goal were to collate data on thousands of individuals,analytical processing costs would also be added to the mix. 3. Today, such a dossier can be built in a matter of minutes, at minimal cost, assuming all the needed information is on-line. Indeed, with the NII, the assumption is that large amounts of sensitive information will be on line, and can be accessed, perhaps without authority, by a large number of network users. With advanced networking, each link in the chain--access, collection, storage, and analysis--becomes a cost-effective method of using information, as does the ability to disseminate the final collated product to others. 4. Such networking offers considerable benefits. The NII holds forth the promise of greater public participation in society, advances in medical treatment and research, and quick verification of critical personal information (e.g., a gun purchaser's criminal record), just to name a few. There is, however, another issue: information privacy. To the extent that the ability to access, collect, store, analyze, and disseminate data has never been greater, the threat to personal information privacy has never been greater either. 5. The truth is, the NII will only achieve its full potential if individual privacy is properly protected. Absent such protections, individuals may be reluctant to participate in the NII, fearful that the risks to personal privacy outweigh the benefits. Citizens should not have to make that choice; rather, they should be assured that the use of personal information will be appropriately limited. The adoption of fair information principles is a critical first step in that direction. 6. Although Fair Information Principles currently exist, [see Advisory Committee on Automated Personal Data Systems, Records, Computers and the Rights of Citizens, (Washington, D.C., Department of Health, Education and Welfare, 1973)], it is clearly time that they be rewritten to address the issues raised by our new electronic environment, as well as cover paper records. The most major concerns: (1) It is no longer governments alone that collect and use large quantities of personal data; the private sector clearly rivals the government sector in information usage. As such, these new principles should apply to both the government and private sectors. (2) The NII will, if it fulfills its promise, be interactive; i.e., individuals about whom data relates (so-called "data subjects") will become increasingly active participants, creating volumes of communicative and transactional data. To the extent that individuals are providing information about themselves, they too should have obligations when using the NII. (3) The transport vehicles for this information (the networks) are vulnerable to abuse; thus, the reliability of the network itself becomes critical to the future success of the NII. (4) Traditional ethical rules, long-accepted when dealing with tangible objects, are not easily applied in the new electronic environment, and all NII participants must be educated in the proper use of the NII. Consider, for example, how an individual who would never trespass in the home of another might attempt to justify computer hacking as an intellectual exercise. Indeed, what constitutes a proper use of the NII or NII information might not be intuitively obvious. Whether a particular use is acceptable may depend on a host of factors including, but by no means limited to, the purpose for which the data was collected, whether the use is compatible with that purpose, and whether the use is specifically authorized by law. In such an environment, individuals need to be educated about the proper use of both the NII and the information it contains. 7. As ambitious as the task is, these Principles attempt to address these issues. That said, one must recognize the limitations inherent in any such principles. First, the Principles are not intended to have the force of law. Broad sweeping principles provide a framework for addressing fair information practices, but any specific regulatory implementation must be sector by sector. This is because each information sector (e.g., medical, financial, law enforcement, national security, research and statistics) has specific and unique needs that cannot be addressed by general principles. 8. Second, the Principles are only intended to apply domestically; although, to the best of our knowledge, these Principles are in accord with current international guidelines regarding personal privacy and data protection, and should not hinder the ongoing development of an international information infrastructure. 9. Third, the Principles only address information identifiable to a living individual. It makes little sense to restrict the use of information that does not relate to an identifiable living person, and to do so would unduly hamper researchers and others who use large quantities of data for generic statistical purposes. 10. Finally, although the Principles are written broadly, there will no doubt be times when their strict application would be inappropriate. For example, public safety could be undermined if law enforcement had to seek a data subject's approval before obtaining transactional records relevant to an ongoing criminal investigation on the theory that this use was incompatible with the purpose for which the records were originally created. To account for such cases, the words "as appropriate" or "to the extent reasonable" appear in the Principles. This is not to suggest, however, that the Principles need not be rigorously adhered to. To the contrary, the need to diverge from a given principle should be the exception, not the rule, and should only occur when there is an compelling reason. For in the end, it is adherence to these Principles that is critical to developing trust between data users and data subjects in the electronic information age. General Principles for the National Information Infrastructure 11. We begin with the three principles that apply to all NII participants: information collectors, information users, and individuals ("data subjects"). These three principles, relating to privacy and information integrity, provide the underpinnings for the successful implementation of the NII. They state clearly that individuals are entitled to a reasonable expectation of information privacy, and that efforts should be made to ensure that information is adequately protected and used appropriately. 12. If the NII is to be trusted, participants must have a reasonable expectation of privacy in personal information. Although individuals harbor subjective expectations of privacy, these must be honored only to the extent that society is prepared to recognize those subjective expectations as objectively reasonable. For example, an individual who posts an unencrypted personal message in an area of a bulletin board service that is provided for open, public messages cannot reasonably expect that his/her message will only be read by the individual listed in the salutation. Where a subjective expectation of privacy is made clear and is objectively reasonable, however, individuals should have their privacy respected. 13. NII participants must also be able to rely upon the integrity of the information contained in and transmitted through the NII. This will be the case only if the information is secure from improper disclosure and alteration, and if the information is accurate, timely, complete, and relevant for the purpose for which it is used. The responsibility of providing adequate security and reliable information falls properly on all participants in the NII. 14. We recognize, of course, that individuals and organizations do not always provide accurate and complete data when requested. Large data brokers, as well as privacy advocates, may intentionally provide false data as a method of monitoring data flow. For example, an individual who misspells his name slightly when dealing with one company and then receives mail, with the name similarly misspelled, from a second company, may now be aware that the first company has disseminated his name to others. We do not intend to suggest that any falsehood violates this principle. It would violate this principle, however, to provide false information to create some improper result (such as receiving illegitimate benefits or injuring another). Responsibilities of Original Collectors (i.e., Entities that Collect Information Directly from the Individual) of Personal Information 15. One of the most alluring features of the NII--easy access to and dissemination of information--also provides one of its most vexing problems: it is impossible for an individual to identify all the other individuals and organizations that may possess some personal information about himself or herself. At the risk of over-simplification, there are essentially two types of data users: those who collect information directly from the data subject, and those who do not. By necessity, the rules for these two groups must differ. 16. Those who collect information directly from the individual should inform the data subject (1) how the information collected will be used, (2) whether the information will remain confidential and be protected against improper access or alteration, and (3) the consequences of providing or withholding the requested information. The fulfilling of these obligations will ensure that individuals have a meaningful opportunity to exercise sound judgment in accordance with the Principles for Individuals Who Provide Personal Information. Juxtaposed, the Principles for Information Collectors and Principles for Individuals Who Provide Personal Information highlight the true interactive nature of the NII and the ideal symbiotic relationship between data collectors and data subjects. 17. It is simply impossible, of course, to impose these Information Collector obligations on entities that have no direct relationship with the individual. If every recipient of data were required to contact every individual on whom they receive data to provide some form of notice, the exchange of information would become unduly burdensome, and the benefits of the NII would be lost. On the other hand, information dispersion will be common on the NII and the following principles, designed to promote fair information use, should apply to all data users (including data collectors). Responsibilities of Information Users (i.e., Information Collectors and Entities that Obtain, Process, Send or Store Personal Information). 18. In an environment where individuals cannot realistically know where all personal information about them resides, and cannot account for each use of that information, it is simply impossible for individuals to ensure that personal information is used fairly. In some cases, even arguably adverse actions may go unnoticed, and therefore redress will not be available. For example, a company may decide not to include an individual in a mass mailing offer regarding a financial opportunity because an analysis of that individual's credit history suggests the individual is a bad credit risk. In such an environment, it is particularly important to ensure that data users use personal information in acceptable ways. The following principles, which apply to all users (including Collectors), fall into four categories: Acquisition and Use, Protection, Education, and Fairness. A. Acquisition and Use Principles 19. The benefit of information lies in its use, but such use may also have a negative effect on personal privacy. Additionally, that privacy, once lost, cannot always be entirely restored (consider, for example, the extent to which the inappropriate release of extremely embarrassing personal information is rectified by a public apology). To protect the information privacy of individuals adequately requires that the effect of data use be considered before personal information is obtained or used. In assessing this effect, data users will need to consider not just the effect of their action on the individual, but other factors (such as public opinion and market forces) which may be relevant in determining whether a particular data use is appropriate. 20. It may well be that the effect on personal privacy has been considered and it has been decided, appropriately, to obtain and use personal information for some purpose. In such cases, the data user should obtain only that information which could reasonably be expected to support current or planned activities. Although the cost of storing information continues to decrease, it is simply inappropriate to collect volumes of personal information because it may, in the future, prove to be of some unanticipated value. Moreover, once collected, personal information should only be used for those current or planned activities, or other compatible purposes. Incompatible uses not authorized by law should not be undertaken without consultation with the data subject. See, Fairness Principles, below. Finally, information should only be kept as long as necessary. It should be destroyed when appropriate. 21. Reasonable efforts should be made to ensure that information that will be relied upon is accurate, timely, complete, and relevant. It must be recognized that information which is accurate when collected may not be used for years, and the use of stale information may have unfair or inaccurate results. B. Protection Principle 22. In a networked environment, the risk of unauthorized access (i.e., loss of confidentiality) and unauthorized alteration (i.e., loss of data integrity) increases exponentially. Both insiders and outsiders may browse through information they have no right to see, or make hard-to-detect changes in data which will then be relied upon in making decisions that affect the individual. For example, our national health system expects to become an intentive user of the NII. A hospital in remote part of the country may pass x-rays through the NII for review by a renowned radiologist at a teaching hospital in another part of the country. For improving the quality of patient care, the benefits of such transfers are enormous. Yet, it is unlikely that such sensitive data will be passed through a system where it could be subject to unauthorized alteration and potential misuse? It is therefore incumbent on data users to protect the data commensurate with the harm that might occur if the data were improperly disclosed or altered. Additionally, the level of protection should be consistent with whatever the data subject was told if the data was collected directly from the individual. 23. It is not enough, however, to rely upon technical controls. Although technological safeguards can serve to protect data confidentiality and integrity, there is a human component that defies a solely technical solution. For example, insiders--those who are authorized to access and alter data--may not violate access controls when they improperly alter or delete data they are authorized to change. Therefore, the protections employed must be multi-faceted and include technical solutions, management solutions (e.g., creating an environment where fair information practices are the accepted norm), and educational solutions (e.g., providing data handlers with proper training). C. Education Principle 24. The Education Principle represents a significant addition to the traditional Fair Information Principles. The effect of the NII on both data use and personal privacy is by no means readily apparent. Most individuals are ignorant as to the amount of personal information already networked, and may not recognize how their lives can be affected by networked information. 25. It is important that information users appreciate how the NII affects information privacy, and that individuals understand the ways in which personal information can be used in this new environment. Thus, data users need to educate themselves, their own employees, and the public in general about how personal information is obtained, transmitted, used and stored, including what types of security measures are being used to protect data confidentiality and data integrity. D. Fairness Principles 26. If information can be used to adversely affect an individual, it is only fair that individual have a reasonable means to obtain, review, and correct personal information about himself or herself. Moreover, to the extent adverse actions are taken against the individual, the individual should be notified and have a means of redress. Equally important, the data collector should explain to the individual exactly what that means of redress is. Redress may take many forms (mediation, arbitration, civil suit, criminal prosecution) and be offered in different forums (federal, state, local) but cannot be imposed by these principles. 27. One of the most difficult issues is dealing with incompatible uses of previously collected information. An incompatible use is not necessarily a bad use; in fact, it may be of considerable benefit to either a data subject or society as a whole. A data subject may benefit, for example, when a customer mailing list is used to warn those customers that a product that they purchased is defective and may cause serious physical injury. Society as a whole may benefit when criminal conviction information is used for some purpose not originally contemplated such as screening candidates for child care positions or weapons purchases. Similarly, researchers and statisticians using previously collected information may determine the cause of a potentially fatal disease such as cancer. 28. On the other hand, without some limitation, information use may know no boundaries. Individuals who disclose information for one purpose may then be subjected to unintended and undesired consequences, and this will discourage them from disclosing personal information in the future. To ensure that this does not occur, information should only be used in ways compatible with the purposes for which it was collected and, before incompatible uses occur, they must either be authorized by law or the individual data subject should be notified so that he or she can opt out of such use. Rights and Responsibilities of Individuals who Provide Personal Information 29. As noted, the NII has significant implications for information use and personal privacy. In such an interactive environment, it is not sufficient for individuals to disclose personal information and then abdicate responsibility for the consequences; rather, individuals must take an active role in deciding whether to disclose personal information in the first instance. But if individuals are to be held responsible for making these choices, they must be empowered to make intelligent choices. This requires that they receive meaningful information on the intended uses of the information they provide, and the consequences for providing or withholding personal information. For these purposes, the "Principles for Individuals who Provide Personal Information" create two discrete categories that apply to individuals: Awareness and Redress. A. Awareness Principles 30. Awareness encompasses the notion that individuals should understand the ways in which personal information may be used, and the results that flow from such use. This will allow them to make intelligent choices regarding the disclosure of personal information. 31. Increasingly, individuals are being asked to surrender personal information about themselves. Sometimes the inquiry is straight-forward; for example, a bank may ask for personal information prior to processing a loan request. In this type of situation, it may be clear to the individual the purpose, or at least the primary purpose, for which the information is sought (e.g., processing the loan application). There may, however, be secondary uses which are not so immediately obvious, such as being put on a mailing list for a credit card solicitation. Indeed, there are no doubt many times when individuals decide to disclose information without being fully cognizant of the many ways in which that information may ultimately be used. 32. It is difficult, if not impossible, to anticipate all such uses. Individuals who pay for medical services with a charge card may not recognize that they are creating transactional records from which others may attempt to ascertain the current state of the individual's health. Equally problematic is that the assumptions drawn from such data may be false, and the individual may never know that the data has been used to reach some conclusion, or take some action, regarding his or her future. 33. It is impossible to formulate any set of principles that can cover comprehensively all possible uses of information. Nor would such an attempt be wise for, in fact, different people desire and expect different levels of privacy, and hold different concerns regarding the ultimate use of personal data. Ultimately, whether an individual chooses to disclose personal information, or create a transactional record, should depend upon the individual's own wishes unless, of course, the information is required by law. 34. The Awareness Principles recognize the importance of personal choice and cultivate an environment where these critical personal decisions can be made intelligently. For whatever the degree of personal interest in information privacy, it is critical that individuals receive enough facts to make rational choices regarding the disclosure of personal information. 35. First and foremost, an individual should know the intended primary and secondary uses of the information. Second, individuals should determine whether efforts will be made to assure data confidentiality and data integrity. In some cases, confidentiality may be required by law (e.g., tax records), but of equal concern may be the technical and managerial controls in place to protect the data. This principle does not mean that the individual should obtain a technical explanation regarding the security measures used to protect such data. Indeed, such technical explanations might be unwelcome, unwarranted and counterproductive (widespread disclosure of the technical measures used might actually expose vulnerabilities in a given system). But individuals should be told whether the information is intended to remain confidential and whether efforts will be made to preserve data integrity. Some individuals might choose not to disclose personal data if they knew that the data provided was freely obtainable by others, or might easily be altered. 36. Individuals should also be informed of the consequences of providing or withholding information. Data subjects should be told whether disclosing the requested information is mandatory (i.e., required by law) or voluntary, and the consequences that can flow from their decision. We recognize fully that even when disclosure is legally "voluntary," it may in fact be coerced (e.g., the refusal to "voluntarily" provide information may result in the denial of critical life-sustaining benefits). General principles cannot resolve such difficult issues but clearly, whatever the consequences, they should be clearly articulated. 37. Lastly, there will be times when individuals feel aggrieved by the improper use of personal information. If redress is available, individuals should be aware of that fact, and be informed as to how such redress can be obtained. B. Principle of Redress 38. Invariably, people will be harmed by the improper disclosure or improper use of personal information. It is therefore important to implement proactive measures to limit that harm, and reactive measures to provide relief when harm occurs. 39. To the extent inaccurate information can be used to harm individuals, it follows that individuals may wish to ensure that collected and stored personal information is in fact accurate and complete. For this reason, individuals should be able to obtain from data users, as appropriate, a copy of this personal information and have the opportunity to correct inaccurate information. This may allow them, proactively, to prevent anticipated harms. This principle is, however, limited in scope. Although, idealistically, all stored personal information should be accurate, the fact remains that inaccurate personal information does and will exist, and correcting inaccurate data cannot be done without cost. Pragmatically, it makes little or no sense to devote resources to correcting data that cannot be used to harm the individual, and therefore the opportunity to review personal information in order to correct data inaccuracies is limited to those cases where harm may occur. 40. When final actions are taken against individuals, they are entitled to notice. Absent notice, it may be impossible to seek available redress. Moreover, redress should be available for individuals who have been harmed by the improper use of information (including the use of inaccurate information). To ensure that individuals can take advantage of these redress mechanisms, the awareness principle, as noted above, requires that individuals be informed of the remedies available.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03327; 25 May 94 10:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03323; 25 May 94 10:52 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa07186; 25 May 94 10:52 EDT Received: by relay.tis.com id AA17342; Wed, 25 May 94 10:36:10 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa17326; Wed May 25 10:35:21 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa13932; 25 May 94 10:34 EDT Received: from sol.tis.com by magellan.TIS.COM id aa13928; 25 May 94 10:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10313; Wed, 25 May 94 10:31:19 EDT Received: by relay.tis.com id AA17301; Wed, 25 May 94 10:32:08 EDT Received: from mwunix.mitre.org(128.29.154.1) by relay via smap (V1.3mjr) id sma017299; Wed May 25 10:31:54 1994 Return-Path: shireytm@smiley.mitre.org Received: from smiley.mitre.org.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id KAA22450 for ; Wed, 25 May 1994 10:31:40 -0400 Received: from Mac-mailer (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA12286; Wed, 25 May 94 10:31:26 EDT Message-Id: <9405251431.AA12286@smiley.mitre.org.sit> Date: Wed, 25 May 94 10:32:54 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" To: pem-dev@tis.com Subject: CommerceNet Security Details? Reply-To: shirey@mitre.org The attached prospectus for CommerceNet includes the following: "Security mechanisms, including authentication and encryption, supported within applications, including Mosaic, using RSA public key cryptography. Public-key certification services will also be provided to CommerceNet members." Does anyone know any details of the proposed certification service? -Rob- --------------------------- From: services@commerce.net To: m23949@mwvm.mitre.org Subject: CommerceNet Information MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii CommerceNet, The First Large-Scale Market Trial of Electronic Commerce on the Internet Electronic Commerce on the Internet The following is a scenario from the not-too-distant future... Bill owns a small printed circuit board design company. His four-engineer design group is located ten miles outside of Boulder Creek in the Santa Cruz, California mountains. This morning, he checked his electronic mail box on the Internet and found a message from Irene, a design engineering manager at a large computer company in San Jose. She asked him to look at a sensitive request for quotation (RFQ) she had just posted. The RFQ was only open to three firms, and the message was encrypted such that only those three firms could read it. After analyzing the RFQ, Bill again used the Internet to check for current prices for the integrated circuits needed to build Irene's board. He accessed several online catalogs for IC manufacturers and made rough estimates of the cost of materials. With that finished, there was one thing left: a sticky design issue he didn't quite understand. He queried several engineers he knew at Irene's company via the Internet as well as an engineer in Amsterdam that he had met at COMDEX. The Amsterdam engineer referred him to an article in a back issue of an electronics association journal, which he promptly downloaded from the journal's Internet forum. After lunch, Bill prepared a quotation and sent it, encrypted, to Irene. The bid was not only secret it was also a legally binding offer. He mused about how his access to the Internet enabled his company to get jobs that used to go only to the big boys on the other side of the hill. His quotations were extremely accurate; he could always look up the most up-to-date prices and inventories via online catalogs. His designers were highly efficient; they accessed the latest applications and utilities from colleagues all over the world. And his cash flow was improved because he could send invoices and receive remittances via the Internet. Irene, at the other end of the "electronics food chain," often remarked about how using the Internet had helped her company's profitability. The publications group cut printing costs by putting their data sheets, catalogs and data books online. Her engineering group could take advantage of independent board designers; the other two firms bidding on her boards were in Oregon and Taiwan. The bottom line: for Bill and Irene, the Internet is easy to use and secure. It provides access to services and information sources around the globe. It is a commercial tool, as fundamental as a spreadsheet or telephone, that they both need to stay competitive. The Internet An outgrowth of a government research project (ARPANET) begun in the 1960's, the Internet was originally used by colleges, universities and the government for research and development purposes. It has since evolved to become "the network of networks," interconnecting not just government and education, but a large portion of the commercial business sector as well. Today, the Internet's 20 million-plus users are connected by over 20,000 public and private networks reaching more than 140 countries around the world. And, the Internet is growing at an average rate of 10% a month. Businesses run 63% of these networks. They use the Internet mostly for electronic mail; in January 1994, IBM sent and received over 580,000 e-mail messages with individuals outside the company. To be sure, this convenient communication via Internet makes doing business easier; however, e-mail only scratches the surface of the possibilities of electronic commerce. Until now, the Internet has been a difficult place to do serious business. Some of the reasons include: the lack of standard and easy-to-use interfaces; the lack of secure means for transmitting sensitive data or identifying users; and the lack of indexing and search mechanisms that make it easy for users to find information. A recent development, the World Wide Web (WWW, or "the Web"), and a program called NCSA Mosaic, have made the Internet much easier to use and navigate. Groups of Internet users developed WWW as a general-purpose architecture for information retrieval. It consists of disparate files and directories spread throughout the Internet and is connected with hypertext links in a client-server architecture. These links allow a user to connect directly and transparently to computers that have needed information. NCSA Mosaic is the most popular hypermedia browser for accessing the World Wide Web. Developed by the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign, NCSA Mosaic is available free for UNIX*, Macintosh( and Windows* platforms, and supports full multimedia presentations (audio, video, text and graphics) as well as electronic forms. Some call Mosaic the Internet's "killer application" because of its sophisticated hyperlink capabilities: users can point and click on designated words and graphics in a document and transparently, via the WWW, connect with the computer on which the referenced information is stored. For example, a user with a Mosaic interface sees a reference to "Vatican Library." The user clicks on the name and connects automatically to the Vatican Library server via WWW. Before the WWW, the user had to type a myriad of arcane, idiosyncratic Internet addresses and commands. What is CommerceNet? CommerceNet is a consortium of Northern California technology-oriented companies and organizations whose goal is to create an electronic marketplace where companies transact business spontaneously over the Internet. CommerceNet will stimulate the growth of a communications infrastructure that will be easy-to-use, oriented for commercial use, and ready to expand rapidly. The net results for businesses in this region will be lower operating costs and a faster dissemination of technological advancements and their practical applications. The CommerceNet marketplace will support all business services that normally depend on paper-based transactions. Buyers will browse multimedia catalogs, solicit bids, and place orders. Sellers will respond to bids, schedule production, and coordinate deliveries. A wide array of value-added information services will spring up to bring buyers and sellers together. These services will include specialized directories, broker and referral services, vendor certification and credit reporting, network notaries and repositories, and financial and transportation services. CommerceNet will provide an integrated set of services from a single source, including: % Affordable, high quality Internet connectivity (through BARRNet) using a variety of options including T1, 56K, Frame Relay and ISDN. Many are now available; others will roll out during the remainder of 1994. % Easy access to user interface and networking software and registration forms for CommerceNet access. % Software tools for providers that make it easy to put up interactive CommerceNet services on any Internet host. % Simple point-and-click access to all CommerceNet services, including a variety of specialized directories, using an enhanced version of Mosaic. % Security mechanisms, including authentication and encryption, supported within applications, including Mosaic, using RSA public key cryptography. Public-key certification services will also be provided to CommerceNet members. CommerceNet eliminates data and transmission security issues because there are no remote logins and passwords are not exchanged in the clear. In addition, authentication, authorization, and data encryption applications made available on CommerceNet will let buyers and sellers safely exchange sensitive information such as credit card numbers and bid amounts, sign legally enforceable contracts, maintain audit trails, and make or receive network payments through cooperating financial institutions. The CommerceNet Consortium The CommerceNet Consortium is a non-profit corporation operating under a matching funds grant from the United States government's Technology Reinvestment Project (TRP). CommerceNet was awarded $6 million over three years, which is to be matched by contributions from member companies and state and local agencies. The TRP was created as part of President Clinton's program to revitalize the economy, create jobs, and help American industry remain competitive and on the cutting edge of technology. The TRP is sponsored by the Defense Department's Advanced Research Projects Agency (ARPA), the Department of Commerce's National Institute of Standards and Technology (NIST), the National Science Foundation (NSF), the Department of Energy (DOE) and the National Aeronautics and Space Administration (NASA). CommerceNet was proposed to the TRP council in 1993 by the core development team of the CommerceNet Consortium, which includes BARRNet, Enterprise Integration Technologies (EIT) and Stanford University's Center for Information Technology (CIT). On November 24, 1993, the government announced the award to CommerceNet in the second round of TRP funding for 55 projects (out of 2,850 submitted) that promote the commercial use of defense-related technology. CommerceNet is one of those programs. The Consortium is comprised of the core development team, sponsoring organizations, and industry participants. The core team is responsible for developing and operating CommerceNet and securing its funding, and oversees the day-to-day management of CommerceNet. Sponsoring organizations include Smart Valley Inc., Joint Venture:Silicon Valley Network and the State of California's Office of Strategic Technology. Initial CommerceNet participants include leading companies from Silicon Valley's semiconductor, electronics and computer industries, and their customers and suppliers around the world. Under the CommerceNet structure, the Consortium's Board of Directors subcontracts program management and technical development to the principal performing organizations: BARRNet, EIT and Stanford CIT. The Board meets quarterly and works closely with an Industry Steering Committee that represents the interests of the Consortium membership. The Industry Steering Committee sets membership criteria and provides priorities for development requirements. CommerceNet's executive director, Cathy J. Medich, reports to the organization's Board of Directors. Allan M. Schiffman, Chief Technical Officer of EIT, serves as CommerceNet's Principal Architect. How CommerceNet Will Benefit Business CommerceNet's founders and supporters believe that the new electronic marketplace will dramatically improve the productivity and competitiveness of its participants. It will provide access to an online global marketplace with millions of customers and thousands of products and services; and, it will provide participating companies with new, more cost- and time-efficient means for working with customers, suppliers and development partners. CommerceNet will enable companies to: % Shorten procurement cycles through online catalogs, ordering and payment; % Cut costs on both stock and manufactured parts through competitive bidding; % Shrink development cycles and accelerate time-to-market through collaborative engineering and product implementation. Participants are likely to use CommerceNet to provide online catalogs and product literature to customers, suppliers, distributors, and partners, and to conduct online ordering and product data exchange. CommerceNet users will also be able to request and provide competitive solicitations and bids, engage in inter-company collaborative engineering, and access and integrate product vendors and service suppliers for faster product time to market. For information technology providers, CommerceNet is an opportunity to build Northern California's information infrastructure, to influence the development of Internet technology and standards for electronic commerce, and to participate in joint marketing efforts. How CommerceNet Works The CommerceNet server, the starting point for participation in CommerceNet, provides users access to all CommerceNet-related information and applications via a Mosaic interface as a part of the World Wide Web. CommerceNet information is also available by automated response to electronic mail requests. The CommerceNet server stores information on the CommerceNet organization; directories to participants, value-added third-party services and Internet resources; member registration and communications; and tutorials and examples. The server is also the distribution center for CommerceNet software. CommerceNet participants create "home pages," which are located on each participating company's WWW server, and which serve as each company's "virtual storefront" on the network. A participant's home page will typically provide an overview of the organization as well as point-and-click access to product or service information, access to online catalogs, product order forms and so on. This company home page would be reached by users either by name, or more likely via a 'reference' link from the CommerceNet server's directory pages, or even via a document reference elsewhere in the World Wide Web perhaps from an online magazine article. The Future of CommerceNet The CommerceNet core team employs state-of-the-art Internet technology and intends to stay on the leading edge of development through an aggressive R&D program at Stanford CIT. Future services being explored include shopping agents that can search through catalogs and negotiate deals; collaboration tools for distributed work teams that support both real-time interaction and videomail; natural language search and retrieval techniques for large, distributed information bases; and format translation services that enable engineering organizations to exchange product data even when they adhere to different standards. In five years, organizers hope to achieve the following goals: % 3,000 organizations using CommerceNet routinely for business transactions and technical collaboration; % 300 organizations providing information services through CommerceNet; % 30 local, state and federal projects in Northern California using CommerceNet as a common infrastructure; % 30 profitable local businesses providing the CommerceNet infrastructure with computer products, telecommunication services, software and consulting. CommerceNet organizers believe that the majority of companies and organizations in the U.S. may conduct business via the Internet in five years. CommerceNet is a step towards a de facto National Information Infrastructure capable of linking up with other electronic commerce projects in places such as Boston, Austin, and the University of Illinois. Potentially, a CommerceNet-like infrastructure could support other national efforts in the areas of education, health care and digital libraries. Key Participants in CommerceNet BARRNet Founded in 1987 as an original component of the National Science Foundation Network (NSFNET), BARRNet provides the information infrastructure supporting research, education and economic development in Northern California. As a founding partner of CommerceNet, BARRNet offers its suite of premier Internet services as the basis for CommerceNet connectivity. BARRNet has points of presence spanning Northern California, with additional POPs planned for Southern California and Nevada in the coming months. The organization's list of offerings includes: A complete package of Internet connectivity services, from 14.4 kbps IP connections, either dialup or dedicated line, to 56 kbps and high-speed T1 connections; a low-cost, standalone Iserver* System; and the High Security Firewall System. With BARRNet connectivity to the Internet, subscribers make full use of the expanding suite of TCP/IP protocols, including telnet, ftp, nntp, http (Mosaic), gopher, wais, archie, POP mail, irc, ntp, etc. Enterprise Integration Technologies (EIT) Enterprise Integration Technologies is an R&D and consulting company specializing in software and services that help companies do business on the Internet. EIT develops information infrastructures for a broad range of programs in agile manufacturing, concurrent engineering, and electronic commerce. EIT is CommerceNet's principal architect, technology supplier, and integrator. The company will also provide program management and services to end users. Stanford Center for Information Technology (CIT) CIT specializes in the development and deployment of information infrastructure technology. CIT is operated by Stanford University in association with affiliated organizations from industry, government and academia. CIT serves as a venue for pre-competitive collaboration among its affiliates as well as a nursery for new commercial ventures based on CIT's technology. CIT focuses its efforts on Silicon Valley to ensure the continued technological leadership of the region. The work of CIT is vertically integrated with a significant amount of effort devoted to each of the following areas: (1) research on the principles underlying information technology; (2) development of practical technology based on this research; and (3) demonstrations and testbeds to illustrate and assess the strength of this technology. For information regarding how to participate in CommerceNet, call or send e-mail to: CommerceNet 459 Hamilton Avenue Palo Alto, Calif. 94301 Phone: (415) 617-8790 Fax: (415) 617-1516 E-Mail: info@commerce.net URL (e.g., WWW) Address: http://www.commerce.net/ ------------------------------------------------------------------------ ----- If you wish to obtain more information, please complete all entries on the CommerceNet Information Form and mail the completed form to more-info@commerce.net. Name:__________________________________________________________________ Title:__________________________________________________________________ _ Company:_______________________________________________________________ Address:________________________________________________________________ _______________________________________________________________________ Phone:________________________________ Fax:__________________________________ Email Address:________________________________________________________________ Type of organization: Business__ Non-Profit__ Organization__ Line of business:_______________________________________________________________ _ Company Size:___________________________________________________________________ ============================================================= CommerceNet Info CN Interest: Provider__ User__ Press__ Consultant__ INet VAS__ Interested in CommerceNet membership? No__ Yes__ ============================================================= Internet Connectivity Current INet Access: None__ UNIX Dial-up__ Individ Wkstn/PC__ Single Host__ LAN: Ethernet__ LocalTalk__ Novell__ Other______________ Current INet use: None__ Email__ FTP__ WWW__ Interested in new or upgraded Internet connectivity? No__ Yes__ Interested in individual dial-up access Internet connectivity? No__ Yes__ Interested in dedicated Internet connectivity? No__ Yes___ (For a group of users or to provide a CommerceNet information service) Interested in approximately what class of service: Slow__ Average__ Premium__ 14.4K 56K T1 (@ approximate cost: <$250/mo <$500/mo <$1200/mo) Interested in managing own Internet services administration? No__ Yes__   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07658; 26 May 94 13:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07654; 26 May 94 13:29 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa11591; 26 May 94 13:29 EDT Received: by relay.tis.com id AA27835; Thu, 26 May 94 13:14:01 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma027824; Thu May 26 13:13:20 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa17947; 26 May 94 13:08 EDT Received: from sol.tis.com by magellan.TIS.COM id aa17943; 26 May 94 13:05 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03540; Thu, 26 May 94 13:05:03 EDT Received: by relay.tis.com id AA27722; Thu, 26 May 94 13:05:53 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma027713; Thu May 26 13:05:47 1994 Received: from wotan.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA28613; Thu, 26 May 1994 13:06:55 -0400 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DE43C00-00000001@wotan.gte.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jueneman@gte.com Date: Thu, 26 May 94 14:04:41 -6 Subject: DUNS numbers and the NII To: pem-dev@tis.com Reply-To: Jueneman@gte.com Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Given some of the discussion that has taken place regarding alternatives to the civil naming structure, and Rob Shirey's recent posting of information regarding commerceNet, the following discussion between Michael Baum and myself might be interesting to pem-dev readers: Bob Robert R. Jueneman GTE Laboratories 40 Sylvan Road Waltham, MA 02254 617/466-2820 Jueneman@GTE.COM ---------- Forwarded message ---------- Date: Mon, 23 May 94 16:09:21 -5 From:Jueneman@GTE.COM To: Baum@im.com Cc: h.kesterson@smtplink.az05.bull.com, 71623.1226@compuserve.com Subject: Re: numbering >Bob, > >What do you think of the President's Task Force's decision to recommend >the use of DUNS NUMBERS as the critical numbering device for NII purposes? > >Regards, > >Michael > >text follows: > >TRADING PARTNER REGISTRATION >Requirement: We must establish a government-wide data base >of trading partner information to eliminate duplicate supplier >registration files throughout the Federal community. We must also >have a unique supplier numbering scheme. >Analysis: By collecting information once early in the registration >phase, future EDI-based business activities can be focused on the >purchase transaction. The trading partner registration data base >covers basic business information, business capabilities, and >financial information. We want to link that information to past >performance and to existing supply, procurement, and financial >files by using a unique supplier numbering scheme. To that end, >we conducted an extensive evaluation of government and private- >sector numbering schemes: the Contractor Establishment Code >(CEC), Data Universal Numbering System (DUNSb) number, >taxpayer identifying number (TIN), Commercial and Government >Entity (CAGE) code, and other commercial codes. Of these >numbering schemes, the DUNSb number was the best: it is a widely >used domestic and international commercial identification number >for electronic commerce (54 U.S. industries and the United Nations >use DUNSb for EDI); it is supported by a worldwide data collection >program that focuses on maintaining an accurate data base of >unique identification numbers (35 million numbers assigned >worldwide); it is a validated numbering scheme ($300 million spent >annually to validate its accuracy as contrasted to TIN, which is not >validated); it has worldwide support for numbering and positive >identification of entities; its numbers are assigned to the lowest >possible organizational business level (far lower than the TIN, >which is a higher organizational control number); and it is issued at >no cost to the Federal government or trading partner. Furthermore, >the DUNSb number can be crosswalked against the other existing >numbering schemes and can serve as a pointer to the data stored >according to another numbering system. > > >[sorry about the translation DINSb = DUN's] !!! Michael, Interestingly enough, at last week's NADF meeting we spent a fair amount of time discussing DUNS numbers and other alternatives to the "normal" X.500 civil naming structure. I'm going to post your question to the NADF, and will forward any replies to you. Certainly such groups as GEIS and Advantis might have some useful input. I am assuming that you are asking my opinion regarding the naming issues, and perhaps implications re the certificate hierarchy. >From the standpoint of an X.500 distributed directory and X.509 public key certificates, the following thoughts occur to me: 1. If the DUNS number is to be useful, we would need a reverse directory that would point from the DUNS number to the more traditional civil organizational name. Conducting a search operation over 35 million organizations located in a number of different countries and spread over multiple directory service providers would certainly be inefficient. The DUNS number is certainly globally unambiguous, so it would satisfy the criteria for a Distinguished Name, but it would also result in a very flat hierarchy that might not be the most efficient from a search strategy. 2. At present, the two primary name attributes that are defined under the C=US are Organization, and StateOrProvince. The NADF adds a third attribute, ADDMD, (ADministration Directory Management Domain) as a way of uniquely qualifiying names that otherwise might not be unique, using the name of the ADDMD in order to avoid the need to coordinate such names across different domains. 3. Ideally, an international EDI number registration authority would be rooted at the ITU level, not under any particular country, as I understand that the TEDIS project is attempting to do. This would take a lot of diplomatic negotiation, I should think, particular if a commercial enterprise such as Dun and Bradstreet were to be granted a world-wide monoply for this function. 4. In the best of all possible worlds (from a purely technical directory standpoint), it would be convenient if the worldwide EDI registration authority were to operate as a monopoly ADDMD. This way every other Directory Service Agent (DSA) would know where to go to find the information. Otherwise, and especially if the DUNS information were spread across multiple countries, it would be necessary to list all 35 million names in the public name space (provided through a batch (at present) process called the CAN to all other ADDMDs). However, competitive forces may require that the information be spread across all providers, which makes the process much more difficult. 5. My assumption would be that the DUNS number would essentially be used as an alias or pointer to the traditional civil naming structure entry, where all of the rest of the payload concerning that entity would be found. However, this would give rise to a certain issue of trust. Clearly the normal Directory Service Provider (DSP) is not going to accept any responsibility for the correctness of the DUNS number and the various implications that go with it (unless Dun and Bradstreet becomes at DSP). So the alias between the DUNS number and the civl name entry cannot necessarily be trusted, at least to the same extent that the D&B entry could be. Of course, the primary entry could and should contain a cross reference to the DUNS number, and the two should be compared, but still the DSP should probably not be trusted in any meaningful sense. 6. Instead, it would appear highly desirable for Dun and Bradstreet (or any other registration authority) to become a Certification Authority, and to issue X.509 certificates binding the name of a company to their DUNS number, at least. Whether they would want to include other information (such as annual sales, bond rating, etc.) in that certificate remains to be seen. Whether this kind of a certificate should be a standard identity certificate or whether it comes closer to an authorization certificate is not quite clear to me. 7. If D&B chooses not to step up the challenge of being a CA, a second best alternative for either a public or private commercial CA would be to request the DUNS number from any listing company, and then seek confirmation of the accuracy of that listing from D&B directly. This is obviously a Trusted Third Party or notarial function. 8. It appears that D&B spends a fair amount of money confirming the accuracy of their database. (At one time I operated a small free-lance photography business, and I used to get periodic questionaires from them.) This at least addresses part of the problem of transfer or cessation of activities. 9. Your question specifically addressed the NII, which seems to mean different things to different people. Some seem to think that it involves a lot of cable, and presumably includes entertainment video. Others may view it as an expanded EDI network. My view is that it is likely to be pretty close to the current Internet in its scope and use, and therefore the use of a DUNS number for general purpose addressing and/or certificate issuance would probably NOT be suitable. Robert R. Jueneman GTE Laboratories 40 Sylvan Road Waltham, MA 02254 617/466-2820 Jueneman@GTE.COM   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07698; 26 May 94 13:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07693; 26 May 94 13:30 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa11642; 26 May 94 13:30 EDT Received: by relay.tis.com id AA27838; Thu, 26 May 94 13:14:01 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smab27824; Thu May 26 13:13:25 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa17955; 26 May 94 13:08 EDT Received: from sol.tis.com by magellan.TIS.COM id aa17951; 26 May 94 13:07 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03711; Thu, 26 May 94 13:07:05 EDT Received: by relay.tis.com id AA27748; Thu, 26 May 94 13:07:55 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma027743; Thu May 26 13:07:21 1994 Received: from wotan.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA28716; Thu, 26 May 1994 13:08:34 -0400 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DE43C5D-00000001@wotan.gte.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jueneman@gte.com Date: Thu, 26 May 94 14:06:18 -6 Subject: Re: DUNS numbers and the NII To: pem-dev@tis.com Reply-To: Jueneman@gte.com Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII [To: Michael Baum] Richard Ankney responded to my comments re DUNS numbers as follows: >> I read the NII announcement as referring only to EDI traffic, not to all NII >> applications. In this case the DUNS number or equivalent is in each >> interchange. I agree. >> X.435 suggests something like what Bob has proposed: alias entries with >> names like C=US; O=D&B; EN= for each trading partner. Other >> registration agencies would have different organizational components in >> the DN. These aliases would point to the normal civil naming entry. I have a bit of a problem with this, if Rich is accurately quoting X.435. The problem is not with the syntax, which would work, but with the semantics. I believe in the use of strong typing, so that an attribute means one and only one thing at all times. The X.435 usage would conflict with that principle, because the "organization" is not the organization whose EN (enterprise number?) is being referred to (which would be the normal implication of an attribute associated with an organization). Instead, D&B is acting as a name registration authority in this case, and ought to be designated as such. In pseudoEnglish/ASN.1, the alias which points to the real organization should be something like C=US, nameRegistrationAuthority=Dun & Bradstreet, EN=. An even better solution, I think, would be to have TEDIS or EDIFACT or D&B or whomever register as a name registration authority directly under the ITU root, i.e., under the joint_ISO_CCITT (2) arc, _before_ country. In this case, as in the case of international organizations such as the UN, no Country would be specified. The numeric OID would make it clear who was acting as the naming authroity. I understand that there may be philosophical objections to creating a monoply position for D&B (or recognizing a de facto monoply). There may be other enterprise numbers that might be more applicable in other countries, for example. In this case, the international EDI organization would simply register alternate attributes, one for DUNS, perhaps one for CAGE numbers, Taxpayer ID numbers, etc. (I'm not commenting on whether the DIUNS number is or is not the best choice for a universal EDI enterprise number, merely iscussing technical alternatives.) From a technical, X.500 directory perspective, disregarding competitive issues involving multiple directory service providers within the US and internationally, it would seem that the best of all worlds solution would be for this international EDI body to provide and operate (or subcontract to some other organization) an X.500 Administrative Directory Management Domain (ADDMD). Efforts are underway within the NADF, the Internet, and the Paradise project in Europe to bring all of these disjoint directory systems under the umbrella of one common naming and knowledge tree, probably making use of knowledge and naming link sharing tools such as the NADF's CAN tools, so that all ADDMDs and any Private Directory Management Domains that care to can have common access to all of the informataon in the public name space. Such an international EDI organization could reasonably sidestep some of the nasty antitrust problems that might otherwise exist, and substantially simpliy the name lookup process. Without a natural monoply service provider, every ADDMD in the world would have to know all of the DUNS numbers for every enterprise in the world -- an untenable situation. The alternative might be to segregate the listing of DUNS numbers to the country in which the company or organization is located or incorporated, but that would defeat much of the purpose of having a directory. It would be necessary to interrogate an ADDMD in every country, from Afganistan to Zimbabwe, in order to find a given number. (I'm assuming that there is no internal structure to a DUNS number that might facilitate this search, but I don't know that for a fact.) On the other hand, if the international EDI body operated an ADDMD, then every DSA in the world would know who it was and how to get to it, and could interrogate it to determine the "real" (civil naming structure" name of the organization, and which ADDMD or PRDMD contained further information about that organization. In other words, the international organization should maintain only a limited pointer to the rest of the information about an organization. The information itself could be stored at any DSA anywhere in the world. For ease of access and replication for reliability, the international organization should probably operate several ADDMDs, perhaps one or two in each country, that would be synchronized, but this is a relatively small point. However, even if this international EDI body were to operate the ADDMD, I would not trust this alias mechanism too far. There are simply too many things that could go wrong. Instead, the applicable Name Registration Authority (e.g., Dun and Bradstreet) should issue a X.509 digitally signed certificate that binds that organization name to the DUNS number. At present, this is technically a little awkward, because X.509 does not provide the ability to digitally sign an attribute that is not a Distinguished Name. Including the DUNS number within an organization's Distinguished Name could be done, especially if it is merely in the X.509 certificate, but it would be a little tacky. Fortunately, there is considerable pressure to modify X.509 to include such a capability, and I believe that Warwick Ford of BNR is introducing such a position in the X.500 standards committee. Otherwise, an approach similar to PKCS #6 could be used, where the certificate is signed, an appendage added, and the whole thing signed again. Or an alternative to X.509 could be introduced for this purpose, perhaps along the lines of X9.30. At the last ABA workshop, Frank Sudia and I discussed the difference between an identity certificate and a capabilities or authorization certificate, and what the root of either of those certificate hierarchies should be from the standpoint of trust. Suppose the D&B were to issue a certificate binding an organization name to a DUNS number. Should they also bind the public key for that organization, a la X.509? This requires some more thought, but my initial reaction would be to say that no, it probably shouldn't bind the public key, becasue of the differences in the trust model for key authentication vs. corporate numbering and identification. The difference between these various trust models hasn't quite jelled yet, but let me try to advance an argument. To my mind, the most important single construct to come out of the PEM work was the notion of a Policy Certification Authority. Unfortunately, we still don't have very many, if any, good examples, but the intent would be that the PCA would operate in such a manner as to enforce (though contracts and auditing) a certain standard of behavior with respect to the lower-level CAs and individuals who are ultimately certified by that PCA. The PCA should establish minimum requirements for key length and other technical and security parameters, and should set certain standards for the identification of individuals. Based on such a standard, users operating within the domain of trust would know what to expect with respect to an individual's identity bona fides. However, it is highly unlikely that the PCA would accept any liability for the _actions_ of such an individual or company. The PCA is almost surely not going to establish the credit worthiness of an individual or company, nor should they. that is more properly the function of someone issuing an authorization certificate, e.g., MasterCard. They _do_ provide a degree of deep pockets liaiblity for individuals, and they try hard to collect. But they also charge a percentage of each transaction, so they can afford to take the risk and the (hopefully modest) rate of fraud and bad debt. It is pretty clear that D&B is _not_ in that position. They publish infomation that is presumably relevant to someone making a decision about a firm's financial strength, but they don't underwrite that firm's obligations or share any liability (other than what might arise from misrepresentations or malpractice on thier part, either deliberate or accidental, presumably.) So a D&B certificate is neither fish nor fowl -- it isn't an identity certificate (although it could be), because D&B presumably doesn't have a contract with the various CAs to act as a PCA and it isn't vouching for the binding between the organization name and the orgnization's public key. And it probaby isn't a capability or authorization certificate either, because D&B doesn't authorize anybody to do anything (although they could, perhaps by running some form of an EDI clearinghouse function.) Maybe I've gone off the deep end here, and if so I trust that someone will throw me a rope. I've been assuming that the DUNS number was really _critical_, and that therefore it needed to be very tightly bound to an organization. But DUNS listings are probably widely available in other forms, and if the Name Registration Authority were to make a mistake in the alias that points to the real organization's entries, the mistake would be caught rather quickly. (It would be a good idea for the organization to include the DUNS number in its own entry, just to allow a cross check.) So although issuing a certificate t tie the organization's Distinguished name to the DUNS number would be a nice idea, it may not be really necessary. >> If one assumes C=US, the rest of the name can be constructed can be >> constructed from the interchange, i.e. Sender ID (DUNS #) and Sender ID >> Qualifier (registration agency). >> >> Regards, >> Rich >> >> I think that assuming C=US is a major problem. Even if D&B is a US corporation, you don't want everyone in the world having to come to their DSA to dereference this information. On the other hand, the NADF takes the position that you list organizations where they are most likely to be found, not necessarily where they reside. With that interpretation, D&B could list their Name Registration Authority under whatever countries they wish, and could provide this service if they wanted to. Depending on the final decisions that may be made regarding Accounting and Settlements for X.500 information flow, they could even make money from this service as an information provider. Bob Robert R. Jueneman GTE Laboratories 40 Sylvan Road Waltham, MA 02254 617/466-2820 Jueneman@GTE.COM   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10053; 26 May 94 14:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10049; 26 May 94 14:47 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa13572; 26 May 94 14:47 EDT Received: by relay.tis.com id AA28850; Thu, 26 May 94 14:37:18 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa28803; Thu May 26 14:36:22 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa18211; 26 May 94 14:20 EDT Received: from sol.tis.com by magellan.TIS.COM id aa18207; 26 May 94 14:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17232; Thu, 26 May 94 14:18:22 EDT Received: by relay.tis.com id AA28595; Thu, 26 May 94 14:19:11 EDT Received: from sprintf.merit.edu(35.1.1.62) by relay via smap (V1.3mjr) id sma028580; Thu May 26 14:18:35 1994 Received: from sprint.com by sprintf.merit.edu (8.6.5/merit-1.0) id OAA16953; Thu, 26 May 1994 14:18:16 -0400 Received: from sprintf.merit.edu by sprintf.merit.edu with SMTP (PP); Thu, 26 May 1994 14:17:59 -0400 Received: from atlas.arc.nasa.gov by sprintf.merit.edu (8.6.5/merit-1.0) id OAA16824; Thu, 26 May 1994 14:17:06 -0400 Message-Id: <199405261817.OAA16824@sprintf.merit.edu> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Thu, 26 May 1994 11:17:03 -0700 To: a <"/RFC-822=Jueneman(a)gte.com/PRMD=internet/ADMD=TELEMAIL/C=US/"@sprint.com> Cc: a <"/RFC-822=pem-dev(a)tis.com/PRMD=internet/ADMD=TELEMAIL/C=US/"@sprint.com> Subject: Re: DUNS numbers and the NII In-Reply-To: Your message of "Thu, 26 May 1994 14:06:18." <2DE43C5D-00000001@wotan.gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 May 1994 11:17:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams >From: Jueneman@gte.com >Subject: Re: DUNS numbers and the NII >Date: Thu, 26 May 94 14:06:18 -6 >Maybe I've gone off the deep end here, and if so I trust that someone will >throw me a rope. I've been assuming that the DUNS number was really _critical_, >and that therefore it needed to be very tightly bound to an organization. But Type=1 Name=EDIRA - Contact Addresses Path=1/Academic, Research and CEC Projects/EDI Registration Authority - CEC Project/EDIRA - Contact Addresses Host=concise.level-7.co.uk Port=70 URL: gopher://concise.level-7.co.uk:70/11/Academic, Research and CEC Projects/EDI Registration Authority - CEC Project/EDIRA - Contact Addresses (Alternatively, you may use the Concise X.500 directory service to search for the same documents.) Contains info on CAs for EDI, the CA interfaces, mechanisms for issuing smartcards etc. and the operational principles for the "UN" registration infrastructure for EDI identifiers. I have not see any intention of the project to delegate name registration to the internet NICs etc, though they do do reuse significantly the existing EDI infrastructure for registration performed by Dun and Bradstreet, Visa, etc. It includes a study of the operational UK Naming Authority, and the method of mapping EDI identifiers to Distinguished Names. Its probably not legitimate to discuss this other than as an FYI in the IETF stds process. (Though I think the OSI moratorium imposed by the Internet IESG was lifted recently, so Ill take advice)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10115; 26 May 94 14:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10109; 26 May 94 14:50 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa13673; 26 May 94 14:50 EDT Received: by relay.tis.com id AA28813; Thu, 26 May 94 14:36:18 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma028803; Thu May 26 14:36:11 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa18177; 26 May 94 14:18 EDT Received: from sol.tis.com by magellan.TIS.COM id aa18173; 26 May 94 14:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16183; Thu, 26 May 94 14:15:20 EDT Received: by relay.tis.com id AA28565; Thu, 26 May 94 14:16:10 EDT Received: from indial1.io.com(198.4.60.11) by relay via smap (V1.3mjr) id sma028548; Thu May 26 14:15:10 1994 Received: from localhost by indial1.io.com (8.6.5/1.00) id NAA23872; Thu, 26 May 1994 13:12:31 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Terry Ritter Message-Id: <199405261812.NAA23872@indial1.io.com> Subject: Toward Axiomatic Fenced DES (long!) To: pem-dev@tis.com Date: Thu, 26 May 1994 13:12:27 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 41850 Ritter Software Engineering 2609 Choctaw Trail Austin, Texas 78745 (512) 892-0494, ritter@io.com Toward Axiomatic Fenced DES Terry Ritter May 26, 1994 Introduction This article continues the development of a block cipher which I have been calling "Fenced DES." This unique construct uses the U.S. Data Encryption Standard (DES) as a component in a strength- enhanced cipher. Even though DES is slow and is now becoming vulnerable to advancing attack technology, DES is also well-known and trusted, and industry would be grateful to continue to use it if only it were stronger. The time has come to replace ordinary DES. One alternative is the complete certification of a totally new cipher at tremendous cost in both treasure and time. Another alternative is "triple- DES," at three times the computation of ordinary DES. But if a strength-enhancing construction can be found which is sufficiently clear and elegant, we may hope for a "derivative certification," based only assumptions about the strength of DES itself. In this article I start the process of proving some things about the Fenced DES cipher. In particular, I prove that the resulting cipher is invertible and has the avalanche property, two admittedly modest characteristics, but ones we do associate with a good block cipher. I claim that the construct is certainly guaranteed to be no weaker than DES. I also argue--with some theoretical support-- that the construct should be expected to be much stronger, at least 120 bits. In other words, it should be "strong enough" for the next couple of decades. The system of definitions, proofs and arguments which takes up the major part of this article is by no means finished, and is known to be casual and inconsistent in places. (Some of these problems could be fixed by expanding the mathematical base, which I avoid for now.) In spite of this, I believe it to be an interesting approach, even if it is an approach to which others are probably far better suited than myself. Therefore, let us just agree to accept it for what it is, and see how close it gets to what we need. The definitions apply to this particular construction. Those generally familiar with combinatorics might start with section 7, "Block Mixing Transforms." Fenced DES Here is the current 4x Fenced DES construct: S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------DES------ ------DES------ ------DES------ ------DES------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S Each "S" represents a separately-shuffled and independent 8-bit substitution table (which also implies the presence of a keyed cryptographic RNG to shuffle the tables). We have 32 input substitutions and 32 output substitutions, for an overall block size of 256 bits. This is only 32 bytes, which should be much smaller than the typical message. Trailing 2x and 1x blocks would reduce data expansion to only that needed by DES itself. Each "---DES---" represents an ordinary 64-bit-block DES operation. Each "---mix---" represents the mixing of the covered data blocks using "block mixing transform" technology. There are two levels of mixing on each side of the DES operations: The innermost levels each have two mixings which combine two 64-bit blocks; the outermost levels each have just a single mixing which combines two 128-bit blocks, a substantial mixing operation. This entire construct requires about 4.8 times the computation to cipher 4 times the data. In contrast, triple-DES would of course need 12 times the computation to cipher 4 times the data. The Proofs 1. SETS ======= 1.1 DEFINITION: A SET is a collection of objects in which any object either is or is not a part of the set. A set S can be described by a list of the elements in the set, viz. S = { a1, a2, ..., an }. 1.2 DEFINITION: The SIZE OF SET S is the number of elements in S, and is denoted |S|. 2. CODES ======== 2.1 DEFINITION: A CODE is a string of symbols in which the symbol in each position is taken from some common set S. When S consists of numeric values, a code can be seen as a polynomial with coefficients in S. 2.2 DEFINITION: An N-POSITION code is a code which has n positions for symbols, and can be denoted by S**n. 2.3 DEFINITION: A BINARY code is a code in which the common set is the set {0,1}. 2.4 DEFINITION: An N-BIT binary code is a binary code with n positions and can be denoted by {0,1}**n or by S**n with S = {0,1}. 2.5 THEOREM: (Size of code.) There are |S|**n distinct code values in an n-position code. (Proof: Each position in a code string can be any possible symbol, there are |S| possible symbols and n positions in each code string, so there are |S|**n possible code values of length n.) 2.6 THEOREM: (No special positions.) Taken over all possible code values, each string position has exactly the same number of occurrences of each symbol. (Proof: Each position in a code string can be any possible symbol. For any particular combination of symbols in other positions, in the selected position each possible symbol occurs once. So for every possible combination of symbols in other positions, in the selected position each possible symbol occurs the same number of times.) 2.7 THEOREM: (Position difference counts.) The number of n-position code values which differ in exactly m positions is (n) m (m) * (|S|-1) . (n) (Proof: There are (m) combinations of m positions out of n possible positions, and in any particular combination of m positions each position can take on |S|-1 other symbols producing (|S|-1)**m other code values for each combination.) 2.8 EXAMPLE: The number of 8-bit binary codes which differ in m bits is: distance count 0 1 1 8 2 28 3 56 4 70 5 56 6 28 7 8 8 1 --- 256 = 2**8 (Comment: There are 256 8-bit binary code values, and 255 values which differ in at least one position from any particular code value.) 2.9 THEOREM: (Average distance and distribution.) The expected number of elements which differ between two n-position code values is n * (1 - 1/|S|), and the distribution is binomial. (Proof: Assume the number of code differences is the binomial (n) m n-m probability of a difference B(m;n,p) = (m) p q , where where p = 1 - 1/|S| and q = 1-p, times the total number of n code values (1/q) : (n) m (n) m n-m -n (m) * (|S|-1) = (m) p q q (n) m = (m) (p / (1-p)) which is correct, so the expected number of different elements is the binomial expectation np.) 2.10 EXAMPLE: The expected number of elements which differ between two 8-bit binary code values is: 8 * (1 - 0.5) = 4. 2.11 EXAMPLE: The probability of having two 8-bit binary code values which differ in exactly two elements is: (8) 2 6 (2) (0.5) (0.5) = 0.109 = 28 / 256. 2.12 EXAMPLE: The expected number of elements which differ between two 64-bit binary code values is: 64 * (1 - 0.5) = 32. 2.13 EXAMPLE: The probability of getting a 64-bit binary code value which differs in exactly m bits from some other value is: difference probability 16 0.000026 28 0.061 29 0.075 30 0.088 31 0.096 32 0.099 (Comment: The 9 difference values 28..36 account for about 74 percent of all possible difference counts, even though they are only about 14 percent of all 65 possibilities.) 3. DISCRETE FUNCTIONS ===================== 3.1 DEFINITION: A DISCRETE FUNCTION takes an input code value to an output code value for a finite number of input code values. 3.2 DEFINITION: A RANDOM discrete function allows each output code value to be selected independently for each possible input condition. 3.3 THEOREM: (Number of random functions.) There are 2**2n possible random functions with an n-bit binary input code and an n-bit binary output code. (Proof: An n-bit binary code can make 2**n possible selections, each of which can be 2**n possible values, and (2**n)*(2**n) = 2**2n.) 4. SUBSTITUTION =============== 4.1 DEFINITION: A SUBSTITUTION is a mapping from input values or positions to output values. (Comment: A SUBSTITUTION can be seen as an indexable vector of substitute values. A SUBSTITUTION can also be seen as a "codebook" with an entry for every possible input code, and storage for each corresponding output code. A SUBSTITUTION can also be seen as an "arbitrary" discrete function, since any possible discrete function can be described by using a separate output code for each possible input condition. A SUBSTITUTION can also be seen as the relation joining substitute values with the position of each value.) 4.2 DEFINITION: SIMPLE substitution is the operation of using a substitution table or codebook to "encode" a string of input values by replacing each value in the string with its associated substitute value. (Comment: If the substitution is invertible, we can use an inverse substitution to "decode" the resulting encoded values and recover the original values.) 4.3 THEOREM: (Unique substitute values.) An invertible substitution can contain any particular output code at most once. (Proof: Suppose not: Then two different values into a substitution will produce the same output value. But that output value can inverse-substitute to only one inverse value, making the other input value unreachable, which contradicts invertibility, so this is false.) 4.4 THEOREM: (Number of invertible substitutions.) There are (2**n)! possible invertible substitutions for an n-bit binary input code. (Proof: The first substitution element can be any one of 2**n elements, the second element can be any except the first element, or (2**n)-1 elements, the third can be any except the first and second, for (2**n)-2 elements, and so on.) 4.5 THEOREM: (Guaranteed change propagation.) A change of even one input bit to an invertible substitution is guaranteed to produce a change in at least one output bit from the substitution. (Proof: Each input bit can select between two different input code values, which will select two different output code values, since an invertible substitution contains no duplicate values. Since any two different codes must be different in at least one bit, any input bit-change will produce at least one output bit-change.) 4.6 DEFINITION: A COMPLETE substitution contains every value of an n-position code, for some n. 4.7 THEOREM: (Probable change propagation.) Any change whatsoever to the input value to a complete invertible substitution is likely to change about half the bits in the output value. (Proof: Changing the input value selects among all remaining output code values. If the output is considered to be binary bits, we expect about half those bits to change (2.9).) 4.8 DEFINITION: AVALANCHE is a statistical property of a discrete function in which any change whatsoever on the input is expected to produce a change in about half the bits in the output value. 4.9 THEOREM: (Avalanche is automatic.) Avalanche is an inherent property of complete invertible substitution. (Proof: See 4.5, 4.7, and 2.9.) 4.10 THEOREM: (No special input bits.) Each input bit to an invertible substitution has exactly the same power to produce the same expected change in output bits. (Proof: Consider any possible change to any possible input value: from all possible input values any particular bit-change will produce all possible input values. Thus, any possible bit-change must produce the same overall expectation.) 4.11 THEOREM: (No special output bits.) Each output bit from a complete invertible substitution has exactly the same change expectation as any other output bit. (Proof: See 2.6.) 4.12 THEOREM: (Not a random function.) An invertible substitution cannot be a random function. (Proof: Suppose a value is selected for placement somewhere in a substitution. Since an invertible substitution cannot allow another occurrence of that same value, other values cannot be selected independently.) 4.13 DEFINITION: In a KEYED substitution the substitute element values have been permuted or re-arranged as a function of some key value or function. 4.14 THEOREM: (Reconstruction requires information linking output values to input values.) An unknown invertible substitution cannot be resolved without simultaneous information about both the input value or position and the output value. (Proof: To the extent that a particular substitution can be said to have an identity, that identity is the relation between substitute values and their position. This relation is both necessary and sufficient to define the substitution.) 5. BIT MIXERS ============= 5.1 DEFINITION: A BIT-MIXER combines multiple input bits such that each output value is defined by each and every input bit. 5.2 THEOREM: An invertible substitution is a bit-mixer. (Proof: Each and every input bit can select between two different input code values. Any input value change into an invertible substitution must necessarily select a different output value. Thus, the output value, and every bit in the output value, inherently depends upon each and every bit of the input value.) 6. BLOCK CIPHERS ================ 6.1 DEFINITION: A CIPHER is a keyed invertible translation from a plaintext element to a ciphertext element. 6.2 THEOREM: A CIPHER is a keyed invertible substitution. (Proof: For "translation" read "substitution.") 6.3 DEFINITION: A BLOCK cipher is a cipher in which the size of the code element is prohibitively large to be exhaustively explored. 6.4 THEOREM: (Not a random function.) No static block cipher can be a random function. (Proof: A cipher must be an invertible function, and no invertible function can have elements which are independent.) 6.5 ASSERTION: (Just a large substitution.) There is no property of a block cipher which is not ideally modelled by a substitution table of appropriate size containing a key-selected permutation of the possible output values. (Invertibility argument: A permutation of the possible output values is just a re-arrangement of values, without duplication. As long as there are no duplicate output values, the substitution is invertible.) (Avalanche argument: Avalanche is an expected property of an invertible substitution (4.9).) 7. BLOCK MIXING TRANSFORMS ========================= 7.1 DEFINITION: A BLOCK MIXING TRANSFORM is a mapping from multiple input code values to the same number of output code values, in which: 1. (Invertible.) The mapping is invertible. (Every possible input will imply a different output, and every possible output will imply a different input.) 2. (Each Output a Function of All Inputs.) Every output code value is a function of all input code values. 3. (Changes Propagate to All Outputs.) Any change to any one of the input code values will change all of the output code values. 4. (Balance and Input Independence.) Stepping any input through all possible values (with the other inputs held fixed) will step every output through all possible values. 7.2 ASSERTION: (We have a finite field.) Mod-2 polynomials modulo some irreducible polynomial p generate a finite field. (Comment: Proofs can use algebra.) 7.3 THEOREM: (Example block mixing transform.) The equations X = 3A + 2B = A + 2(A + B) Y = 2A + 3B = B + 2(A + B) and the inverse A = X + 2(X + Y) B = Y + 2(X + Y) mod 2 and mod p, where p is some mod 2 irreducible polynomial, represent a block mixing transform. (Inverse Proof: assume true, thus A = A + 2(A + B) + 2(A + 2(A + B) + B + 2(A + B)) = A + 2(A + B) + 2(A + B) = A and B = B + 2(A + B) + 2(A + 2(A + B) + B + 2(A + B)) = B + 2(A + B) + 2(A + B) = B which are both correct, so the inverse does exist for any polynomials X and Y.) (Function Proof: the equations for output code X includes both input code values A and B, so X is a function of both input codes. Y reasons similarly.) (Change Propagation Proof: First consider one term of one output block equation: Suppose some change C is added to A: X = 3A + 2B (mod 2, mod p) X' = 3(A+C) + 2B X' = 3A + 3C + 2B dX = X' - X = 3C So, for any non-zero change, X has changed. Similar reasoning covers the other term, and the other equation.) (Balance Proof: Suppose not. Assuming A is fixed, then there must be two different values, B and B', which produce the same X: X = 3A + 2B = 3A + 2B' so X + 3A = 2B = 2B' which implies that B = B' a contradiction. Fixing B or working on the other block reason similarly.) 7.4 THEOREM: It is easy to manipulate both input blocks to a block mixing transform so as to fix one of the output blocks at a constant value. (Proof: Just inverse-transform the desired output blocks.) 7.5 ASSERTION: A block cipher can be used as a block mixing transform. (Method: Just divide the input block and output block into smaller "sub-blocks.") (Inverse Proof: A block cipher is invertible (6.1) and (6.3).) (Function Proof: To the extent that the block cipher can be considered an invertible substitution, each output bit is a function of each input bit (4.5), so each sub-block result is certainly a function of all sub-block input values.) (Change Propagation Argument: In a statistical sense, assuming substantial sub-blocks, each sub-block is extremely likely to change for any input change whatsoever (2.9).) (Balance Argument: In a statistical sense, over all possible inputs and all possible keys, any output value is equally likely, so any set of input changes is likely to produce a statistically-balanced result.) 8. 1X FENCED DES STRUCTURES ========================= 8.1 DEFINITION: A 1X INPUT-FENCED DES STRUCTURE is a 64-bit- wide construct consisting of eight keyed invertible byte- substitutions feeding a single DES ciphering: S S S S S S S S ------DES------ 8.2 THEOREM: Any data change whatsoever into a 1x input-fenced DES structure will produce a different result, and is expected to change about half of the output bits. (Proof: Every bit in the input block enters some small substitution which selects a keyed or arbitrary value from its set of output codes. Any input-change into an invertible substitution is is guaranteed to produce a change to at least one output bit (4.5). We model the DES ciphering as a large invertible substitution (6.5), and so expect that any change to the input will select a different output code value, which is likely to change about half of the output bits (4.7).) 8.3 DEFINITION: A 1X OUTPUT-FENCED DES STRUCTURE is a 64-bit-wide construct consisting of a single DES ciphering and eight keyed invertible byte-substitutions on the output: ------DES------ S S S S S S S S 8.4 THEOREM: Any data change whatsoever into a 1x output-fenced DES structure is expected to change about half of the output bits. (Proof: We model the DES ciphering as a large invertible substitution (6.5) and expect that any change to the input will change about half the bits in the output value (4.7). Since every possible DES result may occur, there are no special bits or bit subsets (2.6). Each of the output substitutions samples a bit subset in which about half of the bits are expected to change. Any change into an output substitution will select a different output code value, thus changing about half of the output bits (4.7) in every output substitution, and, thus, the overall output.) (Comment: One time in 255 there is no change to an output substitution, which is exactly what is required for an even output distribution. ) 8.5 DEFINITION: A 1X FENCED DES CIPHER is a 64-bit-wide construct consisting of eight keyed invertible byte-substitutions on the input, a single DES ciphering, and eight keyed invertible byte-substitutions on the output: S S S S S S S S ------DES------ S S S S S S S S 8.6 THEOREM: (Avalanche.) In 1x Fenced DES, any change of even a single bit in the large input block can be expected to change about half the bits in the large output block. (Proof: See 8.2 and 8.4.) 8.7 THEOREM: (Invertibility.) A 1x Fenced DES cipher is invertible. (Proof: From the construction of 1x Fenced DES, the small input substitutions are invertible, as are the small output substitutions. DES is assumed to be invertible. Since all elements in sequence from input to output are separately invertible, the sequential combination of these elements must also be invertible.) 9. 2X FENCED DES STRUCTURES ============================ 9.1 DEFINITION: A 2X INPUT-FENCED DES STRUCTURE is a 128-bit- wide construct consisting of 16 keyed invertible byte-substitutions feeding a block mixing transform, which feeds two DES cipherings: S S S S S S S S S S S S S S S S --------------mix-------------- ------DES------ ------DES------ 9.2 THEOREM: Any data change whatsoever into a 2x input-fenced DES structure will produce a different result, and is expected to change about half of the output bits. (Proof: Any change into an invertible substitution is guaranteed to produce a change to at least one output bit (4.5). Any change to either input block of a two-block block mixing transform is guaranteed to produce a change to both output blocks (7.1.3). We model the DES cipherings as large invertible substitutions (6.5) and so expect that any change to the input will select a different output code value, which is likely to change about half of the output bits (4.7).) 9.3 DEFINITION: A 2X OUTPUT-FENCED DES STRUCTURE is a 128-bit- wide construct consisting of two DES cipherings which feed a two- block block mixing transform, which feeds 16 keyed invertible byte- substitutions. ------DES------ ------DES------ --------------mix-------------- S S S S S S S S S S S S S S S S 9.4 THEOREM: Any data change whatsoever into a 2x output-fenced DES structure is expected to change about half of the output bits. (Proof: We model the DES cipherings as large invertible substitutions (6.5) and expect that any change to their inputs will select a different output value from all possible output values (4.5). Since any DES result is possible, any value is possible from both block mixing transform outputs (7.1.4), so we expect about half of the output bits to change (4.7). Since any block mixing result value is possible, there are no special bits (2.6), and each of the output substitutions samples a bit subset in which about half of the bits are expected to change. Any change into an output substitution will select a different output code value, thus changing about half of the output bits (4.7) in every output substitution, and, thus, the overall output.) 9.5 DEFINITION: A 2X FENCED DES STRUCTURE is a 128-bit-wide construct consisting of 16 keyed invertible byte-substitutions which feed a block mixing transform which feeds two DES cipherings which feed another two-block block mixing transform, which feeds another 16 keyed invertible byte-substitutions: S S S S S S S S S S S S S S S S --------------mix-------------- ------DES------ ------DES------ --------------mix-------------- S S S S S S S S S S S S S S S S 9.6 THEOREM: (Avalanche.) In a 2x Fenced DES cipher, any change of even a single bit in the large input block can be expected to change about half the bits in the large output block. (Proof: See 9.2 and 9.4.) 9.7 THEOREM: (Invertibility.) A 2x Fenced DES cipher is invertible. (Proof: From the construction of 2x Fenced DES, the small input substitutions are invertible, as are the small output substitutions. The block mixing transform is invertible (7.1.1). DES is assumed to be invertible. Since all elements in sequence from input to output are separately invertible, the sequential combination of these elements must also be invertible.) 10. 4X FENCED DES STRUCTURES ============================ 10.1 DEFINITION: A 4X FENCED DES CIPHER is a 256-bit-wide construct consisting of 32 keyed invertible byte-substitutions feeding a block mixing transform with two 128-bit blocks, which then feeds two block mixing transforms each with two 64-bit blocks, which feed four DES cipherings. The DES results feed two block mixing transforms each with two 64-bit blocks, which feed a block mixing transform with 128-bit blocks, which feeds 32 more keyed invertible byte-substitutions. S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------DES------ ------DES------ ------DES------ ------DES------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S 10.2 THEOREM: (Every input bit affects every DES ciphering.) In 4x Fenced DES, every bit in the large input block will affect at least one bit of the input to each of the DES cipherings. (Proof: Every bit in the large block enters some small substitution. Any input-change into a substitution is guaranteed to produce a change to at least one output bit (4.5). Any change into either side of the first-level block mixing transform is guaranteed to change both sides of the output (7.1.3), so some change is guaranteed to be present in the input of both next-level block mixing transforms. Again, any change anywhere on those inputs is guaranteed to be present in both sides of both outputs, which are the inputs to each DES ciphering.) 10.3 THEOREM: (Each output bit is affected by every DES ciphering.) In 4x Fenced DES, any data change whatsoever into any of the four DES cipherings is expected to change about half of the output bits. (Proof: We model the DES cipherings as large invertible substitutions (6.5) and expect that any change to their inputs will select a different output value from all possible output values (4.5). Since any DES result is possible, any value is possible on both outputs of the first-level output block mixing transform (7.1.4). Any possible block mixing transform result can be produced by some BMT input, so any possible value can occur as the input to the second-level output block mixing transform. With any possible BMT input, every output will occur, so there are no special bits (2.6), and each of the output substitutions samples a bit subset in which about half of the bits are expected to change. Any change into an output substitution will select a different output code value, thus changing about half of the output bits (4.7) in every substitution, and, thus, the overall output.) 10.4 THEOREM: (Avalanche.) In 4x Fenced DES, any change of even a single bit in the large input block can be expected to change about half the bits in the large output block. (Proof: See 10.2 and 10.3.) 10.5 THEOREM: (Invertibility.) 4x Fenced DES is invertible. (Proof: From the construction of 4x Fenced DES, the small input substitutions are invertible, as are the small output substitutions. The block mixing transform is invertible (7.3.1). DES is assumed to be invertible. Since all elements in sequence from input to output are separately invertible, the sequential combination of these elements must also be invertible.) 11. 4X FENCED DES STRENGTH CHARACTERISTICS ========================================== 11.1 ASSERTION: (DES cipherings cannot be separated.) In 4x Fenced DES, it is not possible to isolate and work on a single DES ciphering unless the small input substitutions have first been resolved. (Argument: In order to key-search a single DES ciphering, it is necessary to develop the input and output value for that particular ciphering. The large input and output blocks are known, but the values sent to the internal cipherings are hidden by the input and output substitutions.) 11.2 ASSERTION: (Input substitutions cannot be separated.) In 4x Fenced DES, it is not possible to isolate and work on any one small input substitution unless all four of the DES keys and at least one element in each of the 32 small output substitutions have first been resolved. (Argument: Even though their input values are known, resolving the content of the small input substitutions requires some information about their output values. Since these values flow through the internal DES cipherings, if DES is effective, these values cannot be known without the DES keys. Further, each of the DES keys is required, since all of the DES cipherings combined produce the known output. There can be no statistical effects which identify particular values from the input substitutions, because any change of any number of bits whatsoever affects the large output block similarly. There can be no statistical effects which isolate individual input substitutions because each input substitution has the same effect on the large output block. Any change whatsoever from any input substitution changes about half the bits in the output block, making statistical issues about the content of the substitutions completely irrelevant.) 11.3 ASSERTION: (Output substitutions cannot be separated.) In 4x Fenced DES, it is not possible to isolate and work on any one small output substitution unless all four of the DES keys and at least one element in each of the 32 small input substitutions have first been resolved. (Argument: Even though their output values are known, resolving the content of the small output substitutions requires some information about their input values. Since the input values flow from the internal DES cipherings, if DES is effective, these values cannot be known without the DES keys. Further, each of the DES keys is required, since each DES ciphering affects all of the output substitutions. There can be no statistical effects which identify particular input values to the output substitutions, because any change of any number of bits whatsoever affects the output from the substitution similarly. There can be no statistical effects which isolate individual output substitutions, because each of their input values come from the the output of the DES cipherings, and these values are "random like." So there can be no statistic to use for attack.) 12. FENCED DES EXPECTED STRENGTH ================================ 12.1 THEOREM: (Absolute minimum strength of 1x Fenced DES.) Assuming a known-plaintext attack, further assuming that all the input and output substitutions are known, if DES has a strength of 56 bits, the 1x Fenced DES construct has a keyspace of 56 bits. (Proof: All data flows through each layer; if the input and output substitutions are known, they do not confuse the data, but they also do not undo whatever confusion DES provides.) 12.2 ASSERTION: (Expected strength of the substitution layers in 1x Fenced DES.) Assuming a known-plaintext attack, and further assuming that the DES key is known, the 1x Fenced DES construct has a keyspace exceeding 64 bits. (Argument: The overall input is known, so the small input substitution _positions_ are all known; the uncertainty lies wholly in the _values_ at those positions. There are 256 possible values at the known position for each of eight input substitutions, for 256**8, or 2**64 possibilities. (A 63-bit expectation.) The uncertainty in the output substitution positions is the same, but the input and output substitutions are not independent: Since the DES key is known, defining the input substitutions implies what the output substitutions must be (or vise versa), so only one substitution level contributes to the keyspace. When working on the small input substitutions, the individual substitutions are independent: If even one of the input substitute values is wrong, we expect that half of the DES result bits will be wrong, which will imply wrong positions for most output substitutions. The process is similar if we choose to work on the output substitutions instead. A 64-bit keysearch is guaranteed to identify one element in each of the eight small input substitutions (for example). Then, assuming infinite known-plaintext, we just look for data blocks which are the same as the solved block in seven of the eight bytes. For each possible value of the eighth byte we can easily try each of the 254, 253,..., 2 remaining values (which will implicitly define many of the output substitutions) at almost no cost beyond holding and finding appropriate messages. With only a limited amount of known-plaintext there will be fewer if any messages which differ in just one byte, few if any quick byte searches, and many more-substantial searches until the input substitutions are filled in.) (Comment: DES with a known key is an example of a block mixing transform with absolutely no strength at all by itself, which nevertheless adds strength through bit mixing.) 12.3 ASSERTION: (Expected strength of 1x Fenced DES.) Assuming a known-plaintext attack, the 1x Fenced DES construct has a keyspace exceeding 120 bits. (Argument: When the DES key is known, the strength is 64 bits; the unknown DES key adds 56 bits more, for a total of 120 bits. (This is 2**64 times the complexity of DES.) It is not possible to separate the substitution layers from the cipher layer and so work on either independently, because the data flows through both. In addition, each DES operation is a function of every input bit (8.2) and each output bit is a function of every DES output (8.4), so individual DES operations cannot be isolated by particular input or output bits. A 120-bit keysearch will identify the DES key and one element in each of the eight small substitutions, and then we need to fill out the rest of each substitution as above.) 12.4 THEOREM: (Absolute minimum strength of 4x Fenced DES.) Assuming a known-plaintext attack, further assuming that all the input and output substitutions are known, if DES has a strength of 56 bits, the 4x Fenced DES construct has a keyspace exceeding 56 bits. (Proof: All data flows through each layer. The information content of the data is 256 bits; to recover that data, all four DES operations must be solved. Even if we assume that some aspect of the construction allows the DES operations to be solved separately, the resulting strength is still somewhat more than a single DES cipher.) 12.5 ASSERTION: (Expected strength of separated 4x Fenced DES.) Assuming a known-plaintext attack, and assuming that the internal ciphers _can_ be isolated and worked on separately, the 4x Fenced DES construct has an overall keyspace of not less than 120 bits. (Argument: The substitution and ciphering occur in series, consequently, at least one eight-byte substitution (input or output) and one DES ciphering must be solved simultaneously, even if the block mixing transform fails.) 12.6 ASSERTION: (Expected strength of 4x Fenced DES.) Assuming a known-plaintext attack, and assuming that the internal ciphers _cannot_ be isolated and worked on separately, the 4x Fenced DES construct has an overall keyspace exceeding 480 bits. (Argument: The small substitutions (input or output) jointly contribute 256 bits, and the four DES keys contribute 224 bits for a total of 480 bits. That is, searching a 480-bit keyspace will solve the system for a particular input (or output) block. This identifies the DES keys, but only solves 1/256th of each of 32 substitutions. Once the system is solved for a particular block, the 255 other entries in each of 32 substitutions must be filled in to completely solve the cipher.) Results It appears that Fenced DES can reasonably be proven to be an invertible block cipher which has the avalanche property (provided, of course, that DES has that property) with a strength at least that of DES itself. Reasonable-sounding arguments suggest that the internal ciphers cannot be separated and worked on independently, and that the resulting cipher has substantial strength. It would be nice to tighten this up; any and all suggestions are welcome. Appendix Some Fenced DES constructions: 1x Fenced DES S S S S S S S S ------DES------ S S S S S S S S 2x Fenced DES S S S S S S S S S S S S S S S S --------------mix-------------- ------DES------ ------DES------ --------------mix-------------- S S S S S S S S S S S S S S S S 4x Construct with 1x Strength S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S ------DES------ ------DES------ ------DES------ ------DES------ S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S Original 4x Fenced DES S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ ------DES------ ------DES------ ------DES------ ------DES------ ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S Current 4x Fenced DES S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------DES------ ------DES------ ------DES------ ------DES------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S 4x Fenced DES with Less Storage and Strength (A..H and S..Z represent 16 keyed byte-substitutions, each used four times.) A B C D E F G H A B C D E F G H A B C D E F G H A B C D E F G H ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------DES------ ------DES------ ------DES------ ------DES------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ S T U V W X Y Z S T U V W X Y Z S T U V W X Y Z S T U V W X Y Z --- Terry Ritter ritter@io.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11156; 26 May 94 15:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11152; 26 May 94 15:30 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa14900; 26 May 94 15:30 EDT Received: by relay.tis.com id AA29660; Thu, 26 May 94 15:19:25 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma029644; Thu May 26 15:18:23 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa18355; 26 May 94 15:11 EDT Received: from sol.tis.com by magellan.TIS.COM id aa18351; 26 May 94 15:10 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29463; Thu, 26 May 94 15:09:34 EDT Received: by relay.tis.com id AA29564; Thu, 26 May 94 15:10:23 EDT Received: from dockmaster.ncsc.mil(26.1.0.172) by relay via smap (V1.3mjr) id sma029540; Thu May 26 15:09:24 1994 Date: Thu, 26 May 94 15:08 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TCJones@dockmaster.ncsc.mil Subject: DUNS are valid names To: pem-dev@tis.com Message-Id: <940526190832.881390@DOCKMASTER.NCSC.MIL> Bob has made the following points: >5. My assumption would be that the DUNS number would essentially be used as an >alias or pointer to the traditional civil naming structure entry, where all of >the rest of the payload concerning that entity would be found. However, this >would give rise to a certain issue of trust. Clearly the normal Directory >Service Provider (DSP) is not going to accept any responsibility for the >correctness of the DUNS number and the various implications that go with it >(unless Dun and Bradstreet becomes at DSP). So the alias between the DUNS >number and the civil name entry cannot necessarily be trusted, at least to the >same extent that the D&B entry could be. Of course, the primary entry could and >should contain a cross reference to the DUNS number, and the two should be >compared, but still the DSP should probably not be trusted in any meaningful >sense. >6. Instead, it would appear highly desirable for Dun and Bradstreet (or any >other registration authority) to become a Certification Authority, and to issue >X.509 certificates binding the name of a company to their DUNS number, at >least. Whether they would want to include other information (such as annual >sales, bond rating, etc.) in that certificate remains to be seen. Whether this >kind of a certificate should be a standard identity certificate or whether it >comes closer to an authorization certificate is not quite clear to me. and later Bob said: >Efforts are underway within the NADF, the Internet, and the Paradise project in >Europe to bring all of these disjoint directory systems under the umbrella of >one common naming and knowledge tree, probably making use of knowledge and >naming link sharing tools such as the NADF's CAN tools, so that all ADDMDs and >any Private Directory Management Domains that care to can have common access to >all of the information in the public name space. I will try to restate some of the points that I was making early on naming authorities. In EDI there is the concept of registration of naming authorities for a wide variety of objects, including trading partner names. In the US this registration is maintained by X12, with international sets of names also available. These names are accepted in the community of interest (ie EDI applications). IMHO, it is a bad mistake for IETF or ITU or any other organization to assume that they can create a singly rooted tree for all names that are ever likely to exist. This is the equivalent of the creation of a common language Esperanto, doomed to failure. Neither this group, nor any other group will ever know all there is to know about naming, and so the best that you can do is to create a structure into which a name can be placed with reference to the source of that name. You say that you cannot trust D&B to name corporations, but how can you trust my parents to name me? The argument is misplaced. Names are just tags, they do not serve to identify people in the sense that you are trying to legislate (and yes, I do mean legislate). I just learned yesterday that Notaries are no longer accepted as signature guarantors for stock transfers in the US. This is a change, which I assume to be for valid reasons, which could have destroyed a trust scheme based on notaries. Please do not try to link naming authorities to identity proofs. This is not a strength of PEM. This is exactly why PEM is failing. Trust schemes must be made flexible enough for the application that requires the trust. In the securities application, it was decided that a new trust grantor was required, so they created one. Latin notaries are not trusted any more, so a second layer of notaries to notarize the lower layer notaries was created. This process of change will go on forever! If you build a trust structure based on today's trust patterns, it will not last as long as the time required to complete the standard. I have written this up in more detail for publication. If anyone would like to preview that paper, AND send me their evaluation, I will copy you. Peace ..Tom   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04583; 27 May 94 11:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04579; 27 May 94 11:41 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa09313; 27 May 94 11:41 EDT Received: by relay.tis.com id AA06438; Fri, 27 May 94 11:27:02 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma006424; Fri May 27 11:26:07 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa20464; 27 May 94 11:03 EDT Received: from sol.tis.com by magellan.TIS.COM id aa20460; 27 May 94 11:00 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16511; Fri, 27 May 94 11:00:02 EDT Received: by relay.tis.com id AA06257; Fri, 27 May 94 11:00:53 EDT Received: from beta.hut.fi(130.233.224.51) by relay via smap (V1.3mjr) id sma006253; Fri May 27 11:00:33 1994 Received: (from aha@localhost) by beta.hut.fi (8.6.8.1/8.6.7) id SAA11885 for pem-dev@tis.com; Fri, 27 May 1994 18:00:10 +0300 Date: Fri, 27 May 1994 18:00:10 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Antti Hannula Message-Id: <199405271500.SAA11885@beta.hut.fi> To: pem-dev@tis.com Subject: duplicate subscription please check that I am not a subscriber twice, I would like to have only one copy of the mailing list to my address aha@beta.hut.fi thank you. antti hannula aha@beta.hut.fi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09840; 27 May 94 18:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09836; 27 May 94 18:48 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa03262; 27 May 94 18:48 EDT Received: by relay.tis.com id AA10618; Fri, 27 May 94 18:37:06 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma010612; Fri May 27 18:37:02 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21760; 27 May 94 18:30 EDT Received: from sol.tis.com by magellan.TIS.COM id aa21756; 27 May 94 18:27 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA15164; Fri, 27 May 94 18:27:38 EDT Message-Id: <9405272227.AA15164@tis.com> To: PEM Developer's Mailing List (PEM-DEV) Subject: Call for Papers - 1995 ISOC Symp. on Netw. and Distr. Sys. Security Date: Fri, 27 May 94 18:27:50 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Balenson" CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security 16-17 February 1995, Catamaran Hotel, San Diego, California GOAL: The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Design and implementation of security services -- access control, authentication, availability, confidentiality, integrity, and non-repudiation. * Design and implementation of security mechanisms and support services -- encipherment, authentication, and key management systems, including fair cryptography -- access control, authorization and audit systems -- and intrusion detection systems. * Requirements and designs for securing distributed applications and network functions -- message handling, file transport, remote file access, directories, time synchronization, interactive sessions, remote data base management and access, routing, voice and video multicast and conferencing, news groups, network management, boot services, mobile computing, and remote I/O. * Requirements and designs for securing networked information resources and tools -- Archie servers, the Wide Area Information Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW). * Design and implementation of measures for controlling internetwork communication and services in a coherent manner -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the international Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems Rob Shirey, The MITRE Corporation PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Ravi Ganesan, Bell Atlantic Burt Kaliski, RSA Laboratories Steve Kent, BBN Communications Paul Lambert, Motorola John Linn, OpenVision Technologies Clifford Neuman, Information Sciences Institute Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Jeff Schiller, Massachusetts Institute of Technology Mike St. Johns, Advanced Research Projects Agency Peter Yee, U.S. National Aeronautics and Space Administration Roberto Zamparo, Telia Research (Sweden) SUBMISSIONS: The committee invites both technical papers and proposals for panel discussions on technical and other topics of general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages in length, and should describe the panel topic, name the panel chair, explain the format of the panel, and list three to four potential panelists. The technical papers will appear in the proceedings. Panel chairs and panelists will have the option of having written statements appear in the proceedings. All submissions should contain a separate title page which includes 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 the point of contact, if more than one author. Since the review process will be anonymous, the author's names, affiliations and other information should appear only on the separate title page. Deadline for paper submission: August 15, 1994 Notification sent to authors by: October 17, 1994 Deadline for camera-ready copy: November 15, 1994 Submissions must be made by 15 August 1994. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and ASCII requested. Therefore, PostScript submissions should arrive well before 15 August. If electronic submission is absolutely impossible, submissions should be sent via postal mail. All submissions and other correspondence should be directed to the Program Co-Chair: David M. Balenson Trusted Information Systems, Inc. 3060 Washington Road (Rt. 97) Glenwood, Maryland 21738 USA Phone: 301-854-6889 FAX: 301-854-5363 Email: balenson@tis.com Each submission will be acknowledged through the medium by which it is received. If acknowledgment is not received within seven days, please contact the Program Co-Chair as indicated above. Authors and panelists will be notified of acceptance by 17 October 1994. Instructions for preparing camera-ready copy for the proceedings will be postal mailed at that time. The camera-ready copy must be received by 15 November 1994. -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04303; 29 May 94 19:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04299; 29 May 94 19:37 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa21040; 29 May 94 19:37 EDT Received: by relay.tis.com id AA21609; Sun, 29 May 94 19:28:42 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma021604; Sun May 29 19:28:33 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25379; 29 May 94 19:20 EDT Received: from sol.tis.com by magellan.TIS.COM id aa25375; 29 May 94 19:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06222; Sun, 29 May 94 19:17:45 EDT Received: by relay.tis.com id AA21565; Sun, 29 May 94 19:18:40 EDT Received: from alsys1.aecom.yu.edu(129.98.1.4) by relay via smap (V1.3mjr) id sma021561; Sun May 29 19:18:18 1994 Received: from yu1.yu.edu by alsys1.aecom.yu.edu with SMTP id AA26697 (5.67b/IDA-1.5/AECOM-RIT for ); Sun, 29 May 1994 19:17:58 -0400 Received: by yu1.yu.edu (AIX 3.2/UCB 5.64/4.03) id AA12670; Sun, 29 May 1994 19:17:45 -0400 Date: Sun, 29 May 1994 19:17:45 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mervyn Frankel Subject: To: pem-dev@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are looking for ways to protect our internetwork from invasion as we open it up to the internet. We are initially going to permit only e-mail to flow in and out. Merv