DKIM Working Group                                               D. Otis
Internet-Draft                                               Trend Micro
Intended status: Standards Track                                D. Black
Expires: April 23, 2010                                 October 20, 2009


                  DKIM Third-Party Authorization Label
                      draft-otis-dkim-tpa-label-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 23, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   A third party authorization label (TPA-Label) is a DNS-based prefix
   for DKIM ADSP records that acts as a scheme for domains to authorize
   acceptable third-party signatures for messages containing their



Otis & Black             Expires April 23, 2010                 [Page 1]


Internet-Draft                  TPA-Label                   October 2009


   domain within the From header.  This scheme allows Author Domains to
   autonomously authorize a range of third-party domains using scalable,
   individual DNS transactions.  This authorization extends the scope of
   DKIM signing practice assertions as a means to supplant more
   difficult to administer schemes.  Alternatives for facilitating
   third-party authorizations currently necessitate the coordination
   between two or more domains to synchronously set up selector/key DNS
   records, DNS zone delegations, and/or the regular exchange of public/
   private keys.

   Checking TPA-Label Resource Records for signing practices may occur
   when an Author Domain Signature is missing or is invalid and a Third
   Party Signature exists.  When a third-party signature is found, TPA-
   Label Resource Record transactions offer an efficient means for
   Author Domains to authorize specific third-party signing domains and
   for recipients to determine whether an authorization exists.  The
   TPA-Label Resource Record scheme reduces reliance upon email source
   reputation that is often based upon an IP address rather than the
   domain.


Requirements Language

   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 [RFC2119].

























Otis & Black             Expires April 23, 2010                 [Page 2]


Internet-Draft                  TPA-Label                   October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Language and Terminology . . . . . . . . . . . . . . . . . . .  4
     2.1.  Terms Imported from other DKIM Specifications: . . . . . .  4
     2.2.  Terms Defined by this Specification: . . . . . . . . . . .  5
       2.2.1.  Third Party Domain . . . . . . . . . . . . . . . . . .  5
       2.2.2.  Third Party Signature  . . . . . . . . . . . . . . . .  5
       2.2.3.  Third Party Signer . . . . . . . . . . . . . . . . . .  5
       2.2.4.  TPA-Label Listed Domain  . . . . . . . . . . . . . . .  5
       2.2.5.  Author's Domain Acceptable Third-Party Signature . . .  5
   3.  TPA-Label Resource Record Authorization Considerations . . . .  6
     3.1.  Evaluating the Third-party Signing Domain  . . . . . . . .  6
       3.1.1.  Third Party Authentication . . . . . . . . . . . . . .  7
   4.  Abuse and DSN Reporting  . . . . . . . . . . . . . . . . . . .  8
   5.  DNS Representation . . . . . . . . . . . . . . . . . . . . . .  9
   6.  TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . .  9
   7.  TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 10
   8.  TPA-Label TXT Resource Record Structure  . . . . . . . . . . . 10
     8.1.  TPA-Label Resource Record Scope Syntax . . . . . . . . . . 11
       8.1.1.  TPA-Label Listed Domain Authorization  . . . . . . . . 11
       8.1.2.  List-ID Header Field . . . . . . . . . . . . . . . . . 11
       8.1.3.  Ancillary Use of Domain Authorizations . . . . . . . . 12
   9.  Authorized Signing Domain  . . . . . . . . . . . . . . . . . . 12
   10. TPA-Label Resource Record Query Transactions . . . . . . . . . 12
   11. TPA-Label Resource Record Compliance Assessment  . . . . . . . 13
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     12.1. Email Authentication Method Registry . . . . . . . . . . . 14
     12.2. Email Authentication Result Names Registry . . . . . . . . 16
     12.3. Third Party Authorizations Labels Registry . . . . . . . . 16
     12.4. Third Party Authorizations Scope Registry  . . . . . . . . 17
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
     13.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 18
     13.2. Risks to Recipients  . . . . . . . . . . . . . . . . . . . 18
     13.3. Benefits to Author Domains . . . . . . . . . . . . . . . . 18
     13.4. Risks to Author Domains  . . . . . . . . . . . . . . . . . 19
     13.5. Benefits to Third Party Signers  . . . . . . . . . . . . . 20
     13.6. Risks caused by Third Party Signers  . . . . . . . . . . . 20
     13.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 20
     13.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 20
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     15.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  DNS Example of TPA-Label Resource Record placement  . 22
   Appendix B.  C code for label generation . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28




Otis & Black             Expires April 23, 2010                 [Page 3]


Internet-Draft                  TPA-Label                   October 2009


1.  Introduction

   Normally a DKIM authorization effort will likely involve sharing a
   number of details between the domain owner, and one or more email and
   DNS providers.  Since there are many ways in which such
   authorizations can be accomplished, it is unlikely there will be
   consistent or standardized formats developed to exchange necessary,
   and at times, sensitive information.  In addition, when there is a
   security breach, the wrong party might be held accountable for
   content they may have never seen nor logged.  The TPA-Label Resource
   Record scheme permits the DKIM signature header to clarify who signed
   the message and on whose behalf, while also permitting greater
   control of specific header field authorizations made by the Author
   Domain.

   This document describes how any Author Domain publishing DKIM ADSP
   records defined in [RFC5617], can also autonomously authorize DKIM
   signatures [RFC4871] (updated by [RFC5672]) by specific third-party
   domains.  TPA-Label listed domains offer secondary signing practices
   for compliance options when no Author Domain Signature is present
   within the message.  Recommended or suggested actions for DKIM
   receivers are not included, and are considered "out-of-scope" for
   this document.  The receiver is considered best able to determine the
   impacts of email handling based on TPA-Label Resource Records.  The
   intended purpose of TPA-Label Resource Records are to improve
   acceptance rates of genuine messages and to lessen administrative
   costs associated with email.

   TPA-Label Resource Records authorize third-party signing domains as a
   means to extend DKIM compliance options for signing practices defined
   by [RFC5617].  TPA-Label listed domains are to be considered
   equivalent to the authorizing Author Domain when assessing compliance
   with DKIM signing practices.  The TXT resource records associated
   with TPA-Label start with the 'dkim' tag as defined by [RFC5617] for
   signing practices, and may contain tags specifically defined for TPA-
   Label Resource Records.


