- cypherpunks-legacy - lists.cpunks.org

Re: Return of the Living Zundel, from The Netly News
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Declan McCullagh wrote: > http://cgi.pathfinder.com/netly/editorial/0,1012,1561,00.html > Return of the Living Zundel > by Chris Stamper (cstamper(a)pathfinder.com) > Does Ernst Zundel have the right to deny the Holocaust and brag > about it on the Net? In the U.S. the answer is unequivocally yes. But > in Canada, where Zundel resides, the Human Rights Commission has been > holding hearings on whether the "Zundelsite" violates the country's > hate speech laws. If Zundel loses the case, he'll be asked to pay > damages and take any offending articles off the web site. Canadian Shock TV!!! Camilla Scott, competing for airtime with Jerry Springer's shows about two-headed lady midget wrestlers in a bed full of chickens with a serial killer who married his own daughter, recently had a show where people who wanted their friends/relatives to change their 'outrageous' behavior could confront them live, on TV. One of the guests was perturbed because his friend, a very successful businessman, always wore black. (Clothes of exceptional quality and design, but _always_ black.) Fortunately, the Canadian sheeple hooted and hollered derision at the fellow, thus protecting us from unsavory types like the Man in Black. Unfortunately, the fellow seemed much happier and satisfied with his life than those doing the hooting and hollering, so chances are, he will continue his diabolical wardrobe atrocities. Canadians know that the answer to racism is to put the racists in ovens and gas them, then bury them in mass graves in Germany. Glad I could clear that up. MapleLeafMonger

1 0

Bay Area Cypherpunks meeting announcement
by Lucky Green 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tomorrow's Bay Area Cypherpunks meeting will be held at the offices of C2Net Software in Oakland. Agenda: o Andrea Liles will present some cool new ideas about virtual CA's. o Lucky Green will demonstrate the Dumb Mouse, a universal chipcard reader, and associated analysis/manipulation software. If you are at all interested in smartcards, especially smartcards for crypto and authentication purposes, you don't want to miss this one. If there aren't too many attendees, we will host a workshop. Attendees are encouraged to bring any smartcards in their possession and discover what is /really/ happening on the card. The Cypherpunks Smartcard Developers Association will accept smartcard donations after the workshop. o Cypherpunks Tonga will announce the release of BSAFEeay, a BSAFE 3.0 API compatible crypto library based on SSLeay. o Cypherpunks Tonga will then combine BSAFEeay with the freeware SETref (which requires BSAFE for the underlying crypto) and demonstrate the first ever globally available *freeware* SET solution. Location: C2Net Software 1440 Broadway 7th Floor Oakland, CA Date/time: Saturday, 11/8, noon Directions: By BART: Exit the system at 12th Street Oakland. Walk north on Broadway one block. 1440 is on the right side of the street. By car: http://www.mapquest.com/ Choose "Trip Quest" from the menu. - -- Lucky Green <shamrock(a)cypherpunks.to> PGP v5 encrypted email preferred. "Tonga? Where the hell is Tonga? They have Cypherpunks there?" -----BEGIN PGP SIGNATURE----- Version: PGP 5.0i Charset: noconv iQA/AwUBNGPhYvXUPTw3WtkkEQKztACeIQwx4voyUVIP6u1HmosCWklX7osAnROD TTJn3K2jCIrKUQtOc5Z3oW1P =byR/ -----END PGP SIGNATURE-----

1 0

