<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >

<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<?xml-stylesheet type="text/css" href="rfc2629.css"?>

<rfc
   category="info"
   docName="draft-crocker-doseta-base-03"
   ipr="trust200902"
   submissionType="independent">

   <front>
      <title
         abbrev="DOSETA">DomainKeys Security Tagging (DOSETA)</title>
      <author
         fullname="D. Crocker"
         initials="D."
         surname="Crocker">
         <organization>Brandenburg InternetWorking</organization>
         <address>
            <postal>
               <street>675 Spruce Dr.</street>
               <city>Sunnyvale</city>
               <country>USA</country>
            </postal>
            <phone>+1.408.246.8253</phone>
            <email>dcrocker@bbiw.net</email>
            <uri>http://bbiw.net</uri>
         </address>
      </author>

      <author
         fullname="M. Kucherawy"
         initials="M."
         surname="Kucherawy">
         <organization>Cloudmark</organization>
         <address>   
            <postal>
               <street>128 King St., 2nd Floor</street>
               <city>San Francisco</city>
               <region>CA</region>
               <code>94107</code>
               <country>USA</country>
            </postal>
            <email>msk@cloudmark.com</email>
         </address>
      </author>

      <date
         year="2011"/>

      <abstract>
         <t>DomainKeys Security Tagging (DOSETA) is a component mechanism that
            enables easy development of security-related services, such as for
            authentication or encryption. It uses self-certifying keys based
            on domain names. The domain name owner can be any actor involved
            in the handling of the data, such as the author's organization, a
            server operator or one of their agents. The DOSETA Library
            provides a collection of common capabilities, including
            canonicalization, parameter tagging and key retrieval. The DOSETA
            Signing Template creates common framework for a signature of data
            that are in a "header/content" form. Defining the meaning of a
            signature is the responsibility of the service that incorporates
            DOSETA. Data security is enforced through the use of cryptographic
            algorithms. </t>
      </abstract>


   </front>



   <middle>


      <section
         title="Introduction">

         <t>DomainKeys Security Tagging (DOSETA) is a component mechanism
            enabling development of security-related services, such as for
            authentication or encryption; it uses self-certifying keys based
            on domain names <xref
               target="RFC1034"/>. The domain name owner can be any actor
            involved in the handling of the data, such as the author's
            organization, a server operator or one of their agents. The DOSETA
            Library provides a collection of common capabilities, including
            canonicalization, parameter tagging and key retrieval. The DOSETA
            Signing Template creates common framework for signing data that are in
            a "header/content" form. Defining the intended meaning of a
            signature is the responsibility of the service that incorporates
            DOSETA. Data security is enforced through the use of cryptographic
            algorithms. </t>


         <t>The approach taken by DOSETA differs from previous approaches to
            data signing -- such as, Secure/Multipurpose Internet Mail
            Extensions (S/MIME) <xref
               target="RFC1847"/>, OpenPGP <xref
               target="RFC4880"/> -- in that: <list
               style="symbols">
               <t>The message signature can be packaged independently of the
                  data it is signing, so that neither human viewers of the
                  data nor existing data handling software is confused by
                  security-related content appearing in the Content.</t>
               <t>There is no dependency on having public and private key
                  pairs being issued by well-known, trusted certificate
                  authorities. </t>
               <t>There is no dependency on the deployment of any new Internet
                  protocols or services for public key distribution or
                  revocation.</t>
               <t>Specific security services can be limited to those needed by
                  the service using them.</t>
            </list></t>

         <t>DOSETA: <list
               style="symbols">
               <t>enables compatibility with the existing data handling
                  infrastructure and is transparent to the fullest extent
                  possible</t>
               <t>requires minimal new infrastructure</t>
               <t>can support a variety of implementation configurations, in
                  order to reduce deployment time</t>
               <t>can be deployed incrementally</t>
               <t>allows delegation of signing to third parties</t>
            </list></t>

         <t>DOSETA derives from Domain Keys Identified Mail (DKIM) <xref
               target="RFC5672"/> and has extracted the core portions of the
            its signing specification <xref
               target="DKIMSign"/>, so that they can be applied to other
            security-related services. For example, the core could support a
            DKIM-like signing service for web pages, and it could support a
            data ion mechanism using the same DNS-based, self-certified
            key service as DKIM. </t>




         <t>DOSETA features include: <list>
               <t><list
                     style="hanging">
                     <t
                        hangText="Identity:  ">DOSETA distinguishes the
                        identity of the DOSETA signature's producer from that
                        of any other identifier associated with the data, such
                        as the data's purported author. In particular, the
                        DOSETA header field includes the DOSETA Domain
                        Identifier (DDI), per <xref
                           target="identitydefs"/>. DOSETA consumers can use
                        the DDI to decide how they want to process the data.
                        The DDI can be directly included in the attributes of
                        the data or can be recorded elsewhere. <list
                           style="hanging">
                           <t
                              hangText="NOTE:  ">DOSETA does not, itself,
                              specify that the identity it uses is required to
                              match any other associated identifier. Those
                              other identifiers already carry their own
                              semantics which might conflict with the use of
                              the identifier needed by DOSETA. However a
                              particular DOSETA-based security service might
                              choose to add constraints on the choice of
                              identifier, such as having it match another
                              identifier that is associated with the data.</t>
                        </list></t>
                     <t
                        hangText="Scalability:  ">DOSETA is designed to easily
                        support the extreme scaling requirements that
                        characterize Internet data identification. </t>
                     <t
                        hangText="Key Management:  ">DOSETA differs from
                        traditional hierarchical public-key systems in that no
                        Certificate Authority infrastructure is required; the
                        verifier requests the public key from a repository
                        under the domain name associated with the use of
                        DOSETA directly, rather than requiring consultation of
                        a certificate authority. That is, DOSETA provides
                        self-certifying keys.</t>
                     <t>The DNS is the initial mechanism for DOSETA public
                        keys. Thus, DOSETA currently depends on DNS
                        administration and the security of the DNS system.
                        DOSETA is designed to be extensible to other key
                        fetching services as they become available.</t>
                     <t
                        hangText="Data Integrity:  "> When DOSETA is used to
                        sign data -- independent of the semantics of that
                        signature -- there is a computed hash of some or all
                        of the data that ensures detection of changes to that
                        data, between the times of signing and verifying. </t>
                  </list></t>
            </list></t>




         <section
            title="Comments and Issues">

            <t><list
                  style="hanging">
                  <t
                     hangText="[RFC EDITOR]  ">Remove this sub-section prior
                     to publication.</t>
               </list>
            </t>
            <t>Possible applications:<list
                  style="symbols">
                  <t>JSON structure</t>
                  <t>XMPP message</t>
                  <t>XML object</t>
                  <t>vCard</t>
                  <t>vCal</t>
                  <t>Web page signing?</t>
                  <t>Web ad authentication</t>
                  <t>Handle System</t>
               </list>
            </t>

            <t><list
                  style="hanging">
                  <t
                     hangText="Discussion Venue:">Discussion of this draft
                     should take place on the doseta-discuss mailing list. It
                     is located at:<list>
                        <t><figure>
                              <artwork>http://www.trusteddomain.org/mailman/listinfo/doseta-discuss</artwork>
                           </figure></t>
                     </list>
                  </t>
               </list>
            </t>
         </section>

      </section>


      <section
         anchor="framework"
         title="Framework">
         <t>This section provides the technical background for the remainder
            of the document. </t>

         <section
            anchor="arch"
            title="DOSETA Architecture">
            <t>As component technology, DOSETA is meant to be incorporated
               into a service. This specification provides an underlying set
               of common features and a template for using them to provide a
               signing service, such as for authenticating an identifier.
               Hence, the pieces can be depicted as follows, with DKIM being
               shown as a specific service that incorporates DOSETA:</t>
            <t>
               <figure
                  align="center">
                  <artwork align="center"><![CDATA[
    +--------+       +----------+           +-----------------+
    |  DKIM  |       | MIMEAUTH |           | Message Privacy |
    +---+----+       +-----+----+           +--------+--------+
        |                  |                         |
 ++=====V==================V========++               |
 ||                                 ||               |
 || Header/Content Signing Template ||               |
 ||                                 ||               |
 ++================+================++               |
                   |                                 |
++=================V=================================V============++
||                                                                ||
||                      D O S E T A     L I B R A R Y             ||
|| +------------------+ +------------+ +-------------+ +--------+ ||
|| |                  | | Key        | | Parameter   | | Tags   | ||
|| | Canonicalization | | Management | | Format      | | Header | ||
|| |                  | | (DNS)      | | (tag=value) | | Field  | ||
|| +------------------+ +------------+ +-------------+ +--------+ ||
||                                                                ||
++================================================================++]]>
                  </artwork>
               </figure> DKIM is as specified in <xref
                  target="DKIMSign"/>. MIMEAUTH is an exemplar use of DOSETA,
               specified in <xref
                  target="mimeauth"/>. Message Privacy is a generic term,
               indicating any service that provides encryption; it is expected
               that such a service can use the DOSETA core library, but not
               take advantage of the DOSETA signing template. </t>
            <t>The library comprises:<list
                  style="hanging">
                  <t
                     hangText="Canonicalization: ">This ensures common data
                     representation and robustness against some forms of data
                     modification during transit. It is discussed in <xref
                        target="canon"/> and <xref
                        target="normalize"/>.</t>
                  <t
                     hangText="Key Management: ">This covers the mechanisms
                     for discovering and obtaining signature key information
                     by a verifier. It is discussed in <xref
                        target="keymgmt"/>, <xref
                        target="selectors"/>, and <xref
                        target="dnsbind"/>.</t>
                  <t
                     hangText="Format: ">This describes a simple syntax for
                     encoding parametric information and is discussed in <xref
                        target="tagval"/>.</t>
                  <t
                     hangText="Tags: ">These are common parameters for the
                     stored public key record, defined in <xref
                        target="keydata"/> and the common parameters for the
                     signature record that is associated with the signed data,
                     defined in <xref
                        target="signeddatastruct"/>.</t>
               </list>
            </t>

         </section>

         <section
            anchor="terminology"
            title="Terminology">
            <t>Within the specification, the label "[TEMPLATE]" is used to
               indicate actions that are required for tailoring the use of
               DOSETA into a specific service.</t>

            <t>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 <xref
                  target="RFC2119"/>.</t>

            <t>Additional terms for this document are divided among Identity
               and Actors.</t>

            <section
               anchor="identitydefs"
               title="Identity">

               <t>
                  <list
                     style="hanging">
                     <t
                        hangText="Identity:  "> A person, role, or
                        organization. In the context of DOSETA, examples
                        include author, author's organization, an ISP along
                        the handling path, an independent trust assessment
                        service, and a data processing intermediary
                        operator.</t>
                     <t
                        hangText="Identifier:  "> A label that refers to an
                        identity. The primary example is a domain name.</t>
                     <t
                        hangText="DOSETA Domain Identifier (DDI):  "> A single
                        domain name that serves as an identifier, referring to
                        the DOSETA key owner's identity. The DDI is specified
                        in <xref
                           target="signeddatastruct"/>. Within this
                        specification, the name has only basic domain name
                        semantics; any possible owner-specific semantics MUST
                        be provided in the specification that incorporates
                        DOSETA. </t>
                     <t
                        hangText="Identity Assessor:  "> A module that
                        consumes DOSETA's payload output. The module is
                        dedicated to the assessment of the delivered
                        identifier. Optionally, other DOSETA (and non-DOSETA)
                        values can also be delivered to this module as well as
                        to a more general message evaluation filtering engine.
                        However, this additional activity is outside the scope
                        of the DOSETA specification. </t>
                  </list>
               </t>
            </section>

            <section
               title="Actors">
               <t>
                  <list
                     style="hanging">
                     <t
                        hangText="Producer:  ">An element in the data handling
                        system that produces a cryptographic encoding, on
                        behalf of a domain, is referred to as a Producer. For
                        example, a signer is a type of producer.</t>
                     <t
                        hangText="Consumer:  ">An element in the data handling
                        system that processes an existing cryptographic
                        encoding, on behalf of a domain, is referred to as a
                        consumer. For example, a verifier is a type of
                        consumer.</t>
                     <t
                        hangText="Signer:  "> An element in the data handling
                        system that creates a digital signature, on behalf of
                        a domain, is referred to as a signer. This element
                        specifies an actor that is a type of DOSETA producer.
                        The actor might operate through a client, server or
                        other agent such as a reputation service. The core
                        requirement is that the data MUST be signed before it
                        leaves the control of the signer's administrative
                        domain. </t>

                     <t
                        hangText="Verifier:  "> An element in the data
                        handling system that verifies signatures is referred
                        to as a verifier. This element is a consumer of a
                        signing service. It might be a client, server, or
                        other agent, such as a reputation service. In most
                        cases it is expected that a verifier will be close to
                        an end user of the data or some consuming agent such
                        as a data processing intermediary. </t>
                  </list>
               </t>

            </section>
         </section>

         <section
            title="Syntax">

            <t>This section specifies foundational syntactic constructs used
               in the remainder of the document.</t>

            <t>Syntax descriptions use Augmented BNF (ABNF) <xref
                  target="RFC5234"/>. </t>

            <section
               anchor="whitespace"
               title="Whitespace">
               <t>There are three forms of whitespace: <list>
                     <t><list
                           style="hanging">
                           <t
                              hangText="WSP:  "> represents simple whitespace,
                              that is, a space or a tab character (formally
                              defined in <xref
                                 target="RFC5234"/>).</t>
                           <t
                              hangText="LWSP:  "> is linear whitespace,
                              defined as WSP plus CRLF (formally defined in <xref
                                 target="RFC5234"/>).</t>
                           <t
                              hangText="FWS:  "> is folding whitespace. It
                              allows multiple lines to be joined with each a
                              separated by a sequence having CRLF followed by
                              at least one whitespace.</t>
                        </list></t>
                  </list></t>
               <t>The formal syntax for these are (WSP and LWSP are given for
                  information only): <list>
                     <t><figure
                           align="left">
                           <preamble>ABNF:</preamble>
                           <artwork type="abnf"><![CDATA[WSP  =  SP / HTAB
LWSP =  *(WSP / CRLF WSP)
FWS  =  [*WSP CRLF] 1*WSP]]></artwork>
                        </figure></t>
                  </list>
               </t>
               <t>The definition of FWS is identical to that in <xref
                     target="RFC5322"/> except for the exclusion of
                  obs-FWS.</t>
            </section>

            <section
               title="Common ABNF Tokens">
               <t>The following tokens are used in this document: <list>
                     <t>
                        <figure>
                           <preamble>ABNF:</preamble>
                           <artwork align="left" type="abnf"><![CDATA[hyphenated-word =  ALPHA 
                   [ *(ALPHA / DIGIT / "-") 
                   (ALPHA / DIGIT) ]
ALPHADIGITPS    =  (ALPHA / DIGIT / "+" / "/")
base64string    =  ALPHADIGITPS *([FWS] ALPHADIGITPS)
                   [ [FWS] "=" [ [FWS] "=" ] ] 
hdr-name        =  field-name
qp-hdr-value    =  D-quoted-printable
                        ; with "|" encoded]]></artwork>
                        </figure></t>
                  </list>
               </t>
            </section>

            <section
               title="Imported ABNF Tokens">
               <t> The following tokens are imported from other RFCs as noted.
                  Those RFCs SHOULD be considered definitive.</t>
               <t>From <xref
                     target="RFC5321"/>: <list>
                     <t><list
                           style="hanging">
                           <t
                              hangText="&lt;local-part&gt;  "> Implementation
                              Warning: This permits quoted strings)</t>
                           <t
                              hangText="&lt;sub-domain&gt;"> </t>
                        </list></t>
                  </list></t>
               <t>From <xref
                     target="RFC5322"/>: <list>
                     <t><list
                           style="hanging">
                           <t
                              hangText="&lt;field-name&gt;  "> (name of a
                              header field)</t>
                        </list></t>
                  </list></t>

               <t>From <xref
                     target="RFC2045"/>: <list>
                     <t><list
                           style="hanging">
                           <t
                              hangText="&lt;qp-section&gt;  ">a single line of
                              quoted-printable-encoded text</t>
                           <t
                              hangText="&lt;hex-octet&gt; ">a quoted-printable
                              encoded octet)</t>
                        </list></t>
                  </list>
               </t>
               <t>
                  <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">Be aware that the ABNF in <xref
                           target="RFC2045"/> does not obey the rules of <xref
                           target="RFC5234"/> and MUST be interpreted
                        accordingly, particularly as regards case folding.</t>
                  </list>
               </t>
               <t> Other tokens not defined herein are imported from <xref
                     target="RFC5234"/>. These are intuitive primitives such
                  as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.</t>
            </section>
            <section
               anchor="D-quoted-printable"
               title="D-Quoted-Printable">
               <t>The D-Quoted-Printable encoding syntax resembles that
                  described in Quoted-Printable <xref
                     target="RFC2045"/>, Section 6.7: <list
                     style="symbols">
                     <t>Any character MAY be encoded as an "=" followed by two
                        hexadecimal digits from the alphabet
                        "0123456789ABCDEF" (no lowercase characters permitted)
                        representing the hexadecimal-encoded integer value of
                        that character.</t>
                     <t>All control characters (those with values &lt; %x20),
                        8-bit characters (values &gt; %x7F), and the
                        characters DEL (%x7F), SPACE (%x20), and semicolon
                        (";", %x3B) MUST be encoded.</t>
                     <t>All whitespace, including SPACE, CR, and LF
                        characters, MUST be encoded.</t>
                     <t>After encoding, FWS MAY be added at arbitrary
                        locations in order to avoid excessively long lines;
                        such whitespace is NOT part of the value, and MUST be
                        removed before decoding.</t>
                  </list></t>
               <t>The formal syntax for D-Quoted-Printable is: <list>
                     <t>
                        <figure>
                           <preamble>ABNF:</preamble>
                           <artwork type="abnf"><![CDATA[D-quoted-printable =  *(FWS / hex-octet / D-safe-char)
                         ; hex-octet is from RFC2045
D-safe-char        =  %x21-3A / %x3C / %x3E-7E 
                         ; '!' - ':', '<', '>' - '~'
                         ; Characters not listed as "mail-safe"
                         ; in [RFC2049] are also not
                         ; recommended.]]></artwork>
                        </figure></t>
                  </list></t>
               <t>D-Quoted-Printable differs from Quoted-Printable as defined
                  in <xref
                     target="RFC2045"/> in several important ways: <list
                     style="numbers">
                     <t>Whitespace in the input text, including CR and LF,
                        MUST be encoded. <xref
                           target="RFC2045"/> does not require such encoding,
                        and does not permit encoding of CR or LF characters
                        that are part of a CRLF line break.</t>
                     <t>Whitespace in the encoded text is ignored. This is to
                        allow tags encoded using D-Quoted-Printable to be
                        wrapped as needed. In particular, <xref
                           target="RFC2045"/> requires that line breaks in the
                        input be represented as physical line breaks; that is
                        not the case here.</t>
                     <t>The "soft line break" syntax ("=" as the last
                        non-whitespace character on the line) does not
                        apply.</t>
                     <t>D-Quoted-Printable does not require that encoded lines
                        be no more than 76 characters long (although there
                        might be other requirements depending on the context
                        in which the encoded text is being used).</t>
                  </list></t>

            </section>
         </section>
      </section>


      <section
         anchor="library"
         title="DOSETA Library">
         <t>DOSETA's library of functional components is distinguished by a
            DNS-based, self-certifying public key mechanism, common data
            normalization and canonicalization algorithms, and a common
            parameter encoding mechanism.</t>


         <section
            anchor="normalize"
            title="Normalization for Transport Robustness">
            <t>Some messages, particularly those using 8-bit characters, are
               subject to modification during transit, notably from conversion
               to 7-bit form. Such conversions will break DOSETA signatures.
               Similarly, data that is not compliant with its associated
               standard, might be subject to corrective efforts
               intermediaries. See Section 8 of <xref
                  target="RFC4409"/> for examples of changes that are commonly
               made to email. Such "corrections" might break DOSETA signatures
               or have other undesirable effects. </t>
            <t>In order to minimize the chances of such breakage, signers
               convert the data to a suitable encoding, such as
               quoted-printable or base64, as described in <xref
                  target="RFC2045"/> before signing. Specification and use of
               such conversions is outside the scope of DOSETA.</t>
            <t>If the data is submitted to a DOSETA process with any local
               encoding that will be modified before transmission, that
               modification to a canonical form MUST be done before DOSETA
               processing. For Text data in particular, bare CR or LF
               characters (used by some systems as a local line separator
               convention) MUST be converted to the CRLF sequences before the
               data is signed. Any conversion of this sort SHOULD be applied
               to the data actually sent to the recipient(s), not just to the
               version presented to the signing algorithm.</t>
            <t>More generally, a DOSETA producer MUST use the data as it is
               expected to be received by the DOSETA consumer rather than in
               some local or internal form.</t>
         </section>


         <section
            anchor="canon"
            title="Canonicalization">
            <t>Some data handling systems modify the original data during
               transit, potentially invalidating a cryptographic function. In
               some cases, mild modification of data can be immaterial to the
               validity of a DOSETA-based service. In these cases, a
               canonicalization algorithm that survives modest handling
               modification is preferred.</t>
            <t>In other cases, preservation of the exact, original bits is
               required; even minor modifications need to result in a failure.
               Hence a canonicalization algorithm is needed that does not
               tolerate any in-transit modification of the data.</t>
            <t>To satisfy basic requirements, two canonicalization algorithms
               are defined: a "simple" algorithm that tolerates almost no
               modification and a "relaxed" algorithm that tolerates common
               modifications such as whitespace replacement and data line
               rewrapping.</t>
            <t>Data presented for canonicalization MUST already be in "network
               normal" format -- text is ASCII encoded, lines are separated
               with CRLF characters, etc.) See <xref
                  target="normalize"/> for information about normalizing
               data.</t>
            <t>Data handling systems sometimes treat different portions of
               text differentially and might be subject to more or less
               likelihood of breaking a signature. DOSETA currently covers two
               types of data:<list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Header:   ">Attribute:value sets, in the
                           style of Internet Mail header fields or MIME header
                           fields</t>
                        <t
                           hangText="Content:  ">Lines of ASCII text</t>
                     </list></t>
               </list></t>
            <t>Some DOSETA producers might be willing to accept modifications
               to some portions of the data, but not other portions. For
               DOSETA, a producer MAY specify one algorithm for the header and
               another for the content. </t>
            <t>If no canonicalization algorithm is specified, the "simple"
               algorithm defaults for each part. DOSETA producers MUST
               implement both of the base canonicalization algorithms. Because
               additional canonicalization algorithms might be defined in the
               future, producers MUST ignore any unrecognized canonicalization
               algorithms.</t>
            <t>Canonicalization simply prepares the data for presentation to
               the DOSETA processing algorithm. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Canonicalization operates on a copy of
                     the data; it MUST NOT change the transmitted data in any
                     way. Canonicalization of distinct data portions is
                     described below.</t>
               </list></t>


            <section
               anchor="hdrcanon"
               title="Header Canonicalization Algorithms">
               <t>This section describes basic entries for the Header
                  Canonicalization IANA registry defined in <xref
                     target="DKIMSign"/>, , which also applies to DOSETA
                  header canonicalization. <list
                     style="hanging">
                     <t
                        hangText="simple:  "> The "simple" header
                        canonicalization algorithm is for a set of
                        "attribute:value" textual data structures, such as
                        email header fields <xref
                           target="RFC5322"/>. It does not change the original
                        Header fields in any way. Header fields MUST be
                        presented to the processing algorithm exactly as they
                        are in the data being processed. In particular, header
                        field names MUST NOT be case folded and whitespace
                        MUST NOT be changed.</t>
                     <t
                        hangText="relaxed:  "> The "relaxed" header
                        canonicalization algorithm is for a set of
                        "attribute:value" textual data structures, such as
                        email header fields <xref
                           target="RFC5322"/>. It does not change the original
                        Header fields in any way. The following steps MUST be
                        applied in order: <list
                           style="symbols">
                           <t>Convert all header field names (not the header
                              field values) to lowercase. For example, convert
                              "SUBJect: AbC" to "subject: AbC".</t>
                           <t>Unfold all header field continuation lines as
                              described in <xref
                                 target="RFC5322"/>; in particular, lines with
                              terminators embedded in continued header field
                              values (that is, CRLF sequences followed by WSP)
                              MUST be interpreted without the CRLF.
                              Implementations MUST NOT remove the CRLF at the
                              end of the header field value.</t>
                           <t>Convert all sequences of one or more WSP
                              characters to a single SP character. WSP
                              characters here include those before and after a
                              line folding boundary.</t>
                           <t>Delete all WSP characters at the end of each
                              unfolded header field value.</t>
                           <t>Delete any WSP characters remaining before and
                              after the colon separating the header field name
                              from the header field value. The colon separator
                              MUST be retained.</t>
                        </list></t>
                  </list></t>
            </section>

            <section
               anchor="contentcanon"
               title="Content Canonicalization Algorithms">
               <t>This section describes basic entries for the Message
                  Canonicalization IANA registry defined in <xref
                     target="DKIMSign"/>, which also applies to DOSETA
                  Content. <list
                     style="hanging">
                     <t
                        hangText="simple:  "> The "simple" Content
                        canonicalization algorithm is for lines of ASCII text,
                        such as occur in the body of email <xref
                           target="RFC5322"/>. It ignores all empty lines at
                        the end of the Content. An empty line is a line of
                        zero length after removal of the line terminator. If
                        there is no Content or no trailing CRLF on the
                        Content, a CRLF is added. It makes no other changes to
                        the Content. In more formal terms, the "simple"
                        Content canonicalization algorithm converts "0*CRLF"
                        at the end of the Content to a single "CRLF".</t>
                     <t>Note that a completely empty or missing Content is
                        canonicalized as a single "CRLF"; that is, the
                        canonicalized length will be 2 octets.</t>
                     <t> The sha1 value (in base64) for an empty Content
                        (canonicalized to a "CRLF") is: <figure>
                           <artwork><![CDATA[uoq1oCgLlTqpdDX/iUbLy7J1Wic=]]></artwork>
                        </figure> The sha256 value is: <figure>
                           <artwork><![CDATA[frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=]]></artwork>
                        </figure>
                     </t>
                     <t
                        hangText="relaxed:  "> The "relaxed" Content
                        canonicalization algorithm is for lines of ASCII text,
                        such as occur in the body of email <xref
                           target="RFC5322"/>. It MUST apply the following
                        steps (a) and (b) in order:<list
                           style="letters">
                           <t>Reduce whitespace: <list
                                 style="symbols">
                                 <t>Ignore all whitespace at the end of lines.
                                    Implementations MUST NOT remove the CRLF
                                    at the end of the line.</t>
                                 <t>Reduce all sequences of WSP within a line
                                    to a single SP character.</t>
                              </list></t>
                           <t>Ignore all empty lines at the end of the
                              Content. "Empty line" is defined in <xref
                                 target="contentcanon"/>. If the Content is
                              non-empty, but does not end with a CRLF, a CRLF
                              is added. (For email, this is only possible when
                              using extensions to SMTP or non-SMTP transport
                              mechanisms.)</t>
                        </list> The sha1 value (in base64) for an empty
                        Content (canonicalized to a null input) is: <figure>
                           <artwork><![CDATA[2jmj7l5rSw0yVb/vlWAYkK/YBwk=]]></artwork>
                        </figure> The sha256 value is: <figure>
                           <artwork><![CDATA[47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=]]></artwork>
                        </figure>
                        <list
                           style="hanging">
                           <t
                              hangText="NOTE: ">The relaxed Content
                              canonicalization algorithm can enable certain
                              types of extremely crude "ASCII Art" attacks in
                              which a message can be conveyed, by adjusting
                              the spacing between words. If this is a concern,
                              the "simple" Content canonicalization algorithm
                              is more appropriate for use.</t>
                        </list>
                     </t>
                  </list></t>
            </section>

            <section
               title="Canonicalization Examples">
               <t>In the following examples, actual whitespace is used only
                  for clarity. The actual input and output text is designated
                  using bracketed descriptors: "&lt;SP&gt;" for a space
                  character, "&lt;HTAB&gt;" for a tab character, and
                  "&lt;CRLF&gt;" for a carriage-return/line-feed sequence. For
                  example, "X &lt;SP&gt; Y" and "X&lt;SP&gt;Y" represent the
                  same three characters.</t>
               <t>
                  <figure
                     align="left">
                     <preamble>Example 1: An email message reading:</preamble>
                     <artwork><![CDATA[A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
                <HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>]]></artwork>
                  </figure>
               </t>
               <t>
                  <figure
                     align="left">
                     <preamble>when canonicalized using relaxed
                        canonicalization for both Header and Content results
                        in a Header reading:</preamble>
                     <artwork><![CDATA[a:X <CRLF>
b:Y <SP> Z <CRLF>]]></artwork>
                  </figure>
               </t>
               <t>
                  <figure
                     align="left">
                     <preamble>and a Content reading:</preamble>
                     <artwork><![CDATA[<SP> C <CRLF>
D <SP> E <CRLF>]]></artwork>
                  </figure>
               </t>
               <t/>
               <t>
                  <figure
                     align="left">
                     <preamble>Example 2: The same message canonicalized using
                        simple canonicalization for both Header and Content
                        results in a header reading:</preamble>
                     <artwork><![CDATA[A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
       <HTAB> Z <SP><SP><CRLF>]]></artwork>
                  </figure>
               </t>
               <t>
                  <figure
                     align="left">
                     <preamble>and a Content reading:</preamble>
                     <artwork><![CDATA[<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>]]></artwork>
                  </figure>
               </t>
               <t/>
               <t>
                  <figure
                     align="left">
                     <preamble>Example 3: When processed using relaxed Header
                        canonicalization and simple Content canonicalization,
                        the canonicalized version has a header of:</preamble>
                     <artwork><![CDATA[a:X <CRLF>
b:Y <SP> Z <CRLF>]]></artwork>
                  </figure>
               </t>
               <t>
                  <figure
                     align="left">
                     <preamble>and a Content reading:</preamble>
                     <artwork><![CDATA[<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>]]></artwork>
                  </figure>
               </t>
            </section>

         </section>



         <section
            anchor="tagval"
            title="Tag=Value Parameters">
            <t>DOSETA uses a simple "tag=value" parameter syntax in several
               contexts, such as when representing associated cryptographic
               data and domain key records.</t>
            <t>Values are a series of strings containing either plain text,
               "base64" text (as defined in <xref
                  target="RFC2045"/>, Section&nbsp;6.8), "qp-section" (ibid,
               Section&nbsp;6.7), or "D-quoted-printable" (as defined in
               Section&nbsp;2.6). The definition of a tag will determine the
               specific encoding for its associated value. Unencoded semicolon
               (";") characters MUST NOT occur in the tag value, since that
               separates tag-specs. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">The "plain text" defined below, as
                     "tag-value", only supports use of 7-bit characters.
                     However, it is likely that support of UTF-8 Unicode <xref
                        target="UTF8"/> data will eventually be deemed
                     important. </t>
               </list></t>
            <t>Formally the syntax rules are as follows: <list>
                  <t>
                     <figure>
                        <preamble>ABNF:</preamble>
                        <artwork type="abnf"><![CDATA[tag-list  =  tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA 0*ALNUMPUNC
tag-value =  [ tval 0*( 1*(WSP / FWS) tval ) ]
                ; WSP and FWS prohibited at beginning and end
tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
                ; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC =  ALPHA / DIGIT / "_"]]></artwork>
                     </figure>
                  </t>
               </list>
               <list
                  style="hanging">
                  <t
                     hangText="NOTE: ">WSP is allowed anywhere around tags. In
                     particular, any WSP after the "=" and any WSP before the
                     terminating ";" is not part of the value. However, WSP
                     inside the value is significant.</t>
               </list>
            </t>
            <t>Tags MUST interpret a VALCHAR as case-sensitive, unless the
               specific tag description of semantics specifies case
               insensitivity.</t>
            <t>Tags MUST be unique; duplicate names MUST NOT occur within a
               single tag-list. If a tag name does occur more than once, the
               entire tag-list is invalid.</t>
            <t>Whitespace within a value MUST be retained unless explicitly
               excluded by the specific tag description.</t>
            <t>Tag=value pairs that represent the default value MAY be
               included to aid legibility.</t>
            <t> Unrecognized tags MUST be ignored.</t>
            <t>Tags that have an empty value are not the same as omitted tags.
               An omitted tag is treated as having the default value; a tag
               with an empty value explicitly designates the empty string as
               the value. </t>
         </section>

         <section
            anchor="keymgmt"
            title="Key Management">
            <t>Applications require some level of assurance that a producer is
               authorized to use a cited public. Many applications achieve
               this by using public key certificates issued by a trusted
               authority. For applications with modest certification
               requirements, DOSETA achieves a sufficient level of security,
               with excellent scaling properties, by simply having the
               consumer query the purported producer's DNS entry (or a
               supported equivalent) in order to retrieve the public key. The
               safety of this model is increased by the use of DNSSEC <xref
                  target="RFC4033"/> for the key records in the DNS.</t>
            <t>DOSETA keys might be stored in multiple types of key servers
               and in multiple formats. As long as the key-related information
               is the same and as long as the security properties of key
               storage and retrieval are the same, DOSETA's operation is
               unaffected by the actual source of a key. </t>
            <t>
               <list>
                  <t><figure>
                        <preamble>The abstract key lookup algorithm
                           is:</preamble>
                        <artwork><![CDATA[public-key = D-find-key(q-val, d-val, s-val)]]></artwork>
                     </figure> where: <list
                        style="hanging">
                        <t
                           hangText="q-val:  ">The type of the lookup, as
                           specified in the "q" parameter (<xref
                              target="signeddatastruct"/>)</t>
                        <t
                           hangText="d-val:  ">The domain of the signature, as
                           specified in the "d" parameter (<xref
                              target="signeddatastruct"/>)</t>
                        <t
                           hangText="s-val:  ">The selector of the lookup as
                           specified in the "s" parameter (<xref
                              target="signeddatastruct"/>)</t>
                        <t
                           hangText="D-find-key:  ">A function that uses q-val
                           to determine the specific details for accessing the
                           desired stored Key record.</t>
                     </list></t>
               </list>
            </t>
            <t>This document defines a single binding between the abstract
               lookup algorithm and a physical instance, using DNS TXT
               records, per <xref
                  target="dnsbind"/>. Other bindings can be defined.</t>
         </section>

         <section
            anchor="selectors"
            title="Selectors for Keys">

            <t>It can be extremely helpful to support multiple DOSETA keys for
               the same domain name. For example: <list>
                  <t><list
                        style="symbols">
                        <t>Rolling over from one key to another is a common
                           security administration requirement; for an
                           operational service this is made far easier when
                           the old and new keys are supported
                           simultaneously.</t>
                        <t>Domains that want to delegate signing capability
                           for a specific address for a given duration to a
                           partner, such as an advertising provider or other
                           outsourced function.</t>
                        <t> Domains that want to allow frequent travelers to
                           generate signed data locally without the need to
                           connect to a particular server.</t>
                        <t>"Affinity" domains (such as, college alumni
                           associations) that provide data forwarding, but
                           that do not operate a data origination agent for
                           outgoing data.</t>
                     </list></t>
               </list></t>

            <t>To these ends, DOSETA includes a mechanism that supports
               multiple concurrent public keys per signing domain. The key
               namespace is subdivided using "selectors". For example,
               selectors might indicate the names of office locations (for
               example, "sanfrancisco", "coolumbeach", and "reykjavik"), the
               signing date (for example, "january2005", "february2005",
               etc.), or even an individual user.</t>

            <t>For further administrative convenience, sub-division of
               selectors is allowed, distinguished as dotted sub-components of
               the selector name. When keys are retrieved from the DNS,
               periods in selectors define DNS label boundaries in a manner
               similar to the conventional use in domain names. Selector
               components might be used to combine dates with locations, for
               example, "march2005.reykjavik". In a DNS implementation, this
               can be used to allow delegation of a portion of the selector
               namespace.</t>
            <t>
               <list>
                  <t>
                     <figure>
                        <preamble>ABNF:</preamble>
                        <artwork type="abnf"><![CDATA[selector =  sub-domain *( "." sub-domain )]]></artwork>
                     </figure>
                  </t>
               </list>
            </t>
            <t>The number of public keys and the corresponding selectors for
               each domain are determined by the domain owner. Many domain
               owners will be satisfied with just one selector, whereas
               administratively distributed organizations might choose to
               manage disparate selectors and key pairs in different regions
               or on different servers.</t>
            <t>As noted, selectors make it possible to seamlessly replace
               public keys on a routine basis. If a domain wishes to change
               from using a public key associated with selector "january2005"
               to a public key associated with selector "february2005", it
               merely makes sure that both public keys are advertised in the
               public-key repository concurrently for the transition period
               during which data might be in transit prior to verification. At
               the start of the transition period, the outbound servers are
               configured to sign with the "february2005" private key. At the
               end of the transition period, the "january2005" public key is
               removed from the public-key repository. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="NOTE:  ">A key can also be revoked as
                           described below. The distinction between revoking
                           and removing a key selector record is subtle. When
                           phasing out keys as described above, a signing
                           domain would probably simply remove the key record
                           after the transition period. However, a signing
                           domain could elect to revoke the key (but maintain
                           the key record) for a further period. There is no
                           defined semantic difference between a revoked key
                           and a removed key.</t>
                     </list></t>
               </list></t>
            <t>While some domains might wish to make selector values well
               known, others will want to take care not to allocate selector
               names in a way that allows harvesting of data by outside
               parties. For example, if per-user keys are issued, the domain
               owner will need to make the decision as to whether to associate
               this selector directly with the name of a registered end-user,
               or make it some unassociated random value, such as a
               fingerprint of the public key. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="NOTE:  ">The ability to reuse a selector
                           with a new key (for example, changing the key
                           associated with a user's name) makes it impossible
                           to tell the difference between data that didn't
                           verify because the key is no longer valid versus a
                           data that is actually forged. For this reason,
                           reuse of selectors with different keys is
                           ill-advised. A better strategy is to assign new
                           keys to new selectors.</t>
                     </list></t>
               </list></t>
         </section>

         <section
            anchor="dnsbind"
            title="DNS Binding for Key Retrieval">
            <t>This section defines a binding using DNS TXT records as a key
               service. All implementations MUST support this binding.</t>
            <section
               title="Namespace">

               <t>A DOSETA key is stored in a subdomain named: <list>
                     <t><figure>
                           <preamble>ABNF:</preamble>
                           <artwork type="abnf"><![CDATA[dns-record =  s "._domainkey." d]]></artwork>
                        </figure> where: <list
                           style="hanging">
                           <t
                              hangText="s:  ">is the selector of the lookup as
                              specified in the "s" parameter (<xref
                                 target="signeddatastruct"/>); use of
                              selectors is discussed in <xref
                                 target="selectors"/></t>
                           <t
                              hangText="d:  ">is the domain of the signature,
                              as specified in the "d" parameter (<xref
                                 target="signeddatastruct"/>)</t>
                        </list></t>
                  </list>
                  <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The string constant "_domainkey" is
                        used to mark a sub-tree that contains unified DOSETA
                        key information. This string is a constant, rather
                        than being a different string for different key-based
                        services, with the view that keys are agnostic about
                        the service they are used for. That is, there is no
                        semantic or security benefit in having a different
                        constant string for different key services. That said,
                        a new service is certainly free to define a new
                        constant and maintain and entirely independent set of
                        keys.</t>
                  </list></t>


               <t>Given a DOSETA&nbhy;Signature field with a "d" parameter of
                  "example.com" and an "s" parameter of "foo.bar", the DNS
                  query will be for: <figure>
                     <artwork><![CDATA[foo.bar._domainkey.example.com]]></artwork>
                  </figure></t>


               <t>Wildcard DNS records (for example,
                  *.bar._domainkey.example.com) do not make sense in the
                  context of DOSETA and their presence can be problematic.
                  Hence DNS wildcards with DOSETA SHOULD NOT be used. Note
                  also that wildcards within domains (for example,
                  s._domainkey.*.example.com) are not supported by the
                  DNS.</t>


            </section>

            <section
               title="Resource Record Types for Key Storage">
               <t>The DNS Resource Record type used is specified by an option
                  to the query-type ("q") parameter. The only option defined
                  in this base specification is "txt", indicating the use of a
                  DNS TXT Resource Record (RR), as defined in <xref
                     target="keydata"/>. A later extension of this standard
                  might define another RR type.</t>
               <t>Strings in a TXT RR MUST be concatenated together before
                  use, with no intervening whitespace. TXT RRs MUST be unique
                  for a particular selector name; that is, if there are
                  multiple records in an RRset, the results are undefined.</t>
            </section>

         </section>

         <section
            anchor="keydata"
            title="Stored Key Data">
            <t>This section defines a syntax for encoding stored key data
               within an unstructured environment such as the simple text
               environment of a DNS TXT record. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="[TEMPLATE]  ">(Key Retrieval) A service
                           that incorporates DOSETA MAY define the specific
                           mechanism by which consumers can obtain associated
                           public keys. This might be as easy as referencing
                           an existing key management system or it might
                           require a new set of conventions.</t>
                        <t>Absent an explicit specification for key retrieval,
                           the default mechanism is specified in <xref
                              target="dnsbind"/>. Use of this means sharing
                           the set of public keys with DKIM and other
                           DOSETA-based services.</t>
                     </list></t>
               </list>
            </t>
            <t>The overall syntax is a tag-list as described in <xref
                  target="tagval"/>. The base set of valid tags is described
               below. Other tags MAY be present and MUST be ignored by any
               implementation that does not understand them.</t>
            <t>
               <list>
                  <t>
                     <list
                        style="hanging">
                        <!--<t
                           hangText="v=  "> Version of the DOSETA key record
                           (SHOULD be included; default is "DKIM1"). If
                           specified, this tag MUST be set to "DKIM1" (without
                           the quotes). This tag MUST be the first tag in the
                           record. Records beginning with a "v" parameter with
                           any other value MUST be discarded. Note that
                           verifiers MUST do a string comparison on this
                           value; for example, "DKIM1" is not the same as
                           "DKIM1.0". <list>
                              <t>ABNF: <figure>
                                    <artwork type="abnf"><![CDATA[key-v-tag    = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31]]></artwork>
                                 </figure></t>
                           </list><list
                              style="hanging">
                              <t
                                 hangText="NOTE:  ">The version string "DKIM1"
                                 is retained from the original DKIM
                                 specification, in order to preserve the
                                 installed base of records. In addition, there
                                 is no functional benefit in defining a new
                                 string, since the key record is not
                                 application-specific. Another use of the
                                 string is to distinguish the Domainkeys use
                                 of a TXT RR from other, unrelated uses.</t>
                           </list>
                        </t>-->

                        <t
                           hangText="k=  ">Key type (MAY be include; default
                           is "rsa"). Signers and verifiers MUST support the
                           "rsa" key type. The "rsa" key type indicates that
                           an ASN.1 DER-encoded <xref
                              target="ITU-X660-1997"/> RSAPublicKey <xref
                              target="RFC3447"/> (see Sections <xref
                              target="selectors"/> and A.1.1) is being used in
                           the "p" parameter. (Note: the "p" parameter further
                           encodes the value using the base64 algorithm.)
                           Unrecognized key types MUST be ignored. </t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; for future extension]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="n=  ">Notes that might be of interest to
                           a human (MAY be included; default is empty). No
                           interpretation is made by any program. This tag
                           should be used sparingly in any key server
                           mechanism that has space limitations (notably DNS).
                           This is intended for use by administrators, not end
                           users.</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[key-n-tag    = %x6e [FWS] "=" [FWS] qp-section]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="p=  ">Public-key data (MUST be included).
                           An empty value means that this public key has been
                           revoked. The syntax and semantics of this tag value
                           before being encoded in base64 are defined by the
                           "k" parameter. <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]]]></artwork>
                                 </figure></t>
                           </list>
                           <list
                              style="hanging">
                              <t
                                 hangText="NOTE:  ">If a private key has been
                                 compromised or otherwise disabled (for
                                 example, an outsourcing contract has been
                                 terminated), a signer might want to
                                 explicitly state that it knows about the
                                 selector, but also have all queries using
                                 that selector result in a failed
                                 verification. Verifiers SHOULD ignore any
                                 DOSETA&nbhy;Signature header fields with a
                                 selector referencing a revoked key.</t>
                              <t
                                 hangText="NOTE: ">A base64string is permitted
                                 to include white space (FWS) at arbitrary
                                 places; however, any CRLFs MUST be followed
                                 by at least one WSP character. Implementors
                                 and administrators are cautioned to ensure
                                 that selector TXT records conform to this
                                 specification.</t>
                           </list>
                        </t>
                     </list>
                  </t>
               </list>
            </t>
         </section>


      </section>

      <section
         anchor="template"
         title="DOSETA H/C Signing Template">
         <t>This section specifies the basic components of a signing
            mechanism; it is similar to the one defined for DKIM. This
            template for a signing service can be mapped to a two-part --
            header/content -- data model. As for DKIM this separates
            specification of the signer's identity from any other identifiers
            that might be associated with that data.<list>
               <t><list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The use of hashing and signing
                        algorithms by DOSETA inherently provides a degree of
                        data integrity protection, between the signing and
                        verifying steps. However it does not necessarily
                        "authenticate" the data that is signed. For example,
                        it does not inherently validate the accuracy of the
                        data or declare that the signer is the author or owner
                        of the data. To the extent that authentication is
                        meant by the presence of a signature, that needs to be
                        specified as part of the semantics for the service
                        based upon this template.</t>
                     <t
                        anchor="hcmapping"
                        hangText="[TEMPLATE]  ">(Header/Content Mapping) The
                        service incorporating this mechanism MUST define the
                        precise mappings onto the template provided in this
                        section. (Data lacking a header component might still
                        be possible to cast in a header/content form, where
                        the header comprises on the DOSETA Signature
                        information.)</t>
                     <t
                        hangText="">The service also MUST define the precise
                        meaning of a signature.</t>
                  </list></t>
            </list></t>

         <section
            anchor="cryptoalgs"
            title="Cryptographic Algorithms">
            <t>DOSETA supports multiple digital signature algorithms: </t>

            <t>
               <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="rsa-sha1:  "> The rsa-sha1 Signing
                           Algorithm computes a message hash as described in <xref
                              target="sigcalc"/> below using SHA-1 <xref
                              target="FIPS-180-2-2002"/> as a hashing
                           algorithm. That hash is then signed by the signer
                           using the RSA algorithm (defined in PKCS#1 version
                           1.5 <xref
                              target="RFC3447"/>) as the crypt-alg and the
                           signer's private key. The hash MUST NOT be
                           truncated or converted into any form other than the
                           native binary form before being signed. The signing
                           algorithm SHOULD use a public exponent of
                           65537.</t>
                        <t
                           hangText="rsa-sha256:  "> The rsa-sha256 Signing
                           Algorithm computes a message hash as described in <xref
                              target="RFC5451"/> below using SHA-256 <xref
                              target="FIPS-180-2-2002"/> as the hash-alg. That
                           hash is then signed by the signer using the RSA
                           algorithm (defined in PKCS#1 version 1.5 <xref
                              target="RFC3447"/>) as the crypt-alg and the
                           signer's private key. The hash MUST NOT be
                           truncated or converted into any form other than the
                           native binary form before being signed.</t>
                        <t
                           hangText="Other:  "> Other algorithms MAY be
                           defined in the future. Verifiers MUST ignore any
                           signatures using algorithms that they do not
                           implement.</t>
                     </list></t>
               </list> Signers MUST implement and SHOULD sign using
               rsa-sha256. Verifiers MUST implement rsa-sha256. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Although sha256 is strongly
                     encouraged, some senders of low-security messages (such
                     as routine newsletters) might prefer to use sha1 because
                     of reduced CPU requirements to compute a sha1 hash. In
                     general, sha256 is always preferred, whenever
                     possible.</t>
               </list></t>


            <t>Selecting appropriate key sizes is a trade-off between cost,
               performance, and risk. Since short RSA keys more easily succumb
               to off-line attacks, signers MUST use RSA keys of at least 1024
               bits for long-lived keys. Verifiers MUST be able to validate
               signatures with keys ranging from 512 bits to 2048 bits, and
               they MAY be able to validate signatures with larger keys.
               Verifier policies might use the length of the signing key as
               one metric for determining whether a signature is
               acceptable.</t>
            <t>Factors that ought to influence the key size choice include the
               following: <list>
                  <t><list
                        style="symbols">
                        <t>The practical constraint that large (for example,
                           4096 bit) keys might not fit within a 512-byte DNS
                           UDP response packet</t>
                        <t>The security constraint that keys smaller than 1024
                           bits are subject to off-line attacks</t>
                        <t>Larger keys impose higher CPU costs to verify and
                           sign data</t>
                        <t>Keys can be replaced on a regular basis, thus their
                           lifetime can be relatively short</t>
                        <t>The security goals of this specification are modest
                           compared to typical goals of other systems that
                           employ digital signatures</t>
                     </list></t>
               </list></t>
            <t>See <xref
                  target="RFC3766"/> for further discussion on selecting key
               sizes.</t>

         </section>


         <section
            anchor="signeddatastruct"
            title="Signature Data Structure">
            <t>A signature of data is stored into an data structure associated
               with the signed data. This structure contains all of the
               signature&nbhy; and key&nbhy;fetching data. This
               DOSETA&nbhy;Signature structure is a tag-list as defined in <xref
                  target="tagval"/>. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="[TEMPLATE]  ">(Signature Association) A
                           service that incorporates DOSETA MUST define the
                           exact means by which the Signature structure is
                           associated with the data.</t>
                     </list></t>
               </list></t>
            <t>When the DOSETA&nbhy;Signature structure is part of a sequence
               of structures -- such as being added to an email header -- it
               SHOULD NOT be reordered and SHOULD be pre-pended to the
               message. (This is the same handling as is given to email trace
               Header fields, defined in Section&nbsp;3.6 of <xref
                  target="RFC5322"/>.) </t>

            <t>The tags are specified below. Tags described as
               &lt;qp-section&gt; are encoded as described in Section&nbsp;6.7
               of MIME Part One <xref
                  target="RFC2045"/>, with the additional conversion of
               semicolon characters to "=3B"; intuitively, this is one line of
               quoted-printable encoded text. The D-quoted-printable syntax is
               defined in <xref
                  target="D-quoted-printable"/>.</t>

            <t>Tags on the DOSETA&nbhy;Signature structure along with their
               type and requirement status are shown below. Unrecognized tags
               MUST be ignored. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="v=  ">Version (MUST be included). This
                           tag defines the version of this specification that
                           applies to the signature record. It MUST have the
                           value "1". Note that verifiers MUST do an exact
                           string comparison on this value; for example, "1"
                           is not the same as "1.0". <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-v-tag       = %x76 [FWS] "=" [FWS] "1"]]></artwork>
                                 </figure></t>
                           </list>
                           <list
                              style="hanging">
                              <t
                                 hangText="NOTE: ">DOSETA&nbhy;Signature
                                 version numbers are expected to increase
                                 arithmetically as new versions of this
                                 specification are released.</t>
                           </list>
                        </t>
                        <t
                           hangText="a=  ">The algorithm used to generate the
                           signature (MUST be included). Verifiers MUST
                           support "rsa-sha1" and "rsa-sha256"; signers SHOULD
                           sign using "rsa-sha256". See <xref
                              target="cryptoalgs"/> for a description of
                           algorithms.</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[
sig-a-tag       = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k     = "rsa" / x-sig-a-tag-k
sig-a-tag-h     = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)   
                     ; for later extension