2.  Language and Terminology

2.1.  Terms Imported from other DKIM Specifications:

      A "Valid Signature" is any signature on a message that correctly
      verifies using the procedure described in Section 6.1 of
      [RFC4871].

      "Author Address" is defined in Section 2.3 of [RFC5617].




Otis & Black             Expires April 23, 2010                 [Page 4]


Internet-Draft                  TPA-Label                   October 2009


      "Author Domain" is defined in section 2.4 of [RFC5617].

      "Alleged Author" is defined in Section 2.5 of [RFC5617].

      "Author Domain Signature" is defined in Section 2.7 of [RFC5617]

2.2.  Terms Defined by this Specification:

2.2.1.  Third Party Domain

   A "Third Party Domain" is an originating domain within a message that
   is not at or below the Author Domain.

2.2.2.  Third Party Signature

   A "Third Party Signature" is a Valid Signature that does not qualify
   as a Author Domain Signature.

      Editor's Note: While this term is defined in Section 6 of
      [I-D.ietf-dkim-deployment] and in Section 2 of [RFC5016], this
      definition is in terms of the Author Domain Signature and avoids
      statements about any header field dependencies.

2.2.3.  Third Party Signer

   A "Third Party Signer" is a signer that adds a valid DKIM signature
   that references a Third Party Domain with the 'd=' tag in the DKIM-
   Signature header field.

2.2.4.  TPA-Label Listed Domain

   TPA-Label Listed Domain, TPA-LLD, is a domain TXT resource record
   that can be referenced with a TPA-Label within an Author Domain.
   When a "tpa" tag exists within the TXT resource record located at the
   TPA-Label, the referenced domain must be within a listed domain.
   When this tag does not exist, the referenced domain is presumed
   listed.  The "scope" tag provides the TPA-LLD authorization, limited
   to the scoped message elements, to act on behalf of Author Domain
   publishing the TPA-Label Resource Record.

2.2.5.  Author's Domain Acceptable Third-Party Signature

   An "Author's Domain Acceptable Third-Party Signature" is a Valid
   Signature in which the domain name of the DKIM signing entity, i.e.,
   the 'd=' tag in the DKIM-Signature header field, is the domain name
   referenced in the TPA-Label Resource Record published by the Author
   Domain with a scope of 'F', or 'L' when the List-ID is within the
   TPA-LLD.  Following [RFC5321], domain name comparisons as well as



Otis & Black             Expires April 23, 2010                 [Page 5]


Internet-Draft                  TPA-Label                   October 2009


   TPA-Labels are case insensitive.


3.  TPA-Label Resource Record Authorization Considerations

   When an Author Domain is not within the DKIM signing domain, the TPA-
   LLD scheme can safely extend ADSP signing practice compliance.  The
   TPA-LLD scheme with an 'F' or 'L' scope permits a contained Third
   Party Signature to be treated as a Author Domain Signature.  This
   avoids a need for Author Domains to always be within the public key
   reference for compliance with restrictive ADSP signing practices.
   The TPA-LLD scheme for offering valid signatures only requires that
   DNS publications be made by Author Domains, even when signing domains
   and the Author Domain differ.  This approach also avoids any need to
   exchange DKIM key information as well.

   While offering only valid signatures will not ensure all possible
   spoofing is prevented, messages signed in this manner should not
   receive annotations that indicate the message contains authenticated
   identities either.  The TPA-LLD scheme plays the role of only
   providing acceptable signatures which might be suitable for non-
   critical messages, where the goal would be to improve delivery
   acceptance, such as those from specific mailing-lists.  Before TPA-
   LLD authorization is deployed, the Author Domain should be assured by
   the domains being authorized that appropriate measures are in place
   to authenticate those submitting messages.

3.1.  Evaluating the Third-party Signing Domain

   An Author Domain deploying a TPA-Label Resource Record for a Third
   Party Signer does so on a trust basis.  Reasons for deploying TPA-
   Label Resource Records might be to allow selective deployment of more
   stringent ADSP records, such as "dkim=all".  TPA-Label Resource
   Records can help reduce the receiver's reliance upon reputation
   services when evaluating any signing practice compliance exception.
   In addition, most reputation services use IP addresses, rather than
   domains, as their basis for evaluation.  An IP address basis reduces
   the benefits that might be obtained by using DKIM signatures.  TPA-
   Label Resource Record authorization by-name scheme can influence
   whether a message is accepted or rejected, and might even impact the
   reputation of the Author Domain itself.

   This act of trust can be abused by Bad Actors when an authorized
   Third Party Signer does not employ necessary authentication control
   to ensure messages are from an Author Address before applying their
   signature.  A lack of authentication control may result in Bad Actors
   successfully spoofing an email as being from an Author Address by
   exploiting the authorization granted by a TPA-Label Resource Record.



Otis & Black             Expires April 23, 2010                 [Page 6]


Internet-Draft                  TPA-Label                   October 2009


3.1.1.  Third Party Authentication

   The Author Domain SHOULD ensure the Authorization Scope of the TPA-
   Label Resource Record is authenticated.  There are a number of ways
   email can be authenticated, and different authentication mechanism
   validate different parts of the email.  The following are examples of
   how authentication might work:

3.1.1.1.  Third Party Authentication - Web Email Provider with
          Subscriber Pingbacks

   The Author Domain "example.com" wants to deploy a TPA-Label Resource
   Record to permit their traveling agents the use of
   "webmail.example.net" services.  This email provider has a closed
   user policy and adds DKIM signatures to messages on behalf of the
   "webmail.example.net" domain.

   The closed user policy of "webmail.example.net" permits subscribers
   to post messages with Author Domains that are not
   "webmail.example.net" in the From header fields only when control of
   the Author Addresses has been validated by a response to an encoded
   "pingback" email.  The "webmail.example.net" service also establishes
   accounts to authenticate all users sending messages through their
   service.  Therefore, the referenced TPA-Label Resource Record can
   include an 'F' scope value to authorize Author Domain messages to be
   signed by this Third-Party Signer.