S/MIME Mail Security WG approved - IETF
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Mime-Version: 1.0 Date: Sat, 8 Nov 1997 12:37:28 -0500 To: dcsb(a)ai.mit.edu From: Vin McLellan <vin(a)shore.net> Subject: S/MIME Mail Security WG approved - IETF Sender: bounce-dcsb(a)ai.mit.edu Precedence: bulk Reply-To: Vin McLellan <vin(a)shore.net> <Forwarded message; off the IETF-Announce mailing list> ------------------------- To: IETF-Announce: ; Subject: WG ACTION: S/MIME Mail Security (smime) Date: Fri, 07 Nov 1997 18:19:29 -0500 From: Steve Coya <scoya(a)cnri.reston.va.us> A new working group has been approved in the Security Area of the IETF. Contact the Area Director or Working Group Chair for more information. S/MIME Mail Security (smime) ---------------------------- Chair(s): Russ Housley <housley(a)spyrus.com> Security Area Director(s): Jeffrey Schiller <jis(a)mit.edu> Security Area Advisor: Jeffrey Schiller <jis(a)mit.edu> Mailing Lists: General Discussion:ietf-smime@imc.org To Subscribe: ietf-smime-request(a)imc.org Archive: http://www.imc.org/ietf-smime/ Description of Working Group: The S/MIME Working Group will define MIME encapsulation of digitally signed and encrypted objects whose format is based on PKCS #7. [1] X.509 Certificates and CRLs as profiled by the existing PKIX Working Group will be used to support authentication and key management. The Working Group will base its work on the S/MIME version 2 specification (available from RSA Data Security), but the Working Group will be free to change any part of that specification. In particular, the Working Group will prepare a new document that allows algorithm independence, based on PKCS #7 1.5. The message syntax specification, based on PKCS #7 version 1.5, will be expanded to allow additional key signature and key exchange algorithms. The message and certificate specifications will be revised to allow them to become standards. The optional security extensions document will specify protocols that allow for additional security features, such as signed message receipts. The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap, particularly in specification of cryptographic algorithms and MIME structure. [1] RSA Data Security publishes the PKCS Series of documents. RSA Data Security has permitted the IETF to publish them as Informational RFCs as well as to extend and enhance them. Goals and Milestones: Nov 97 Submit First draft of message syntax specification as an I-D. Nov 97 Submit First draft of S/MIME v3 message specification as an I-D. Nov 97 Submit First draft of S/MIME optional security extensions as an I-D. Nov 97 Submit First draft of S/MIME v3 certificate specification as an I-D Dec 97 WG Last Call on Message Syntax. Dec 97 WG Last Call on Certifiticate Specification. Dec 97 WG Last Call on Message specification. Jan 98 WG Last Call on Optional Security Extensions. Jan 98 Submit Message Syntax I-D to IESG for consideration as a /end forwarded message/ "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _ A thinking man's Creed for Crypto/ vbm. * Vin McLellan + The Privacy Guild + <vin(a)shore.net> * 53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548 For help on using this list (especially unsubscribing), send a message to "dcsb-request(a)ai.mit.edu" with one line of text: "help". --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

1 0

Senator Ashcroft on Encryption
by John Young 17 Dec '03

17 Dec '03

[Congressional Record: November 7, 1997 (Senate)] [Page S11959] ENCRYPTION Mr. ASHCROFT. Mr. President, I wanted to take a moment to associate myself with the comments of the majority leader from October 21, 1997. Senator Lott has correctly highlighted the FBI's constantly shifting arguments and the Bureau's seemingly relentless attempts to grab more power at the expense of the Constitution, particularly the fourth amendment's protection of privacy and the fifth amendment's guarantee of due process. The FBI legislative proposal goes far beyond the Commerce Committee's misguided encryption legislation in further disregarding our Constitution. Instead of working with those who understand that S.909 gives the FBI unprecedented and troubling authority to invade lives, the FBI has attempted to grab even broader authority. The Senate would be foolish to pass S.909. In no way can we even consider the ill-advised FBI approach. The reach of the FBI has now extended so far that the President has taken the other side of the issue and supported a free market approach, according to his public comments delivered abroad. I can only conclude that the FBI has introduced its proposal as a ploy to make S.909 look like a reasonable compromise. The only other explanation for the FBI's proposal is that the Bureau will not be satisfied with S.909, but instead will continue to work to erode our Constitutional protections. In fact, the new proposal only draws attention to the many problems of the Commerce Committee language. Neither proposal is acceptable. The issue of encryption must be revisited in a real and serious way next year, both at the committee level and in the Senate chamber, to examine the many Constitutional implications of the various proposals. I look forward to working with the Majority Leader and other Senators who have expressed interest in encryption legislation. I yield the floor. [End] See Senator Lott's comments on encryption: http://jya.com/lott-crypto.htm

1 0

Re: [SURVEY try again] pgp5.x / pgp2.x users
by 3umoelle＠informatik.uni-hamburg.de 17 Dec '03

17 Dec '03