x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)   
                     ; for later extension]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="b=  ">The signature data (MUST be
                           included). Whitespace is ignored in this value and
                           MUST be ignored when reassembling the original
                           signature. In particular, the signing process can
                           safely insert FWS in this value in arbitrary places
                           to conform to line-length limits. See Signer
                           Actions (<xref
                              target="signer"/>) for how the signature is
                           computed.</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-b-tag       = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data  = base64string]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="bh=  ">The hash of the canonicalized
                           Content (body), as limited by the "l" parameter
                           (MUST be included). Whitespace is ignored in this
                           value and MUST be ignored when reassembling the
                           original signature. In particular, the signing
                           process can safely insert FWS in this value in
                           arbitrary places to conform to line-length limits.
                           See <xref
                              target="sigcalc"/> for how the Content hash is
                           computed. <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-bh-tag      = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="c=  ">Data canonicalization (MAY be
                           included; default is "simple/simple"). This tag
                           informs the verifier of the type of
                           canonicalization used to prepare the message for
                           signing. It consists of two names separated by a
                           "slash" (%d47) character, corresponding to the
                           header and Content canonicalization algorithms
                           respectively: <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-bh-tag      = %x63 [FWS] "=" [FWS] sig-c-header "/" sig-c-content]]></artwork>
                                 </figure> where:<list
                                    style="hanging">
                                    <t
                                       hangText="sig-c-header:  ">A value from
                                       Header Canonicalization IANA registry
                                       defined in <xref
                                       target="DKIMSign"/></t>
                                    <t
                                       hangText="sig-c-content:  ">A value
                                       from Message Canonicalization IANA
                                       registry defined in <xref
                                       target="DKIMSign"/></t>
                                 </list>
                              </t>
                           </list> These algorithms are described in <xref
                              target="canon"/>. If only one algorithm is
                           named, that algorithm is used for the header and
                           "simple" is used for the Content. For example,
                           "c=relaxed" is treated the same as
                           "c=relaxed/simple".</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-c-tag       = %x63 [FWS] "=" [FWS] sig-c-tag-alg
                  ["/" sig-c-tag-alg]
