DKIM Working Group D. Otis Internet-Draft Trend Micro Intended status: Standards Track October 11, 2009 Expires: April 14, 2010 DKIM Third-Party Authorization Label draft-otis-dkim-tpa-label-02 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 14, 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 TPA-Label is a DNS-based prefix for DKIM policy records that acts as a scheme for domains to authorize acceptable third-party signatures for messages containing their domain within the From Otis Expires April 14, 2010 [Page 1] Internet-Draft TPA-Label October 2009 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 policy 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 DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a third-party signature is found, TPA-Label transactions offer an efficient means for Author Domains to authorize specific third-party signing domains. 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 Expires April 14, 2010 [Page 2] Internet-Draft TPA-Label October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 2.1. Terms Imported from the DKIM ADSP Record Specification . . 5 2.1.1. Author Domain . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Author Domain Signature . . . . . . . . . . . . . . . 5 2.2. Terms Defined by this Specification . . . . . . . . . . . 5 2.2.1. TPA-Label Listed Domain . . . . . . . . . . . . . . . 5 2.2.2. Author's Domain Acceptable Third-Party Signature . . . 5 3. Evaluating Signing Domains . . . . . . . . . . . . . . . . . . 5 4. Authorization Scope . . . . . . . . . . . . . . . . . . . . . 6 5. TPA-Label Tag Definitions . . . . . . . . . . . . . . . . . . 7 6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. TPA-Label Listed Domain Authorization . . . . . . . . . . 9 6.1.1. From (Author) Header Field . . . . . . . . . . . . . . 9 6.2. Use of Domain Authorization . . . . . . . . . . . . . . . 9 6.2.1. Other Originating Header Fields . . . . . . . . . . . 9 6.2.2. MailFrom Parameter . . . . . . . . . . . . . . . . . . 9 6.2.3. SMTP Host domains . . . . . . . . . . . . . . . . . . 9 6.3. NO-TPA . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Authorized Signing Domain . . . . . . . . . . . . . . . . . . 10 8. Use of TPA-Label Resource Records . . . . . . . . . . . . . . 10 9. Authentication-Results Header Extended Results . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. DNS Example of TPA-Label policy record placement . . 14 Appendix B. C code for label generation . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Otis Expires April 14, 2010 [Page 3] Internet-Draft TPA-Label October 2009 1. Introduction This document describes how any Author Domain publishing DKIM policy records, such as those defined in [RFC5617], can also autonomously authorize [RFC4871] signing by specific third-party domains. TPA- Label listed domains offer secondary policy compliance options when no valid 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 assumed to better understand their environment's impact upon the performance of DKIM signatures and how the transactional results are best utilized. TPA-Labels authorize third-party signing domains as a means to extend DKIM policy compliance options defined by [RFC5617]. TPA-Label listed domains are to be considered equivalent to the authorizing Author Domain in the application of DKIM policies. The TXT records associated with TPA-Labels start with the 'dkim' tag as defined by [RFC5617], and may contain tags specifically defined for TPA-Labels. This scheme can eliminate the complex coordination of selector/key DNS records, DNS delegation, or exchanges of public/private keys between two or more domains otherwise required to facilitate transparent authorizations. Trust is an essential requisite before the DKIM signature header field's 'i=' semantics provide valuable advisory information. This advisory information is in regard to the "on-behalf-of" identity as a means to enable safer message annotations, and to better ensure trusted identities are recognized. However, in the case of third- party signatures, the 'i=' value will not directly reflect an email- address found within the From header, but would be in the form of an alias. TPA-Labels 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 submitting entities have demonstrated receipt of messages sent to the From header address contained within the domain's signed messages. Otis Expires April 14, 2010 [Page 4] Internet-Draft TPA-Label October 2009 2. Language and Terminology 2.1. Terms Imported from the DKIM ADSP Record Specification 2.1.1. Author Domain An "Author Domain" is everything to the right of the "@" in an Author Address (excluding the "@" itself). 2.1.2. Author Domain Signature An "Author Domain 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 same as the domain name in the Author Address. Following [RFC5321], domain name comparisons are case insensitive. 2.2. Terms Defined by this Specification 2.2.1. TPA-Label Listed Domain TPA-Label Listed Domain, TPA-LLD, is the domain referenced as authorization to act on behalf of the Author Domain. 2.2.2. 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 published by the Author Domain with a scope of 'F'. Following [RFC5321], domain name comparisons as well as TPA-Labels are case insensitive. 3. Evaluating Signing Domains Regulatory agencies are unable to control Internet abuse by curtailing access. Unlike IPv4 addresses, there is virtually no limit on the number of domain-names available. Registrar pricing of domain-names need to remain uniform. Otherwise, fees based upon the intrinsic value of a name could cause name holders to become extortion targets. High initial costs for domain-names are also unlikely to represent a deterrent, largely due to high levels of payment fraud. In addition, DKIM can not directly identify the domain transmitting the message, and can not prevent abusive message replay. Abusive message replay may prove indistinguishable from bulk mailings of Otis Expires April 14, 2010 [Page 5] Internet-Draft TPA-Label October 2009 various types. Since abuse may be beyond the control of the Author Domain, message acceptance might become dependent upon an scheme that helps receivers to correlate DKIM signing domains and SMTP clients with domains that have been authorized to sign or transmit messages carrying the Author Domain. Appropriate abuse reporting is facilitated when signing domains correspond with domains administering SMTP Clients publicly transmitting messages. This correspondence between SMTP Client hosts with DKIM signing domains and Author Domains can be affirmed by the TPA-LLD scheme. A correspondence with SMTP Client hosts help determine which should be monitored for consistent IP address use. Relationships established between email related domains and stable hosts by the TPA-LLD scheme can provide improved message acceptance and reporting criteria. A receiver's evaluation process will confront many domains with unknown reputations. New domains are constantly being introduced where registrars are unable to prevent bad actors from controlling either new or previously held domain names. Receivers may seek to limit a DKIM verification process, since acquiring policy records or DKIM keys may inadvertently leak valuable information that could benefit bad actors. Processing all DKIM signatures may also inundate a receiver's limited resources. As a result, validating DKIM signatures and obtaining related resource records might be limited to known trustworthy domains. Signing domains having good reputations referenced by a TPA-LLD might provide a means to safely extend limited verification resources to otherwise unknown Author Domains or SMTP Clients. 4. Authorization Scope Without the TPA-LLD scheme, an 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-LLD scheme permits the DKIM signature header to clarify who signed the message and on whose behalf, while also permitting greater control by the Author Domain. TPA-Label resource records replace domain delegations, selector/key record mirroring, or key exchanges. Significant amounts of detail is associated with selector/key records. These details include user Otis Expires April 14, 2010 [Page 6] Internet-Draft TPA-Label October 2009 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, 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. When an Author Domain is not within the DKIM signing domain, the TPA- LLD scheme safely extends policy compliance where a DNS publication is only required by the Author Domain, even when signing domains and the email-address domains differ. While offering only valid signatures will not ensure all possible spoofing is prevented, messages signed in this manner should not receive annotations indicating messages contain 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. 5. TPA-Label Tag Definitions 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 tags defined by [RFC5617], TPA-Label syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC5234]. The "base32" function is defined in [RFC4648] and the "sha-1" hash function is defined in [FIPS.180-2.2002]. The TPA-Label TXT resource records 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 function "lcase" converts upper- case ALPHA characters to lower-case. The function "sha-1" returns a hash that is converted to a base32 character set. The terminating period is not included in domain-name conversions as indicated by the ABNF definition. In addition, no newline character, (0x0A), should be appended to the end of the domain name, as might occur with command line generation of SHA1 values. Command line appended newlines can be avoided by using the 'echo -n" option, for example. The tags used in TPA-Label resource records are as follows: asterisk = %x2A ; "*" Otis Expires April 14, 2010 [Page 7] Internet-Draft TPA-Label October 2009 dash = %x2D ; "-" dot = %x2E ; "." 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))) +--------+------------------------------------+ | Tag | Function | +--------+------------------------------------+ | scope= | Authorization Scope List (as-list) | | tpa= | Authorized Domains List (ad-list) | +--------+------------------------------------+ TPA-Label Extended Parameters +--------------+----------------------------------+ | Scope Values | Field or Parameter | +--------------+----------------------------------+ | F | From (Author) Header | | O | Other than From (Author) Headers | | M | MailFrom | | H | SMTP Host | | L | List-ID | | NO-TPA | All | +--------------+----------------------------------+ TPA-Label Scope Values 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 generated by processing the domain found within the DKIM signature's "d=" parameter (does not include the trailing period). A TPA-Label is published below the normal ADSP policy record, for example below "._adsp.domainkey.". The existence of a TPA- Label provides authorization for the listed domain. 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: Otis Expires April 14, 2010 [Page 8] Internet-Draft TPA-Label October 2009 ._adsp._domainkey.. 6. Scope scope= Authorization Scope List (Optional). This tag defines a list of scoping assertions for various email-address locations within the message. scope = "F" / "O" / "M" / "H" / "L" / "NO-TPA" as-list = "scope" [WSP] "=" [WSP] scope 0*([WSP] ":" [WSP] scope) 6.1. TPA-Label Listed Domain Authorization 6.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. 6.2. Use of Domain Authorization 6.2.1. Other Originating Header Fields The "O" scope asserts that messages with Sender or Resent-* header fields with email-address domains within the TPA-LLD are also authorized. 6.2.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. 6.2.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. 6.3. NO-TPA The "NO-TPA" scope asserts that the authorizing domain does not Otis Expires April 14, 2010 [Page 9] Internet-Draft TPA-Label October 2009 publish TPA-Labeled policy records. This scope is intended to be used in normal [RFC5617] ADSP records as a means to inhibit subsequent TPA-Label transactions. 7. Authorized Signing Domain tpa= Authorized Signing Domain list (Optional). This tag, if present, MUST repeat all or portions of the domain encoded within the TPA-Label. 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. ad = [ANY] domain ad-list = "tpa" [WSP] "=" [WSP] ad 0*([WSP] ":" [WSP] ad) 8. Use of TPA-Label Resource Records Use of TPA-Label resource record assertions need not be subsequent to the discovery of the policy record specified by [RFC5617]. When an acceptable Author Domain Signature was not discovered, and the From domain's [RFC5617] resource record contains the "scope" tag then: When one or more valid Third-Party Signatures are present in the message, and a scope tag exists within the normal policy record, and the scope tag does not contain "NO-TPA", then: * When a TPA-Label TXT 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's Domain Acceptable Third- Party Signature. * When a TPA-Label TXT resource record within the Author Domain has a scope tag of "O", and the email-address domain within the Sender, or Resent-* headers are within the TPA-LLD, use of these headers by this domain is authorized by the Author's Domain. * When a TPA-Label TXT resource record within the Author Domain 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's Domain. Otis Expires April 14, 2010 [Page 10] Internet-Draft TPA-Label October 2009 * When a TPA-Label TXT resource record within the Author Domain 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's Domain. * When a TPA-Label TXT resource record within the Author Domain has a scope tag of "L", and a host domain given by [RFC5321] EHLO or HELO command is within the TPA-LLD, the SMTP client is authorized by the Author's Domain. * When no TPA-Label TXT resource record is found or published, and a valid Third-party signature is acceptable to the verifier, then the message is considered signed by a Verifier Acceptable Third-Party Signature. 9. Authentication-Results Header Extended Results To accomodate the results derived from TPA-Label processing, section 2.2 of [RFC5451] needs to expand the 'ptype' list to include "tpa- label". The table in section 6.2 of [RFC5451] needs to include a 'ptype' of "tpa-label" with "lld" and "scope" properties. When 'scope' contains 'H', the 'iprev' results should also be included, in addition to 'dkim' results. 10. IANA Considerations A registry has been established for DKIM policy record tags for RFC5617 which will need updated with the tags "tpa" and "scope". Note to RFC Editor: this section may be removed on publication as an RFC. 11. Security Considerations This draft extends signing policies related to [RFC4871]. Security considerations 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]. 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 "tpa=" option. Otis Expires April 14, 2010 [Page 11] Internet-Draft TPA-Label October 2009 Use of the TPA-Label rather than simply listing the authorized domain ensures the maximal domain name size used with SMTP is reduced by less than 20%, rather than by an amount greater than 50% when attempting to include two domain names. The typical domain name size has been steadily increasing. This increase has been caused domain names that encode international character sets, and perhaps soon will be spurred by the expanse of TLDs having larger labels. Otis Expires April 14, 2010 [Page 12] Internet-Draft TPA-Label October 2009 12. Acknowledgements Daniel Black, Frank Ellermann, and Wietse Venema. 13. References 13.1. Normative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 13.2. Informative References [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Otis Expires April 14, 2010 [Page 13] Internet-Draft TPA-Label October 2009 Identified Mail (DKIM)", RFC 4686, September 2006. Appendix A. DNS Example of TPA-Label policy record placement #### # Policies for Example.com email domain using example.com, isp.com, # and example.com.isp.com as signing domains. #### #### 5322.From authorization for 3P domains #### #### Normal ADSP record indicating use of TPA-Labels #### _adsp._domainkey.example.com. IN TXT "dkim=all; scope=F:O:M;" ## "isp.com" TPA-Label ## _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 ## _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._adsp._domainkey.example.com. IN TXT "dkim=all; tpa=*.isp.com; scope=F:O:M;" Otis Expires April 14, 2010 [Page 14] 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 #include #include #include #include #include #include #include #include #include #include #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 Expires April 14, 2010 [Page 15] 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 Expires April 14, 2010 [Page 16] 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 Expires April 14, 2010 [Page 17] 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 Expires April 14, 2010 [Page 18] 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 Expires April 14, 2010 [Page 19] 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); } Author's Address Douglas Otis Trend Micro 10101 N. De Anza Blvd Cupertino, CA 95014 USA Phone: +1.408.257-1500 Email: doug_otis@trendmicro.com Otis Expires April 14, 2010 [Page 20]