> > 20 % of the users who have posted digitally signed messages that are > > available in my news spool (international and local newsgroups and > > mailing lists) use PGP 5. The sample contains 545 unique e-mail > > addresses. YMMV. > > These are very interesting results. One question: what are the groups > about? Are they close in to PGP topics or far away? A number of them are crypto related, including the OpenPGP and a German PGP users' mailing list. Perhaps someone with access to a large newsserver could grep for PGP signatures on the rec.* hierarchy?

1 0

Make money From People Watching TV
by skyway＠t-1net.com 17 Dec '03

17 Dec '03

Just Released Bill Gates has just joined with Ted Turner and Rupert Murdock to form the greatest consortium of combined technology and opportunity available today! Their plan is to take over the digital communications market by setting up people with DSS satellite equipment at no charge. As a representative with our company, you will get paid between $25 and $100 for "giving away" Digital Direct Satellites, For every person that joins the business with you to give away free Digital Direct Satellites, you will make an additional $55 to $280 We are getting paid for getting consumers set up with a total Digital Direct Satellite system with no charge, and building the distribution network of the future. Imagine how easy it is to give these away! In the first week sharing it with friends I gave away 5 not even trying and made an extra $375. There are no credit applications for the client to fill out, no mandatory 12 month contracts to join, and no surprises later down the line. The company will even upgrade the system later if it becomes obsolete, For Free! This new union was created intentionally to capture a huge active ongoing database of consumers. That's right, consumers who will purchase continuously from shows like QVC, HSN and many others, and when they purchase off of the TV you as a distributor will also make a commission off everything that they order, even while you are out golfing or sleeping, 24 hours a day. All this from you having them fill out an application that should take no more than 60 seconds. There are several other ways to get paid also, and I have enclosed the actual application for you to review. Could you imagine Christmas when they are buying like crazy and you are getting paid up to 30% of what they purchase off the television? I could and that's why we are here. Come "profit from the future of television" and join the fastest growing segment of this company and become a winner with us. If you are ready for the greatest business opportunity to come down the pike, don't miss this one, it is only 2 months old!!! Give our information hot line a call at 1-800-942-9304 pin #20088 CHECK OUT http://www.millenniumgroup2000.com -------------------------- Removes to skyway(a)t-1net.com, put remove in subject, thanks.

1 0

Rape as Performance Art
by Anonymous 17 Dec '03

17 Dec '03

I can sympathize with the demonstrators that the Humboldt Sheriff's Department sprayed with pepper spray during their sit-in/protest. The police have done the same thing to me during the closing scenes of my performance art, as I climb out of the performance victim's window and try to make a run for it. I have found that judges are seldom impressed with a plea of, "Everyone wants to be a critic!" Art Lover (aka 'SouthSide Slasher') "It's not art until *I* have slashed it with a razor."

1 0

Re: WARNING: Serious Pentium Bug
by Anonymous 17 Dec '03

17 Dec '03

"William H. Geiger III" <whgiii(a)invweb.net> wrote: >For the same reason Intel does nothing about any of thier bugs: they are >assholes. The only way any of these type of things are ever addressed is >by enough users putting pressure on Intel to fix their fuckups. (Really >slopy not testing the microcode) Yeah. A conspiracy theorist might be prompted to theorize that Intel deliberately placed this in their processor, took a chance that nobody else would find it and publically release it, and then leaked the information themselves. If they refuse to replace the P5s many people will upgrade to a PPro or a P5. Of course Cyrix and AMD throw a wrench into this theory, but I doubt there are a whole lot of people who won't be buying any more Intel products due to this, and some of the clones have or did have big problems such as annoyingly slow FPUs. If they don't make it extraordinarily easy for me to replace my processor I'll probably be one of the people who falls into the latter catagory and goes off to Cyrixland.

1 0

Re: [patent] Secure electronic message transfer and voting scheme
by ulf＠fitug.de 17 Dec '03

17 Dec '03