sig-c-tag-alg   = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word    ; for later extension]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>

                        <t
                           hangText="cl=  ">A list of semantic claims,
                           asserting the set of "meanings" intended by the
                           signer, such as author validity or content validity
                           (SHOULD be included; default is "handled"}. The
                           list of supported claims comprises values from the
                           DOSETA Claims IANA registry, defined in <xref
                              target="dosetaclaims"/> using values listed in <xref
                              target="ianaclaims"/>. </t>

                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-cl-tag        = %x63 %x6C [FWS] "=" [FWS]
                                        sig-cl-tag-claim
                                        ["/" sig-c-tag-claim]
sig-c-tag-claim   = hyphenated-word 
                       ; per DOSETA Claims Registry]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           anchor="dsemantics"
                           hangText="d=  ">The DDI doing the signing (MUST be
                           included). Hence, the DDI value is used to form the
                           query for the public key. The DDI MUST correspond
                           to a valid DNS name under which the DOSETA key
                           record is published. The conventions and semantics
                           used by a signer to create and use a specific DDI
                           are outside the scope of the DOSETA Signing
                           specification, as is any use of those conventions
                           and semantics. When presented with a signature that
                           does not meet these requirements, verifiers MUST
                           consider the signature invalid.</t>
                        <t>Internationalized domain names MUST be encoded as
                           described in <xref
                              target="RFC5890"/>.</t>
                        <t><list>
                              <t><list
                                    style="hanging">
                                    <t
                                       hangText="[TEMPLATE]  ">(Semantics) The
                                       service incorporating DOSETA MUST
                                       define the semantics of a
                                       signature.</t>
                                 </list></t>
                           </list></t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[
sig-d-tag       = %x64 [FWS] "=" [FWS] domain-name
domain-name     = sub-domain 1*("." sub-domain) 
                     ; from RFC 5321 Domain, 
                     ; but excluding address-literal]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="h=  ">Signed Header fields (MUST be
                           included). A colon-separated list of header field
                           names that identify the Header fields presented to
                           the signing algorithm. The field MUST contain the
                           complete list of Header fields in the order
                           presented to the signing algorithm. The field MAY
                           contain names of Header fields that do not exist
                           when signed; nonexistent Header fields do not
                           contribute to the signature computation (that is,
                           they are treated as the null input, including the
                           header field name, the separating colon, the header
                           field value, and any CRLF terminator). The field
                           MUST NOT include the DOSETA Signature header field
                           that is being created or verified, but might
                           include others. Folding whitespace (FWS) MAY be
                           included on either side of the colon separator.
                           Header field names MUST be compared against actual
                           header field names in a case-insensitive manner.
                           This list MUST NOT be empty. See <xref
                              target="fields2sign"/> for a discussion of
                           choosing Header fields to sign.</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-h-tag       = %x68 [FWS] "=" [FWS] hdr-name
                   0*( [FWS] ":" [FWS] hdr-name )]]></artwork>
                                 </figure></t>
                           </list></t>
                        <t>By "signing" Header fields that do not actually
                           exist, a signer can prevent insertion of those
                           Header fields before verification. However, since a
                           signer cannot possibly know all possible Header
                           fields that might be created in the future, the
                           security of this solution is not total.</t>
                        <t>The exclusion of the header field name and colon as
                           well as the header field value for non-existent
                           Header fields prevents an attacker from inserting
                           an actual header field with a null value.</t>
                        <t
                           hangText="q=  ">A colon-separated list of query
                           methods used to retrieve the public key (MAY be
                           included; default is "dns/txt"). Each query method
                           is of the form "type[/options]", where the syntax
                           and semantics of the options depend on the type and
                           specified options. If there are multiple query
                           mechanisms listed, the choice of query mechanism
                           MUST NOT change the interpretation of the
                           signature. Implementations MUST use the recognized
                           query mechanisms in the order presented.
                           Unrecognized query mechanisms MUST be ignored. </t>
                        <t>Currently, the only valid value is "dns/txt", which
                           defines the DNS TXT record lookup algorithm
                           described elsewhere in this document. The only
                           option defined for the "dns" query type is "txt",
                           which MUST be included. Verifiers and signers MUST
                           support "dns/txt".</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-q-tag        = %x71 [FWS] "=" [FWS] sig-q-tag-method
                      *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
                   ["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word  ; for future extension
x-sig-q-tag-args = qp-hdr-value]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="s=  ">The selector subdividing the
                           namespace for the "d=" (domain) tag (MUST be
                           included).</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-s-tag    = %x73 [FWS] "=" [FWS] selector]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="t=  ">Signature Timestamp (SHOULD be
                           included; default is an unknown creation time). The
                           time that this signature was created. The format is
                           the number of seconds since 00:00:00 on January 1,
                           1970 in the UTC time zone. The value is expressed
                           as an unsigned integer in decimal ASCII. This value
                           is not constrained to fit into a 31- or 32-bit
                           integer. Implementations SHOULD be prepared to
                           handle values up to at least 10^12 (until
                           approximately AD 200,000; this fits into 40 bits).
                           To avoid denial-of-service attacks, implementations
                           MAY consider any value longer than 12 digits to be
                           infinite. Leap seconds are not counted.
                           Implementations MAY ignore signatures that have a
                           timestamp in the future.</t>
                        <t>
                           <list>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-t-tag    = %x74 [FWS] "=" [FWS] 1*12DIGIT]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                        <t
                           hangText="x=  ">Signature Expiration (SHOULD be
                           included; default is no expiration). The format is
                           the same as in the "t" parameter, represented as an
                           absolute date, not as a time delta from the signing
                           timestamp. The value is expressed as an unsigned
                           integer in decimal ASCII, with the same constraints
                           on the value in the "t=" tag. Signatures MAY be
                           considered invalid if the verification time at the
                           verifier is past the expiration date. Ideally
                           verification time is when a message is first
                           received at the administrative domain of the
                           verifier; otherwise the current time SHOULD be
                           used. The value of the "x" parameter MUST be
                           greater than the value of the "t" parameter if both
                           are present.</t>
                        <t>
                           <list
                              style="hanging">
                              <t
                                 hangText="NOTE: ">The "x" parameter is not
                                 intended as an anti-replay defense.</t>
                              <t
                                 hangText="NOTE: "> Due to clock drift, the
                                 receiver's notion of when to consider the
                                 signature expired might not match exactly
                                 when the sender is expecting. Receivers MAY
                                 add a 'fudge factor' to allow for such
                                 possible drift. </t>
                              <t>
                                 <figure>
                                    <preamble>ABNF:</preamble>
                                    <artwork type="abnf"><![CDATA[sig-x-tag    = %x78 [FWS] "=" [FWS]
               1*12DIGIT]]></artwork>
                                 </figure>
                              </t>
                           </list>
                        </t>
                     </list></t>
               </list></t>
         </section>

         <section
            anchor="addedtags"
            title="Additional Tags">
            <t>Some applications can benefit from additional, common
               functional enhancements. These are defined here, as options to
               the core mechanism. </t>


            <t>
               <list>
                  <t>
                     <list
                        style="hanging">
                        <t
                           hangText="id=  "> The local identifier, restricting
                           the scope of the DDI, such as to a specific user.
                           This value is combined with the DDI, to specify the
                           identifier to be used for assessment.
                           Administrative choices for selectors can provide
                           different keys for different local identifiers. See <xref
                              target="selectors"/><list>
                              <t>ABNF: <figure>
                                    <artwork type="abnf"><![CDATA[key-id-tag   = %x69 %64 [FWS] "=" [FWS] hyphenated-word ]]></artwork>
                                 </figure></t>
                           </list>
                        </t>
                     </list>
                  </t>
               </list>
            </t>
         </section>

         <section
            anchor="sigcalc"
            title="Signature Calculations">
            <t>Hashing and cryptographic signature algorithms are combined
               into a procedure for computing a digital signature. Producers
               will choose appropriate parameters for the signing process.
               Consumers will use the tags that are then passed as an
               associated DOSETA&nbhy;Signature header field. <xref
                  target="signeddatastruct"/>. In the following discussion,
               the names of the tags are parameters in that field. </t>

            <t>The basic operations for producing a signature are
               canonicalization, hashing and signing. Canonicalization removes
               irrelevant variations. Hashing produces a very short
               representation for the data and signing produces a unique,
               protected string to be exchanged. <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="NOTE:  "> Canonicalization (see <xref
                              target="canon"/>) prepares a separate
                           representation of the data for additional
                           processing; it does not affect the original,
                           transmitted data in any way.</t>
                     </list></t>
               </list></t>

            <t>Producers MUST compute hashes in the order defined. Consumers
               MAY compute them in any order convenient to the producer,
               provided that the result is semantically identical to the
               semantics that would occur, had they been computed in this
               order.</t>

            <t>The combined hashing and signing algorithms are: <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Content Hash:  "><list
                              style="numbers">
                              <t>Truncate the content to the length specified
                                 in the "l" parameter. </t>
                              <t>Canonicalize the truncated content, using the
                                 algorithm specified in the "c" parameter. </t>
                              <t>Hash the canonicalized content, using the
                                 hashing algorithm specified in the "a"
                                 parameter.</t>
                              <t>Convert the resulting hash to base64 form. </t>
                              <t>Signers then insert the base64 result into
                                 the "bh" parameter of the
                                 DOSETA&nbhy;Signature field; verifiers
                                 compare their hash with the value in the "bh"
                                 parameter.</t>
                           </list></t>

                        <t
                           hangText="Header Hash:  "><list
                              style="numbers">
                              <t>Select the header fields specified by the "h"
                                 parameter.</t>
                              <t>Ensure that each field is terminated by a
                                 single CRLF.</t>
                              <t>Canonicalize each of these fields, using the
                                 header canonicalization algorithm specified
                                 in the "c" parameter. </t>
                              <t>Select the DOSETA&nbhy;Signature field that
                                 exists (verifying), or will be inserted
                                 (signing), in the header.</t>
                              <t>From that field, delete the value portion of
                                 the "b" parameter, including all surrounding
                                 whitespace; that is, treat the "b" parameter
                                 as containing an empty string. </t>
                              <t>Canonicalize the resulting field, using the
                                 Header canonicalization algorithm specified
                                 in the "c" parameter, but remove the trailing
                                 CRLF, if present. </t>
                              <t>Using the hashing algorithm specified in the
                                 "a" parameter, hash the sequence: <list
                                    style="numbers">
                                    <t>the canonicalized header fields, in the
                                       order specified by the "h" parameter, </t>
                                    <t>the output from the content hash,
                                       and</t>
                                    <t>the canonicalized DOSETA&nbhy;Signature
                                       field.</t>
                                 </list></t>
                           </list></t>

                        <t
                           hangText="Signature:  ">
                           <list
                              style="numbers">
                              <t>Obtain the relevant key associated with the
                                 relevant domain and selector; for signing
                                 this is a private key; for verifying this is
                                 a public key. </t>
                              <t>Obtain the header hash produced by the
                                 previous calculation.</t>
                              <t>Using the signing algorithm specified in the
                                 "a" parameter, and the relevant key, process
                                 the hash.</t>
                           </list>
                        </t>
                     </list></t>
               </list>
            </t>


            <t>All tags cited in the "h" parameter MUST be included even if
               they are not understood by the verifier. Note that the
               DOSETA&nbhy;Signature field is presented to the hash algorithm
               after the content hash is processed, rather than with the rest
               of the header fields that are processed before the content
               hash. The DOSETA&nbhy;Signature header structure MUST NOT be
               cited in its own h= tag. If present, other
               DOSETA&nbhy;Signature header fields MAY be cited and included
               in the signature process (see <xref
                  target="multisig"/>).</t>
            <t>When calculating the hash on data that will be transmitted
               using additional encoding, such as base64 or quoted-printable,
               signers MUST compute the hash after the encoding. Likewise, the
               verifier MUST incorporate the values into the hash before
               decoding the base64 or quoted-printable text. However, the hash
               MUST be computed before transport level encodings such as SMTP
               "dot-stuffing" (the modification of lines beginning with a "."
               to avoid confusion with the SMTP end-of-message marker, as
               specified in <xref
                  target="RFC5321"/>).</t>
            <t>With the exception of the canonicalization procedure described
               in <xref
                  target="canon"/>, the DOSETA signing process treats the
               content as a simple string of octets. DOSETA content MAY be
               either simple lines of plain-text or as a MIME object; no
               special treatment is afforded to MIME content. </t>


            <t>Formally, the algorithm for the signature is as follows: <list>
                  <t><figure>
                        <preamble>ABNF: </preamble>
                        <artwork type="abnf"><![CDATA[content-hash =  hash-alg (canon-content, l-param)
data-hash    =  hash-alg (h-headers, D-SIG, content-hash) 
signature    =  sig-alg (d-domain, selector, data-hash) ]]></artwork>
                     </figure></t>
               </list>
            </t>
            <t>where: <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="content-hash:  ">is the output from
                           hashing the content, using hash-alg.</t>
                        <t
                           hangText="hash-alg:  ">is the hashing algorithm
                           specified in the "a" parameter.</t>
                        <t
                           hangText="canon-content:  ">is a canonicalized
                           representation of the content.</t>
                        <t
                           hangText="l-param:  ">is the length-of-content
                           value of the "l" parameter.</t>
                        <t
                           hangText="data-hash:  ">is the output from using
                           the hash-alg algorithm, to hash the header
                           including the DKIM&nbhy;Signature header, and the
                           content hash.</t>
                        <t
                           hangText="h-headers:  ">is the list of headers to
                           be signed, as specified in the "h" parameter.</t>
                        <t
                           hangText="D-SIG:  ">is the canonicalized
                           DOSETA&nbhy;Signature field without the signature
                           value portion of the parameter, itself; that is, an
                           empty parameter value.</t>
                        <t
                           hangText="canon-content:  ">is the canonicalized
                           data content (respectively) as defined in <xref
                              target="canon"/> (excluding the
                           DOSETA&nbhy;Signature field). </t>
                        <t
                           hangText="signature:  ">is the signature value
                           produced by the signing algorithm.</t>
                        <t
                           hangText="sig-alg:  ">is the signature algorithm
                           specified by the "a" parameter.</t>
                        <t
                           hangText="d-domain:  ">is the domain name specified
                           in the "d" parameter.</t>
                        <t
                           hangText="selector:  ">is the selector value
                           specified in the "s" parameter.</t>
                     </list></t>
               </list>
               <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Many digital signature APIs provide
                     both hashing and application of the RSA private key using
                     a single "sign()" primitive. When using such an API, the
                     last two steps in the algorithm would probably be
                     combined into a single call that would simultaneously
                     perform both "a-hash-alg" and the "sig-alg".</t>
               </list></t>


         </section>


         <section
            anchor="signer"
            title="Signer Actions">
            <t>The following steps are performed in order by signers.</t>

            <section
               title="Determine Whether the Data Should Be Signed and by Whom">
               <t>A signer can obviously only sign data using domains for
                  which it has a private key and the necessary knowledge of
                  the corresponding public key and selector information.
                  However, there are a number of other reasons beyond the lack
                  of a private key why a signer could choose not to sign the
                  data. <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">Signing modules can be incorporated
                        into any portion of a service, as deemed appropriate,
                        including end-systems, servers and intermediaries.
                        Wherever implemented, signers need to beware of the
                        semantics of signing data. An example of how this can
                        be problematic is that within a trusted enclave the
                        signing address might be derived from the data
                        according to local policy; the derivation is based on
                        local trust rather than explicit validation.</t>
                  </list></t>
               <t>If the data cannot be signed for some reason, the
                  disposition of that data is a local policy decision.</t>
            </section>

            <section
               anchor="selectpriv"
               title="Select a Private Key and Corresponding Selector Information">
               <t>This specification does not define the basis by which a
                  signer ought to choose which private key and selector
                  information to use. Currently, all selectors are equal, with
                  respect to this specification. So the choices ought to
                  largely be a matter of administrative convenience.
                  Distribution and management of private keys is also outside
                  the scope of this document. <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">A signer SHOULD use a private key
                        with an associated selector record that is expected to
                        still be valid by time the verifier is likely to have
                        an opportunity to validate the signature. The signer
                        SHOULD anticipate that verifiers can choose to defer
                        validation, perhaps until the message is actually read
                        by the final recipient. In particular, when rotating
                        to a new key pair, signing SHOULD immediately commence
                        with the new private key, but the old public key
                        SHOULD be retained for a reasonable validation
                        interval before being removed from the key server.</t>
                  </list></t>
            </section>

            <section
               anchor="fields2sign"
               title="Determine the Header Fields to Sign">
               <t> Signers SHOULD NOT sign an existing header field that is
                  likely to be legitimately modified or removed in transit.
                  Signers MAY include any other Header fields present at the
                  time of signing at the discretion of the signer. <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The choice of which Header fields
                        to sign is non-obvious. One strategy is to sign all
                        existing, non-repeatable Header fields. An alternative
                        strategy is to sign only Header fields that are likely
                        to be displayed to or otherwise be likely to affect
                        the processing of the Content at the receiver. A third
                        strategy is to sign only "well known" headers. Note
                        that verifiers might treat unsigned Header fields with
                        extreme skepticism, including refusing to display them
                        to the end user or even ignoring the signature if it
                        does not cover certain Header fields. </t>
                  </list></t>
               <t> The DOSETA&nbhy;Signature header field is always implicitly
                  signed and MUST NOT be included in the "h" parameter except
                  to indicate that other preexisting signatures are also
                  signed.</t>
               <t>Signers MAY claim to have signed Header fields that do not
                  exist (that is, signers MAY include the header field name in
                  the "h" parameter even if that header field does not exist
                  in the message). When computing the signature, the
                  non-existing header field MUST be treated as the null string
                  (including the header field name, header field value, all
                  punctuation, and the trailing CRLF). <list
                     style="hanging">
                     <t
                        hangText="NOTE: ">This allows signers to explicitly
                        assert the absence of a header field; if that header
                        field is added later the signature will fail.</t>
                     <t
                        hangText="NOTE: ">A header field name need only be
                        listed once more than the actual number of that header
                        field in a message at the time of signing in order to
                        prevent any further additions. For example, if there
                        is a single Comments header field at the time of
                        signing, listing Comments twice in the "h" parameter
                        is sufficient to prevent any number of Comments Header
                        fields from being appended; it is not necessary (but
                        is legal) to list Comments three or more times in the
                        "h" parameter.</t>
                  </list></t>
               <t>Signers choosing to sign an existing header field that
                  occurs more than once in the message (such as Received) MUST
                  sign the physically last instance of that header field in
                  the header block. Signers wishing to sign multiple instances
                  of such a header field MUST include the header field name
                  multiple times in the h= tag of the DOSETA&nbhy;Signature
                  header field, and MUST sign such Header fields in order from
                  the bottom of the header field block to the top. The signer
                  MAY include more instances of a header field name in h= than
                  there are actual corresponding Header fields to indicate
                  that additional Header fields of that name SHOULD NOT be
                  added. <list>
                     <t>EXAMPLE:</t>
                     <t>If the signer wishes to sign two existing Received
                        Header fields, and the existing header contains: <figure
                           align="left">
                           <artwork><![CDATA[Received: <A>
Received: <B>
Received: <c> ]]></artwork>
                        </figure>
                        <figure
                           align="left">
                           <preamble>then the resulting DOSETA&nbhy;Signature
                              header field ought to read:</preamble>
                           <artwork><![CDATA[
DKIM-Signature: ... h=Received : Received :...]]></artwork>
                        </figure> and Received Header fields &lt;C&gt; and
                        &lt;B&gt; will be signed in that order.</t>
                  </list></t>
               <t>Signers need to be careful of signing Header fields that
                  might have additional instances added later in the delivery
                  process, since such Header fields might be inserted after
                  the signed instance or otherwise reordered. Trace Header
                  fields (such as Received) and Resent-* blocks are the only
                  fields prohibited by <xref
                     target="RFC5322"/> from being reordered. In particular,
                  since DOSETA&nbhy;Signature Header fields might be reordered
                  by some intermediate MTAs, signing existing
                  DOSETA&nbhy;Signature Header fields is error-prone. <list
                     style="hanging">
                     <t
                        hangText="NOTE: ">Despite the fact that <xref
                           target="RFC5322"/> permits Header fields to be
                        reordered (with the exception of Received Header
                        fields), reordering of signed Header fields with
                        multiple instances by intermediate MTAs will cause
                        DOSETA signatures to be broken; such anti-social
                        behavior ought to be avoided.</t>
                     <t
                        hangText="NOTE: ">Although not required by this
                        specification, all end-user visible Header fields
                        SHOULD be signed to avoid possible "indirect
                        spamming". For example, if the Subject header field is
                        not signed, a spammer can resend a previously signed
                        mail, replacing the legitimate subject with a one-line
                        spam.</t>
                  </list></t>
            </section>

            <section
               title="Compute the Message Signature">
               <t>The signer MUST compute the message hash as described in <xref
                     target="sigcalc"/> and then sign it using the selected
                  public-key algorithm. This will result in a
                  DOSETA&nbhy;Signature header field that will include the
                  Content hash and a signature of the header hash, where that
                  header includes the DOSETA&nbhy;Signature header field
                  itself.</t>
               <t>Entities such as mailing list managers that implement DOSETA
                  and that modify the message or a header field (for example,
                  inserting unsubscribe information) before retransmitting the
                  message SHOULD check any existing signature on input and
                  MUST make such modifications before re-signing the
                  message.</t>
               <t> The signer MAY elect to limit the number of bytes of the
                  Content that will be included in the hash and hence signed.
                  The length actually hashed SHOULD be inserted in the "l="
                  tag of the DOSETA&nbhy;Signature header field.</t>
            </section>
            <section
               title="Insert the DOSETA&nbhy;Signature Header Field">
               <t>Finally, the signer MUST insert the DOSETA&nbhy;Signature
                  header field created in the previous step prior to
                  transmitting the data. The DOSETA&nbhy;Signature header
                  field MUST be the same as used to compute the hash as
                  described above, except that the value of the "b" parameter
                  MUST be the appropriately signed hash computed in the
                  previous step, signed using the algorithm specified in the
                  "a" parameter of the DOSETA&nbhy;Signature header field and
                  using the private key corresponding to the selector given in
                  the "s=" tag of the DOSETA&nbhy;Signature header field, as
                  chosen above in <xref
                     target="selectpriv"/></t>
               <t>The DOSETA&nbhy;Signature header field MUST be inserted
                  before any other DOSETA&nbhy;Signature fields in the header
                  block. <list
                     style="hanging">
                     <t
                        hangText="NOTE: ">The easiest way to achieve this is
                        to insert the DOSETA&nbhy;Signature header field at
                        the beginning of the header block. In particular, it
                        might be placed before any existing Received Header
                        fields. This is consistent with treating
                        DOSETA&nbhy;Signature as a trace header field.</t>
                  </list></t>
            </section>
         </section>
         <section
            anchor="verifier"
            title="Verifier Actions">
            <t>Since a signer MAY remove or revoke a public key at any time,
               it is recommended that verification occur in a timely manner.
               In many configurations, the most timely place is during
               acceptance by the border MTA or shortly thereafter. In
               particular, deferring verification until the message is
               accessed by the end user is discouraged.</t>
            <t>A border or intermediate server MAY verify the data
               signature(s). An server that has performed verification MAY
               communicate the result of that verification by adding a
               verification header field to incoming data.</t>
            <t>A verifying server MAY implement a policy with respect to
               unverifiable data, regardless of whether or not it applies the
               verification header field to signed messages.</t>
            <t>Verifiers MUST produce a result that is semantically equivalent
               to applying the following steps in the order listed. In
               practice, several of these steps can be performed in parallel
               in order to improve performance.</t>
            <section
               anchor="extractsig"
               title="Extract Signatures from the Message">
               <t> The order in which verifiers try DOSETA&nbhy;Signature
                  Header fields is not defined; verifiers MAY try signatures
                  in any order they like. For example, one implementation
                  might try the signatures in textual order, whereas another
                  might try signatures by identities that match the contents
                  of the From header field before trying other signatures.
                  Verifiers MUST NOT attribute ultimate meaning to the order
                  of multiple DOSETA&nbhy;Signature Header fields. In
                  particular, there is reason to believe that some relays will
                  reorder the Header fields in potentially arbitrary ways. <list
                     style="hanging">
                     <t
                        hangText="NOTE: ">Verifiers might use the order as a
                        clue to signing order in the absence of any other
                        information. However, other clues as to the semantics
                        of multiple signatures (such as correlating the
                        signing host with Received Header fields) might also
                        be considered.</t>
                  </list></t>
               <t>A verifier SHOULD NOT treat a message that has one or more
                  bad signatures and no good signatures differently from a
                  message with no signature at all; such treatment is a matter
                  of local policy and is beyond the scope of this
                  document.</t>
               <t>When a signature successfully verifies, a verifier will
                  either stop processing or attempt to verify any other
                  signatures, at the discretion of the implementation. A
                  verifier MAY limit the number of signatures it tries to
                  avoid denial-of-service attacks. <list
                     style="hanging">
                     <t
                        hangText="NOTE: ">An attacker could send messages with
                        large numbers of faulty signatures, each of which
                        would require a DNS lookup and corresponding CPU time
                        to verify the message. This could be an attack on the
                        domain that receives the message, by slowing down the
                        verifier by requiring it to do a large number of DNS
                        lookups and/or signature verifications. It could also
                        be an attack against the domains listed in the
                        signatures, essentially by enlisting innocent
                        verifiers in launching an attack against the DNS
                        servers of the actual victim.</t>
                  </list></t>
               <t>In the following description, text reading "return status
                  (explanation)" (where "status" is one of "PERMFAIL" or
                  "TEMPFAIL") means that the verifier MUST immediately cease
                  processing that signature. The verifier SHOULD proceed to
                  the next signature, if any is present, and completely ignore
                  the bad signature. If the status is "PERMFAIL", the
                  signature failed and SHOULD NOT be reconsidered. If the
                  status is "TEMPFAIL", the signature could not be verified at
                  this time but might be tried again later. A verifier MAY
                  either defer the message for later processing, perhaps by
                  queueing it locally or issuing a 451/4.7.5 SMTP reply, or
                  try another signature; if no good signature is found and any
                  of the signatures resulted in a TEMPFAIL status, the
                  verifier MAY save the message for later processing. The
                  "(explanation)" is not normative text; it is provided solely
                  for clarification.</t>
               <t>Verifiers SHOULD ignore any DOSETA&nbhy;Signature Header
                  fields where the signature does not validate. Verifiers that
                  are prepared to validate multiple signature Header fields
                  SHOULD proceed to the next signature header field, if it
                  exists. However, verifiers MAY make note of the fact that an
                  invalid signature was present for consideration at a later
                  step. <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The rationale of this requirement
                        is to permit messages that have invalid signatures but
                        also a valid signature to work. For example, a mailing
                        list exploder might opt to leave the original
                        submitter signature in place even though the exploder
                        knows that it is modifying the message in some way
                        that will break that signature, and the exploder
                        inserts its own signature. In this case, the message
                        ought to succeed even in the presence of the
                        known-broken signature.</t>
                  </list></t>
               <t>For each signature to be validated, the following steps need
                  to be performed in such a manner as to produce a result that
                  is semantically equivalent to performing them in the
                  indicated order.</t>
            </section>

            <section
               anchor="validatesig"
               title="Validate the Signature Header Field">
               <t>Implementers MUST meticulously validate the format and
                  values in the DOSETA&nbhy;Signature header field; any
                  inconsistency or unexpected values MUST cause the header
                  field to be completely ignored and the verifier to return
                  PERMFAIL (signature syntax error). Being "liberal in what
                  you accept" is definitely a bad strategy in this security
                  context. Note however that this does not include the
                  existence of unknown tags in a DOSETA&nbhy;Signature header
                  field, which are explicitly permitted.
                  <!--Verifiers MUST ignore
                  DOSETA&nbhy;Signature Header fields with a "v" parameter
                  that is inconsistent with this specification and return
                  PERMFAIL (incompatible version). --><!--<list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">An implementation might, of course,
                        choose to also verify signatures generated by older
                        versions of this specification.</t>
                        </list>-->
               </t>

               <t>If any tag listed as "required" in <xref
                     target="signeddatastruct"/> is omitted from the
                  DOSETA&nbhy;Signature header field, the verifier MUST ignore
                  the DOSETA&nbhy;Signature header field and return PERMFAIL
                  (signature missing required tag). <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The tags listed as required in <xref
                           target="signeddatastruct"/> are "v=", "a=", "b=",
                        "bh=", "d=", "h=", and "s=". Should there be a
                        conflict between this note and <xref
                           target="signeddatastruct"/>, is normative.</t>
                  </list></t>
               <t>If the DOSETA&nbhy;Signature header field does not contain
                  the "i" parameter, the verifier MUST behave as though the
                  value of that tag were "@d", where "d" is the value from the
                  "d=" tag.</t>
               <t>Verifiers MUST confirm that the domain specified in the "d="
                  tag is the same as or a parent domain of the domain part of
                  the "i" parameter. If not, the DOSETA&nbhy;Signature header
                  field MUST be ignored and the verifier SHOULD return
                  PERMFAIL (domain mismatch).</t>
               <t>If the "h" parameter does not include the From header field,
                  the verifier MUST ignore the DOSETA&nbhy;Signature header
                  field and return PERMFAIL (From field not signed).</t>
               <t>Verifiers MAY ignore the DOSETA&nbhy;Signature header field
                  and return PERMFAIL (signature expired) if it contains an
                  "x" parameter and the signature has expired.</t>
               <t>Verifiers MAY ignore the DOSETA&nbhy;Signature header field
                  if the domain used by the signer in the "d" parameter is not
                  associated with a valid signing entity. For example,
                  signatures with "d=" values such as "com" and "co.uk" might
                  be ignored. The list of unacceptable domains SHOULD be
                  configurable.</t>
               <t>Verifiers MAY ignore the DOSETA&nbhy;Signature header field
                  and return PERMFAIL (unacceptable signature header) for any
                  other reason, for example, if the signature does not sign
                  Header fields that the verifier views to be essential. As a
                  case in point, if MIME Header fields are not signed, certain
                  attacks might be possible that the verifier would prefer to
                  avoid.</t>
            </section>
            <section
               title="Get the Public Key">
               <t>The public key for a signature is needed to complete the
                  verification process. The process of retrieving the public
                  key depends on the query type as defined by the "q"
                  parameter in the DOSETA&nbhy;Signature header field.
                  Obviously, a public key need only be retrieved if the
                  process of extracting the signature information is
                  completely successful. Details of key management and
                  representation are described in <xref
                     target="keymgmt"/>. The verifier MUST validate the key
                  record and MUST ignore any public key records that are
                  malformed.</t>
               <t>
                  <list
                     style="hanging">
                     <t
                        hangText="NOTE:"> The use of wildcard TXT records in
                        the DNS will produce a response to a DOSETA query that
                        is unlikely to be valid DOSETA key record. This
                        problem applies to many other types of queries, and
                        client software that processes DNS responses needs to
                        take this problem into account.</t>
                  </list>
               </t>
               <t>When validating a message, a verifier MUST perform the
                  following steps in a manner that is semantically the same as
                  performing them in the following order -- in some cases the
                  implementation might parallelize or reorder these steps, as
                  long as the semantics remain unchanged: <list
                     style="numbers">
                     <t>Retrieve the public key as described in <xref
                           target="keymgmt"/> using the algorithm in the "q="
                        tag, the domain from the "d" parameter, and the
                        selector from the "s" parameter.</t>
                     <t>If the query for the public key fails to respond, the
                        verifier MAY defer acceptance of this data and return
                        TEMPFAIL - key unavailable. (If verification is
                        occurring during the incoming SMTP session, this MAY
                        be achieved with a 451/4.7.5 SMTP reply code.)
                        Alternatively, the verifier MAY store the message in
                        the local queue for later trial or ignore the
                        signature. Note that storing a message in the local
                        queue is subject to denial-of- service attacks.</t>
                     <t> If the query for the public key fails because the
                        corresponding key record does not exist, the verifier
                        MUST immediately return PERMFAIL (no key for
                        signature).</t>
                     <t>If the query for the public key returns multiple key
                        records, the verifier might choose one of the key
                        records or might cycle through the key records
                        performing the remainder of these steps on each record
                        at the discretion of the implementer. The order of the
                        key records is unspecified. If the verifier chooses to
                        cycle through the key records, then the "return ..."
                        wording in the remainder of this section means "try
                        the next key record, if any; if none, return to try
                        another signature in the usual way".</t>
                     <t>If the result returned from the query does not adhere
                        to the format defined in this specification, the
                        verifier MUST ignore the key record and return
                        PERMFAIL (key syntax error). Verifiers are urged to
                        validate the syntax of key records carefully to avoid
                        attempted attacks.
                        <!--In particular, the verifier MUST
                        ignore keys with a version code ("v" parameter) that
                        they do not implement.--></t>
                     <t>If the "h" parameter exists in the public key record
                        and the hash algorithm implied by the a= tag in the
                        DOSETA&nbhy;Signature header field is not included in
                        the contents of the "h" parameter, the verifier MUST
                        ignore the key record and return PERMFAIL
                        (inappropriate hash algorithm).</t>
                     <t>If the public key data (the "p" parameter) is empty,
                        then this key has been revoked and the verifier MUST
                        treat this as a failed signature check and return
                        PERMFAIL (key revoked). There is no defined semantic
                        difference between a key that has been revoked and a
                        key record that has been removed.</t>
                     <t>If the public key data is not suitable for use with
                        the algorithm and key types defined by the "a=" and
                        "k" parameters in the DOSETA&nbhy;Signature header
                        field, the verifier MUST immediately return PERMFAIL
                        (inappropriate key algorithm).</t>
                  </list></t>
            </section>
            <section
               title="Compute the Verification">
               <t>Given a signer and a public key, verifying a signature
                  consists of actions semantically equivalent to the following
                  steps. <list
                     style="numbers">
                     <t>Based on the algorithm defined in the "c" parameter,
                        the Content length specified in the "l" parameter, and
                        the header field names in the "h" parameter, prepare a
                        canonicalized version of the Content as is described
                        in <xref
                           target="sigcalc"/> (note that this version does not
                        actually need to be instantiated). When matching
                        header field names in the "h" parameter against the
                        actual message header field, comparisons MUST be
                        case-insensitive.</t>
                     <t>Based on the algorithm indicated in the "a" parameter,
                        compute the message hashes from the canonical copy as
                        described in <xref
                           target="sigcalc"/></t>
                     <t>Verify that the hash of the canonicalized Content
                        computed in the previous step matches the hash value
                        conveyed in the "bh" parameter. If the hash does not
                        match, the verifier SHOULD ignore the signature and
                        return PERMFAIL (Content hash did not verify).</t>
                     <t> Using the signature conveyed in the "b" parameter,
                        verify the signature against the header hash using the
                        mechanism appropriate for the public key algorithm
                        described in the "a" parameter. If the signature does
                        not validate, the verifier SHOULD ignore the signature
                        and return PERMFAIL (signature did not verify).</t>
                     <t>Otherwise, the signature has correctly verified.</t>
                  </list>
                  <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">Implementations might wish to
                        initiate the public-key query in parallel with
                        calculating the hash as the public key is not needed
                        until the final decryption is calculated.
                        Implementations might also verify the signature on the
                        message header before validating that the message hash
                        listed in the "bh" parameter in the
                        DOSETA&nbhy;Signature header field matches that of the
                        actual Content; however, if the Content hash does not
                        match, the entire signature MUST be considered to have
                        failed.</t>
                  </list>
               </t>

            </section>


            <section
               title="Communicate Verification Results">
               <t>Verifiers wishing to communicate the results of verification
                  to other parts of the data handling system can do so in
                  whatever manner they see fit. For example, implementations
                  might choose to add a Header field to the data before
                  passing it on. Any such header field SHOULD be inserted
                  before any existing DOSETA&nbhy;Signature or preexisting
                  verification status Header fields in the header field block.
                  The Authentication-Results: header field (<xref
                     target="RFC5451"/>) MAY be used for this purpose. <list>
                     <t>Patterns intended to search for results Header fields
                        to visibly mark authenticated data for end users
                        SHOULD verify that the header field was added by the
                        appropriate verifying domain In particular, filters
                        SHOULD NOT be influenced by bogus results header
                        fields added by attackers. To circumvent this attack,
                        verifiers SHOULD delete existing results Header fields
                        after verification and before adding a new header
                        field.</t>
                  </list></t>
            </section>
            <section
               title="Interpret Results/Apply Local Policy">
               <t>It is beyond the scope of this specification to describe
                  what actions an Assessment phase will take, but data with a
                  verified DOSETA signature presents an opportunity to an
                  Assessor that unsigned data does not. Specifically, signed
                  data creates a predictable identifier by which other
                  decisions can reliably be managed, such as trust and
                  reputation. Conversely, unsigned data typically lacks a
                  reliable identifier that can be used to assign trust and
                  reputation. It is usually reasonable to treat unsigned data
                  as lacking any trust and having no positive reputation.</t>
               <t>In general, verifiers SHOULD NOT reject data solely on the
                  basis of a lack of signature or an unverifiable signature;
                  such rejection would cause severe interoperability problems.
                  However, if the verifier does opt to reject such data</t>
               <t>Temporary failures such as inability to access the key
                  server or other external service are the only conditions
                  that SHOULD use a temporary failure code. In particular,
                  cryptographic signature verification failures MUST NOT
                  return temporary failure replies.</t>
               <t>Once the signature has been verified, that information MUST
                  be conveyed to the Assessor (such as an explicit
                  allow/whitelist and reputation system) and/or to the end
                  user. If the DDI is not the same as the address in the From:
                  header field, the data system SHOULD take pains to ensure
                  that the actual DDI is clear to the reader.</t>
               <t>The verifier MAY treat unsigned Header fields with extreme
                  skepticism, including marking them as untrusted or even
                  deleting them.</t>
               <t>While the symptoms of a failed verification are obvious --
                  the signature doesn't verify -- establishing the exact cause
                  can be more difficult. If a selector cannot be found, is
                  that because the selector has been removed, or was the value
                  changed somehow in transit? If the signature line is
                  missing, is that because it was never there, or was it
                  removed by an overzealous filter? For diagnostic purposes,
                  the exact nature of a verification failure SHOULD be made
                  available to the policy module and possibly recorded in the
                  system logs. If the data cannot be verified, then it SHOULD
                  be rendered the same as all unverified data regardless of
                  whether or not it looks like it was signed.</t>
            </section>
         </section>

         <section
            title="Requirements for Tailoring the Signing Service">
            <t>This generic template requires additional details, to define a
               specific service:<list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Association: ">Specify the means by which
                           the signature field is associated with the data it
                           signs. This identifies the specific signing service
                           and the mechanics of attaching the signature. For
                           example, DKIM uses the DKIM&nbhy;Signature email
                           header field. If the header field is encoded
                           differently than defined for the DOSETA generic
                           service, such as in XML or JSON, then that also
                           needs to be specified, including the algorithm for
                           mapping between the common encoding provided here
                           and the new encoding.</t>

                        <t
                           hangText="Semantics:  ">Define the meaning(s) of a
                           signature that is intended by the signer. Note that
                           exactly the same algorithms might be used for very
                           different semantics. One might merely affix an
                           identifier to some data, in a verifiable fashion,
                           while the same set of mechanisms might separately
                           be defined as authenticating the validity of that
                           data. A single service can support multiple
                           semantics for a signature. These SHOULD be
                           specified using the "cl=" claims mechanism defined
                           in <xref
                              target="signeddatastruct"/> and <xref
                              target="dosetaclaims"/> with values listed in <xref
                              target="ianaclaims"/>
                        </t>
                        <t
                           hangText="Structural Mapping:  ">The mappings
                           between the template's generic service and data of
                           a particular service needs to be defined. For
                           example, with DKIM the DOSETA Header maps to the email header
                           and DOSETA Content maps to the email body.</t>
                        <t
                           hangText="Required Fields:  ">Specify the header
                           fields that MUST, SHOULD or MAY be included in the
                           signature calculation.</t>
                        <t
                           hangText="Required Algorithms:  ">Specify the
                           hashing and signing algorithms that MUST, SHOULD or
                           MAY be supported by participants in the
                           service.</t>
                     </list></t>
               </list>
            </t>
         </section>

         <!--<section
            anchor="parentsig"
            title="Signing by Parent Domains">
            
            <t>*** THIS SECTION IS CONFUSED RESIDUE FROM DKIM.  /d ***</t>
            
            <t>In some circumstances, it is desirable for a domain to apply a
               signature on behalf of any of its subdomains without the need to
               maintain separate selectors (key records) in each subdomain. By
               default, private keys corresponding to key records can be used to
               sign messages for any subdomain of the domain in which they
               reside; for example, a key record for the domain example.com can
               be used to verify messages where the AUID ("i=" tag of the
               signature) is sub.example.com, or even sub1.sub2.example.com. In
               order to limit the capability of such keys when this is not
               intended, the "s" flag MAY be set in the "t" parameter of the key
               record, to constrain the validity of the domain of the AUID. If
               the referenced key record contains the "s" flag as part of the
               "t" parameter, the domain of the AUID ("i=" flag) MUST be the
               same as that of the DDI (d=) domain. If this flag is absent, the
               domain of the AUID MUST be the same as, or a subdomain of, the
               DDI.</t>
               </section>-->

      </section>

      <section
         anchor="multisig"
         title="Semantics of Multiple Signatures">
         <section
            title="Example Scenarios">
            <t>There are many reasons why a message might have multiple
               signatures. For example, a given signer might sign multiple
               times, perhaps with different hashing or signing algorithms
               during a transition phase. <list
                  style="hanging">
                  <t
                     hangText="EXAMPLE: ">Suppose SHA-256 is in the future
                     found to be insufficiently strong, and DOSETA usage
                     transitions to SHA-1024. A signer might immediately sign
                     using the newer algorithm, but continue to sign using the
                     older algorithm for interoperability with verifiers that
                     had not yet upgraded. The signer would do this by adding
                     two DOSETA&nbhy;Signature Header fields, one using each
                     algorithm. Older verifiers that did not recognize
                     SHA-1024 as an acceptable algorithm would skip that
                     signature and use the older algorithm; newer verifiers
                     could use either signature at their option, and all other
                     things being equal might not even attempt to verify the
                     other signature.</t>
               </list></t>
            <t>Similarly, a signer might sign a message including all headers
               and no "l" parameter (to satisfy strict verifiers) and a second
               time with a limited set of headers and an "l" parameter (in
               anticipation of possible message modifications in route to
               other verifiers). Verifiers could then choose which signature
               they preferred. <list
                  style="hanging">
                  <t
                     hangText="EXAMPLE: ">A verifier might receive data with
                     two signatures, one covering more of the data than the
                     other. If the signature covering more of the data
                     verified, then the verifier could make one set of policy
                     decisions; if that signature failed but the signature
                     covering less of the data verified, the verifier might
                     make a different set of policy decisions.</t>
               </list></t>
            <t>Of course, a message might also have multiple signatures
               because it passed through multiple signers. A common case is
               expected to be that of a signed message that passes through a
               mailing list that also signs all messages. Assuming both of
               those signatures verify, a recipient might choose to accept the
               message if either of those signatures were known to come from
               trusted sources. <list
                  style="hanging">
                  <t
                     hangText="EXAMPLE: ">Recipients might choose to whitelist
                     mailing lists to which they have subscribed and that have
                     acceptable anti- abuse policies so as to accept messages
                     sent to that list even from unknown authors. They might
                     also subscribe to less trusted mailing lists (for
                     example, those without anti-abuse protection) and be
                     willing to accept all messages from specific authors, but
                     insist on doing additional abuse scanning for other
                     messages.</t>
               </list></t>
            <t>Another related example of multiple signers might be forwarding
               services, such as those commonly associated with academic
               alumni sites. <list
                  style="hanging">
                  <t
                     hangText="EXAMPLE: ">A recipient might have an address at
                     members.example.org, a site that has anti-abuse
                     protection that is somewhat less effective than the
                     recipient would prefer. Such a recipient might have
                     specific authors whose messages would be trusted
                     absolutely, but messages from unknown authors that had
                     passed the forwarder's scrutiny would have only medium
                     trust.</t>
               </list></t>
         </section>
         <section
            title="Interpretation">
            <t>A signer that is adding a signature to a message merely creates
               a new DOSETA&nbhy;Signature header, using the usual semantics
               of the h= option. A signer MAY sign previously existing
               DOSETA&nbhy;Signature Header fields using the method described
               in <xref
                  target="fields2sign"/> to sign trace Header fields. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Signers need to be cognizant that
                     signing DOSETA&nbhy;Signature Header fields might result
                     in verification failures due to modifications by
                     intermediaries, such as their reordering
                     DOSETA&nbhy;Signature header fields. For this reason,
                     signing existing DOSETA&nbhy;Signature Header fields is
                     unadvised, albeit legal.</t>
                  <t
                     hangText="NOTE: ">If a header field with multiple
                     instances is signed, those header fields are always
                     signed from the "bottom" up (from last to first). Thus,
                     it is not possible to sign only specific instances of
                     header fields. For example, if the message being signed
                     already contains three DOSETA&nbhy;Signature header
                     fields (from the bottom, up) A, B, and C, it is possible
                     to sign all of them, A and B only, or A only, but not C
                     only, B only, B and C only, or A and C only.</t>
               </list></t>
            <t>A signer MAY add more than one DOSETA&nbhy;Signature header
               field using different parameters. For example, during a
               transition period a signer might want to produce signatures
               using two different hash algorithms.</t>
            <t>Signers SHOULD NOT remove any DOSETA&nbhy;Signature Header
               fields from messages they are signing, even if they know that
               the signatures cannot be verified.</t>
            <t>When evaluating a message with multiple signatures, a verifier
               SHOULD evaluate signatures independently and on their own
               merits. For example, a verifier that by policy chooses not to
               accept signatures with deprecated cryptographic algorithms
               would consider such signatures invalid. Verifiers MAY process
               signatures in any order of their choice; for example, some
               verifiers might choose to process signatures corresponding to
               the From field in the message header before other signatures.
               See <xref
                  target="extractsig"/> for more information about signature
               choices. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Verifier attempts to correlate valid
                     signatures with invalid signatures in an attempt to guess
                     why a signature failed are ill-advised. In particular,
                     there is no general way that a verifier can determine
                     that an invalid signature was ever valid.</t>
               </list></t>
            <t>Verifiers SHOULD ignore failed signatures as though they were
               not present in the message. Verifiers SHOULD continue to check
               signatures until a signature successfully verifies to the
               satisfaction of the verifier. To limit potential
               denial-of-service attacks, verifiers MAY limit the total number
               of signatures they will attempt to verify.</t>
         </section>

      </section>

      <section
         anchor="dosetaclaims"
         title="DOSETA Claims Registry Definition">
         <t>A registry entry MUST contain: <list>
               <t>
                  <list
                     style="hanging">
                     <t
                        hangText="Label:  ">Specifies a textual name for
                        claim, to be used in the "cl=" tag.</t>
                     <t
                        hangText="Description:  ">Explains the semantics of
                        the claim being asserted.</t>
                  </list></t>
            </list> The registry entries are contained in the IANA DOSETA
            Claims Registry, defined in <xref
               target="ianaclaims"/></t>
      </section>

      <section
         title="Considerations">


         <section
            anchor="iana"
            title="IANA Considerations">


            <section
               title="DKIM Registries">
               <t>DOSETA relies on IANA registration data bases specified by
                  DKIM <xref
                     target="DKIMSign"/>. Services that incorporate DOSETA
                  might need to define new registries or add to existing
                  ones.</t>
            </section>

            <section
               anchor="ianaclaims"
               title="Claims Registry">

               <t> Per <xref
                     target="RFC2434"/>, IANA is requested to establish a
                  DOSETA Claims Registry, for assertions (claims) that are
                  meant by the presence of the DOSETA-based signature that
                  contains the claims. See <xref
                     target="dosetaclaims"/> for the definition of the columns
                  in the registry table.</t>

               <texttable
                  align="left"
                  anchor="underscope"
                  title="DOSETA Claim Registry
                (with initial values)">

                  <ttcol>LABEL</ttcol>
                  <ttcol>CLAIM DESCRIPTION</ttcol>

                  <!---->

                  <c>handled</c>
                  <c>The signer claims they have had a role in processing the
                     object. (This claim is approximately equivalent to the
                     semantics of DKIM.)</c>
                  <!---->

                  <c>validauth</c>
                  <c>If there is a standardized field listing the purported
                     author of the data, the signer claims that the value in
                     that field is valid.</c>
                  <!---->

                  <c>validdata</c>
                  <c>The signer claims that all of the data in the object
                     valid.</c>
                  <!---->

                  <c>validfields</c>
                  <c>The signer claims that the portions of the object that
                     are covered by the signature hash are valid.</c>
                  <!---->



                  <!--  Table entry template 
       <c>label</c>
       <c>description</c>
       <!-\- -\->