3.1.1.2.  Third Party Authentication - Closed Mailing List Example

   The Author Domain wants to deploy a TPA-Label Resource Record for a
   mailing list with a closed posting policy that redistributes email in
   a way that breaks Author Domain Signatures, but that adds a DKIM
   signature on behalf of their domain and includes an Authentication-
   Results header field for posted messages.  The closed posting policy
   is enforced by requiring subscribers to validate their control of
   their Author Address by responding to encoded "pingback" email sent
   to this address.

   Because the list management always verifies control of the Author
   Address, is configured to include Authentication-Results headers, the
   referenced TPA-Label Resource Record can include an 'L' scope value
   to permit Author Domain messages containing an authorized List-ID
   domain to be signed by this Third-Party Signer.

3.1.1.3.  Third Party Authentication - Open Mailing List Example

   The Author Domain wants to deploy a TPA-Label Resource Record for a
   mailing list with an open posting policy that redistributes email in



Otis & Black             Expires April 23, 2010                 [Page 7]


Internet-Draft                  TPA-Label                   October 2009


   a way that breaks Author Domain Signatures, but that adds a DKIM
   signature on behalf of their domain and includes an Authentication-
   Results header field for posted messages.  The open posting policy
   will refuse messages lacking Author Domain Signatures for domains
   that have deployed an ADSP signing practice of "dkim=all" or
   "dkim=discardable".

   Because the list management always refuses the posting of an Author
   Address lacking a Author Domain Signature when the domain has
   deployed an ADSP record with an "dkim=all" or "dkim=discardable", and
   is configured to include Authentication-Results headers, the
   referenced TPA-Label Resource Record can include an 'L' scope value
   to permit Author Domain messages containing an authorized List-ID
   domain to be signed by this Third-Party Signer.

3.1.1.4.  Third Party Authentication Example - Sender Header Field

   Author Domain "example.com" wishes to temporarily employ the service
   agency "temp.example.org" to handle overflow secretarial support.
   The agency "temp.example.org" sends email on behalf of the executive
   staff of "example.com" and adds the Sender header field of
   "secretary@example.org" in the email.  Since "temp.example.org" only
   allows its own staff to email through its server that adds
   "temp.example.org" DKIM signatures, a TPA-LLD can include the
   "temp.example.org" domain with 'O' and 'F' scope to specifically
   authorize the use of the Sender header field to help ensure these
   messages are not detected as a phishing attempt.

3.1.1.5.  Third Party Authentication Example - SMTP Host

   Author Domain "example.com" makes use of Virtual Private Servers to
   handle their enterprise services.  This VPS service provides a shared
   outbound SMTP server with the host name given by the EHLO command as
   "vps.example.net".  The Author Domain can authorize the domain
   "vps.example.net" with the scope of 'H' to improve acceptance of DKIM
   signed messages that are on behalf of "example.com" from this
   outbound server.


4.  Abuse and DSN Reporting

   The ancillary scopes available within the TPA-LLD records allow the
   Author Domain to be associated with SMTP Clients publicly
   transmitting messages and/or the Mail return path when these domains
   differ.  Appropriate DSN or abuse reporting is better assured as a
   result.  The correspondence between SMTP Client hosts and Mail return
   path can be affirmed by the TPA-LLD scheme with a scope of 'H' or 'M'
   that might be used to better categorize feedback data or DSN



Otis & Black             Expires April 23, 2010                 [Page 8]


Internet-Draft                  TPA-Label                   October 2009


   destinations.  In addition, a correspondence with SMTP Client hosts
   may help in determining which outbound SMTP Clients are to be
   monitored for consistent IP address use.  Relationships established
   between email related domains and stable hosts by the TPA-LLD scheme
   may provide both improved message acceptance and reporting criteria.


5.  DNS Representation

   The receiver obtains domain authorizations with a DNS query for an IN
   class TXT TPA-Label resource record located below the ADSP record
   location specified in [RFC5617] section 4.3.  The TPA-Label is
   normally generated by processing the domain referenced within the
   DKIM signature's "d=" parameter.  A TPA-Label Resource Record is then
   published below the [RFC5617] conventional ADSP record, for example
   below "._adsp.domainkey.<Author-Domain>".  The Author Domain provides
   authorization for other domains with the existence of a TPA-Label TXT
   resource record that when a "tpa" tag value exists, it includes the
   referenced domain.  Authorization to act on behalf of the Author
   Domain is limited by the "scope" tag value to specific message
   elements.

   Character-strings contained within the TXT resource record are
   concatenated into forming a single string.  A character-string is a
   single length octet followed by that number of characters treated as
   binary information.  As an example, a TPA-Label Resource Record may
   be located at these domains:

      <tpa-label>._adsp._domainkey.<Author-Domain>.



6.  TPA-Label and Tag Syntax Definitions

      "base32" function is defined in [RFC4648].

      "sha1" function is defined in [FIPS.180-2.2002].

      "lcase" converts upper-case ALPHA characters to lower-case.

      "signing-domain" is the "d=" tag value defined in Section 3.5 of
      [RFC4871].

   Augmented BNF for Syntax Specifications:

           asterisk = %x2A ; "*"
           dash = %x2D ; "-"
           dot = %x2E ; "."



Otis & Black             Expires April 23, 2010                 [Page 9]


Internet-Draft                  TPA-Label                   October 2009


           underscore = %x5F ; "_"
           ANY = asterisk dot ; "*."
           dns-char = ALPHA / DIGIT / dash
           id-prefix = ALPHA / DIGIT
           label = id-prefix [*61dns-char id-prefix]
           sldn = label dot label
           base-char = (dns-char / underscore)
           domain = *(label dot) sldn
           tpa-label = underscore base32( sha-1( lcase(signing-domain)))


