Internet Draft P. Hallam-Baker Document: draft-hallambaker-accreditation-00.txt VeriSign Inc. Expires: April 2004 Meng Weng Wong PoBox.com October 2004 DNS Publication of Accreditation Data Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2005. By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is intended to evolve, based on comments from readers. Comments and corrections are welcome, and may be sent to . Abstract Hallam-Baker Expires - April 2005 [Page 1] DNS Publication of Accreditation Data October 2004 This document describes a mechanism that may be used to publish accreditation data associated with email senders. The accreditation data may apply to an IP address or in the case that an appropriate authentication mechanism is used a domain name. An accreditation is a description by a third party that describes an email sender in some way that helps the recipient estimate the likelihood that a message authenticated as being originated by the sender is spam. Accreditations may be based on the observed behavior of the email sender (reputation accreditation) or on the basis of appropriate bona fides provided by the email sender and verified by a third party. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................3 1.1 Terminology................................................3 1.2 Accreditation and Authentication...........................4 1.3 Reputation Service (RS)....................................5 1.4 Verification Service.......................................5 1.5 Accountability of Accreditation Authorities................6 1.6 Announcements and Barriers to Entry........................7 1.7 Practices Considerations...................................7 1.8 DNS Publication Mechanism..................................7 1.9 Interpretation of Accreditation Statements.................8 2. Policy Notification Bindings...................................8 2.1 SPF and Sender ID..........................................8 3. Accreditation Schema...........................................9 3.1 Schema Announcement via DNS................................9 3.2 Example....................................................9 3.3 Schema....................................................11 3.4 Namespace Declarations....................................11 3.5 Element Accredit..........................................12 3.6 Element Collection........................................13 3.7 Element Distribution......................................14 3.8 Element DistributionDNS...................................14 3.9 Element DistributionText..................................15 3.10 Element Entry............................................15 3.11 Element EntryItem........................................16 3.12 Defined Representations..................................17 Hallam-Baker Expires - April 2005 [Page 2] DNS Publication of Accreditation Data October 2004 4. Accreditation Statements......................................18 4.1 DNS A Record..............................................18 4.2 Example...................................................18 4.3 Text format...............................................19 4.4 Example...................................................20 5. Filter Interpretation Guidelines..............................20 5.1 Establishing Provider Reputation..........................20 5.2 Combining Accreditations..................................21 6. Security Considerations.......................................21 6.1 Unauthenticated or Wrongly Authenticated Sender...........21 6.2 Untrustworthy Accreditation Provider......................21 6.3 Re-distribution attack....................................22 6.4 DNS Security Issues.......................................22 7. Appendix A: Collected Schema..................................22 References.......................................................24 Author's Addresses...............................................25 1. Introduction This specification describes a mechanism that may be used to indicate and publish accreditation statements associated with email senders. An accreditation statement is an assertion made by a third party known as an accreditation authority regarding a sender of email. Receivers of email may use accreditation statements as an input to policy decisions about the disposition of incoming mail. The architecture of this proposal generalizes existing industry practice with respect to publication of DNS blacklists according to the method proposed by Vixie [2]. In addition to supporting traditional blacklists this architecture suited to scenarios where an accreditation authority is reporting positive accreditation data about senders. The bulk of this document is styled as a prescription for receivers. It tells mail receivers how they should interpret and evaluate accreditation statements. Email senders and Accreditation Authorities are expected to construct their accreditation statements accordingly. 1.1 Terminology The following terms are used with specific meaning in this specification: Accreditation Authority A third party that issues Accreditation Statements. Hallam-Baker Expires - April 2005 [Page 3] DNS Publication of Accreditation Data October 2004 Accreditation Statement A statement issued by an Accreditation Authority that an email recipient may choose to use to help predict the behavior of an email sender Reputation Service An Accreditation Authority that issues Accreditation Statements that evaluate the Reputation of an email sender. Verification Service An Accreditation Authority that issues Accreditation Statements based on credentials presented by the email sender and verified by the authority. Announcement A machine-readable statement made by an email sender that indicates that an Accreditation Authority has issued an Accreditation Statement that refers to that sender. Accreditation Authority Schema A machine-readable document issued by an Accreditation Authority that describes the Accreditation Statements it publishes. 1.2 Accreditation and Authentication Accreditation is a generalization of the service provided by traditional email 'block lists'. Traditional block lists provide only negative reputation reports, listing email senders known to send large volumes of spam or who maintain an open relay mail server configuration likely to be abused by spammers. Traditional block lists have been limited to publishing reputation data indexed by the IP address of the outgoing mail server. This mechanism is of limited value when publishing positive reputation data that relates to the email sender using the IP address. The introduction of authentication makes it possible to publish an accreditation record that is tied to a domain name used by one of the parties responsible for sending it. This mechanism is better suited to the publication of data based on bona fides presented by the email sender and verified by a third party. Hallam-Baker Expires - April 2005 [Page 4] DNS Publication of Accreditation Data October 2004 Reputation Service (RS) A Reputation Service is an accreditation authority that offers information about the observed behavior of an email sender. It is generally desirable for a reputation service to provide data that is based on empirical measurement of objective criteria but a reputation service may choose to provide other forms of reputation. The following types of information are generally considered valuable in attempting to identify spam: Email Volume The volume of email sent by the sender Spam-Pot Volume The volume of email received from the sender at one or more 'honey-pot' email addresses. Complaint Volume The volume of complaints received concerning email from the sender. Caution SHOULD be taken when interpreting data of this type since it is not uncommon for malicious complaints to be made in order to perform a denial of service attack on a sender. Open Relay The email sender has been observed to operate email servers in an open relay configuration likely to be abused by spammers. A reputation service typically operates exclusively on behalf of email receivers. In most cases the email sender does not obtain either the approval or co-operation of the email sender whose reputation is reported. This raises the question of what recourse is or should be available to a party who believes that their reputation is rated unfairly. In some cases a reputation service has denied all responsibility to email senders and taken measures to prevent any party holding them accountable. 1.3 Verification Service A Verification Service issues Accreditation Statements based on credentials presented by the email sender and verified by the authority. The following types of accreditation issued by a verification service are likely to prove of particular advantage: Hallam-Baker Expires - April 2005 [Page 5] DNS Publication of Accreditation Data October 2004 Identity Accreditation The email sender has provided a real world identity and a physical address at which legal process can be served and this information has been authenticated by means of some trustworthy process. The accreditation authority may make this information available by open request or require a subpoena. Code of Conduct Accreditation In addition to meeting the identity accreditation requirements, the email sender has undertaken to comply with a specified email sending policy. Economic Accreditation The email sender has posted a performance bond or participates in some form of payments scheme that creates an economic incentive to comply with a code of conduct. Performance Accreditation The AA has determined that the email sender's practices do meet the requirements of a Code of Conduct policy. A verification service requires the email sender to present their credentials for verification and thus requires the active cooperation of email senders. A verification service is thus accountable to both senders (as customers) and receivers (as parties relying on the information provided). 1.4 Accountability of Accreditation Authorities The purpose of an accreditation authority is to hold email senders accountable to receivers. It is therefore important to ask the question of how accreditation authorities will be held accountable. A reputation service has a direct line of accountability to the email receivers who use the information it provides. A verification service has a direct line of accountability to email senders and an indirect line of accountability to receivers. In order for the receivers to be able to evaluate the performance of any type of accreditation authority an independent source of information is required. This might be by comparison to information provided by other accreditation authorities or by measuring the Hallam-Baker Expires - April 2005 [Page 6] DNS Publication of Accreditation Data October 2004 accuracy of the rating information against a corpus of email messages appropriately classified as spam or not spam. 1.5 Announcements and Barriers to Entry For the market in accreditation services to function well the barriers to entry must be appropriate. In particular it is important for new verification services to be able to enter the market without artificial barriers to entry such as magic lists of 'approved' providers. We propose that this problem be addressed by allowing email senders to specify the accreditation providers who list them. Although it is unlikely that any individual would specify an accreditation provider that gave them a bad rating, an accreditation service that had established a sufficiently high reputation on the basis of its positive accreditations could offer to supply negative ratings. 1.6 Practices Considerations As a trusted third party the actions of an Accreditation Authority raise numerous legal issues. These issues are outside the scope of this document and have been considered at length in the context of PKI Certification Authorities. 1.7 DNS Publication Mechanism The DNS is currently used as the defacto standard protocol by which Reputation Services publish accreditation data. The DNS protocol has many advantages including being lightweight, requiring only one UDP round trip connection to return information and having the benefit of an extensive deployed cache infrastructure. The principle limitations of using DNS are that responses can only carry a limited amount of information and a separate transaction is required for each query. Current practice amongst reputation services makes use of the DNS A record as the principle means for reporting the reputation associated with a given IP address. This follows the practice originally established by Paul Vixie [2]. The query is constructed by mapping the IP address space to the DNS name space using the naming convention established by the reverse DNS in which the IP address segments are written backwards. The response consists of Hallam-Baker Expires - April 2005 [Page 7] DNS Publication of Accreditation Data October 2004 one or more DNS A records that are usually given in the loopback address range (127.x.x.x) to avoid accidental confusion with legitimate IP addresses. For example to obtain the reputation of IP address 192.168.0.1 from the reputation service dnsbl.example.com a request is made for the A record(s) associated with the DNS name 1.0.168.192.dnsbl.example.com. A response of 127.0.0.0 might indicate that the reputation of the address queried was good, 127.0.0.1 that the reputation was bad. The principle disadvantage of this scheme is that it does not support query by domain name and the protocol gives the requestor no guidance on the interpretation of the returned records. In this document we define mechanism that allows an Accreditation Authority to describe the protocols through which information may be obtained and the format of the information returned. 1.8 Interpretation of Accreditation Statements Email recipients MAY interpret Accreditation Statements in any fashion they choose, including regarding an Accreditation Statement as a negative indicator. 2. Policy Notification Bindings Policy notification bindings are specified for the SPF syntax used in Sender ID. 2.1 SPF and Sender ID A sender which has registered with an AA SHOULD use the SPF modifier 'accredit' to notify recipients of that fact. accredit= The expands to a . That tells a receiver where to query accreditation credentials. Optional submodifiers may provide further information. This document reserves and defines the "schema" submodifier. Unrecognized submodifiers MUST be ignored by receivers. Example accreditation modifiers: Hallam-Baker Expires - April 2005 [Page 8] DNS Publication of Accreditation Data October 2004 accredit=aa.example.com accredit=%{d}.aa.example.com accredit=%{i}.aa.example.com Queries are constructed based on the according to the indicated schema. The may not actually contain any macros: if the string does contain macros, those macros exist only as hints to the query constructor. They MUST NOT be expanded before being handed to the vouch query constructor; it is the responsibility of the vouch query constructor to validate the macro-string according to the chosen schema, and only if the macro- string is valid, to expand those macros and use them as part of the vouch query. 3. Accreditation Schema A schema record points to a document which describes the syntax and semantics of the vouches. That document is meant to be read or recognized by filters which analyze the vouch records accordingly. Since the schema data may be provided by an untrustworthy or even a malicious source, a filter which does not recognize a given schema is, naturally, not required to fully engage the DTD. 3.1 Schema Announcement via DNS An accreditation authority may publish the location of an accreditation schema using a DNS TXT record. The record has the prefix _schema to distinguish it from other TXT records that may exist for that node. The corresponding data value is a URI that provides the location of the schema. _schema.aa.example.com TXT "http://schema.aa.example.com/schema.txt" Knowing the type of information that an accreditation record expresses is useful when attempting to compare the information provided by one accreditation source with information from other sources. Accreditation sources that claim to provide the same type of information should show a high degree of correlation in the information they provide. Example Hallam-Baker Expires - April 2005 [Page 9] DNS Publication of Accreditation Data October 2004 The following accreditation schema describes an accreditation service that publishes both reputation and verification data via a traditional DNS lookup scheme and through a text file. The accreditation service provides four basic streams of data as follows: Data Stream A Record Range Verified Data 127.0.0.x Reputation - Email Volume 127.1.x.x Reputation - Complaint Volume 127.2.x.x Reputation - Spamtrap Volume 127.3.x.x The accreditation service offers a variety of verification programs. In the simplest program only the identity of the sender is verified. In a second program the sender undertakes to observe a code-of-conduct and may additionally be enrolled in one of three code-of-conduct programs specific to a particular field. Records in the verified data stream are subdivided into 6 bit fields as follows: Bit 0 Identity verification Bit 1 Conduct accreditation - General Bit 2 Conduct accreditation - ISP program Bit 3 Conduct accreditation - Bulk email sender program Bit 4 Conduct accreditation - Enterprise program Bit 5-7 Conduct accreditation - Compliance performance Hallam-Baker Expires - April 2005 [Page 10] DNS Publication of Accreditation Data October 2004 3.2 Schema Namespace Declarations The schema does not import or extend any other schema. The schema namespace is: http://xmltrustcenter.org/schemas/2004/10/accredit.xsd The following schema contains the schema preamble, namespace definition and closing: Hallam-Baker Expires - April 2005 [Page 11] DNS Publication of Accreditation Data October 2004 XML Schema for Accreditation Distribution Description ... Element Accredit The Accredit element is the toplevel element of an accreditation description and may contain one or more collections of accreditation data. The Accredit element may contain the following elements. Collection [One or more] A signature key that may be used to sign messages from the domain. The following schema defines the Accredit element: Hallam-Baker Expires - April 2005 [Page 12] DNS Publication of Accreditation Data October 2004 Element Collection The Collection element specifies a collection of related accreditation data. The Collection element may contain the following attributes. Open If true the accreditation service is open and MAY be consulted to obtain information even if the sender does not list the service as an accreditor. Index Specifies the index by which the collection is organized. Possible values are "IP" for a collection indexed by originating IP address and "Domain" for a collection indexed by domain name. The Collection element may contain the following elements. Distribution [Any number] A protocol that may be used to retrieve the data in the collection. Entry [Any number] A description of a data field entry The following schema defines the Collection element: Hallam-Baker Expires - April 2005 [Page 13] DNS Publication of Accreditation Data October 2004 Element Distribution The Distribution element is an abstract placeholder element that is inherited by the DistributionDNS and DistributionText elements that specify a distribution via a specific protocol. The following schema defines the Distribution element: Element DistributionDNS The DistributionDNS element specifies means of accessing the collection through a DNS server. The following attribute values are defined: Record The accreditation data is encoded in DNS A records. Domain The distribution point for the domain information. The following schema defines the DistributionDNS element: Hallam-Baker Expires - April 2005 [Page 14] DNS Publication of Accreditation Data October 2004 Element DistributionText The DistributionText element describes a distribution of the data collection by means of a text file. The following attribute values are defined: Location A URI that specifies the location of the text distribution Algorithm Specifies a one-way hash or MAC algorithm used to obfuscate the index key values (domain name or IP address). Key Specifies a key for use with the MAC algorithm to obfuscate the index key values. The following schema defines the DistributionText element: Element Entry The Entry element specifies the encoding of a data stream within a collection. The Entry element may contain the following attributes Prefix An integer prefix value used to identify this entry when data is encoded using the DNS-A protocol. Hallam-Baker Expires - April 2005 [Page 15] DNS Publication of Accreditation Data October 2004 PrefixLength The length of the prefix in bits. Element EntryItem The EntryItem element specifies the encoding of a data field within a data stream. The EntryItem element may contain the following attributes Position The bit field offset of the entry Length The number of bits used to encode the entry Scale {log2 | log10 | linear | none} The scale to be applied when comparing the corresponding record values. Precision For a logarithmic scale specifies the number of bits to the right of the decimal point. Represents A URI that indicates the value represented by the entry item. A table of pre-defined values is given in Section 3.3. Hallam-Baker Expires - April 2005 [Page 16] DNS Publication of Accreditation Data October 2004 Title A human readable title for the scale which applications may use to provide explanatory feedback. Reverse It true the scale runs in the reverse direction to that specified by the representation value. The following schema defines the EntryItem element: 3.3 Defined Representations The following URIs are defined for use as representation specifiers. Additional representation specifiers may be given by means of a URI. Identifier Referenced value #Volume Proportional to the total volume of email sent. #SpamTrap Proportional to the volume of email sent to spam traps #Complaint Proportional to the volume of complaints received (and optionally verified or otherwise validated) #OpenRelay If set to 1 indicates an open relay has been detected Hallam-Baker Expires - April 2005 [Page 17] DNS Publication of Accreditation Data October 2004 #Identity If set to 1 indicates that the corresponding domain name has been subject to identity verification and has passed. #Conduct If set to 1 indicates that the holder of the corresponding domain name has undertaken to comply with a code of conduct. #Economic If set to 1 indicates that the holder of the corresponding domain name has undertaken to comply with a code of conduct with an economic incentive to maintain compliance. #Performance Indicates the degree to which the holder of the corresponding domain name has been observed to comply with an a code of conduct. The value 0 indicates that the holder has not undertaken compliance, values greater than zero indicate successively greater degrees of compliance. 4. Accreditation Statements 4.1 DNS A Record Accreditation statements may be published by means of a DNS A record distribution. In order to avoid undesirable side effects from logic errors or misconfiguration it is recommended that the address range used is in the loop-back address space 127.x.x.x. The data in the A record is interpreted using direction provided by the accreditation authority description record. Example Using the accreditation schema specified earlier the following addresses are interpreted as follows: example.com A record 10.0.0.1 Ignored, not matched by any prefix specified in the corresponding schema 127.128.0.0 Ignored, not matched by any prefix specified in the corresponding schema Hallam-Baker Expires - April 2005 [Page 18] DNS Publication of Accreditation Data October 2004 127.0.0.0 No form of verification accreditation has been issued to example.com 127.0.0.1 example.com has passed the identity verification process 127.0.0.2 example.com has been accepted as making the general code of conduct undertaking 127.0.0.3 example.com has passed the identity verification process and been accepted as making the general code of conduct undertaking 127.1.0.10 example.com sends a relatively small volume of email 127.1.200.23 example.com sends a relatively huge volume of email Multiple data values may be given: 127.1.0.50, 127.2.0.35,127.3.0.100 These values indicate that the email sender sends a relatively small volume of email (50 units) but sends a significant volume of email to spam traps (35 units) and generates a significant volume of complaints (100 units) 127.1.50,0, 127.2.0.35,127.3.0.100 These values indicate that the email sender sends a relatively large volume of email (12,800 units) and has the same volume of email sent to spam traps and the same complaint volume. All data values MUST be considered in the context of the accreditation provider that supplied them. A value of 100 complaint units from one accreditation provider may indicate a much larger complaint volume than a value of 10,000 units from another provider. Complaint and spam trap volume SHOULD be considered in the context of the sender profile, in particular the type of business they perform and the volume of mail sent. The first set of data shows a high incidence of problems relative to the volume of mail while the second shows the same incidence of problems for a much higher volume of mail. It is therefore likely that the first email sender is a spammer while the second mostly sends legitimate mail. 4.2 Text format The text record format consists of a series of lines as follows: Hallam-Baker Expires - April 2005 [Page 19] DNS Publication of Accreditation Data October 2004 Lines beginning with the # or % character contain comments and are ignored. If a # character appears in the middle of a line the rest of the line is ignored. Data lines consist of a data field followed by one or more space delimited entry fields. Each entry is encoded in hexadecimal. Example example.com 7f000000 # equivalent to 127.0.0.0 a1.example.com 7f000001 # equivalent to 127.0.0.1 r1.example.com 7f010032 7f020023 7f030064 r2.example.com 7f013200 7f020023 7f030064 5. Filter Interpretation Guidelines In the typical use case, we expect accreditation records to be interpreted by a receiver-side email filtering system. We expect such a system to primarily interested in reading accreditation statements to estimate the desirability of incoming mail. An email filter MAY make any use it chooses of information provided. Accreditation information may come from an untrustworthy or even outright malicious source. The fact that an email sender is accredited by such a source MAY be considered a negative judgment on the reputation of the source. 5.1 Establishing Provider Reputation It is suggested that email filters SHOULD determine weightings to assign to accreditation notices from particular Accreditation Authorities by means of empirical measurement of their effectiveness rather than fixed a-priori values. If fixed weightings are assigned it SHOULD be possible to override these values. For example an email recipient receiving a large quantity of email might perform an analysis of the accuracy of various Accreditation Authorities on a statistically significant sample of that email. Recipients of smaller quantities of email might rely on third party assessments of the accuracy of Accreditation Authorities or on feedback from end-users identifying messages that have been wrongly categorized. Hallam-Baker Expires - April 2005 [Page 20] DNS Publication of Accreditation Data October 2004 5.2 Combining Accreditations When combining Accreditations from different Accreditation Providers filters MAY use the information provided in the Accreditation Authority Description record to determine whether the information provided is likely to have dependencies or not. For example an email sender that is accredited by two different Accreditation Authorities that verify identity information is not likely to be significantly less likely to be a spammer than an email sender that is only accredited by one Accreditation Authority. But an Email sender that is accredited by one Accreditation Authority that verifies identity information and another that monitors complaints from end users is less likely to be a spammer than a sender with only one of the accreditations. 6. Security Considerations 6.1 Unauthenticated or Wrongly Authenticated Sender A positive accreditation has no value if someone other than the accreditation subject can make use of it. It is therefore essential for the sender of an email to be accredited before a positive weight is given to an accreditation value. 6.2 Untrustworthy Accreditation Provider An Accreditation Authority may be untrustworthy for many reasons, they may perform their activities in a negligent fashion or with actual malice. For example a spammer might run an unrestricted accreditation service that accurately listed all his rivals as spammers but did not list the spammer who operated the service. Alternatively an Accreditation service may maliciously publish a negative reputation about a subject. For this reason email filters MUST evaluate the reputation of the Accreditation Authority as well as the data provided by that authority. The number of email senders that reference accreditation records published by an Accreditation Authority MAY provide an indication of the relative trustworthiness of that provider. Hallam-Baker Expires - April 2005 [Page 21] DNS Publication of Accreditation Data October 2004 6.3 Re-distribution attack If accreditation services are evaluated on reputation alone an attacker may be able to perform a redistribution attack in which the false accreditation provider appropriates data from a legitimate accreditation service and republish it with limited changes to affect a small number of targeted sites. 6.4 DNS Security Issues The DNS protocol does not provide cryptographic assurance of the integrity of the information published and is vulnerable to Denial of Service attacks. These weaknesses do not seriously affect the security of the accreditation mechanism when used for the purpose of spam reduction but may affect the security of the mechanism if it is applied to other purposes. 7. Appendix A: Collected Schema XML Schema for Accreditation Distribution Description Hallam-Baker Expires - April 2005 [Page 22] DNS Publication of Accreditation Data October 2004 Hallam-Baker Expires - April 2005 [Page 23] DNS Publication of Accreditation Data October 2004 References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Paul Vixie, Proposal to IETF ASRG working group. http://www1.ietf.org/mail-archive/working- groups/asrg/current/msg04508.html Notices Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." Hallam-Baker Expires - April 2005 [Page 24] DNS Publication of Accreditation Data October 2004 "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Acknowledgments The author acknowledges the contributions made to this proposal by Jeff Burstein and Nico Popp of VeriSign, Harry Katz and Bob Atkinson of Microsoft and Ann Mitchell Esq. Author's Addresses Phillip Hallam-Baker VeriSign Inc. Email: pbaker@verisign.com Meng Weng Wong PoBox.com Hallam-Baker Expires - April 2005 [Page 25]