-->
               </texttable>
            </section>
         </section>


         <section
            anchor="security"
            title="Security Considerations">
            <t> Any mechanism that attempts to prevent or detect abuse is
               subject to intensive attack. DOSETA needs to be carefully
               scrutinized to identify potential attack vectors and the
               vulnerability to each. See also <xref
                  target="RFC4686"/>.</t>

            <t>DOSETA core technology derives from DKIM <xref
                  target="DKIMSign"/>. The Security Considerations of that
               specification applies equally to DOSETA.</t>
            <t>The DOSETA "cl=" claims list provides a list of claimed
               meanings for a DOSETA signature. An opportunity for security
               problems comes from failing to distinguish between a signer
               "claim" and claim validity. Whether to trust claims made by a
               signer requires a level of assessment beyond DOSETA. </t>
         </section>
      </section>

   </middle>


   <back>
      <references
         title="Normative References">
         <reference
            anchor="FIPS-180-2-2002">
            <front>
               <title>Secure Hash Standard</title>
               <author
                  fullname="U.S. Department of Commerce"
                  surname="U.S. Department of Commerce"/>
               <date
                  month="August"
                  year="2002"/>
            </front>
            <seriesInfo
               name="FIPS PUB"
               value="180-2"/>
         </reference>

         <reference
            anchor="ITU-X660-1997">
            <front>
               <title>Information Technology - ASN.1 encoding rules:
                  Specification of Basic Encoding Rules (BER), Canonical
                  Encoding Rules (CER) and Distinguished Encoding Rules
                  (DER)</title>
               <author
                  fullname="ITU-T Recommendation X.660"/>
               <date
                  year="1997"/>
            </front>
         </reference>
         <reference
            anchor="RFC1034">
            <front>
               <title>DOMAIN NAMES - CONCEPTS AND FACILITIES</title>
               <author
                  fullname="P. Mockapetris"
                  initials="P."
                  surname="Mockapetris"/>
               <date
                  month="November"
                  year="1987"/>
            </front>
            <seriesInfo
               name="RFC"
               value="1034"/>
         </reference>

         <reference
            anchor="RFC2045">
            <front>
               <title
                  abbrev="Internet Message Bodies">Multipurpose Internet Mail
                  Extensions (MIME) Part One: Format of Internet Message
                  Bodies</title>
               <author
                  fullname="Ned Freed"
                  initials="N."
                  surname="Freed">
                  <organization>Innosoft International, Inc.</organization>
                  <address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
               </author>
               <author
                  fullname="Nathaniel S. Borenstein"
                  initials="N.S."
                  surname="Borenstein">
                  <organization>First Virtual Holdings</organization>
                  <address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
               </author>
               <date
                  month="November"
                  year="1996"/>
               <abstract>
                  <t>STD 11, RFC 822, defines a message representation
                     protocol specifying considerable detail about US-ASCII
                     message headers, and leaves the Content, as flat US-ASCII
                     text. This set of documents, collectively called the
                     Multipurpose Internet Mail Extensions, or MIME, redefines
                     the format of messages to allow for</t>
                  <t>(1) textual message bodies in character sets other than
                     US-ASCII,</t>
                  <t>(2) an extensible set of different formats for
                     non-textual message bodies,</t>
                  <t>(3) multi-part message bodies, and</t>
                  <t>(4) textual header information in character sets other
                     than US-ASCII.</t>
                  <t>These documents are based on earlier work documented in
                     RFC 934, STD 11, and RFC 1049, but extends and revises
                     them. Because RFC 822 said so little about message
                     bodies, these documents are largely orthogonal to (rather
                     than a revision of) RFC 822.</t>
                  <t>This initial document specifies the various Header fields
                     used to describe the structure of MIME messages. The
                     second document, RFC 2046, defines the general structure
                     of the MIME media typing system and defines an initial
                     set of media types. The third document, RFC 2047,
                     describes extensions to RFC 822 to allow non-US-ASCII
                     text data in Internet mail Header fields. The fourth
                     document, RFC 2048, specifies various IANA registration
                     procedures for MIME-related facilities. The fifth and
                     final document, <xref
                        target="RFC2049"/>, describes MIME conformance
                     criteria as well as providing some illustrative examples
                     of MIME message formats, acknowledgements, and the
                     bibliography.</t>
                  <t>These documents are revisions of RFCs 1521, 1522, and
                     1590, which themselves were revisions of RFCs 1341 and
                     1342. An appendix in RFC 2049 describes differences and
                     changes from previous versions.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="2045"/>
            <format
               octets="72932"
               target="http://www.rfc-editor.org/rfc/rfc2045.txt"
               type="TXT"/>
         </reference>

         <reference
            anchor="RFC2049">
            <front>
               <title
                  abbrev="MIME Conformance">Multipurpose Internet Mail
                  Extensions (MIME) Part Five: Conformance Criteria and
                  Examples</title>
               <author
                  fullname="Ned Freed"
                  initials="N."
                  surname="Freed">
                  <organization>Innosoft International, Inc.</organization>
                  <address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
               </author>
               <author
                  fullname="Nathaniel S. Borenstein"
                  initials="N.S."
                  surname="Borenstein">
                  <organization>First Virtual Holdings</organization>
                  <address>