7.  TPA-Label Generation

   The TPA-Label is created from the hash value returned by the "sha1"
   function of the signing-domain expressed in lower case ASCII.  The
   hash is then converted to a base32 character set, with the resulting
   label prefixed with an underscore.  Any terminating period is not
   included with the signing-domain, as indicated by the ABNF
   definition.

      Note: No newline character, 0x0A, is to be appended to the end of
      the domain name, as might occur with the command line generation
      of SHA1 values.  Command line appended newlines can be avoided by
      using the 'echo -n" option, for example.


8.  TPA-Label TXT Resource Record Structure

   Every TPA-Label TXT resource record MUST start with an outbound
   signing-practices tag, so the first four characters of the record are
   lowercase "dkim", followed by optional whitespace and "=".  In
   addition to the tags defined by [RFC5617], TPA-Label syntax
   descriptions for additional tags follow the tag-value syntax
   described in section 4.2.1 of [RFC5617] and section 3.2 of [RFC4871].
   Unrecognized tags and tags with illegal values MUST be ignored.  In
   the ABNF below, the WSP token is inherited from [RFC5322].  The ALPHA
   and DIGIT tokens are imported from [RFC5234].

   The tags used in TPA-Label resource records are as follows:

              +--------+------------------------------------+
              |   Tag  | Function                           |
              +--------+------------------------------------+
              | scope= | Authorization Scope List (as-list) |
              |  tpa=  | Authorized Domains List (ad-list)  |
              +--------+------------------------------------+

                          TPA-Label Extended Tags



Otis & Black             Expires April 23, 2010                [Page 10]


Internet-Draft                  TPA-Label                   October 2009


            +--------------+----------------------------------+
            | Scope Values | Field or Parameter               |
            +--------------+----------------------------------+
            |       F      | From (Author) Header             |
            |       L      | List-ID                          |
            |       O      | Other than From (Author) Headers |
            |       M      | MailFrom                         |
            |       H      | SMTP Host                        |
            +--------------+----------------------------------+

                          TPA-Label Scope Values

8.1.  TPA-Label Resource Record Scope Syntax

   scope= Authorization Scope List (Optional).  This tag defines a list
   of scoping assertions for various email-address locations within the
   message.  Only recognized scope values offer any form of DKIM
   authorization.

      scope = "F" / "L" / "O" / "M" / "H"
      as-list = "scope" [WSP] "=" [WSP] scope 0*([WSP] ":" [WSP] scope)

8.1.1.  TPA-Label Listed Domain Authorization

8.1.1.1.  From (Author) Header Field

   The "F" scope asserts that messages carrying the Author Domain within
   the From header field are authorized to be signed by the TPA-LLD.
   When the Third Party Signing Domain is within the TPA-LLD, then the
   signing practice, the value of the "dkim" tag, can supersede the
   signing practice generally asserted by the conventional ADSP record.


8.1.2.  List-ID Header Field

   The "L" scope asserts that a List-ID identifier of the List-ID header
   field [RFC2919] that is within the TPA-LLD are also authorized.  When
   the LIST-ID is within the TPA-LLD, then the signing practice, the
   value of the "dkim" tag, can supersede the signing practice generally
   asserted by the conventional ADSP record.  When 'L' is used in
   absence of the 'F' scope, then an 'F' scope is assumed only when
   List-ID is authorized.  Asserting a signing practice of "unknown" for
   an TPA-LLD might be used to aid acceptance of messages from mailing
   lists that have not yet adopted use of DKIM.







Otis & Black             Expires April 23, 2010                [Page 11]


Internet-Draft                  TPA-Label                   October 2009


8.1.3.  Ancillary Use of Domain Authorizations

   Ancillary Authorizations will not alter TPA-LLD results.

8.1.3.1.  Other Originating Header Fields

   The "O" scope asserts that messages with Sender, Resent-From, or
   Resent-Sender header fields with email-address domains within the
   TPA-LLD are also authorized.


8.1.3.2.  MailFrom Parameter

   This "M" scope asserts that an email-address domain that is within a
   TPA-LLD used in the [RFC5321] MAIL command is also authorized.


8.1.3.3.  SMTP Host domains

   The "H" scope asserts that host names given in [RFC5321] EHLO or HELO
   commands within TPA-LLD are also authorized.  This scope might be
   used to better ensure DKIM signatures within messages from these
   hosts are validated.



9.  Authorized Signing Domain

   tpa= Authorized Signing Domain list. (optional) This tag when
   present, MUST repeat all or portions of the domain encoded within the
   TPA-Label Resource Record.  This option ensures the proper handling
   of possible hash collisions.  When a domain is prefixed with the "*."
   ANY label, then all subdomains of this domain are to be considered
   included within the list.  When the 'tpa' tag is not present or has
   no value, it should be assumed to compare with the domain used to
   generate the TPA-Label.

      ad = [ANY] domain
      ad-list = "tpa" [WSP] "=" [WSP] ad 0*([WSP] ":" [WSP] ad)




10.  TPA-Label Resource Record Query Transactions

   The discovery of TPA-Label resource records need not be subsequent to
   the discovery of the ADSP record specified by [RFC5617].  However,
   when no ADSP record is discovered, the verifier MAY assume that no



Otis & Black             Expires April 23, 2010                [Page 12]


Internet-Draft                  TPA-Label                   October 2009


   TPA-Label Resource Records have been published below this location.
   Otherwise, when there is a Third Party Signature without any Author
   Domain Signature, then the discovery of TPA-Label Resource Records
   should be attempted.  The discovery of a TPA-Label Resource Record
   may be attempted for LIST-ID domains as well.


