| Network Working Group | J. Macdonald |
| Internet Draft | e-Dialog |
| <macdonald-affiliated-nameslist-00-04dc (pre-release)> | D. Crocker |
| Intended status: Informational | Brandenburg InternetWorking |
| Expires: July 2009 | January 27, 2009 |
Affiliations List (AffiL)
macdonald-affiliated-nameslist-00-04dc (pre-release)
CONFORMANCE UNDEFINED.
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 in July 2009.
Domain names can be used as the core identifier in an assessment process, such as when filtering incoming email. One type of assessment is to note that the name is used by a person, role or organization having a particular affiliation, such as being part of a well-known company or being part of a salient industry association. Such a list is distinct from qualitative assessment lists, such as for email reputation. This specification provides a method for determining whether an individual, authenticated domain name has a particular affiliation. It provides a means by which the list owner can describe the list, but the specification does not indicate what affiliations exist or should be consulted. The specification uses Vouch By Reference (VBR) as its query mechanism.
Organizations are often referenced on the Internet in terms of their registered domain names. It can be helpful to determine whether a particular name is affiliated with a particular organization or, in turn, whether a particular organization itself has an "interesting" affiliation with some other organization, group or activity. The ability to discern these affiliations can provide useful input to an assessment process, such as for filtering inbound email. Affiliation is distinct from reputation, in that it is an objective statement about a relationship, rather than a more subjective statement about quality. Typically, an affiliation list merely documents an existing relationship, whereas quality assessment statements are the result of incremental and subjective work by the publisher. Hence, affiliations are more easily documented. In terms of using the publication information for performing decision-making by the consumer, the utility of an affiliations list is based on having the consumer of the list perform the quality assessment step, rather than the publisher.
Many different types of affiliation lists are possible. They can declare ownership by the publisher, some sort of permission by the publisher, membership in a group, and so on. Examples include:
This specification defines a method by which organizations can publish these affiliations in an online list, so as to permit easy verification. The means by which a potential user of a list learns of its existence and then decides to query it is outside the scope of this specification. It is a distributed, open process, much like discovering and deciding to use email addresses or web addresses.
Conventions used in this specification are defined by:
A list declares affiliation for a set of names, that is, association to the group or activity for which the list is published. It carries no additional semantics beyond the claim of membership. For example it does not suggest that a member of the list is a Good Actor or a Bad Actor in their email interactions with the consumer of the list. Lists can be self-published, by the owner of the listed names -- self-listed publication -- or by a different organization -- independent publication. The list is published by the list owner, so that presence on the list is self-authenticating and self-certifying. The list owner separately publishes an Affiliation Description which specifies the list's criteria for membership and provides any details for attributes encoded into a list entry.
A list is accessible via a domain name that is called the List Name. The owner of that domain name is called the List Owner.
The decision to consult a particular list is made in two stages. The first stage occurs long before the list is consulted and is performed as an administrative act. It is a strategic, deliberative activity that decides what lists are to be enabled for consultation.
The second stage occurs as part of regular, in-line operations, at the time lists are consulted. It is determined by immediate details of operation, such as the content or attributes of a received email.
When a list is queried, the primary result MUST be a binary statement of list membership: Is the queried domain in the queried list? The query MAY also produce related, parametric information about the queried domain.
AffiL uses Vouch By Reference (VBR) [I-D.VBR] as its query mechanism. As currently specified, VBR is defined for use by independent parties to certify a set of domain name owners that are associated with received mail. However, the mechanism equally can support publication by the owner of listed names. That is, it permits an organization to self-list a set of domain names. AffiL treats the cases of Self-Listing and Independent Listing as equivalent and the differences between the two are outside the cope of AffiL, but of course can be an important factor in a potential querier's decision about whether to consult a particular list.
Prior to consulting a particular list, a potential querier decides that this list is (sometimes) worthy of consultation. They decide to configure their run-time software to include the list for queries under specified conditions that the querier can envision. There are many different ways by which a potential querier might learn about the existence of a list and the details for it.
To assist such discovery efforts, the publisher MAY provide a web page that describes the list and specifies any special syntax and semantics for it. This section defines a standard format for such a description of an Affiliations List.
A list description comprises:
ABNF TBD
(Where is a List Description located?)
TBD
Content, such as email, typically contains many name references. Any of these might be a candidate as the name to use for an AffiL query. The choice is determined by the semantics of the list to be queried. If the VBR-Info tag is present, the md= can suggest the choice; other tags within the header field can indicate further query constraints.
A module that is performing assessments is likely to have a range of lists available for consulting. The first task, then, is to decide which to query. The factors that determine the choices will vary. For email, the presence of specific identifiers or specific types of identifiers will be important. For example, the rfc5322.From field might contain a well-known domain name that is often spoofed, or a validated identifier for message responsibility might need to be assessed.
As input to the decision process the data being evaluated MAY itself offer hints. For example, VBR is tailored for use with email and permits a message to contain a VBR-Info: header field. The field contains advice from the message creator. This advice is only a suggestion about lists to consult and MUST NOT be taken as confirming the affiliation that is claimed. That is, it can only be used as a hint by a possible list member about which lists should be consulted. Validation of affiliation can only be obtained by performing the query and queries SHOULD only be made of lists already vetted by the querier.
The primary semantic result of an AffiL query is a binary assessment about affiliation with a particular list. This assessment is then communicated to an external modules, such as an email Handling Filter that determines whether to deliver a message.
The mere fact that a person or organization is a member of a particular group can sometimes be useful in making an assessment. For example, if a message purports to be from a bank, evaluating that claim can benefit from being able to determine whether any domain names that it cites do, indeed, belong to a bank. One indication of status for the organization owning the cited domain name would be membership in a banking association.
This scenario in that the list owner is independent of the domain name owner(s), except for the relationship asserted through publication of the list.
List Description:
A company, conglomerate.example, sells many different products, under many different brand names. Some of these brands are spoofed, including by the use of look-alike domain names. The company wishes to list the set of domain names that actually are affiliated with conglomerate.example. One use of this would be for an anti-abuse filtering engine to detect when a message as purports to be from the company. Consulting the conglomerate.example list could determine whether the validated domain name(s) being used with the message are, in fact, used by the company
This example is distinctive in that the list owner is the same as the owner of the listed domain names.
List Description:
Organizations often outsourced their email processing, such as for sending large blocks of subscription-based email to customers. Such an Email Service Provider (ESP) is an authorized agent of the organization. However the ESP's own domain names have no obvious relationship to the authorizing organization. For some scenarios, it is decided to have authenticated domain names that are associated with messages be those of the ESP. The desire, then, is to permit the authorizing organization to declare that the ESP is an authorized agent for sending messages on behalf of the organization.
This scenario can appear to be similar to a membership listing. However it is distinctive in that the list owner is indicated through the content of the message -- notably including the author identifier, such as the From: field. Further, by virtue of declaring that the listed domains are acting as agents of the list owner, its semantics indicate an explicit degree of trust that the list owner is declaring for the listed domains.
List Description:
***** All drafts are required to have a security considerations section. *****
| [I-D.VBR] | Hoffman, P., Levine, K., and A. Hathcock, “Vouch By Reference (VBR)”, ID draft-hoffman-dac-vbr, December 2008. |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. |
| [RFC2434] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, RFC 2434, October 1998. |
| [I-D.email-arch] | Crocker, D., “Internet Mail Architecture”, Feb 2008. |
*** Procedures for registering a "type of list" label ***
*** Acknowledgements ***
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.
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, THE IETF TRUST 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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <http://www.ietf.org/ipr>.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.