<postal>
<street>25 Washington Avenue</street>
<street>Morristown</street>
<street>NJ 07960</street>
<country>USA</country>
</postal>

<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
               </author>
               <date
                  month="November"
                  year="1996"/>
               <area>Applications</area>
               <keyword>mail</keyword>
               <keyword>multipurpose internet mail extensions</keyword>
               <abstract>
                  <t> STD 11, RFC 822, defines a message representation
                     protocol specifying considerable detail about US-ASCII
                     message headers, and leaves the Content, as flat US-ASCII
                     text. This set of documents, collectively called the
                     Multipurpose Internet Mail Extensions, or MIME, redefines
                     the format of messages to allow for <list>
                        <t> (1) textual message bodies in character sets other
                           than US-ASCII, </t>
                        <t> (2) an extensible set of different formats for
                           non-textual message bodies, </t>
                        <t> (3) multi-part message bodies, and </t>
                        <t> (4) textual header information in character sets
                           other than US-ASCII. </t>
                     </list>
                  </t>
                  <t> These documents are based on earlier work documented in
                     RFC 934, STD 11, and RFC 1049, but extends and revises
                     them. Because RFC 822 said so little about message
                     bodies, these documents are largely orthogonal to (rather
                     than a revision of) RFC 822. </t>
                  <t> The initial document in this set, RFC 2045, specifies
                     the various headers used to describe the structure of
                     MIME messages. The second document defines the general
                     structure of the MIME media typing system and defines an
                     initial set of media types. The third document, RFC 2047,
                     describes extensions to RFC 822 to allow non-US- ASCII
                     text data in Internet mail Header fields. The fourth
                     document, RFC 2048, specifies various IANA registration
                     procedures for MIME- related facilities. This fifth and
                     final document describes MIME conformance criteria as
                     well as providing some illustrative examples of MIME
                     message formats, acknowledgements, and the bibliography. </t>
                  <t> These documents are revisions of RFCs 1521, 1522, and
                     1590, which themselves were revisions of RFCs 1341 and
                     1342. Appendix B of this document describes differences
                     and changes from previous versions. </t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="2049"/>
            <format
               octets="51207"
               target="http://www.rfc-editor.org/rfc/rfc2049.txt"
               type="TXT"/>
            <format
               octets="56682"
               target="http://xml.resource.org/public/rfc/html/rfc2049.html"
               type="HTML"/>
            <format
               octets="42032"
               target="http://xml.resource.org/public/rfc/xml/rfc2049.xml"
               type="XML"/>
         </reference>

         <reference
            anchor="RFC2119">
            <front>
               <title
                  abbrev="RFC Key Words">Key words for use in RFCs to Indicate
                  Requirement Levels</title>
               <author
                  fullname="Scott Bradner"
                  initials="S."
                  surname="Bradner">
                  <organization>Harvard University</organization>
                  <address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>