11.  TPA-Label Resource Record Compliance Assessment

   Signing practice compliance assessment of Third Party Signatures is a
   discretionary operation performed by the verifier.  Where a verifier
   decides to assess compliance with signing practices asserted by the
   Author Domain for Third Party Signatures, all of the following
   conditions MUST be met for the result to be considered a pass.

   o  The Third Party Signature MUST validate according to [RFC4871].
   o  The TPA-Label TXT Resource Record MUST exist in DNS.
   o  The TPA-Label TXT Resource Record Structure MUST be valid.
   o  Where a scope of "F" is specified, then the Author Domain MUST
      have an Author Domain Signature or an Author's Domain Acceptable
      Third-Party Signature.
   o  Where a scope of "L" is specified, then when a List-ID identifier
      in the List-ID header field is within the TPA-LLD, then the Author
      Domain MUST have an Author Domain Signature or an Author's Domain
      Acceptable Third-Party Signature.

   When the TPA-Label TXT Resource Record can not be retrieved due to
   some error that is likely transient in nature, as specified in
   [RFC5617] Section 4.3. such as "SERVFAIL" for example, the result of
   the TPA-Label Resource Record compliance assessment is "temperror".

   When the TPA-Label TXT Resource Record can not be retrieved with a
   DNS "NOERROR" with zero or more than one TXT records, the result of
   the TPA-Label Resource Record compliance assessment is "permerror".

   When the TPA-Label TXT Resource Record can not be retrieved with a
   DNS "NXDOMAIN",the result of the TPA-Label Resource Record compliance
   assessment is "nxdomain".

   When one or more valid Third-Party Signatures are present in the
   message, then:

   o  When a TPA-Label Resource Record referenced from the Author Domain
      has a scope tag of "F", and the TPA-LLD represents the domain of
      the DKIM signing entity, then the message is considered signed
      with an Author Domain Acceptable Third-Party Signature.

   o  When a TPA-Label Resource Record referenced from the Author Domain



Otis & Black             Expires April 23, 2010                [Page 13]


Internet-Draft                  TPA-Label                   October 2009


      has a scope tag of "L", and the List-ID given by [RFC2919] in the
      List-ID header is within the TPA-LLD, and the TPA-LLD represents
      the domain of the DKIM signing entity, then the message is
      considered signed with an Author Domain Acceptable Third-Party
      Signature.

   o  When a TPA-Label Resource Record referenced from the Author Domain
      returns a TXT resource record that has a scope tag of "O", and the
      email-address domain within the Sender, Resent-From, or Resent-
      Sender headers are within the TPA-LLD, use of these headers by
      this domain is authorized by the Author Domain.

   o  When a TPA-Label Resource Record referenced from the Author Domain
      returns a TXT resource record that has a scope tag of "M", and the
      email-address domain within the [RFC5321] MAIL command is within
      the TPA-LLD, use of this command by this domain is authorized by
      the Author Domain.

   o  When a TPA-Label Resource Record referenced from the Author Domain
      returns a TXT resource record that has a scope tag of "H", and a
      host domain given by [RFC5321] EHLO or HELO command is within the
      TPA-LLD, the SMTP client is authorized by the Author Domain.



12.  IANA Considerations

12.1.  Email Authentication Method Registry

   To accommodate the method derived from TPA-Label Resource Record
   processing, The IANA Registry "Email Authentication Method" defined
   by Section 6.2 of [RFC5451] needs the following elements to be added:

   Note to RFC EDITOR: This is currently located at: http://
   www.iana.org/assignments/email-auth/
   email-auth.xhtml#email-auth-methods















Otis & Black             Expires April 23, 2010                [Page 14]


Internet-Draft                  TPA-Label                   October 2009


   +---------+-----------+--------+----------+-------------------------+
   | Method  |  Defined  |  ptype | property | value                   |
   +---------+-----------+--------+----------+-------------------------+
   | tpa-lld |   [THIS   | header | d        | value of signature "d"  |
   |         | DOCUMENT] |        |          | tag.  The dkim method   |
   |         |           |        |          | results from [RFC5451]  |
   |         |           |        |          | should also be included |
   |         |           |        |          | in a Authenticated      |
   |         |           |        |          | Results header field    |
   |         |           |        | scope    | value of scope          |
   |         |           |        |          | (Section 12.4) tag.     |
   |         |           |        |          | (When 'scope' contains  |
   |         |           |        |          | 'H', the iprev          |
   |         |           |        |          | [RFC5451] (Section 3)   |
   |         |           |        |          | method results should   |
   |         |           |        |          | also be included in the |
   |         |           |        |          | Authenticated-Results   |
   |         |           |        |          | header field)           |
   |         |           |        | ca-scope | The scopes              |
   |         |           |        |          | (Section 12.4) with a   |
   |         |           |        |          | compliance assessment   |
   |         |           |        |          | as pass                 |
   |         |           |        | tpa      | Value of tpa            |
   |         |           |        |          | (Section 9) tag at time |
   |         |           |        |          | of compliance           |
   |         |           |        |          | assessment              |
   +---------+-----------+--------+----------+-------------------------+

                TPA-Label Resource Record validation Method






















Otis & Black             Expires April 23, 2010                [Page 15]


Internet-Draft                  TPA-Label                   October 2009


12.2.  Email Authentication Result Names Registry

   To accommodate the results derived from TPA-Label Resource Record
   processing, The IANA Registry "Email Authentication Method" defined
   by Section 6.3 of [RFC5451] needs the following elements added:

   Note to RFC EDITOR: This is currently located at: http://
   www.iana.org/assignments/email-auth/
   email-auth.xhtml#email-auth-result-names

   +--------------+---------+------------------------------------------+
   | code         | method  | meaning                                  |
   +--------------+---------+------------------------------------------+
   | none         | tpa-lld | No TPA-Label was published               |
   | pass         | tpa-lld | section Section 11                       |
   | tempfail     | tpa-lld | section Section 11                       |
   | permfail     | tpa-lld | section Section 11                       |
   | unknown      | tpa-lld | The TPA-Label Resource Record had a      |
   |              |         | tag/value of "dkim=unknown" and the      |
   |              |         | Third Party Signature failed its         |
   |              |         | compliance assessment.                   |
   | discard      | tpa-lld | The TPA-Label Resource Record had a      |
   |              |         | tag/value of dkim=discard and the Third  |
   |              |         | Party Signature failed its compliance    |
   |              |         | assessment.                              |
   | fail         | tpa-lld | The TPA-Label Resource Record had a      |
   |              |         | tag/value of dkim=all and the Third      |
   |              |         | Party Signature failed to its compliance |
   |              |         | assessment.                              |
   | nxdomain     | tpa-lld | When obtaining the TPA-Label Resource    |
   |              |         | Record, DNS indicated this domain does   |
   |              |         | not exist.                               |
   | Other value  | tpa-lld | The TPA-Label Resource Record had a      |
   | defined in   |         | tag/value of dkim={other value} and the  |
   | the IANA     |         | Third Party Signature failed to its      |
   | ADSP         |         | compliance assessment.                   |
   | Outbound     |         |                                          |
   | Signing      |         |                                          |
   | Practices    |         |                                          |
   | Registry     |         |                                          |
   +--------------+---------+------------------------------------------+

          TPA-Label Resource Record complaince assessment Results