>Patent Number: 5682430 >Inventor(s): Kilian, Joseph John{#buSako, Kazue#} The full text is available at <http://patent.womplex.ibm.com>. The novelty in this patent is an algorithm that uses Fiat-Shamir to prove that the mixes operate correctly. The general idea of using non-interactive zero-knowledge proofs to verify that mixes follow the protocol was already published by Rackoff and Simon in 1991, although that is not acknowledged in the patent specification. Does anyone have details about Kilian's patent application on identity escrow, other than the paper at <http://www.princeton.edu/~erez/ident.ps>?

1 0

InterNIC Guardian Object Draft
by Eric Eden 17 Dec '03

17 Dec '03

We're distributing this to the Internet community for comments and suggestions. If you have any ideas for improving this draft please let us know. I apologize in advance for the length, but the authors are really interested in your thoughts. Thanks, Eric Eden erice(a)internic.net InterNIC Registration Services 703-736-0145 [ URL ftp://rs.internic.net/policy/internic/internic-gen-1.txt ] [ 2/96 ] Jasdip Singh Network Solutions Mark Kosters Network Solutions The InterNIC Guardian Object DRAFT Table of Contents 1. Introduction....................................................... 1 2. Main Features of a Guardian........................................ 1 3. Guardian Attributes................................................ 1 4. Registering the Guardian Attributes................................ 4 4.1 Using the New Contact Template.................................... 5 4.2 Using the Modified Registration Templates......................... 5 5. Linking Guardian Information to Existing Records................... 5 6. Notification....................................................... 6 7. Object Update Rules................................................ 6 7.1 Request from a Contact with Authentication Information............ 7 7.2 Request from a Contact without Authentication Information......... 7 7.3 Request from a Sender not listed as a Contact..................... 7 8. Object Use Rules................................................... 8 8.1 Request from a Contact............................................ 8 8.2 Request from a Sender not listed as a Contact..................... 8 9. Other Guardian Issues.............................................. 8 9.1 Number of Guardians per Object.................................... 8 9.2 Protecting Guardian Information................................... 9 9.3 Displaying Guardian Information................................... 9 10. Conclusion........................................................ 9 11. References........................................................ 9 12. Acknowledgements.................................................. 9 A. The Proposed Contact Template...................................... 10 B. The Proposed Link Template......................................... 12 C. The Proposed Notify Template....................................... 14 D. Object Update Rules................................................ 15 E. Object Use Rules................................................... 16 F. Examples........................................................... 17 F.1 How to Register a New Contact with Authentication Information..... 17 F.2 How to Link Guardian Information to Existing Records.............. 18 F.3 How to Update a Guarded Record.................................... 19 F.4 WHOIS Display of Guardian Information............................. 20 [Page i] 1. Introduction This document proposes a model to authorize changes made to the Objects (Domains, Networks, Autonomous System Numbers, and Hosts) registered with the InterNIC. The registration activity at the InterNIC has increased exponentially with the rapid growth of the Internet. In the absence of a formal authorization model, the likelihood of making malicious changes to the registered Objects has also increased and could have serious consequences at the affected sites. For example, an unauthorized update could lead a commercial organization to lose its presence on the Internet until that update is reversed. 2. Main Features of a Guardian - A Guardian is an Object that protects other Objects from unauthorized changes. It is basically a Contact with Authentication Information. - The different authorization schemes to authenticate a Guardian are MAIL-FROM, CRYPT-PW, and PGP. - The use of a Guardian is optional. - An Object may be guarded by multiple Guardians with each Guardian having an equal authority to make changes to the Object. 3. Guardian Attributes Currently, the InterNIC allows a registered Object to be updated if the request came from one of its Contacts. This model is weak due to potential mail spoofing. To allow for stronger authorization schemes, the proposed authorization model defines a new Object called Guardian. A Guardian is basically a Contact with Authentication Information. It inherits the attributes of a Contact Object and has the additional authentication attributes. The definition of a Guardian is derived from a Contact because a particular Contact (Administrative, Technical, or Billing) represents some form of holding of a registered Object and the holder of an Object is most likely to guard it also. [Page 1] The attributes of a Guardian are: Name Required Type Required Address Required Phone Required Fax Optional Email Required Notify Update Optional Notify Use Optional Auth Scheme Required * Auth Info Required * Public Optional * The Auth Scheme and Auth Info attributes are required only for a Guardian Object (a Contact with Authentication Information) and not for a Contact Object (a Contact without Authentication Information). Name, Type, Address, Phone, Fax, Email, Notify Update, and Notify Use are the attributes a Guardian inherits from a Contact Object. Auth Scheme, Auth Info, and Public are the additional authentication attributes of a Guardian. Name Name of a Guardian. Type Type of a Guardian. It can have values I (Individual) or R (Role Account). Address Postal address of a Guardian. Phone Phone number of a Guardian. Fax Fax number of a Guardian. Email Email address of a Guardian. [Page 2] Notify Update This attribute determines if and when a Guardian should be notified about the update of an Object the Guardian is responsible for. It can have values BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE. BEFORE-UPDATE The Guardian will be notified before updating the Object. AFTER-UPDATE The Guardian will be notified after updating the Object. AFTER-UPDATE is the default value. NOT-CARE The Guardian will not be notified about the Object update because it does not want to be notified. Currently, a Guardian's Notify Update attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Notify Use This attribute determines if and when a Guardian should be notified about the use of an Object the Guardian is responsible for. For example, a Guardian of a Host may be notified when someone else lists it as a DNS server for a Domain. It can have values BEFORE-USE, AFTER-USE, and NOT-CARE. BEFORE-USE The Guardian will be notified before using the Object. AFTER-USE The Guardian will be notified after using the Object. AFTER-USE is the default value. NOT-CARE The Guardian will not be notified about the Object use because it does not want to be notified. Currently, a Guardian's Notify Use attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Auth Scheme Authorization scheme used to authenticate a Guardian before updating the Object it is guarding. The proposed schemes in an increasing order of strength are MAIL-FROM, CRYPT-PW, and PGP [1]. MAIL-FROM MAIL-FROM will parse the FROM: field in the mail header of an update message and match it with the email address of the Guardian guarding the Object to be updated. MAIL-FROM is the default Auth Scheme. [Page 3] CRYPT-PW CRYPT-PW will encrypt the cleartext password supplied in an update message and match it with the encrypted password of the Guardian guarding the Object to be updated. Initially when a new Guardian is being registered or the authentication information is being added to an existing Contact, the encrypted password MUST be supplied. The Unix crypt(3) routine SHOULD be used to encrypt a cleartext password. PGP PGP stands for Pretty Good Privacy [2]. The sender will sign the update message with a Guardian's secret PGP key. The InterNIC will verify the received update message with the Guardian's public PGP key. How to register a Guardian's public PGP key with the InterNIC will be explained in another document. Auth Info Information for the selected authorization scheme. The authentication information stored in the database for a Guardian registered with the InterNIC is: MAIL-FROM Email address of a Guardian. CRYPT-PW Encrypted password of a Guardian. PGP Key ID of the public PGP key of a Guardian. Public Boolean indicating whether the authentication information for a Guardian will be public or not. Public means visible in WHOIS. It can have values Y (Yes) or N (No). The default value is Y. Note that the terms "Guardian" and "Contact with Authentication Information" are used interchangeably in the remaining document. 4. Registering the Guardian Attributes There will be two alternatives available to register or update the Guardian attributes: - Using the new Contact Template, or - Using the registration templates for Domains, Networks, Autonomous System Numbers (ASNs), and Hosts modified to include the authentication information for the Contacts. Note that registering a PGP-authenticated Guardian will be a two-step process because the Guardian will first have to register its public PGP key with the InterNIC and then report the key ID as Auth Info using one of the above methods. [Page 4] 4.1 Using the New Contact Template A new Contact Template is proposed to independently register or update a Contact with Authentication Information. Appendix A describes the new Contact Template and its use. 4.2 Using the Modified Registration Templates The registration templates for Domains, Networks, ASNs, and Hosts will be modified to include: a) The Authentication Information for the Contacts. b) The Authorization Section in the beginning of the template to authenticate the Guardian updating the Object. It SHOULD be filled only when the Object is being modified or deleted, and if the Object is being guarded. It has the following items: Auth Scheme Authorization scheme used to authenticate the Guardian updating the Object. It can have values MAIL-FROM, CRYPT-PW, or PGP. Auth Info Information for the selected authorization scheme. The different Auth Scheme and Auth Info combinations are: Auth Scheme Auth Info MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Object and send it in cleartext to the InterNIC. 5. Linking Guardian Information to Existing Records There are two ways to link Guardian information to existing records: a) Once the authentication information is added to an existing Contact, all the database records the Contact is responsible for will be automatically guarded by that Contact and any subsequent update request from that Contact for one of those records will be first authenticated. This approach should be used carefully because here a Contact guards either all or none of its Objects. [Page 5] b) A new Link Template is proposed to do a wholesale linkage of Contacts with Authentication Information (Guardian Objects) to database records (Guarded Objects) in a single transaction. This approach is more flexible because the records that need to be guarded by a particular set of Guardians are listed explicitly in the Link Template. Appendix B describes the new Link Template and its use. 6. Notification The rules to update or use an Object will depend on when its Contacts are notified. There are two types of notification: Active Notification If the Notify Update attribute for a Contact of an Object is set to BEFORE-UPDATE, the Contact will be notified before updating the Object and the request will only be processed if an ACK (Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to BEFORE-USE, the Contact will be notified before using the Object and the request will only be processed if an ACK is received. Passive Notification If the Notify Update attribute for a Contact of an Object is set to AFTER-UPDATE, the Contact will be notified after the Object has been updated and the processed request will be revoked if a NAK (Negative Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to AFTER-USE, the Contact will be notified after the Object has been used and the processed request will be revoked if a NAK is received. An ACK or a NAK MUST be received within a certain time interval to be effective. Clearly, active notification is safer than passive notification. Appendix C describes the new Notify Template and its use. 7. Object Update Rules A request to update an Object could possibly come from a Contact with Authentication Information, a Contact without Authentication Information or a sender not listed as a Contact for the Object. [Page 6] The Object Update Rules for such requests are: 7.1 Request from a Contact with Authentication Information The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE. 7.2 Request from a Contact without Authentication Information 7.2.1 Object has at least one Contact with Authentication Information All the Contacts with Authentication Information will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2 Object has no Contacts with Authentication Information 7.2.2.1 Object has at least one of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE All the other Contacts with Notify Update attribute set to BEFORE-UPDATE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2.2 Object has none of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE. The Contacts with Notify Update attribute set to NOT-CARE will not be notified. 7.3 Request from a Sender not listed as a Contact All the Contacts will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. If the request from a sender not listed as a Contact is rejected, the sender MUST present an evidence that the organization using the Object has approved it to update the Object. Another request from the same sender must be faxed to the InterNIC on the corporate letterhead and must contain the tracking number of the initial request. The sender could also present its contract with the organization using the Object. Appendix D gives a summary of the Object Update Rules. [Page 7] 8. Object Use Rules One of the more common registration problems is a Domain holder using without permission someone else's DNS servers or someone else's IP addresses to number its DNS servers. The Object Use Rules will help prevent such illegal use of Objects, particularly Hosts and Networks. A request to use an Object could possibly come from one of its Contacts or a sender not listed as a Contact for the Object. The Object Use Rules for such requests are: 8.1 Request from a Contact The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE. 8.2 Request from a Sender not listed as a Contact 8.2.1 Object to be used has at least one Contact with Notify Use Attribute set to BEFORE-USE All the Contacts with Notify Use attribute set to BEFORE-USE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 8.2.2 Object to be used has no Contact with Notify Use Attribute set to BEFORE-USE The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to AFTER-USE. The Contacts with Notify Use attribute set to NOT-CARE will not be notified. Appendix E gives a summary of the Object Use Rules. 9. Other Guardian Issues 9.1 Number of Guardians per Object The number of Guardians for an Object will be equal to the number of its Contacts with Authentication Information. Each Guardian will have an equal authority to make changes to the Object. In future, multiple Contacts of the same type (for example, Technical) will be allowed for an Object. If an Object has no Contacts with Authentication Information, it will not be guarded at all. [Page 8] 9.2 Protecting Guardian Information By default, a Guardian will guard itself (that is, only the Guardian will have the authority to make changes to its information). However, a Guardian can be guarded by another Guardian. If a Guardian is guarding itself and needs to update its authentication information or scheme, the update message MUST contain the Guardian's old authentication information. Otherwise, the Guardian can not be authenticated before the update. For example, if a Guardian's Auth Scheme is MAIL-FROM, and it needs to either update its email address or change its Auth Scheme, the update message must come from its old email address. 9.3 Displaying Guardian Information The authentication information for a Guardian will be visible in WHOIS unless the Guardian chooses to keep it private. This information will be public by default because a Guarded Object should be protected by the inherent strength of the selected authorization scheme rather than by hiding the authorization information for its Guardian. The WHOIS display for a Guarded Object will be extended to indicate that the Object is being guarded. 10. Conclusion The increased market value of the Objects registered with the InterNIC, particularly Domains and Networks, has necessitated the need for more secure database transactions. This Guardian proposal will help solve most of the current, unauthorized Object update and use problems at the InterNIC. It balances operational expediency with stronger authorization by allowing the Contacts of an Object to select the appropriate level of security (MAIL-FROM, CRYPT-PW, or PGP) for the Object. 11. References [1] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", ripe-120, RIPE NCC, RIPE NCC. [2] Garfinkel, S., "PGP Pretty Good Privacy", O'Reilly & Associates, Inc. 12. Acknowledgements The authors thank the InterNIC staff for some very useful suggestions, especially Eric Eden, Tom Newell, Kim Hubbard, Duane Stone, and Carley Johnson. [Page 9] Appendix A The Proposed Contact Template [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: Contact Information 2a. NIC Handle..............: 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: The Contact Template will be used to independently register or update a Contact (with or without Authentication Information). [Page 10] Items 0a-0b SHOULD be filled only when a Contact is being modified or deleted, and if the Contact is being guarded. These items contain the information to authenticate the Guardian updating the Contact. Item 0a is the authorization scheme for that Guardian. It can have values MAIL-FROM, CRYPT-PW, or PGP. Item 0b is the information for the selected authorization scheme. The different items 0a and 0b combinations are: Item 0a Item 0b MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Contact and send it in cleartext to the InterNIC. Item 1 is the registration action type. It can have values N, M, or D. N registers a new Contact. M modifies the information for an existing Contact. D deletes an existing Contact if it is no longer linked to any Object. Items 2a-2k contain the basic information for a Contact. Item 2a is the NIC handle assigned to a Contact. Items 2b, 2c, 2d-2h, 2i, 2j, and 2k are respectively the Name, Type, Address, Phone, Fax, and Email attributes of a Contact. Items 3a-3b contain the notification information for a Contact. Items 3a and 3b are respectively the Notify Update and Notify Use attributes of a Contact. Items 4a-4c contain the authentication information for a Contact. These items are optional, and are required only if either the authentication information is being added to an existing Contact or a new Contact with Authentication Information is being registered. Items 4a, 4b, and 4c are respectively the Auth Scheme, Auth Info, and Public attributes of a Guardian. [Page 11] Appendix B The Proposed Link Template [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: Object 1a. Identifier..............: 1b. Type....................: 1c. Function................: Linked Object 2a. Identifier..............: 2b. Type....................: The Link Template will be used to do wholesale database changes in a single transaction. Some of the more commonly requested database changes are: a) Link or unlink Contacts (with or without Authentication Information) to or from existing Domains, Networks, ASNs, and Hosts. b) Link or unlink DNS servers to or from existing Domains and Networks. Item 0 is the registration action type. It can have values N, M, or D. N links the Objects (Contacts or DNS servers) in the Object Sections to the Objects (Domains, Networks, ASNs, and Hosts) in the Linked Object Sections. M modifies the linkage. D unlinks the Objects in the Object Sections from the Objects in the Linked Object Sections. Items 1a-1c contain information for an Object (Contact or DNS server) in the Object Section. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is optional and is required only if the Object is a Contact. It is the Function Type of a Contact. It can have values AC (Administrative Contact), TC (Technical Contact), or BC (Billing Contact). The Object Section SHOULD be copied for each Object (Contact or DNS server). Items 2a-2b contain information for an Object (Domain, Network, ASN, or Host) in the Linked Object Section. Item 2a is the Identifier of the Object. Item 2b is the Type of the Object. The Linked Object Section SHOULD be copied for each Object (Domain, Network, ASN, or Host). [Page 12] The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 13] Appendix C The Proposed Notify Template [ URL ftp://rs.internic.net/templates/notify-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Notify Version Number: 1.0 ************** Please see attached detailed instructions ************** 0a. (A)ck (N)ak.....: 0b. Comments........: Object 1a. Identifier......: 1b. Type............: 1c. Tracking Number.: The Notify Template will be used to notify a Contact of an Object before or after updating or using the Object, and get its approval. The InterNIC will fill in the information for the requested Object update or use in the template (Items 1a-1c) and send it to a Contact of the Object for approval. The Contact will, in turn, fill in the ACK/NAK response in the template (Items 0a-0b) and send it back to the InterNIC. If no ACK or NAK is received within 4 days for an Object update request or 2 days for an Object use request, the InterNIC may assume an implicit ACK or NAK depending on the type of request. Items 0a-0b contain the response from a Contact. Item 0a is the ACK/NAK response. It can have values A (Ack) or N (Nak). Item 0b contains the comments from the Contact on the approval or disapproval of the request. Items 1a-1c contain information for the requested Object update or use. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is the Tracking Number of the request. The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 14] Appendix D Object Update Rules IF Request from a Contact with Authentication Information Passive Notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE after updating the Object ELSE IF Request from a Contact without Authentication Information IF Object has at least one Contact with Authentication Information Active Notification to these Contacts before updating the Object ELSE IF Object has at least one of the other Contacts with Notify Update attribute set to BEFORE-UPDATE Active Notification to these Contacts before updating the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE after updating the Object ENDIF ENDIF ELSE IF Request from a Sender not listed as a Contact Notification to all the Contacts before updating the Object IF the InterNIC receives an ACK Object updated ELSE IF the Sender faxes a copy of its contract with the Object Holder Object updated ELSE IF the Object Holder faxes the request on corporate letterhead Object updated ELSE Object not updated ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 4 days Object updated ELSE Object not updated ENDIF Passive Notification: IF the InterNIC receives a NAK first within 4 days Object update revoked ELSE OK ENDIF [Page 15] Appendix E Object Use Rules IF Request from a Contact Passive Notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE after using the Object ELSE IF Request from a Sender not listed as a Contact IF Object has at least one Contact with Notify Use attribute set to BEFORE-USE Active Notification to these Contacts before using the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-USE after using the Object ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 2 days Object used ELSE Object not used ENDIF Passive Notification: IF the InterNIC receives a NAK first within 2 days Object use revoked ELSE OK ENDIF [Page 16] Appendix F Examples F.1 How to Register a New Contact with Authentication Information [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: N Contact Information 2a. NIC Handle..............: 2b. Name....................: Xary Y. Zmith 2c. (I)ndividual (R)ole.....: I 2d. Street Address..........: Fictitious Street 2e. City....................: Imaginary 2f. State...................: VA 2g. Postal Code.............: 22079 2h. Country Code............: US 2i. Phone Number............: 1-703-999-8484 2j. Fax Number..............: 1-703-999-8485 2k. E-Mailbox...............: xyz(a)internic.net Notify Information 3a. Notify Update...........: BEFORE-UPDATE 3b. Notify Use..............: AFTER-USE Authentication Information 4a. Auth Scheme.............: CRYPT-PW 4b. Auth Info...............: %.d!Hr3(a)rm.Gh 4c. Public (Y/N)............: Y Here, a new Contact Xary Y. Zmith is registered with CRYPT-PW as its Auth Scheme. The Contact will be notified before updating or after using an Object it is responsible for. The authentication information for the Contact will be visible in WHOIS. [Page 17] F.2 How to Link Guardian Information to Existing Records [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: N Object 1a. Identifier..............: XYZ10000 1b. Type....................: I 1c. Function................: TC Linked Object 2a. Identifier..............: HOST.EXAMPLE.COM 2b. Type....................: H In Example F.1, the new Contact is registered with NIC handle XYZ10000. Here, the Contact XYZ10000 is linked as Technical Contact to the Host HOST.EXAMPLE.COM. [Page 18] F.3 How to Update a Guarded Record [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: CRYPT-PW 0b. Auth Info...............: Cleartext Password 1. (N)ew (M)odify (D)elete.: M Contact Information 2a. NIC Handle..............: XYZ10000 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 1-703-999-8486 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: Here, the authorization information in items 0a-0b is first verified and then the record for the Contact XYZ10000 is updated. [Page 19] F.4 WHOIS Display of Guardian Information Whois: XYZ10000 Zmith, Xary Y. (XYZ10000) xyz(a)INTERNIC.NET Fictitious Street Imaginary, VA 22079 (703) 999-8486 (703) 999-8485 Auth Scheme: CRYPT-PW %.d!Hr3(a)rm.Gh Record last updated on 18-Jan-96. Here, the WHOIS display of the Guardian XYZ10000 contains its authentication information because its Public attribute is set to Y. [Page 20]

3 3