<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
               </author>
               <date
                  month="March"
                  year="1997"/>
               <area>General</area>
               <keyword>keyword</keyword>
               <abstract>
                  <t> In many standards track documents several words are used
                     to signify the requirements in the specification. These
                     words are often capitalized. This document defines these
                     words as they should be interpreted in IETF documents.
                     Authors who follow these guidelines should incorporate
                     this phrase near the beginning of their document: <list>
                        <t> The key words "MUST", "MUST NOT", "REQUIRED",
                           "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
                           "RECOMMENDED", "MAY", and "OPTIONAL" in this
                           document are to be interpreted as described in RFC
                           2119. </t>
                     </list>
                  </t>
                  <t> Note that the force of these words is modified by the
                     requirement level of the document in which they are used.
                  </t>
               </abstract>
            </front>
            <seriesInfo
               name="BCP"
               value="14"/>
            <seriesInfo
               name="RFC"
               value="2119"/>
            <format
               octets="4723"
               target="http://www.rfc-editor.org/rfc/rfc2119.txt"
               type="TXT"/>
            <format
               octets="17491"
               target="http://xml.resource.org/public/rfc/html/rfc2119.html"
               type="HTML"/>
            <format
               octets="5777"
               target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
               type="XML"/>
         </reference>

         <reference
            anchor="RFC2434">
            <front>
               <title>Guidelines for Writing an IANA Considerations Section in
                  RFCs</title>
               <author
                  fullname="T. Narten"
                  initials="T."
                  surname="Narten">
                  <organization>IBM</organization>
               </author>
               <author
                  fullname="H. Alvestrand"
                  initials="H."
                  surname="Alvestrand">
                  <organization>Maxware</organization>
               </author>
               <date
                  month="October"
                  year="1998"/>
            </front>
            <seriesInfo
               name="RFC"
               value="2434"/>
         </reference>

         <reference
            anchor="RFC3447">
            <front>
               <title>Public-Key Cryptography Standards (PKCS) #1: RSA
                  Cryptography Specifications Version 2.1</title>
               <author
                  fullname="J. Jonsson"
                  initials="J."
                  surname="Jonsson">
                  <organization/>
               </author>
               <author
                  fullname="B. Kaliski"
                  initials="B."
                  surname="Kaliski">
                  <organization/>
               </author>
               <date
                  month="February"
                  year="2003"/>
               <abstract>
                  <t>This memo represents a republication of PKCS #1 v2.1 from
                     RSA Laboratories' Public-Key Cryptography Standards
                     (PKCS) series, and change control is retained within the
                     PKCS process. The body of this document is taken directly
                     from the PKCS #1 v2.1 document, with certain corrections
                     made during the publication process. This memo provides
                     information for the Internet community.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="3447"/>
            <format
               octets="143173"
               target="http://www.rfc-editor.org/rfc/rfc3447.txt"
               type="TXT"/>
         </reference>

         <reference
            anchor="RFC5321">
            <front>
               <title>Simple Mail Transfer Protocol</title>
               <author
                  fullname="J. Klensin"
                  initials="J."
                  surname="Klensin">
                  <organization/>
               </author>
               <date
                  month="October"
                  year="2008"/>
               <abstract>
                  <t>This document is a self-contained specification of the
                     basic protocol for the Internet electronic mail
                     transport. [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="5321"/>
            <format
               octets="192504"
               target="http://www.rfc-editor.org/rfc/rfc5321.txt"
               type="TXT"/>
         </reference>
         <reference
            anchor="RFC5322">
            <front>
               <title>Internet Message Format</title>
               <author
                  fullname="P. Resnick"
                  initials="P."
                  surname="Resnick">
                  <organization/>
               </author>
               <date
                  month="October"
                  year="2008"/>
               <abstract>
                  <t>This document specifies a syntax for text messages that
                     are sent between computer users, within the framework of
                     "electronic mail" messages. [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="5322"/>
            <format
               octets="110695"
               target="http://www.rfc-editor.org/rfc/rfc5322.txt"
               type="TXT"/>
         </reference>

         <reference
            anchor="RFC5234">
            <front>
               <title
                  abbrev="ABNF">Augmented BNF for Syntax Specifications:
                  ABNF</title>
               <author
                  fullname="Dave Crocker"
                  initials="D."
                  role="editor"
                  surname="Crocker">
                  <organization>Brandenburg InternetWorking</organization>
                  <address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
               </author>
               <author
                  fullname="Paul Overell"
                  initials="P."
                  surname="Overell">
                  <organization>THUS plc.</organization>
                  <address>
<postal>
<street>1/2 Berkeley Square, </street>
<street>99 Berkeley Street</street>
<city>Glasgow</city>
<code>G3 7HR</code>
<country>UK</country>
</postal>

<email>paul.overell@thus.net</email>
</address>
               </author>
               <date
                  month="January"
                  year="2008"/>
               <keyword>ABNF</keyword>
               <keyword>Augmented</keyword>
               <keyword>Backus-Naur</keyword>
               <keyword>Form</keyword>
               <keyword>electronic</keyword>
               <keyword>mail</keyword>
               <abstract>
                  <t>Internet technical specifications often need to define a
                     formal syntax. Over the years, a modified version of
                     Backus-Naur Form (BNF), called Augmented BNF (ABNF), has
                     been popular among many Internet specifications. The
                     current specification documents ABNF. It balances
                     compactness and simplicity, with reasonable
                     representational power. The differences between standard
                     BNF and ABNF involve naming rules, repetition,
                     alternatives, order-independence, and value ranges. This
                     specification also supplies additional rule definitions
                     and encoding for a core lexical analyzer of the type
                     common to several Internet specifications. </t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="4234"/>
            <format
               octets="26351"
               target="http://www.rfc-editor.org/rfc/rfc4234.txt"
               type="TXT"/>
            <format
               octets="52334"
               target="http://xml.resource.org/public/rfc/html/rfc4234.html"
               type="HTML"/>
            <format
               octets="37285"
               target="http://xml.resource.org/public/rfc/xml/rfc4234.xml"
               type="XML"/>
         </reference>


         <reference
            anchor="RFC5890">
            <front>
               <title>Internationalizing Domain Names in Applications (IDNA):
                  Definitions and Document Framework</title>
               <author
                  fullname="J. Klensin"
                  initials="J."
                  surname="Klensin">
                  <organization/>
               </author>

               <date
                  month="August"
                  year="2010"/>
               <abstract>
                  <t>Until now, there has been no standard method for domain
                     names to use characters outside the ASCII repertoire.
                     This document defines internationalized domain names
                     (IDNs) and a mechanism called Internationalizing Domain
                     Names in Applications (IDNA) for handling them in a
                     standard fashion. IDNs use characters drawn from a large
                     repertoire (Unicode), but IDNA allows the non-ASCII
                     characters to be represented using only the ASCII
                     characters already allowed in so-called host names today.
                     This backward-compatible representation is required in
                     existing protocols like DNS, so that IDNs can be
                     introduced with no changes to the existing
                     infrastructure. IDNA is only meant for processing domain
                     names, not free text. [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="5890"/>
            <format
               octets="51943"
               target="http://www.rfc-editor.org/rfc/rfc5890.txt"
               type="TXT"/>
         </reference>



         <!--  <reference
            anchor="RFC5598">
            <front>
               <title>Internet Mail Architecture</title>
               <author
                  fullname="D. Crocker"
                  initials="D."
                  surname="Crocker"/>
               <date
                  month="July"
                  year="2009"/>
            </front>
            <seriesInfo
               name="RFC"
               value="5598"/>
               </reference>  -->



      </references>




      <references
         title="Informative References">
         <!--<reference
            anchor="BONEH03">
            <front>
               <title>Remote Timing Attacks are Practical</title>
               <author />
               <date
                  year="2003" />
            </front>
            <seriesInfo
               name="Proceedings "
               value="12th USENIX Security Symposium" />
               </reference>-->

         <reference
            anchor="mimeauth">
            <front>
               <title
                  abbrev="MIMEAUTH">MIME Content Authentication using DOSETA
                  (MIMEAUTH) </title>
               <author
                  fullname="D. Crocker"
                  initials="D."
                  surname="Crocker">
                  <organization>Brandenburg InternetWorking</organization>
                  <address>
            <postal>
               <street>675 Spruce Dr.</street>
               <city>Sunnyvale</city>
               <country>USA</country>
            </postal>
            <phone>+1.408.246.8253</phone>
            <email>dcrocker@bbiw.net</email>
            <uri>http://bbiw.net</uri>
         </address>
               </author>

               <author
                  fullname="M. Kucherawy"
                  initials="M."
                  surname="Kucherawy">
                  <organization>Cloudmark</organization>
                  <address>   
            <postal>
               <street>128 King St., 2nd Floor</street>
               <city>San Francisco</city>
               <region>CA</region>
               <code>94107</code>
               <country>USA</country>
            </postal>
            
            <email>msk@cloudmark.com</email>
         </address>
               </author>

               <date
                  year="2011"/>

               <abstract>
                  <t>MIME is a method of packaging and labeling aggregations
                     of data; it is used both for email and the Web. Many
                     usage scenarios would benefit by having an objective
                     method of assessing the validity of MIME data, based on
                     an authenticated identity. MIMEAUTH leverages technology
                     developed for DKIM to provide such a method. Its use can
                     be extended to cover specific header-fields of a
                     containing email message or World Wide Web HTTP content.
                     Existing authentication mechanisms have achieved only
                     limited success due to challenges with administration and
                     use. MIMEAUTH has very low administration and use
                     overhead, through self-certifying keys in the DNS and a
                     labeling method that can be transparent to end-users. For
                     relayed and mediated sequences, MIMEAUTH can be
                     implemented within a service and therefore can be
                     transparent to end-system software.</t>
               </abstract>
            </front>
            <seriesInfo
               name="I-D"
               value="draft-crocker-doseta-mimeauth"/>
         </reference>

         <reference
            anchor="RFC1847">
            <front>
               <title
                  abbrev="Security Multiparts">Security Multiparts for MIME:
                  Multipart/Signed and Multipart/Encrypted</title>
               <author
                  fullname="Jim Galvin"
                  initials="J."
                  surname="Galvin">
                  <organization>Trusted Information Systems</organization>
                  <address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>galvin@tis.com</email>
</address>
               </author>
               <author
                  fullname="Sandy Murphy"
                  initials="S."
                  surname="Murphy">
                  <organization>Trusted Information Systems</organization>
                  <address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>sandy@tis.com</email>
</address>
               </author>
               <author
                  fullname="Steve Crocker"
                  initials="S."
                  surname="Crocker">
                  <organization>CyberCash, Inc.</organization>
                  <address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<facsimile>+1 703 391 2651</facsimile>
<email>crocker@cybercash.com</email>
</address>
               </author>
               <author
                  fullname="Ned Freed"
                  initials="N."
                  surname="Freed">
                  <organization>Innosoft International, Inc.</organization>
                  <address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
               </author>
               <date
                  month="October"
                  year="1995"/>
               <abstract>
                  <t>This document defines a framework within which security
                     services might be applied to MIME body parts. MIME, an
                     acronym for "Multipurpose Internet Mail Extensions",
                     defines the format of the contents of Internet mail
                     messages and provides for multi-part textual and
                     non-textual message bodies. The new content types are
                     subtypes of multipart: signed and encrypted. Each will
                     contain two body parts: one for the protected data and
                     one for the control information necessary to remove the
                     protection. The type and contents of the control
                     information body parts are determined by the value of the
                     protocol parameter of the enclosing multipart&sol;signed
                     or multipart&sol;encrypted content type, which is
                     required to be present.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="1847"/>
            <format
               octets="23679"
               target="http://www.rfc-editor.org/rfc/rfc1847.txt"
               type="TXT"/>
         </reference>

         <!--<reference
            anchor="RFC5226">
            <front>
               <title
                  abbrev="Guidelines for IANA Considerations">Guidelines for
                  Writing an IANA Considerations Section in RFCs</title>
               <author
                  fullname="Thomas Narten"
                  initials="T."
                  surname="Narten">
                  <organization>IBM Corporation</organization>
                  <address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195 - BRQA/502</street>
<street>Research Triangle Park</street>
<street>NC 27709-2195</street>
</postal>

<phone>919-254-7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
               </author>
               <author
                  fullname="Harald Tveit Alvestrand"
                  initials="H.T."
                  surname="Alvestrand">
                  <organization>Maxware</organization>
                  <address>
<postal>
<street>Pirsenteret</street>
<street>N-7005 Trondheim</street>
<country>Norway</country>
</postal>

<phone>+47 73 54 57 97</phone>
<email>Harald@Alvestrand.no</email>
</address>
               </author>
               <date
                  month="May"
                  year="2008" />
               <area>General</area>
               <keyword>Internet Assigned Numbers Authority</keyword>
               <keyword>IANA</keyword>
               <abstract>
                  <t> Many protocols make use of identifiers consisting of
                     constants and other well-known values. Even after a
                     protocol has been defined and deployment has begun, new
                     values might need to be assigned (for example, for a new
                     option type in DHCP, or a new encryption or authentication
                     algorithm for IPSec). To insure that such quantities have
                     consistent values and interpretations in different
                     implementations, their assignment needs to be administered
                     through a central authority. For IETF protocols, that role
                     is provided by the Internet Assigned Numbers Authority
                     (IANA). </t>
                  <t> In order for the IANA to manage a given name space
                     prudently, it needs guidelines describing the conditions
                     under which new values can be assigned. If the IANA is
                     expected to play a role in the management of a name space,
                     the IANA MUST be given clear and concise instructions
                     describing that role. This document discusses issues that
                     should be considered in formulating a policy for assigning
                     values to a name space and provides guidelines to document
                     authors on the specific text that needs to be included in
                     documents that place demands on the IANA. </t>
               </abstract>
            </front>
            <seriesInfo
               name="BCP"
               value="26" />
            <seriesInfo
               name="RFC"
               value="5226" />
            <format
               octets="25092"
               target="http://www.rfc-editor.org/rfc/rfc5226.txt"
               type="TXT" />
            <format
               octets="37803"
               target="http://xml.resource.org/public/rfc/html/rfc5226.html"
               type="HTML" />
            <format
               octets="27060"
               target="http://xml.resource.org/public/rfc/xml/rfc5226.xml"
               type="XML" />
               </reference>-->

         <reference
            anchor="RFC2047">
            <front>
               <title
                  abbrev="Message Header Extensions">MIME (Multipurpose
                  Internet Mail Extensions) Part Three: Message Header
                  Extensions for Non-ASCII Content</title>
               <author
                  fullname="Keith Moore"
                  initials="K."
                  surname="Moore">
                  <organization>University of Tennessee</organization>
                  <address>
<postal>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street>
</postal>

<email>moore@cs.utk.edu</email>
</address>
               </author>
               <date
                  month="November"
                  year="1996"/>
               <area>Applications</area>
               <keyword>American Standard Code for Information
                  Interchange</keyword>
               <keyword>mail</keyword>
               <keyword>multipurpose internet mail extensions</keyword>
               <abstract>
                  <t> STD 11, RFC 822, defines a message representation
                     protocol specifying considerable detail about US-ASCII
                     message headers, and leaves the Content, as flat US-ASCII
                     text. This set of documents, collectively called the
                     Multipurpose Internet Mail Extensions, or MIME, redefines
                     the format of messages to allow for <list>
                        <t> (1) textual message bodies in character sets other
                           than US-ASCII, </t>
                        <t> (2) an extensible set of different formats for
                           non-textual message bodies, </t>
                        <t> (3) multi-part message bodies, and </t>
                        <t> (4) textual header information in character sets
                           other than US-ASCII. </t>
                     </list>
                  </t>
                  <t> These documents are based on earlier work documented in
                     RFC 934, STD 11, and RFC 1049, but extends and revises
                     them. Because RFC 822 said so little about message
                     bodies, these documents are largely orthogonal to (rather
                     than a revision of) RFC 822. </t>
                  <t> This particular document is the third document in the
                     series. It describes extensions to RFC 822 to allow
                     non-US-ASCII text data in Internet mail header fields.
                     Other documents in this series include: <list
                        style="symbols">
                        <t>RFC 2045, which specifies the various headers used
                           to describe the structure of MIME messages. </t>
                        <t>RFC 2046, which defines the general structure of
                           the MIME media typing system and defines an initial
                           set of media types, </t>
                        <t>RFC 2048, which specifies various IANA registration
                           procedures for MIME-related facilities, and </t>
                        <t>RFC 2049, which describes MIME conformance criteria
                           and provides some illustrative examples of MIME
                           message formats, acknowledgements, and the
                           bibliography. </t>
                     </list>
                  </t>
                  <t> These documents are revisions of RFCs 1521, 1522, and
                     1590, which themselves were revisions of RFCs 1341 and
                     1342. An appendix in RFC 2049 describes differences and
                     changes from previous versions. </t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="2047"/>
            <format
               octets="33262"
               target="http://www.rfc-editor.org/rfc/rfc2047.txt"
               type="TXT"/>
            <format
               octets="52141"
               target="http://xml.resource.org/public/rfc/html/rfc2047.html"
               type="HTML"/>
            <format
               octets="39330"
               target="http://xml.resource.org/public/rfc/xml/rfc2047.xml"
               type="XML"/>
         </reference>


         <reference
            anchor="RFC4880">
            <front>
               <title>OpenPGP Message Format</title>
               <author
                  fullname="Jon Callas"
                  initials="J."
                  surname="Callas">
                  <organization>Network Associates, Inc.</organization>
                  <address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>

<phone>+1 408-346-5860</phone>
<email>jon@pgp.com</email>
</address>
               </author>
               <author
                  fullname="Lutz Donnerhacke"
                  initials="L."
                  surname="Donnerhacke">
                  <organization>IKS GmbH</organization>
                  <address>
<postal>
<street>Wildenbruchstr. 15</street>
<street>07745 Jena</street>
<country>Germany</country>
</postal>

<phone>+49-3641-675642</phone>
<email>lutz@iks-jena.de</email>
</address>
               </author>
               <author
                  fullname="Hal Finney"
                  initials="H."
                  surname="Finney">
                  <organization>Network Associates, Inc.</organization>
                  <address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>

<email>hal@pgp.com</email>
</address>
               </author>
               <author
                  fullname="Rodney Thayer"
                  initials="R."
                  surname="Thayer">
                  <organization>EIS Corporation</organization>
                  <address>
<postal>
<street>Clearwater</street>
<street>FL 33767</street>
<country>USA</country>
</postal>

<email>rodney@unitran.com</email>
</address>
               </author>
               <date
                  month="November"
                  year="2007"/>
               <area>Security</area>
               <keyword>pretty good privacy</keyword>
               <keyword>PGP</keyword>
               <keyword>security</keyword>
               <abstract>
                  <t> This document defines many tag values, yet it
                     doesn&apos;t describe a mechanism for adding new tags
                     (for new features). Traditionally the Internet Assigned
                     Numbers Authority (IANA) handles the allocation of new
                     values for future expansion and RFCs usually define the
                     procedure to be used by the IANA. However, there are
                     subtle (and not so subtle) interactions that might occur
                     in this protocol between new features and existing
                     features which result in a significant reduction in over
                     all security. Therefore, this document does not define an
                     extension procedure. Instead requests to define new tag
                     values (say for new encryption algorithms for example)
                     should be forwarded to the IESG Security Area Directors
                     for consideration or forwarding to the appropriate IETF
                     Working Group for consideration. </t>
                  <t> This document is maintained in order to publish all
                     necessary information needed to develop interoperable
                     applications based on the OpenPGP format. It is not a
                     step-by-step cookbook for writing an application. It
                     describes only the format and methods needed to read,
                     check, generate, and write conforming packets crossing
                     any network. It does not deal with storage and
                     implementation questions. It does, however, discuss
                     implementation issues necessary to avoid security flaws. </t>
                  <t> Open-PGP software uses a combination of strong
                     public-key and symmetric cryptography to provide security
                     services for electronic communications and data storage.
                     These services include confidentiality, key management,
                     authentication, and digital signatures. This document
                     specifies the message formats used in OpenPGP. </t>
               </abstract>
               <note
                  title="IESG Note">
                  <t> This document defines many tag values, yet it
                     doesn&apos;t describe a mechanism for adding new tags
                     (for new features). Traditionally the Internet Assigned
                     Numbers Authority (IANA) handles the allocation of new
                     values for future expansion and RFCs usually define the
                     procedure to be used by the IANA. However, there are
                     subtle (and not so subtle) interactions that might occur
                     in this protocol between new features and existing
                     features which result in a significant reduction in over
                     all security. Therefore, this document does not define an
                     extension procedure. Instead requests to define new tag
                     values (say for new encryption algorithms for example)
                     should be forwarded to the IESG Security Area Directors
                     for consideration or forwarding to the appropriate IETF
                     Working Group for consideration. </t>
               </note>
            </front>
            <seriesInfo
               name="RFC"
               value="4880"/>
            <format
               octets="141371"
               target="http://www.rfc-editor.org/rfc/rfc4880.txt"
               type="TXT"/>
            <format
               octets="157503"
               target="http://xml.resource.org/public/rfc/html/rfc4880.html"
               type="HTML"/>
            <format
               octets="137322"
               target="http://xml.resource.org/public/rfc/xml/rfc4880.xml"
               type="XML"/>
         </reference>
         <reference
            anchor="RFC3766">
            <front>
               <title>Determining Strengths For Public Keys Used For
                  Exchanging Symmetric Keys</title>
               <author
                  fullname="H. Orman"
                  initials="H."
                  surname="Orman">
                  <organization/>
               </author>
               <author
                  fullname="P. Hoffman"
                  initials="P."
                  surname="Hoffman">
                  <organization/>
               </author>
               <date
                  month="April"
                  year="2004"/>
               <abstract>
                  <t>Implementors of systems that use public key cryptography
                     to exchange symmetric keys need to make the public keys
                     resistant to some predetermined level of attack. That
                     level of attack resistance is the strength of the system,
                     and the symmetric keys that are exchanged MUST be at
                     least as strong as the system strength requirements. The
                     three quantities, system strength, symmetric key
                     strength, and public key strength, MUST be consistently
                     matched for any network protocol usage. While it is
                     fairly easy to express the system strength requirements
                     in terms of a symmetric key length and to choose a cipher
                     that has a key length equal to or exceeding that
                     requirement, it is harder to choose a public key that has
                     a cryptographic strength meeting a symmetric key strength
                     requirement. This document explains how to determine the
                     length of an asymmetric key as a function of a symmetric
                     key strength requirement. Some rules of thumb for
                     estimating equivalent resistance to large-scale attacks
                     on various algorithms are given. The document also
                     addresses how changing the sizes of the underlying large
                     integers (moduli, group sizes, exponents, and so on)
                     changes the time to use the algorithms for key exchange.
                     This document specifies an Internet Best Current
                     Practices for the Internet Community, and requests
                     discussion and suggestions for improvements.</t>
               </abstract>
            </front>
            <seriesInfo
               name="BCP"
               value="86"/>
            <seriesInfo
               name="RFC"
               value="3766"/>
            <format
               octets="55939"
               target="http://www.rfc-editor.org/rfc/rfc3766.txt"
               type="TXT"/>
         </reference>

         <!--<reference
            anchor="RFC3833">
            <front>
               <title>Threat Analysis of the Domain Name System (DNS)</title>
               <author
                  fullname="D. Atkins"
                  initials="D."
                  surname="Atkins">
                  <organization />
               </author>
               <author
                  fullname="R. Austein"
                  initials="R."
                  surname="Austein">
                  <organization />
               </author>
               <date
                  month="August"
                  year="2004" />
               <abstract>
                  <t>Although the DNS Security Extensions (DNSSEC) have been
                     under development for most of the last decade, the IETF has
                     never written down the specific set of threats against
                     which DNSSEC is designed to protect. Among other drawbacks,
                     this cart-before-the-horse situation has made it difficult
                     to determine whether DNSSEC meets its design goals, since
                     its design goals are not well specified. This note attempts
                     to document some of the known threats to the DNS, and, in
                     doing so, attempts to measure to what extent (if any)
                     DNSSEC is a useful tool in defending against these threats.
                     This memo provides information for the Internet
                     community.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="3833" />
            <format
               octets="39303"
               target="http://www.rfc-editor.org/rfc/rfc3833.txt"
               type="TXT" />
               </reference>-->

         <!--<reference
            anchor="RFC5751">
            <front>
               <title>Secure/Multipurpose Internet Mail Extensions (S/MIME)
                  Version 3.1 Message Specification</title>
               <author
                  fullname="B. Ramsdell"
                  initials="B."
                  surname="Ramsdell">
                  <organization />
               </author>
               <date
                  month="January"
                  year="2010" />
               <abstract>
                  <t>This document defines Secure/Multipurpose Internet Mail
                     Extensions (S/MIME) version 3.1. S/MIME provides a
                     consistent way to send and receive secure MIME data.
                     Digital signatures provide authentication, message
                     integrity, and non-repudiation with proof of origin.
                     Encryption provides data confidentiality. Compression can
                     be used to reduce data size. This document obsoletes RFC
                     2633. [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="5751" />
            <format
               octets="53328"
               target="http://www.rfc-editor.org/rfc/rfc5751.txt"
               type="TXT" />
         </reference>-->

         <!--<reference
            anchor="RFC3864">
            <front>
               <title>Registration Procedures for Message Header Fields</title>
               <author
                  fullname="G. Klyne"
                  initials="G."
                  surname="Klyne">
                  <organization />
               </author>
               <author
                  fullname="M. Nottingham"
                  initials="M."
                  surname="Nottingham">
                  <organization />
               </author>
               <author
                  fullname="J. Mogul"
                  initials="J."
                  surname="Mogul">
                  <organization />
               </author>
               <date
                  month="September"
                  year="2004" />
               <abstract>
                  <t>This specification defines registration procedures for the
                     message header fields used by Internet mail, HTTP, Netnews
                     and other applications. This document specifies an Internet
                     Best Current Practices for the Internet Community, and
                     requests discussion and suggestions for improvements.</t>
               </abstract>
            </front>
            <seriesInfo
               name="BCP"
               value="90" />
            <seriesInfo
               name="RFC"
               value="3864" />
            <format
               octets="36231"
               target="http://www.rfc-editor.org/rfc/rfc3864.txt"
               type="TXT" />
         </reference>-->

         <reference
            anchor="RFC4033">
            <front>
               <title>DNS Security Introduction and Requirements</title>
               <author
                  fullname="R. Arends"
                  initials="R."
                  surname="Arends">
                  <organization/>
               </author>
               <author
                  fullname="R. Austein"
                  initials="R."
                  surname="Austein">
                  <organization/>
               </author>
               <author
                  fullname="M. Larson"
                  initials="M."
                  surname="Larson">
                  <organization/>
               </author>
               <author
                  fullname="D. Massey"
                  initials="D."
                  surname="Massey">
                  <organization/>
               </author>
               <author
                  fullname="S. Rose"
                  initials="S."
                  surname="Rose">
                  <organization/>
               </author>
               <date
                  month="March"
                  year="2005"/>
               <abstract>
                  <t>The Domain Name System Security Extensions (DNSSEC) add
                     data origin authentication and data integrity to the
                     Domain Name System. This document introduces these
                     extensions and describes their capabilities and
                     limitations. This document also discusses the services
                     that the DNS security extensions do and do not provide.
                     Last, this document describes the interrelationships
                     between the documents that collectively describe DNSSEC.
                     [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="4033"/>
            <format
               octets="52445"
               target="http://www.rfc-editor.org/rfc/rfc4033.txt"
               type="TXT"/>
         </reference>
         <reference
            anchor="RFC4409">
            <front>
               <title>Message Submission for Mail</title>
               <author
                  fullname="R. Gellens"
                  initials="R."
                  surname="Gellens">
                  <organization>QUALCOMM</organization>
               </author>
               <author
                  fullname="J. Klensin"
                  initials="J."
                  surname="Klensin"/>
               <date
                  month="April"
                  year="2006"/>
            </front>
            <seriesInfo
               name="RFC"
               value="4409"/>
         </reference>
         <reference
            anchor="RFC4686">
            <front>
               <title>Analysis of Threats Motivating DomainKeys Identified
                  Mail (DKIM)</title>
               <author
                  fullname="J. Fenton"
                  initials="J."
                  surname="Fenton">
                  <organization/>
               </author>
               <date
                  month="September"
                  year="2006"/>
               <abstract>
                  <t>This document provides an analysis of some threats
                     against Internet mail that are intended to be addressed
                     by signature-based mail authentication, in particular
                     DomainKeys Identified Mail. It discusses the nature and
                     location of the bad actors, what their capabilities are,
                     and what they intend to accomplish via their attacks.
                     This memo provides information for the Internet
                     community.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="4686"/>
            <format
               octets="70382"
               target="http://www.rfc-editor.org/rfc/rfc4686.txt"
               type="TXT"/>
         </reference>
         <reference
            anchor="RFC4870">
            <front>
               <title>Domain-Based Email Authentication Using Public Keys
                  Advertised in the DNS (DomainKeys)</title>
               <author
                  fullname="M. Delany"
                  initials="M."
                  surname="Delany">
                  <organization/>
               </author>
               <date
                  month="May"
                  year="2007"/>
               <abstract>
                  <t>"DomainKeys" creates a domain-level authentication
                     framework for email by using public key technology and
                     the DNS to prove the provenance and contents of an
                     email.&lt;/t>&lt;t> This document defines a framework for
                     digitally signing email on a per-domain basis. The
                     ultimate goal of this framework is to unequivocally prove
                     and protect identity while retaining the semantics of
                     Internet email as it is known today.&lt;/t>&lt;t> Proof
                     and protection of email identity might assist in the
                     global control of "spam" and "phishing". This memo
                     defines a Historic Document for the Internet
                     community.</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="4870"/>
            <format
               octets="87378"
               target="http://www.rfc-editor.org/rfc/rfc4870.txt"
               type="TXT"/>
         </reference>
         <reference
            anchor="DKIMSign">
            <front>
               <title>DomainKeys Identified Mail (DKIM) Signatures</title>
               <author
                  fullname="E. Allman"
                  initials="E."
                  surname="Allman">
                  <organization/>
               </author>
               <author
                  fullname="J. Callas"
                  initials="J."
                  surname="Callas">
                  <organization/>
               </author>
               <author
                  fullname="M. Delany"
                  initials="M."
                  surname="Delany">
                  <organization/>
               </author>
               <author
                  fullname="M. Libbey"
                  initials="M."
                  surname="Libbey">
                  <organization/>
               </author>
               <author
                  fullname="J. Fenton"
                  initials="J."
                  surname="Fenton">
                  <organization/>
               </author>
               <author
                  fullname="M. Thomas"
                  initials="M."
                  surname="Thomas">
                  <organization/>
               </author>
               <date
                  month="May"
                  year="2007"/>
               <abstract>
                  <t>DomainKeys Identified Mail (DKIM) defines a domain-level
                     authentication framework for email using public-key
                     cryptography and key server technology to permit
                     verification of the source and contents of messages by
                     either Mail Transfer Agents (MTAs) or Mail User Agents
                     (MUAs). The ultimate goal of this framework is to permit
                     a signing domain to assert responsibility for a message,
                     thus protecting message signer identity and the integrity
                     of the messages they convey while retaining the
                     functionality of Internet email as it is known today.
                     Protection of email identity might assist in the global
                     control of "spam" and "phishing". [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="4871"/>
            <format
               octets="166054"
               target="http://www.rfc-editor.org/rfc/rfc4871.txt"
               type="TXT"/>
         </reference>
         <reference
            anchor="RFC5451">
            <front>
               <title>Message Header Field for Indicating Message
                  Authentication Status</title>
               <author
                  fullname="M. Kucherawy"
                  initials="M."
                  surname="Kucherawy">
                  <organization/>
               </author>
               <date
                  month="April"
                  year="2009"/>
               <abstract>
                  <t>This memo defines a new header field for use with
                     electronic mail messages to indicate the results of
                     message authentication efforts. Any receiver-side
                     software, such as mail filters or Mail User Agents
                     (MUAs), might use this message header field to relay that
                     information in a convenient way to users or to make
                     sorting and filtering decisions. [STANDARDS TRACK]</t>
               </abstract>
            </front>
            <seriesInfo
               name="RFC"
               value="5451"/>
            <format
               octets="97404"
               target="http://www.rfc-editor.org/rfc/rfc5451.txt"
               type="TXT"/>
         </reference>

         <reference
            anchor="RFC5672">
            <front>
               <title>RFC 4871 DomainKeys Identified Mail (DKIM) Signatures:
                  Update</title>
               <author
                  fullname="D. Crocker"
                  initials="D."
                  role="editor"
                  surname="Crocker">
                  <organization>Brandenburg InternetWorking</organization>
                  <address>
            <postal>
               <street>675 Spruce Dr.</street>
               <city>Sunnyvale</city>
               <country>USA</country>
            </postal>
            <phone>+1.408.246.8253</phone>
            <email>dcrocker@bbiw.net</email>
            <uri>http://bbiw.net</uri>
         </address>
               </author>
               <date
                  month="August"
                  year="2009"/>
               <workgroup>DKIM</workgroup>
            </front>
            <seriesInfo
               name="RFC"
               value="5672"/>
         </reference>

         <reference
            anchor="UTF8">
            <front>
               <title>UTF-8, a transformation format of ISO 10646</title>
               <author
                  fullname="F. Yergeau"
                  initials="F."
                  surname="Yergeau">
                  <organization>Alis Technologies</organization>
               </author>
               <date
                  month="November"
                  year="2003"/>
            </front>
            <seriesInfo
               name="RFC"
               value="3629"/>
         </reference>



      </references>

      <section
         anchor="createpkey"
         title="Creating a Public Key">
         <t> The default signature is an RSA signed SHA256 digest of the
            complete email. For ease of explanation, the openssl command is
            used to describe the mechanism by which keys and signatures are
            managed. One way to generate a 1024-bit, unencrypted private key
            suitable for DOSETA is to use openssl like this: <figure>
               <artwork><![CDATA[$ openssl genrsa -out rsa.private 1024]]></artwork>
            </figure> For increased security, the "-passin" parameter can also
            be added to encrypt the private key. Use of this parameter will
            require entering a password for several of the following steps.
            Servers might prefer to use hardware cryptographic support.</t>
         <t>
            <figure
               align="left">
               <preamble>The "genrsa" step results in the file rsa.private
                  containing the key information similar to this:</preamble>
               <artwork><![CDATA[-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
-----END RSA PRIVATE KEY-----]]></artwork>
            </figure>
         </t>
         <t>
            <figure>
               <preamble>To extract the public-key component from the private
                  key, use openssl like this:</preamble>
               <artwork><![CDATA[$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM]]></artwork>
            </figure>
         </t>
         <t>
            <figure
               align="left">
               <preamble>This results in the file rsa.public containing the
                  key information similar to this:</preamble>
               <artwork><![CDATA[-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----]]></artwork>
            </figure>
            <figure
               align="left">
               <preamble>This public-key data (without the BEGIN and END tags)
                  is placed in the DNS:</preamble>
               <artwork><![CDATA[
brisbane IN  TXT  
        ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
         "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
         "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
         "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
         "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")]]></artwork>
            </figure>
         </t>
      </section>



      <section
         title="Acknowledgements">
         <t>DOSETA is derived from DKIM <xref
               target="DKIMSign"/>. DKIM is an evolution of DomainKeys <xref
               target="RFC4870"/>, which was developed by Mark Delany, then of
            Yahoo!. In particular, the key management service, based on the
            DNS, and the user-INvisible tagging scheme was developed by
            him.</t>
      </section>

      <section
         title="Example -- DKIM Using DOSETA">
         <t>This example re-specifies DKIM in terms of DOSETA, while retaining
            bit-level compatibility with the existing DKIM specification <xref
               target="DKIMSign"/>.<list
               style="hanging">
               <t
                  hangText="NOTE: ">This section is merely an example. Any use
                  of normative language in this section is strictly for
                  completness of the example and has no normative effect on
                  the DOSETA specification.</t>
            </list></t>

         <section
            title="Signing and Verification Protocol">

            <t>The DOSETA template specifies TEMPLATE information that is
               required to tailor the signing service:<list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Association: ">The DOSETA&nbhy;Signature
                           data are stored in a DKIM&nbhy;Signature header
                           field that is part of the header of the message
                           being signed. This contains all of the signature
                           and key-fetching data, per <xref
                              target="signeddatastruct"/>.</t>

                        <t
                           hangText="Semantics:  ">A DKIM signature means that
                           the owner of the signing domain is taking "some"
                           responsibility for the message. Hence, the payload,
                           or output, of DKIM is:<list
                              style="symbols">
                              <t>A validated domain name, specifically the d=
                                 parameter in the DKIM&nbhy;Signature header
                                 field</t>
                              <t>An indication that its use has been
                                 validated</t>
                           </list> The nature and extent of a DKIM signer's
                           responsibility can vary widely and is beyond the
                           scope of this specification.</t>
                        <t
                           hangText="Structural Mapping:  ">DKIM maps the
                           DOSETA Header processing to an email header and the
                           DOSETA Content to an email body, per <xref
                              target="RFC5322"/></t>
                        <t
                           hangText="Required Support"><list
                              style="hanging">
                              <t
                                 hangText="Field Hash: ">The basic rule for
                                 choosing fields to include is to select those
                                 fields that constitute the "core" of the
                                 message content. Hence, any replay attack
                                 will have to include these in order to have
                                 the signature succeed; but with these
                                 included, the core of the message is valid,
                                 even if sent on to new recipients. </t>
                              <t>Common examples of fields with addresses and
                                 fields with textual content related to the
                                 body are: From (MUST be included), Reply-To,
                                 Subject, Date, To, Cc, Resent-Date,
                                 Resent-From, Resent-To, Resent-Cc,
                                 In-Reply-To, References, List-Id, List-Help,
                                 List-Unsubscribe, List-Subscribe, List-Post,
                                 List-Owner, List-Archive.</t>
                              <t
                                 hangText="Required Algorithms: ">Use DOSETA
                                 defaults.</t>
                           </list></t>
                     </list></t>
               </list>
            </t>

         </section>


         <section
            title="Extensions to DOSETA Template">
            <t>This section contains specifications that are added to the
               basic DOSETA H/C Signing Template.</t>

            <section
               anchor="dksigneddatastruct"
               title="Signature Data Structure">


               <t>These are DKIM-specific tags: <list>
                     <t><list
                           style="hanging">

                           <t
                              hangText="i= ">The Agent or User Identifier
                              (AUID) on behalf of which the SDID is taking
                              responsibility (DOSETA-quoted-printable;
                              OPTIONAL, default is an empty &lt;local-part&gt;
                              followed by an "@" followed by the domain from
                              the "d=" tag).</t>
                           <t>The syntax is a standard email address where the
                              &lt;local-part&gt; MAY be omitted. The domain
                              part of the address MUST be the same as, or a
                              subdomain of, the value of the "d=" tag.</t>
                           <t>Internationalized domain names MUST be converted
                              using the steps listed in Section 4 of <xref
                                 target="RFC5890"/> using the "ToASCII"
                              function.</t>
                           <t>
                              <list>
                                 <t>
                                    <figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[sig-i-tag       = %x69 [FWS] "=" [FWS] 
                  [ local-part ] "@" domain-name]]></artwork>
                                    </figure>
                                 </t>
                              </list>
                           </t>
                           <t>The AUID is specified as having the same syntax
                              as an email address, but is not required to have
                              the same semantics. Notably, the domain name is
                              not required to be registered in the DNS -- so
                              it might not resolve in a query -- and the
                              &lt;local-part&gt; MAY be drawn from a namespace
                              unrelated to any mailbox. The details of the
                              structure and semantics for the namespace are
                              determined by the Signer. Any knowledge or use
                              of those details by verifiers or assessors is
                              outside the scope of the DOSETA Signing
                              specification. The Signer MAY choose to use the
                              same namespace for its AUIDs as its users' email
                              addresses or MAY choose other means of
                              representing its users. However, the signer
                              SHOULD use the same AUID for each message
                              intended to be evaluated as being within the
                              same sphere of responsibility, if it wishes to
                              offer receivers the option of using the AUID as
                              a stable identifier that is finer grained than
                              the SDID. <list
                                 style="hanging">
                                 <t
                                    hangText="NOTE: ">The &lt;local-part&gt;
                                    of the "i=" tag is optional because in
                                    some cases a signer might not be able to
                                    establish a verified individual identity.
                                    In such cases, the signer might wish to
                                    assert that although it is willing to go
                                    as far as signing for the domain, it is
                                    unable or unwilling to commit to an
                                    individual user name within their domain.
                                    It can do so by including the domain part
                                    but not the &lt;local-part&gt; of the
                                    identity.</t>
                                 <t
                                    hangText="NOTE:  ">Absent public standards
                                    for the semantics of an AUID, an
                                    assessment based on AUID requires a
                                    non-standardized basis.</t>
                                 <t
                                    hangText="NOTE: ">This specification does
                                    not require the value of the "i=" tag to
                                    match the identity in any Header field.
                                    This is considered to be an
                                    assessment-time policy issue. Constraints
                                    between the value of the "i=" tag and
                                    other identities in other Header fields
                                    might seek to apply basic authentication
                                    into the semantics of trust associated
                                    with a role such as content author. Trust
                                    is a broad and complex topic and trust
                                    mechanisms are subject to highly creative
                                    attacks. The real-world efficacy of any
                                    but the most basic bindings between the
                                    "i=" value and other identities is not
                                    well established, nor is its vulnerability
                                    to subversion by an attacker. Hence
                                    reliance on the use of these options needs
                                    to be strictly limited. In particular, it
                                    is not at all clear to what extent a
                                    typical end-user recipient can rely on any
                                    assurances that might be made by
                                    successful use of the "i=" options.</t>
                              </list></t>
                           <t
                              hangText="l=  ">Content length count (plain-text
                              unsigned decimal integer; OPTIONAL, default is
                              entire Content). This tag informs the verifier
                              of the number of octets in the Content of the
                              data after canonicalization included in the
                              cryptographic hash, starting from 0 immediately
                              following the CRLF preceding the Content. This
                              value MUST NOT be larger than the actual number
                              of octets in the canonicalized Content. <list>
                                 <t><figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[sig-l-tag    = %x6c [FWS] "=" [FWS]
               1*76DIGIT]]></artwork>
                                    </figure></t>
                              </list>
                              <list
                                 style="hanging">
                                 <t
                                    hangText="NOTE: ">Use of the "l=" tag
                                    might allow display of fraudulent content
                                    without appropriate warning to end users.
                                    The "l=" tag is intended for increasing
                                    signature robustness when sending to
                                    intermediaries that append data to
                                    Content, such as mailing lists that both
                                    modify their content and do not sign their
                                    messages. However, using the "l=" tag
                                    enables attacks in which an intermediary
                                    with malicious intent modifies a message
                                    to include content that solely benefits
                                    the attacker. It is possible for the
                                    appended content to completely replace the
                                    original content in the end recipient's
                                    eyes and to defeat duplicate message
                                    detection algorithms. Examples are
                                    described in Security Considerations <xref
                                       target="security"/>. To avoid this
                                    attack, signers need be extremely wary of
                                    using this tag, and verifiers might wish
                                    to ignore the tag or remove text that
                                    appears after the specified content
                                    length.</t>
                                 <t
                                    hangText="NOTE: ">The value of the "l="
                                    tag is constrained to 76 decimal digits.
                                    This constraint is not intended to predict
                                    the size of future data or to require
                                    implementations to use an integer
                                    representation large enough to represent
                                    the maximum possible value, but is
                                    intended to remind the implementer to
                                    check the length of this and all other
                                    tags during verification and to test for
                                    integer overflow when decoding the value.
                                    Implementers might need to limit the
                                    actual value expressed to a value smaller
                                    than 10^76, for example, to allow a
                                    message to fit within the available
                                    storage space.</t>

                              </list>
                           </t>

                           <t
                              hangText="z=  ">Copied Header fields
                              (DOSETA-quoted-printable, but see description;
                              OPTIONAL, default is null). A
                              vertical-bar-separated list of selected Header
                              fields present when the message was signed,
                              including both the field name and value. It is
                              not required to include all Header fields
                              present at the time of signing. This field need
                              not contain the same Header fields listed in the
                              "h=" tag. The Header field text itself MUST
                              encode the vertical bar ("|", %x7C) character.
                              That is, vertical bars in the "z=" text are
                              meta-characters, and any actual vertical bar
                              characters in a copied header field MUST be
                              encoded. Note that all whitespace MUST be
                              encoded, including whitespace between the colon
                              and the header field value. After encoding, FWS
                              MAY be added at arbitrary locations in order to
                              avoid excessively long lines; such whitespace is
                              NOT part of the value of the header field, and
                              MUST be removed before decoding.</t>
                           <t>The Header fields referenced by the "h=" tag
                              refer to the fields in the <xref
                                 target="RFC5322"/> Header, not to any copied
                              fields in the "z=" tag. Copied header field
                              values are for diagnostic use.</t>
                           <t>Header fields with characters requiring
                              conversion (perhaps from legacy MTAs that are
                              not <xref
                                 target="RFC5322"/> compliant) SHOULD be
                              converted as described in MIME Part Three <xref
                                 target="RFC2047"/>.</t>
                           <t>
                              <list>
                                 <t>
                                    <cref>errata 1379</cref>
                                    <figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[
sig-z-tag      = %x7A [FWS] "=" [FWS] 
                 sig-z-tag-copy
                 *( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name [FWS] ":" 
                 qp-hdr-value]]></artwork>
                                    </figure></t>
                              </list></t>
                        </list></t>
                  </list>
                  <cref>errata 1386</cref><figure
                     align="left">
                     <preamble>EXAMPLE of a signature header field spread
                        across multiple continuation lines:</preamble>
                     <artwork><![CDATA[DKIM-Signature: v=1; a=rsa-sha256; d=example.net; 
  s=brisbane;   c=simple; q=dns/txt; i=@eng.example.net;
  t=1117574938; x=1118006938;
  h=from:to:subject:date;
  z=From:foo@eng.example.net|To:joe@example.com|
   Subject:demo=20run|
   Date:July=205,=202005=203:44:08=20PM=20-0700;
  bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR]]></artwork>
                  </figure></t>

               <section
                  anchor="textlength"
                  title="Content Length Limits">
                  <t>A text length count MAY be specified to limit the
                     signature calculation to an initial prefix of an ASCII
                     text data portion, measured in octets. If the Content
                     length count is not specified, the entire Content is
                     signed. </t>
                  <t>This capability is provided because it is very common for
                     intermediate data handling services to add trailers to
                     text (for example, instructions how to get off a mailing
                     list). Until such data is signed by the intermediate
                     handler, the text length count can be a useful tool for
                     the verifier since it can, as a matter of policy, accept
                     messages having valid signatures that do not cover the
                     additional data.</t>
                  <t><list
                        style="hanging">
                        <t
                           hangText="NOTE: ">Using text length limits enables
                           an attack in which an attacker modifies a message
                           to include content that solely benefits the
                           attacker. It is possible for the appended content
                           to completely replace the original content in the
                           end recipient's eyes and to defeat duplicate
                           message detection algorithms. To avoid this attack,
                           signers need to be wary of using this tag, and
                           verifiers might wish to ignore the tag or remove
                           text that appears after the specified content
                           length, perhaps based on other criteria.</t>
                     </list></t>

                  <t>The text length count allows the signer of text to permit
                     data to be appended to the end of the text of a signed
                     message. The text length count MUST be calculated
                     following the canonicalization algorithm; for example,
                     any whitespace ignored by a canonicalization algorithm is
                     not included as part of the Content length count. Signers
                     of MIME messages that include a Content length count
                     SHOULD be sure that the length extends to the closing
                     MIME boundary string. <list
                        style="hanging">
                        <t
                           hangText="NOTE:  ">A creator wishing to ensure that
                           the only acceptable modifications are to add to a
                           MIME postlude would use a text length count
                           encompassing the entire final MIME boundary string,
                           including the final "--CRLF". A signer wishing to
                           allow additional MIME parts but not modification of
                           existing parts would use a Content length count
                           extending through the final MIME boundary string,
                           omitting the final "--CRLF". Note that this only
                           works for some MIME types, such as,
                           multipart&sol;mixed but not
                           multipart&sol;signed.</t>
                     </list></t>
                  <t>A text length count of zero means that the text is
                     completely unsigned.</t>
                  <t>Creators wishing to ensure that no modification of any
                     sort can occur will specify the "simple" canonicalization
                     algorithm for all data portions and will and omit the
                     text length counts.</t>
               </section>



               <section
                  title="Signature Verification">
                  <t>A Content length specified in the "l=" tag of the
                     signature limits the number of bytes of the Content
                     passed to the verification algorithm. All data beyond
                     that limit is not validated by DOSETA. Hence, verifiers
                     might treat a message that contains bytes beyond the
                     indicated Content length with suspicion, such as by
                     truncating the message at the indicated Content length,
                     declaring the signature invalid (for example, by
                     returning PERMFAIL (unsigned content)), or conveying the
                     partial verification to the policy module. <list
                        style="hanging">
                        <t
                           hangText="NOTE: ">Verifiers that truncate the
                           Content at the indicated Content length might pass
                           on a malformed MIME message if the signer used the
                           "N-4" trick (omitting the final "--CRLF") described
                           in the informative note in <xref
                              target="textlength"/>. Such verifiers might wish
                           to check for this case and include a trailing
                           "--CRLF" to avoid breaking the MIME structure. A
                           simple way to achieve this might be to append
                           "--CRLF" to any "multipart" message with a Content
                           length; if the MIME structure is already correctly
                           formed, this will appear in the postlude and will
                           not be displayed to the end user.</t>
                     </list></t>
               </section>
            </section>


            <section
               anchor="dkkeydata"
               title="Stored Key Data">

               <t>This section defines additions to the DOSETA Library,
                  concerning stored key data. <list>
                     <t><list
                           style="hanging">
                           <t
                              hangText="g=  ">Granularity of the key
                              (plain-text; OPTIONAL, default is "*"). This
                              value MUST match the Local-part of the "i=" tag
                              of the DKIM- Signature header field (or its
                              default value of the empty string if "i=" is not
                              specified), with a single, optional "*"
                              character matching a sequence of zero or more
                              arbitrary characters ("wildcarding"). An email
                              with a signing address that does not match the
                              value of this tag constitutes a failed
                              verification. The intent of this tag is to
                              constrain which signing address can legitimately
                              use this selector, for example, when delegating
                              a key to a third party that should only be used
                              for special purposes. Wildcarding allows
                              matching for addresses such as "user+*" or
                              "*-offer". An empty "g=" value never matches any
                              addresses. <list>
                                 <t><figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[key-g-tag       = %x67 [FWS] "=" [FWS] key-g-tag-lpart
                     key-g-tag-lpart = [dot-atom-text] 
                                       ["*" [dot-atom-text] ]]]></artwork>
                                    </figure></t>
                              </list>
                           </t>

                           <t
                              hangText="h=  ">Acceptable hash algorithms
                              (plain-text; OPTIONAL, defaults to allowing all
                              algorithms). A colon-separated list of hash
                              algorithms that might be used. Signers and
                              Verifiers MUST support the "sha256" hash
                              algorithm. Verifiers MUST also support the
                              "sha1" hash algorithm. <cref>errata 1381</cref>
                              Unrecognized hash algorithms MUST be ignored. </t>
                           <t>
                              <list>
                                 <t>
                                    <figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[
key-h-tag       = %x68 [FWS] "=" [FWS] 
                  key-h-tag-alg
                  0*( [FWS] ":" [FWS] 
                  key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / 
                  x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   
                       ; for future extension]]></artwork>
                                    </figure>
                                 </t>
                              </list>
                           </t>
                           <t
                              anchor="svctypesseq"
                              hangText="s=  ">Service Type (plain-text;
                              OPTIONAL; default is "*"). A colon-separated
                              list of service types to which this record
                              applies. Verifiers for a given service type MUST
                              ignore this record if the appropriate type is
                              not listed. <cref>errata 1381, 1382</cref>
                              Unrecognized service types MUST be ignored.
                              Currently defined service types are as follows: </t>
                           <t><list
                                 style="hanging">
                                 <t
                                    hangText="* ">matches all service
                                    types</t>
                                 <t
                                    hangText="email ">electronic mail (not
                                    necessarily limited to SMTP)</t>
                              </list> This tag is intended to constrain the
                              use of keys for other purposes, if use of DOSETA
                              is defined by other services in the future.</t>
                           <t>
                              <list>
                                 <t>
                                    <figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[
key-s-tag        = %x73 [FWS] "=" [FWS] 
                   key-s-tag-type
                   0*( [FWS] ":" [FWS] 
                   key-s-tag-type )
key-s-tag-type   = "email" / "*" / 
                   x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   
                        ; for future extension]]></artwork>
                                    </figure>
                                 </t>
                              </list>
                           </t>
                           <t
                              anchor="svcflagteq"
                              hangText="t=  ">Flags, represented as a
                              colon-separated list of names (plain-text;
                              OPTIONAL, default is no flags set). <cref>errata
                                 1381</cref> Unrecognized flags MUST be
                              ignored. The defined flags are as follows: <list
                                 style="hanging">
                                 <t
                                    hangText="y  ">This domain is testing
                                    DOSETA. Verifiers MUST NOT treat data from
                                    signers in testing mode differently from
                                    unsigned data, even if the signature fails
                                    to verify. Verifiers MAY wish to track
                                    testing mode results to assist the
                                    signer.</t>
                                 <t
                                    hangText="s  ">Any DOSETA&nbhy;Signature
                                    Header fields using the "i=" tag MUST have
                                    the same domain value on the right-hand
                                    side of the "@" in the "i=" tag and the
                                    value of the "d=" tag. That is, the "i="
                                    domain MUST NOT be a subdomain of "d=".
                                    Use of this flag is RECOMMENDED unless
                                    subdomaining is required.</t>
                              </list>
                           </t>
                           <t>
                              <list>
                                 <t>
                                    <figure>
                                       <preamble>ABNF:</preamble>
                                       <artwork type="abnf"><![CDATA[key-t-tag        = %x74 [FWS] "=" [FWS] 
                   key-t-tag-flag
                   0*( [FWS] ":" [FWS] 
                   key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / 
                   x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   
                        ; for future extension]]></artwork>
                                    </figure>
                                 </t>
                              </list>
                           </t>

                        </list></t>
                  </list>
               </t>
            </section>


         </section>

      </section>
   </back>
</rfc>