12.3.  Third Party Authorizations Labels Registry

   Names of tags that are valid in TPA-Label Resource Records with the
   exception of experimental tags Section 8 MUST be registered in this



Otis & Black             Expires April 23, 2010                [Page 16]


Internet-Draft                  TPA-Label                   October 2009


   created IANA registry.

   New entries are assigned only for values that have been documented in
   a published RFC that has had IETF Review, per IANA CONSIDERATIONS
   [RFC5226].

   Each tag registered must correspond to a definition.

   The initial set of values for this registry is:

   +-------+-------------+---------------------------------------------+
   | tag   | defined     | definition                                  |
   +-------+-------------+---------------------------------------------+
   | dkim  | Section 8   | As per IANA Registry ADSP Outbound Signing  |
   |       |             | Practices                                   |
   | scope | Section 8.1 | Section 12.4                                |
   | tpa   | Section 9   | List of authorized domains                  |
   +-------+-------------+---------------------------------------------+

          TPA-Label Resource Record compliance assessment Results

12.4.  Third Party Authorizations Scope Registry

   Values that correspond to Section 8.1 MUST be registered in this
   created registry:

   New entries are assigned only for values that have been documented in
   a published RFC that has had IETF Review, per IANA CONSIDERATIONS
   [RFC5226].

   Each value registered must correspond to a definition.

   The initial set of values for this registry is:

                        +-------+-----------------+
                        | value | defined         |
                        +-------+-----------------+
                        | F     | Section 8.1.1   |
                        | L     | Section 8.1.2   |
                        | O     | Section 8.1.3.1 |
                        | M     | Section 8.1.3.2 |
                        | H     | Section 8.1.3.3 |
                        +-------+-----------------+

          TPA-Label Resource Record compliance assessment Results


13.  Security Considerations



Otis & Black             Expires April 23, 2010                [Page 17]


Internet-Draft                  TPA-Label                   October 2009


   This draft extends signing practices related to [RFC4871] where most
   generic DKIM Signature related security matters are discussed there.
   Security considerations for the TPA-Label Resource Record scheme are
   mostly related to attempts on the part of malicious senders to
   represent themselves as other senders, often in an attempt to defraud
   either the recipient or the alleged originator.  Additional security
   considerations regarding DKIM signing practices may be found in the
   DKIM threat analysis [RFC4686].

13.1.  Benefits to Recipients

   The verifier, after finding an Author's Domain Acceptable Third-Party
   Signature in a message, has a significantly greater confidence in the
   Third-Party authorization than when the no TPA-Label Resource Record
   could be retrieved.  This enhanced confidence may, at the recipients'
   discretion, cause a message to be delivered to recipient without
   further domain compliance assessment.

13.2.  Risks to Recipients

   The decisions that a recipient makes with regard to message filtering
   based on TPA-Label Resource Records is likely to depend on the system
   integrity of the Third Party with respect to Authentication (see
   Section 3.1.1) and the provided scope labels.  When the scope is not
   authenticated by the Third Party, there is a risk of accepting a
   potentially spoofed message.

   With this specification, third party signatures now have some
   verifiable value.  When implementing the compliance assessment of
   third party signatures and TPA-Label Resource Records, implementers
   need to consider the possibility that a Bad Actor will send the
   recipient a message with a large number of valid DKIM Signatures.
   Verifying all of these may consume a large amount of processing
   resources and it may be worth checking the existence of a TPA-Label
   Resource Record first.  Section 10 describes a quick check to see if
   TPA-Label Resource Records may exist.  Additionally validating DKIM
   signatures and obtaining related resource records might be limited to
   known trustworthy domains.

13.3.  Benefits to Author Domains

   TPA-Label resource records can replace domain delegations, selector/
   key record mirroring, or key exchanges.  Significant amounts of
   detail is associated with selector/key records.  These details
   include user limitations, suitable services, key resource record's
   Time-To-Live, revocation and update procedures, and how the DKIM
   Signature header field's 'i=' semantics are to be applied.  In
   addition, to better secure services that might depend upon DKIM keys,



Otis & Black             Expires April 23, 2010                [Page 18]


Internet-Draft                  TPA-Label                   October 2009


   rather than delegating DKIM keys, the TPA-LLD scheme allows Author
   Domains an ability to limit the scope of their authorizations,
   without being mistaken for having authenticated the entity submitting
   the message, or for running ancillary services that may make use of
   DKIM public keys.

   TPA-Label Resource Records convey which third-party domains are
   authoritative.  However, third-party domains are unable to utilize
   DKIM signature's 'i=' semantics to directly assert which identifiers
   on whose behalf a signature was added.  As such, no third-party
   domain should be authorized unless it is trusted to ensure the
   Alleged Author of an email undergoes some form authentication that
   offers acceptable protections for the Author Domain.  Such
   authentication might be to ensure submitting entities have
   demonstrated receipt of "pingback" messages sent to the Author
   Address contained within the messages being signed, for example.

   Author Domains benefit by deploying TPA-Label Resource Records in
   that a recipient who assesses signing practice compliance using the
   TPA-LLD scheme is less likely to drop messages from their domain.  In
   addition, the authorized third party domains are less likely to need
   reputations for the recipient to validate the signature and assess
   the message for compliance with signing practices.

   Scope labels provide a fine grained control that allows the Author
   Domain to limit message attributes even from the authorized third
   parties.

   Signing domains having good reputations referenced by a TPA-LLD might
   therefore provide a means to safely extend limited compliance
   assessment resources to otherwise unknown Author Domains or SMTP
   Clients.

