DKIM Working Group D. Otis Internet-Draft Trend Micro, NSSG Intended status: Standards Track May 24, 2008 Expires: November 25, 2008 DKIM Third-Party Authorization for Author Domain Signing Practices draft-otis-dkim-tpa-adsp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 November 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to authorize Third-Party domains. This mechanism allows first-party domains to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization extends the scope of DKIM policy assertions to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate the coordination between two or more domains by setting up selector/key Otis Expires November 25, 2008 [Page 1] Internet-Draft TPA-label May 2008 DNS records, DNS zone delegations, 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-labels offer an efficient means for email address domains to authorize specific third-party signing domains. The scope of the authorization may separately assert identity authentication for From and Sender and Resent-* headers for email- addresses within the authorizing domain. Identity authentication can be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs. 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 November 25, 2008 [Page 2] Internet-Draft TPA-label May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Envelope Authorizations . . . . . . . . . . . . . . . . . . . 4 3. Evaluating Signing Domains . . . . . . . . . . . . . . . . . . 5 4. Authorization Scope . . . . . . . . . . . . . . . . . . . . . 5 5. TPA-labeled Policy Assertions . . . . . . . . . . . . . . . . 6 6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. From Originator Header Field . . . . . . . . . . . . . . . 8 6.2. MailFrom Parameter . . . . . . . . . . . . . . . . . . . . 8 6.3. Other than From Originating Header Fields . . . . . . . . 8 6.4. NO-TPA . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Authorized Signing Domain . . . . . . . . . . . . . . . . . . 9 8. Use of TPA-labeled Policy . . . . . . . . . . . . . . . . . . 9 9. Restricted Local-part . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. References - Normative . . . . . . . . . . . . . . . . . . 12 13.2. References - Informative . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. DNS Example of TPA-label policy record placement . . 14 Appendix C. C code for label generation . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Otis Expires November 25, 2008 [Page 3] Internet-Draft TPA-label May 2008 1. Introduction This document describes how any email-address domain publishing DKIM policy records such as those defined in [I-D.otis-dkim-adsp] can also autonomously authorize [RFC4871] signing by specific third-party domains. 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 results are utilized within their domain. TPA-labels authorize signing domains to permit compliance with DKIM policies. TPA-label authorized domains are to be considered equivalent to the authorizing domain for the application of DKIM policies. This mechanism eliminates 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 desired authorizations. Trust is an essential requisite before the DKIM signature header field's 'i=' semantics or the TPA-label policy record's "-i" suffix scope assertions provide valuable advisory information. This advisory information regarding "on-behalf-of" identity authentication enables safer message annotations to better ensure trusted identities can be recognized. TPA-labeled policy records also convey which third-party domains are authoritative. Although third-party domains are unable to utilize DKIM signature's 'i=' semantics to assert which identifiers on whose behalf a signature was added, the related identity can be constrained by the policy record's 'g=' parameter and by permitted header fields specified by the policy scope parameter. Policy scoping in this manner enables control over the recognition of trusted identities, as well as indicating when a message source may require added scrutiny. 2. Envelope Authorizations DKIM is fully independent of the SMTP Client and the [RFC2821].MailFrom email-address. Depending upon the normal policy assertions, allowing the [RFC2821].MailFrom email-address to authorize signing domains and assert policies may prevent Delivery Status Notifications (DSNs) from being sent when the domain is not authorized. Conversely, authorization may ensure DSNs are not dropped when the signing domain is authorized. The application of TPA-labels at the MailFrom domain represents an entirely optional strategy which may or may not prove either effective or practical. The MailFrom scope is offered only for experimentation. Otis Expires November 25, 2008 [Page 4] Internet-Draft TPA-label May 2008 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. Driven by market forces, registrars also offer the sampling of domain names (domain tasting) to generate additional revenue. 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 various types. Since abuse may not be controlled by the signing domain, message acceptance will likely remain largely dependent upon the reputation of the SMTP client's IP address. Abuse reporting facilitated by DKIM signatures should therefore first select signing domains that correspond with domains administering the SMTP Client publicly transmitting the message. A correspondence between SMTP Client and the DKIM signing domain can be retained by using TPA-label authorizations. The receiver's domain 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 a new or previously held domain names. The receiver may seek to limit the DKIM verification process, since acquiring policy records or DKIM keys may inadvertently leak valuable information that benefit bad actors. Processing all DKIM signatures may also inundate a receiver's limited resources. As a result, validating DKIM signatures and obtaining policy resource records might become limited to known trustworthy domains. Signing domains authorized with TPA-labels by domains having good reputations provide a means to safely extend a limited verification resources. 4. Authorization Scope An Authorization effort without using TPA-labels will likely involve sharing details between the domain owner, and one or more email and DNS providers. Since there are many ways in which authorizations can be accomplished, it is unlikely there will be consistent or standardized formats for exchanging the necessary information. In addition, in the case of security breaches, the wrong party might be held accountable for content never seen nor logged by them. The TPA- Otis Expires November 25, 2008 [Page 5] Internet-Draft TPA-label May 2008 label authorization scheme clarifies who signed the message and on whose behalf, while permitting greater control by the authorizing domain. TPA-labeled policy 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 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. The TPA-labeled policy records allow authorizing domains an improved ability to limit the scope of their authorizations and associated identities. When a signing domain differs from that of a domain within the header email-address, TPA-labeled policy records can safely extend compliance where the action of only the email-address domain is required. In addition, just as a DKIM signature can assert an email- address has been authenticated via the "i" construct, a signing domain that only signs authenticated email-addresses from the authorizing domain can be denoted by the "-i" suffix on the scope assertion within the corresponding TPA-labeled policy record. A TPA- labeled policy record returning a scope with an "-i" suffix indicates the domain assures that email-addresses identities from the authorizing domain have been authenticated. This assertion remains valid even when signing domains and the email-address domains differ. Without the "-i" suffix on the scope assertion within the TPA-labeled policy record, the authorized domain is designated as providing only acceptable signatures. The same would be true for a DKIM signature lacking the "i" parameter. While offering only valid signatures will not ensure all possible spoofing is prevented, messages signed in this manner should not receive annotations indicating authenticated identities either. Choosing not to implement identity authentication may represent an economical means to administer domains employing DKIM signatures. Authorizing domains to play the role of only providing acceptable signatures may be suitable for non-critical messages, where the goal might be to improve delivery acceptance. 5. TPA-labeled Policy Assertions 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-labeled policy records follow the tag- value syntax described in section 4.2.1 of [I-D.otis-dkim-adsp] and Otis Expires November 25, 2008 [Page 6] Internet-Draft TPA-label May 2008 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 [RFC2822]. 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. In addition, a newline character (0x0A) is appended to the end of the string to match a command line generation of SHA1 values. The tags used in TPA-labeled policy records are as follows: asterisk = %x2A ; "*" 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 = base32( sha-1( lcase(signing-domain))) +--------+------------------------------------+ | Tag | Function | +--------+------------------------------------+ | scope= | Authorization Scope List (as-list) | | tpa= | Authorized Domains List (ad-list) | | g= | Local-part restriction | +--------+------------------------------------+ TPA-label Policy Tags +------------+----------------------------------+-------------------+ | Scope | Field or Parameter | Identity | | Values | | Authenticated | +------------+----------------------------------+-------------------+ | F | From (Author) Header | No | | F-i | From (Author) Header | Yes | | O | Other than From (Author) Headers | No | | O-i | Other than From (Author) Headers | Yes | | M | MailFrom | No | | M-i | MailFrom | Yes | | NO-TPA | All | No | +------------+----------------------------------+-------------------+ TPA-label Policy Scope Values Otis Expires November 25, 2008 [Page 7] Internet-Draft TPA-label May 2008 The receiver obtains the TPA-labeled policy record for the email- address domain using a DNS query for an IN class TXT resource record. The tpa-label is created by processing the domain found within the signature's "d=" parameter (does not include the trailing period). The tpa-label would be placed below the normal policy records, for example "._adsp.". These labels would then be used to access the TPA-labeled policy TXT records. 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-labeled policy record may be located at these domains: ._adsp.. 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" / "F-i" / "O" / "O-i" / "M" / "M-i" / "NO-TPA" as-list = "scope" [WSP] "=" [WSP] scope 0*([WSP] ":" [WSP] scope) 6.1. From Originator Header Field The "F" or "F-i" scope asserts that messages carrying the email- address domain within the From header field are authorized to be signed by the tpa listed domain. When the "-i" suffix is included, it can be assumed identities for the scoped header have been authenticated. 6.2. MailFrom Parameter This "M" or "M-i" scope asserts that messages carrying the email- address domain within the MailFrom parameter are authorized to be signed by the authorized domain. When the "-i" suffix is included, it can be assumed identities for the MailFrom have been authenticated. 6.3. Other than From Originating Header Fields The "O" or "O-i" scope asserts that messages carrying the email- address domain within the Sender or Resent-* header fields are Otis Expires November 25, 2008 [Page 8] Internet-Draft TPA-label May 2008 authorized to be signed by the authorized domain. When the "-i" suffix is included, it can be assumed identities for the scoped header have been authenticated. 6.4. NO-TPA The "NO-TPA" scope asserts that domain does not publish TPA-labeled policy records. 7. Authorized Signing Domain tpa= Authorized Signing Domain list (Optional). This tag repeats all or portions of the domain encoded within the tpa-label. This option ensures 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-labeled Policy Use of TPA-labeled policy is subsequent to the discovery of the policy record specified by [I-D.otis-dkim-adsp]. Only when an acceptable First-Party signature was not discovered, and the normal policy 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-labeled policy record within the From header domain has a scope tag of "F" or "F-i" and the email-address domain within the From headers is within the authorizing domain, then the message is considered signed with an Author's Domain Acceptable Third-Party Signature. When the scope tag within the TPA-labeled policy record is "F-i", then email-addresses within the authorizing domain can be considered to have been authenticated. * When a TPA-labeled poliy record within the From header domain has a scope tag of "O" or "O-i" and the email-address domain within the Sender, or Resent-* headers are within the authorizing domain, then the message is considered signed with Otis Expires November 25, 2008 [Page 9] Internet-Draft TPA-label May 2008 an Author's Domain Acceptable Third-Party Signature. When the scope tag within the TPA-labeled policy record is "O-i", then email-addresses within the authorizing domain can be considered to have been authenticated when included within the signature's hash. * When no TPA-labeled policy 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. Restricted Local-part The "g=" tag provides a means for an authorizing domain to restrict authorization for local-parts appearing within the scoped headers. g= Granularity of the TPA authorization (plain-text; OPTIONAL, default is "*"). This value MUST match the Local-part of the From header email-address. A single optional "*" character matches a sequence of zero or more arbitrary characters ("wildcarding"). An email with a From address local-part that does not match the value of this tag constitutes a failed TPA authorization. The intent of this tag is to constrain which email-addresses the domain can legitimately be authorized to sign. Wildcarding allows matching for addresses such as "user+*" or "*-offer". An empty "g=" value never matches any addresses. ABNF: tpa-g-tag = %x67 [WSP] "=" [WSP] tpa-tag-lpart tpa-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] 10. IANA Considerations Unless a registry is established for DKIM policy record tags, there are no IANA requirements in this draft. Note to RFC Editor: this section may be removed on publication as an RFC and no request is desired or registration is not considered practical. 11. Security Considerations This draft extends signing policies related to [RFC4871]. Security considerations in the Author Domain Signing Practices are mostly related to attempts on the part of malicious senders to represent themselves as other senders, often in an attempt to defraud the recipient. Additional security considerations regarding Sender Otis Expires November 25, 2008 [Page 10] Internet-Draft TPA-label May 2008 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 November 25, 2008 [Page 11] Internet-Draft TPA-label May 2008 12. Acknowledgements Frank Ellermann and Wietse Venema. 13. References 13.1. References - Normative [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [I-D.otis-dkim-adsp] Address, A. and D. Otis, "DKIM Author Domain Signing Practices (ADSP)", draft-otis-dkim-adsp-01 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [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. 13.2. References - Informative Otis Expires November 25, 2008 [Page 12] Internet-Draft TPA-label May 2008 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [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. Appendix A. Change Log Changed title and record references used in draft-otis-dkim-tpa-ssp to reflect the record name change. Otis Expires November 25, 2008 [Page 13] Internet-Draft TPA-label May 2008 Appendix B. DNS Example of TPA-label policy record placement #### # Policies for Example.com email domain using both example.com, isp.com, # and example.com.isp.com as signing domains. #### #### 2822.From authorization for TP domains #### _adsp.example.com. IN TXT "dkim=all; scope=F-i:O:M;" ## "isp.com" tpa-label ## _HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp.example.com. IN TXT "tpa=isp.com; scope=F;" #### 2822.From/Originator/MailFrom authorization for TP domains #### ## "example.com.isp.com" tpa-label ## _ZZHFFXWCFI7RPDDQDIGYHPBTAA7VWITU._adsp.example.com. IN TXT "tpa=*.isp.com; scope=F-i:O:M; " Otis Expires November 25, 2008 [Page 14] Internet-Draft TPA-label May 2008 Appendix C. 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) The IETF Trust & Douglas Otis (2008). * Mountain View, CA */ #include #include #include #include #include #include #include #include #include #include #include /* * Copyright (C) The IETF Trust & Douglas Otis (2008). * 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. */ #define TPA_LABEL_VERSION 100 #define MAX_DOMAIN_NAME 512 #define MAX_FILE_NAME 1024 static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; static char sign_on[] = {"%s v%d.%02d Copyright (C) The IETF Trust & Douglas Otis (2008)\n"}; Otis Expires November 25, 2008 [Page 15] Internet-Draft TPA-label May 2008 char err_cmd[] =\ "ERR: Command error with [%s]\n"; char use_txt[]=\ "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 long 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 time */ (void) strncpy(out_fn, optarg, sizeof(out_fn)); Otis Expires November 25, 2008 [Page 16] Internet-Draft TPA-label May 2008 out_fn[sizeof(out_fn) - 1] = '\0'; break; case 'v': 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); } Otis Expires November 25, 2008 [Page 17] Internet-Draft TPA-label May 2008 for (i = 0; i < MAX_DOMAIN_NAME && !done; i++) { 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++] = '\n'; /* newline simulates commmand-line use */ 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) Otis Expires November 25, 2008 [Page 18] Internet-Draft TPA-label May 2008 { printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len); 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); Otis Expires November 25, 2008 [Page 19] Internet-Draft TPA-label May 2008 printf("\n"); /* close */ 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, NSSG 10101 N. De Anza Blvd Cupertino, CA 95014 USA Phone: +1.408.257-1500 Email: doug_otis@trendmicro.com Otis Expires November 25, 2008 [Page 20] Internet-Draft TPA-label May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Otis Expires November 25, 2008 [Page 21]