13.4.  Risks to Author Domains

   As indicated in Section 3.1, there is ultimately a trust of the third
   party domain to do the right thing and not generate or allow others
   to generate messages that appear to be from the Author Domain.  The
   compliance assessment mechanisms deployed need to carefully match the
   scope of the TPA records.

   By authorizing some mailing lists with TPA-Label Resource Records
   there could be a loss of confidentiality in respect to mailing list
   domain participation by the Author Domain.  This might then help Bad
   Actors deduce which subscription email the Author Domain might
   receive.  Because of the hashing function in generating the TPA-
   label, anyone wishing to find out the authorized domains has to probe
   each TPA-label based on the exact signing domain.



Otis & Black             Expires April 23, 2010                [Page 19]


Internet-Draft                  TPA-Label                   October 2009


13.5.  Benefits to Third Party Signers

   Third Party Signers benefit by having the autonomy to deploy and
   change DKIM signing without consultation with Author Domains.  This
   is particularly useful for mailing lists.

13.6.  Risks caused by Third Party Signers

   Third Party Signers as mentioned before need to authenticate in some
   way messages from Author Domains.  This authentication provides a
   safety mechanism for the Author Domain and the recipient.  The Third
   Party may not be aware of the value of the authentication and change
   this without understanding the negative impact this may have on the
   author and recipient domains.  The Third Party also may stop DKIM
   signing messages also causing a detriment to both author and
   recipient.

13.7.  SHA-1 Collisions

   The use of the SHA-1 hash algorithm does not represent a security
   concern.  The hash simply ensures a deterministic domain-name size is
   achieved.  Unexpected collisions can be detected and handled by using
   the extended TPA-Label Resource Record "tpa=" option.  The use of
   TPA-Label Resource Records without the TPA-Label "tpa=" options does
   present an opportunity for an adversary to attempt to find a hash
   collision.  Message spoofing outside the realm of DKIM protection is
   still likely to be easier to achieve than finding hash collisions.

13.8.  DNS Limits

   Use of the TPA-Label Resource Records, rather than simply listing the
   authorized domain, ensures the DNS record size is independent of the
   Third Party Domain.  The typical domain name size has been steadily
   increasing.  This increase has been caused by domain names that
   encode international character sets, and perhaps soon an increase
   will be spurred by an expanse of TLDs having larger labels.

   Using TPA-Label Resource Records in the DNS, as described by this
   scheme, leaves a residual size of 430 for the length of the author
   domain and the resource record content.  DNS servers that add
   additional resource records, for nameservers as an example, will
   further limit this size.  Author Domains exceeding this length will
   need to rely on the recipients using TCP for DNS retrieval or
   extended DNS lengths [RFC2671].  Normally, DNS messages should not
   exceed 512 bytes as per Section 2.3.4 of [RFC1035].






Otis & Black             Expires April 23, 2010                [Page 20]


Internet-Draft                  TPA-Label                   October 2009


14.  Acknowledgements

   Frank Ellermann, and Wietse Venema.







15.  References

15.1.  Normative References

   [FIPS.180-2.2002]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002, <http://
              csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

   [RFC5617]  Allman, E., Fenton, J., Delany, M., and J. Levine,
              "DomainKeys Identified Mail (DKIM) Author Domain Signing
              Practices (ADSP)", RFC 5617, August 2009.



Otis & Black             Expires April 23, 2010                [Page 21]


Internet-Draft                  TPA-Label                   October 2009


15.2.  Informative References

   [I-D.ietf-dkim-deployment]
              Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development, Deployment
              and Operations", draft-ietf-dkim-deployment-08 (work in
              progress), August 2009.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC5016]  Thomas, M., "Requirements for a DomainKeys Identified Mail
              (DKIM) Signing Practices Protocol", RFC 5016,
              October 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5672]  Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
              Signatures -- Update", RFC 5672, August 2009.


Appendix A.  DNS Example of TPA-Label Resource Record placement

 ####
 # Practices for Example.com email domain using example.com, isp.com,
 # and example.com.isp.com as signing domains.
 ####

 #### 5322.From authorization for 3P domains ####

 ## "isp.com" TPA-Label Resource Record ##
 _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._adsp._domainkey.example.com. IN TXT
    "dkim=all; tpa=isp.com; scope=F;"

 #### 5322.From/Originator/MailFrom authorization for 3P domains ####

 ## "example.com.isp.com" TPA-Label Resource Record ##
 _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._adsp._domainkey.example.com.  IN TXT
    "dkim=all; tpa=*.isp.com; scope=F:O:M;"




Otis & Black             Expires April 23, 2010                [Page 22]


Internet-Draft                  TPA-Label                   October 2009


Appendix B.  C code for label generation

   The following utility can be compiled as tpa-label.c using the
   following:

   gcc -lcrypto tpa-label.c -o tpa-label

/*
 * TPA-Label generation utility
 * Copyright (C) 2009 The IETF Trust & and the persons identified as
 * the document authors.  All rights reserved.
 * Redistributions of source code must retain the above copyright
 * notice and the following disclaimer.
 *
 * 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.
 */

#include <stdio.h>
#include <sys/types.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <openssl/sha.h>

#define TPA_LABEL_VERSION   102
#define MAX_DOMAIN_NAME     256
#define MAX_FILE_NAME       1024

static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567";
static char sign_on[] =
{"%s v%d.%02d Copyright (C) (2009)  The IETF Trust & Douglas Otis\n"};
char err_cmd[] =\
 "ERR: Command error with [%s]\n";
char use_txt[]=\



Otis & Black             Expires April 23, 2010                [Page 23]


Internet-Draft                  TPA-Label                   October 2009


 "Usage: tpa-label [-i domain_input_file] [-o label_output_file][-v]\n";
char help_txt[]=\
"The options are as follows:\n"\
"-i  domain name input. Defaults to stdin. Removes trailing '.'\n"\
"-o  TPA-Label output.  Defaults to stdout.\n"\
"-v  Specifies Verbose Mode.\n\n";

static void usage(void);
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

static void
usage(void)
{
    (void) fprintf(stderr, "\n%s%s", use_txt, help_txt);
    exit(1);
}
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

int
main (int argc, char * argv[])
{
    int  ret_val, in_mode, out_mode, verbose, done, i, j, k;
    char ch;
    unsigned int len;
    unsigned long long b_5;
    char in_fn[MAX_FILE_NAME], out_fn[MAX_FILE_NAME];
    unsigned char in_buf[MAX_DOMAIN_NAME + 2];
    unsigned char sha_res[20], tpa_label[33];
    FILE *in_file, *out_file;

    ret_val = in_mode = out_mode = verbose = done = 0;
    len = 0;

    while ((ch = getopt(argc, argv, "i:o:v")) != -1)
    {
        switch (ch)
        {
            case 'i':
                in_mode = 1;          /* input from file */
                (void) strncpy(in_fn, optarg, sizeof(in_fn));
                in_fn[sizeof(in_fn) - 1] = '\0';
                break;
            case 'o':
                 out_mode = 1;         /* out to file */
                 (void) strncpy(out_fn, optarg, sizeof(out_fn));
                 out_fn[sizeof(out_fn) - 1] = '\0';
                 break;
            case 'v':



Otis & Black             Expires April 23, 2010                [Page 24]


Internet-Draft                  TPA-Label                   October 2009


                 verbose = 1;
                 break;
            case '?':
            default:
                (void) usage();
                break;
        }
    };

    if (in_mode)
    {
        if ((in_file = fopen(in_fn, "r")) == NULL)
        {
            (void) fprintf(stderr,
                           "ERR: Error opening [%s] input file.\n",
                           in_fn);
            exit(2);
        }
    }
    else
    {
        in_file = stdin;
    }

    if (out_mode)
    {
        if ((out_file = fopen(out_fn, "w")) == NULL)
        {
            (void) fprintf(stderr,
                           "ERR: Error opening [%s] output file.\n",
                           out_fn);
            exit(3);
        }
    }
    else
    {
        out_file = stdout;
    }

    if (out_mode && verbose)
    {
        (void) printf(sign_on, "tpa-label utility",
                      TPA_LABEL_VERSION / 100,
                      TPA_LABEL_VERSION % 100);
    }

    for (i = 0; i < MAX_DOMAIN_NAME && !done; i++)
    {



Otis & Black             Expires April 23, 2010                [Page 25]


Internet-Draft                  TPA-Label                   October 2009


        if ((ch = fgetc(in_file)) == EOF)
        {
            ch = 0;
        }
        else  if (ch == '\n' || ch == '\r')
        {
            ch = 0;
        }

        in_buf[i] = tolower(ch);

        if (ch == 0)
        {
            len = i;         /* string length */
            done = 1;
        }
    }

    if (!done)
    {
        (void) fprintf(stderr, "ERR: Domain name too long.\n");
        exit (4);
    }

    if (len && in_buf[len - 1] == '.')    /* remove any trailing "." */
    {
        len--;
        in_buf[len] = 0;     /* replace trailing "." with 0 */
    }

    in_buf[len] = 0;         /* terminate string */

    if (len < 2)
    {
        (void)
        fprintf(stderr,
                "ERR: Domain name [%s] too short with %d length.\n",
                in_buf,
                len);
        exit (5);
    }

    SHA1(in_buf, len, sha_res);

    if (verbose)
    {
        printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len);




Otis & Black             Expires April 23, 2010                [Page 26]


Internet-Draft                  TPA-Label                   October 2009


        for (i = 0; i < 20; i++)
        {
            printf("%02x", sha_res[i]);
        }
        printf("\nTPA-Label: 5 bit intervals left to right.\n");
    }

    /* process sha-1 results 4 times by 40 bits (0 to 160) */

    for (i = 0, j = 0; i < 4 ; i++)
    {
        b_5 =  (unsigned long long) sha_res[(i * 5)] << 32;
        b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24;
        b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16;
        b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8;
        b_5 |= (unsigned long long) sha_res[(i * 5) + 4];

        if (verbose)
        {
            printf(" {%010llX}->", b_5);
        }

        for (k = 35; k >= 0; k-= 5, j++)    /* convert 40 bits (5x8) */
        {
            tpa_label[j] = base32[(b_5 >> k) & 0x1F];

            if (verbose)
            {
                 printf(" %02X:%c",
                        (unsigned int)(b_5 >> k) & 0x1F,
                        tpa_label[j]);
            }
        }
        if (verbose)
        {
            printf ("\n");
        }
    }
    if (verbose)
    {
        printf("\n");
    }

    tpa_label[j] = 0;   /* terminate label string */
    fprintf(out_file, "_%s", tpa_label);
    printf("\n");

    /* close */



Otis & Black             Expires April 23, 2010                [Page 27]


Internet-Draft                  TPA-Label                   October 2009


    if (out_mode)
    {
        if (fclose (out_file) != 0)
        {
            (void) fprintf(stderr,
                           "ERR: Unable to close %s output file.\n",
                           out_fn);
            ret_val = 6;
        }
    }
    if (in_mode)
    {
        if (fclose (in_file) != 0)
        {
            (void) fprintf(stderr,
                           "ERR: Unable to close %s input file.\n",
                           in_fn);
             ret_val = 7;
        }
    }
    return (ret_val);
}


Authors' Addresses

   Douglas Otis
   Trend Micro
   10101 N. De Anza Blvd
   Cupertino, CA  95014
   USA

   Phone: +1.408.257-1500
   Email: doug_otis@trendmicro.com


   Daniel Black
   Canberra ACT
   Australia

   Email: daniel.subs@internode.on.net










Otis & Black             Expires April 23, 2010                [Page 28]