<?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="std"
   docName="draft-crocker-dkim-doseta-00"
   ipr="trust200902"
   submissionType="IETF">

   <front>
      <title
         abbrev="DOSETA">DomainKeys Security Tagging (DOSETA)</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>

      <!--      <author
         fullname="Tony Hansen"
         initials="T."
         role="editor"
         surname="Hansen">
         <organization>AT&amp;T Laboratories</organization>
         <address>
				<postal>
					<street>200 Laurel Ave. South</street>
					<city>Middletown</city>
					<region>NJ</region>
					<code>07748</code>
					<country>USA</country>
				</postal>
				<email>tony+dkimov@maillennium.att.com</email>
			</address>
			</author> -->

      <author
         fullname="M. Kucherawy"
         initials="M."
         role="editor"
         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"/>

      <workgroup>DKIM</workgroup>

      <abstract>
         <t>DomainKeys Security Tagging (DOSETA) is a component mechanism that
            enables development of a security-related service, such as
            authentication or encryption, with keys based on domain names; the
            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
            retrieval of self-certified keys. The DOSETA Signing Template
            affixes a signature to data that is in a "header/content" form.
            Defining the meaning of the signature is the responsibility of the
            service that incorporates DOSETA. The signature is validated
            through a cryptographic signature and querying the signer's domain
            directly, to retrieve the appropriate public key. </t>
      </abstract>

   </front>



   <middle>


      <section
         title="Introduction">

         <t>DomainKeys Security Tagging (DOSETA) is a component mechanism that
            enables development of a security-related service, such as
            authentication or encryption, with keys based on domain names <xref
               target="RFC1034"/>; the 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 retrieval of
            self-certified keys. The DOSETA Signing Template affixes a
            signature to data that is in a "header/content" form. Defining the
            meaning of the signature is the responsibility of the service that
            incorporates DOSETA. The signature is validated through a
            cryptographic signature and querying the signer's domain directly,
            to retrieve the appropriate public key.</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
                  signature-related content appearing in the Content;</t>
               <t>there is no dependency on 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>no attempt is made to include encryption as part of the
                  mechanism;</t>
            </list></t>

         <t>DOSETA: <list
               style="symbols">
               <t>enables compatibility with the existing data handling
                  infrastructure and transparent to the fullest extent
                  possible;</t>
               <t>requires minimal new infrastructure;</t>
               <t>can be implemented independently of data clients 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 is taken directly from the original DKIM Signing
            specification <xref
               target="RFC4871"/>, <xref
               target="RFC5672"/>. It has merely extracted the core portions
            of the specification, 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 encryption mechanism using the same DNS-based, self-certified
            key service as DKIM. <list
               style="hanging">
               <t
                  hangText="NOTE:  ">Much of the text for this draft is taken
                  from the DKIM working group draft-ietf-DKIM-rfc4871bis-02
                  revision. Sections in this document cross reference their
                  source with the notation: <figure>
                     <artwork><![CDATA[{rfc4871bis-02 xx}]]></artwork>
                  </figure>where "xx" indicates the section number. It might
                  also indicate that a subset is taken, such as when a portion
                  is applied to the DKIM-over-DOSETA draft and a portion to
                  the DOSETA draft. In some cases the base text also has been
                  enhanced.</t>
            </list></t>


         <section
            anchor="features"
            title="DOSETA Features">
            <t>DOSETA features include: <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Identity:  ">DOSETA separates the
                           question of the identity of the DOSETA Creator from
                           any other associated identifier, such as the data's
                           purported author. In particular, a DOSETA header
                           includes the identity of the signer. DOSETA
                           Consumers can use the DOSETA identity information
                           to decide how they want to process the data. That
                           identity can be included in the attributes of the
                           data or recorded elsewhere. <list
                              style="hanging">
                              <t
                                 hangText="NOTE:  ">DOSETA does not, iiself,
                                 require that the identity it uses be 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 service that
                                 incorporates DNS might choose to add
                                 constraints on the choice of identifier, such
                                 as having it match another identifier
                                 associated with the data.</t>
                           </list></t>
                        <t
                           hangText="Scalability:  ">DOSETA is designed to
                           support the extreme scalability 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 in the domain of the claimed signer
                           directly rather than from a third party. Hence
                           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:  "> A DOSETA signature
                           associates its identifier with the computed hash of
                           some or all of the data in order to prevent the
                           re-use of the signature with different data.
                           Verifying the signature asserts that the hashed
                           data has not changed since it was signed, and
                           asserts nothing else about "protecting" the
                           end-to-end integrity of the data.</t>
                        <t
                           hangText="Assessment:  ">For identity and
                           authentication related processes, this phase
                           integrates the validation output for determing
                           further action.</t>
                     </list></t>
               </list></t>
         </section>

         <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:<figure
                  align="center">
                  <artwork><![CDATA[    +--------+                              +-----------------+
    |  DKIM  |                              | Message Privacy |
    +---+----+                              +--------+--------+
        |                                            |
  +-----V---------------------------+                |
  | Header/Content Signing Template |                |
  +----------------+----------------+                |
                   |                                 |
...................V.................................V.............
.                     D O S E T A     L I B R A R Y               .
.+------------------+ +------------+ +-------------+ +-----------+.
.|                  | |    Key     | |  Common     | | Signature |.
.| Canonicalization | | Management | |  Parameters | |  Header   |.
.|                  | |   (DNS)    | | (tab=value) | |           |.
.+------------------+ +------------+ +-------------+ +-----------+.
...................................................................]]>
                     </artwork>
               </figure>
            </t>
         </section>

      </section>


      <section
         title="Terminology and Definitions {rfc4871bis-02 2, subset}">
         <t>This section defines terms used in the rest of the document. </t>
         <t>Within the specification, the label "TEMPLATE" is used to indicate
            actions that are required to incorporate DOSETA into a
            service.</t>
         <t>Syntax descriptions use Augmented BNF (ABNF) <xref
               target="RFC5234"/>. </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/>

         <section
            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.</t>
                  <t
                     hangText="Signing Domain Identifier (SDID):  "> A single
                     domain name that refers to the identity owning the key to
                     be used for DOSETA processing. The name has only basic
                     domain name semantics; any possible owner-specific
                     semantics are outside the scope of DOSETA. It is
                     specified in <xref
                        target="signeddatastruct"/>.</t>
               </list></t>
         </section>

         <section
            title="Actors">
            <t><list
                  style="hanging">
                  <t
                     hangText="Creator:  ">An element in the data handling
                     system that produces a cryptographic encoding, on behalf
                     of a domain, is referred to as a Creator. </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.</t>
                  <t
                     hangText="Signer:  "> An element in the data handling
                     system that signs messages on behalf of a domain is
                     referred to as a signer. This element specifies the
                     organization acting as a type of DOSETA Creator. It might
                     be a client, server or other agent such as a reputation
                     service. The key issue is that the data MUST be signed
                     before it leaves the administrative domain of the signer. </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
                     (Creator) of the data or some consuming agent such as a
                     data processing intermediary. </t>
               </list></t>

         </section>


         <section
            title="Syntax">
            <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 (formal
                              definition in <xref
                                 target="RFC5234"/>).</t>
                           <t
                              hangText="LWSP:  "> is linear whitespace,
                              defined as WSP plus CRLF (formal definition in <xref
                                 target="RFC5234"/>).</t>
                           <t
                              hangText="FWS:  "> is folding whitespace. It
                              allows multiple lines separated by CRLF followed
                              by at least one whitespace, to be joined.</t>
                        </list></t>
                  </list></t>
               <t>The formal syntax for these are (WSP and LWSP are given for
                  information only): <list>
                     <t><figure>
                           <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><cref>errata 1596</cref>
                        <figure>
                           <preamble>ABNF:</preamble>
                           <artwork 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>"dot-atom-text" (in the &lt;local-part&gt; of an email address)</t>
               </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 is distinguished by a DNS-based, self-certifying public key
            mechanism, common canonicalization algorithms, and a common
            parameter encoding mechanism.</t>


         <section
            anchor="canon"
            title="Canonicalization {rfc4871bis-02 3.4}">
            <t>Some data handling systems modify the original data,
               potentially invalidating a cryptographic function, such as with
               a signature. For most signers, mild modification of data is
               immaterial to validation of the DOSETA domain name's use. For
               such signers, a canonicalization algorithm that survives modest
               handling modification is preferred.</t>
            <t>Other signers demand that any modification of the data, however
               minor, result in a signature verification failure. These
               signers prefer a canonicalization algorithm that does not
               tolerate any in-transit modification of the signed email.</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 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 an Internet Mail header fields</t>
                        <t
                           hangText="Content:  ">Lines of ASCII text</t>
                     </list></t>
               </list></t>
            <t>Some DOSETA Creators might be willing to accept modifications
               to some portions of the data, but not other portions. For
               DOSETA, a Creator MAY specify either algorithm for one portion
               of the data and another for a different portion when signing
               the data. </t>
            <t>If no canonicalization algorithm is specified, the "simple"
               algorithm defaults for all of the data. DOSETA Creators MUST
               implement both canonicalization algorithms. Because further
               canonicalization algorithms might be defined in the future,
               Creators MUST ignore any signatures that use unrecognized
               canonicalization algorithms.</t>
            <t>Canonicalization simply prepares the data for presentation to
               the signing or verification algorithm. It MUST NOT change the
               transmitted data in any way. Canonicalization of distinct data
               portions is described below.<list
                  style="hanging">
                  <t
                     hangText="NOTE: ">This section assumes that data is
                     already in "network normal" format (text is ASCII
                     encoded, lines are separated with CRLF characters, etc.).
                     See also <xref
                        target="normalize"/> for information about normalizing
                     the message.</t>
               </list></t>

            <section
               anchor="hdrcanon"
               title="Header Canonicalization Algorithms">
               <t>This section specifies initial entry for the IANA registry
                  defined in <xref
                     target="hdrcanonreg"/>. <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 signing or verification algorithm
                        exactly as they are in the message being signed or
                        verified. 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. It MUST apply the following
                        steps 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 specifies initial entry for the IANA registry
                  defined in <xref
                     target="bodcanonreg"/>. <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>
                        <cref>errata 1376</cref>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:  ">
                        <!-- <t>The "relaxed" Content canonicalization algorithm: <list
                  style="symbols">
                  <t>Ignores all whitespace at the end of lines.
                  Implementations MUST NOT remove the CRLF at the end of
                  the line.</t>
                  <t>Reduces all sequences of WSP within a line to a single
                  SP character.</t>
                  <t>Ignores all empty lines at the end of the Content.
                  "Empty line" is defined in <xref
                  target="simplebody" />.</t>
                  <cref>errata 1377</cref>
                  <t>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></t>-->
                        <cref>errata 1384</cref> 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 Section
                              3.4.3. <cref>errata 1377</cref> 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>
                        <cref>errata 1376</cref>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: ">It ought to be noted that the
                              relaxed Content canonicalization algorithm might
                              enable certain types of extremely crude "ASCII
                              Art" attacks where a message might be conveyed
                              by adjusting the spacing between words. If this
                              is a concern, the "simple" Content
                              canonicalization algorithm SHOULD be used
                              instead.</t>
                        </list>
                     </t>
                  </list></t>
            </section>

            <section
               title="Canonicalization Examples (3.4.6}">
               <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 {rfc4871bis-02 3.2}">
            <t>DOSETA uses a simple "tag=value" syntax in several contexts,
               including to represent associated cryptographic data and domain
               cryptographic 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 name of the tag will determine the
               encoding of each value. Unencoded semicolon (";") characters
               MUST NOT occur in the tag value, since that separates
               tag-specs. <list
                  style="hanging">
                  <t
                     hangText="NOTE:  ">Although the "plain text" defined
                     below (as "tag-value") only includes 7-bit characters, an
                     implementation that wished to anticipate future standards
                     would be advised not to preclude the use of UTF8-encoded
                     text in tag=value lists. </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>
            </t>
            <t>Note that 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>
            <t>Tags MUST be interpreted in a case-sensitive manner. Values
               MUST be processed as case sensitive unless the specific tag
               description of semantics specifies case insensitivity.</t>
            <t>Tags with 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 {rfc4871bis-02 3.6}">
            <t>Applications require some level of assurance that a cited
               public key is associated with the Creator using it. Many
               applications achieve this by using public key certificates
               issued by a trusted third party. For applications with modest
               certification requirements, DOSETA achieves a sufficient level
               of security, with significantly enhanced scalability, by simply
               having the Consumer query the purported Creator's DNS entry (or
               a supported equivalent) in order to retrieve the public
               key.</t>
            <t>DOSETA keys might be stored in multiple types of key servers
               and in multiple formats. The storage and format of keys are
               irrelevant to the remainder of the DOSETA algorithm.</t>
            <t>
               <list>
                  <t><figure>
                        <preamble>The 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=" tag (<xref
                              target="signeddatastruct"/>)</t>
                        <t
                           hangText="d-val:  ">The domain of the signature, as
                           specified in the "d=" tag (<xref
                              target="signeddatastruct"/>)</t>
                        <t
                           hangText="s-val:  ">The selector of the lookup as
                           specified in the "s=" tag (<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, using DNS TXT records
               to distribute the keys, per <xref
                  target="dnsbind"/>. Other bindings might be defined in the
               future.</t>
         </section>

         <section
            anchor="selectors"
            title="Selectors for Keys {rfc4871bis-02 3.1}">
            <t>To support 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>Selectors are needed to support some important use cases. For
               example: <list
                  style="symbols">
                  <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>
            <t> Periods are allowed in selectors and are component separators.
               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 corresponding selectors for each
               domain is 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>Beyond administrative convenience, 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,
                           signers are ill-advised to reuse selectors for new
                           keys. 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 {rfc4871bis-02 3.6.2}">
            <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=" tag (<xref
                                 target="signeddatastruct"/>)</t>
                           <t
                              hangText="d:  ">is the domain of the signature,
                              as specified in the "d=" tag (<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, in 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.</t>
                  </list></t>


               <t>Given a DOSETA&nbhy;Signature field with a "d=" tag of
                  "example.com" and an "s=" tag 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 this
                  context and 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=") tag. The only option defined in
                  this base specification is "txt", indicating the use of a
                  TXT Resource Record (RR). 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>
               <t>TXT RRs are encoded as described in <xref
                     target="keydata"/>.</t>
            </section>

         </section>

         <section
            anchor="keydata"
            title="Stored Key Data {rfc4871bis-02 3.6.1, subset, with preface}">
            <t>This section defines a syntax for encoding stored key data
               within an unstructured environment such as simple text. <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"/>.</t>
                     </list></t>
               </list>
            </t>
            <t>The overall syntax is a tag-list as described in <xref
                  target="tagval"/>. The current valid tags are 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
                  (plain-text; RECOMMENDED, 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=" tag 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".</t>
                  
                  <t>
                  <list>
                  <t>
                  <figure>
                  <preamble>ABNF:</preamble>
                  <artwork type="abnf"><![CDATA[key-v-tag    = %x76 [FWS] "="
                  [FWS] "DKIM1"]]></artwork>
                  </figure>
                  </t>
                  </list>
                  </t>-->
                        <t
                           hangText="v=">
                           <cref>errata 1487</cref>Version of the DOSETA key
                           record (plain-text; RECOMMENDED, 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=" tag 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.</t>
                           </list>
                        </t>

                        <t
                           hangText="k=  ">Key type (plain-text; OPTIONAL,
                           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=" tag. (Note: the "p=" tag further encodes
                           the value using the base64 algorithm.) <cref>errata
                              1381</cref> 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 (qp-section; OPTIONAL, 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 (base64; REQUIRED).
                           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=" tag. <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, which 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 with DKIM it 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.</t>

                     <t
                        hangText="TEMPLATE:  ">(Header/Content Mapping) The
                        service incorporating this mechanism MUST define the
                        precise mappings onto the template provided in this
                        section. (Note that 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 {rfc4871bis-02 3.3, subset}">
            <t>DOSETA supports multiple digital signature algorithms:
               <!-- errata 1378
		         The rsa-sha256 algorithm is the default if no algorithm 
		         is specified. Verifiers MUST implement both
               rsa-sha1 and rsa-sha256.-->
            </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
                  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>
            <t>See <xref
                  target="RFC3766"/> for further discussion on selecting key
               sizes.</t>

         </section>


         <section
            anchor="signeddatastruct"
            title="Signature Data Structure {rfc4871bis-02 3.5, subset}">
            <t>A signature of data is stored into an data structure associated
               with the signed data. This structure contains all of the
               signature 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 is part of a sequence of
               structures -- such as being added to an email header -- it
               SHOULD NOT be reordered and SHOULD be prepended 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 a 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 (plain-text; REQUIRED). 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 (base64;
                           REQUIRED). 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=" tag (base64;
                           REQUIRED). 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=  ">Message canonicalization
                           (plain-text; OPTIONAL, 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
                                       IANA registry defined in <xref
                                       target="hdrcanonreg"/></t>
                                    <t
                                       hangText="sig-c-content:  ">A value
                                       from IANA registry defined in <xref
                                       target="bodcanonreg"/></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="d=  ">The SDID doing the signing
                           (plain-text; REQUIRED). Hence, the SDID value is
                           used to form the query for the public key. The SDID
                           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 SDID 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 (plain-text,
                           but see description; REQUIRED). 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>
                                 <cref>errata 1461</cref>
                                 <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
                           (plain-text; OPTIONAL, 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.
                              <cref>errata 1381</cref> 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 (plain-text;
                           REQUIRED).</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 (plain-text
                           unsigned decimal integer; RECOMMENDED, 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 (plain-text
                           unsigned decimal integer; RECOMMENDED, default is
                           no expiration). The format is the same as in the
                           "t=" tag, 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=" tag MUST be
                           greater than the value of the "t=" tag if both are
                           present.</t>
                        <t>
                           <list
                              style="hanging">
                              <t
                                 hangText="NOTE: ">The "x=" tag is not
                                 intended as an anti-replay defense.</t>
                              <t
                                 hangText="NOTE: ">
                                 <cref>errata 1380</cref>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="sigcalc"
            title="Signature Calculation {rfc4871bis-02 3.7, reorganized and clarified}">
            <t>Hashing and Cryptographic algorithms are combined into a
               procedure for computing a digital signature. </t>
            <t>Creators will choose appropriate parameters for the signing
               process; Creators will use the tags that are then passed as an
               associated DOSETA Header field. <xref
                  target="signeddatastruct"/> defines the contents of the
               Header field.</t>
            <t>In the following discussion, the names of the tags in the
               Header field that either exist (when consuming) or will be
               created (when creating) are used. <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 transmitted data
                           in any way.</t>
                     </list></t>
               </list></t>

            <t>Creators MUST compute hashes in the order defined. Consumers
               MAY compute them in any order convenient to the Creator,
               provided that the result is semantically identical to the
               semantics that would be the case had they been computed in this
               order.</t>

            <t>The combined hashing algorithm is: <list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="Step 1:  ">The Creator/Creator hashes the
                           Content portion, canonicalized using the Content
                           canonicalization algorithm specified in the "c="
                           tag and then truncated to the length specified in
                           the "l=" tag. That hash value is then converted to
                           base64 form. Signers then insert it into the "bh="
                           tag of the DOSETA&nbhy;Signature field; verifiers
                           compare their hash with the value in the "bh="
                           tag.</t>
                        <t
                           hangText="Step 2:  ">Pass the following to a second
                           hash algorithm in the indicated order: <list
                              style="symbols">
                              <t>Complete attribute:value Header fields
                                 specified by the "h=" tag, in the order
                                 specified in that tag, and canonicalized
                                 using the Header canonicalization algorithm
                                 specified in the "c=" tag. Each field MUST be
                                 terminated with a single CRLF. </t>
                              <t>The DOSETA&nbhy;Signature field that exists
                                 (verifying), or will be inserted (signing),
                                 in the Header, with the value of the "b="
                                 signature data tag (including all surrounding
                                 whitespace) deleted (that is, treated as the
                                 empty string), canonicalized using the Header
                                 canonicalization algorithm specified in the
                                 "c=" tag, and without a trailing CRLF. </t>
                              <t>The hash produced in Step 1.</t>
                           </list></t>
                     </list></t>
               </list>
            </t>

            <t>When calculating or verifying a signature, the value of the
               "b=" tag (signature value) of that DOSETA&nbhy;Signature
               structure MUST be treated as though it were an empty string.
               Unknown tags in the DOSETA&nbhy;Signature header field MUST be
               included in the signature calculation but MUST be otherwise
               ignored by verifiers.
               <!-- What does the next sentence mean??? b= is not a header field, and what does it
                  mean to be treated as a 'normal' header field? /d-->
               Other DOSETA&nbhy;Signature tags that are included in the
               signature SHOULD be treated as normal tags; in particular, the
               "b=" tag is not treated specially.</t>

            <t>All tags and their values in the DOSETA&nbhy;Signature field
               are included in the cryptographic hash with the sole exception
               of the value portion of the "b=" (signature) tag, which MUST be
               treated as the null string. All tags MUST be included even if
               they might not be understood by the verifier. The
               DOSETA&nbhy;Signature field MUST be presented to the hash
               algorithm after the Content. rather than with the rest of the
               Header fields and MUST be canonicalized as specified in the
               "c=" (canonicalization) tag. The DOSETA&nbhy;Signature header
               structure MUST NOT be included in its own h= tag, although
               other DOSETA&nbhy;Signature Header fields MAY be signed (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 simply a string of octets. DOSETA Content MAY be
               either in plain-text or in MIME format; no special treatment is
               afforded to MIME content. </t>
            <t>More formally, the algorithm for the signature is as follows: <list>
                  <t><figure>
                        <preamble>ABNF:
                           <!-- RFC 4871 version:
                     body-hash = hash-alg(canon_body)
                     header-hash = hash-alg(canon_header || DKIM-SIG)
                     signature = sig-alg(header-hash, key)
                    -->
                        </preamble>
                        <artwork type="abnf"><![CDATA[content-hash =  bh-hash-alg (canon-content, l-param)
data-hash    =  a-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 of a
                           function to hash the data Content.</t>
                        <t
                           hangText="bh-hash-alg:  ">is the hashing algorithm
                           specified in the "bh" parameter.</t>
                        <t
                           hangText="canon-body:  ">is a canonicalized
                           representation of the body.</t>
                        <t
                           hangText="l-param:  ">is the value of the l= length
                           parameter.</t>
                        <t
                           hangText="data-hash:  ">is the output from hashing
                           the header, the DOSETA&nbhy;Signature header, and
                           the Content hash.</t>
                        <t
                           hangText="a-hash-alg:  ">is the hash algorithm
                           specified by the "a=" tag, </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 sans the signature
                           value itself.</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=" tag, </t>
                        <t
                           hangText="d-domain:  ">is the domain name specified
                           in the d= parameter.</t>
                        <t
                           hangText="selector:  ">is the value of the s=
                           selector 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
                     last two steps in the algorithm would probably be
                     combined into a single call that would perform both the
                     "a-hash-alg" and the "sig-alg".</t>
               </list></t>
         </section>
         <section
            anchor="signer"
            title="Signer Actions {rfc4871bis-02 5}">
            <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="normalize"
               title="Normalize the Message to Prevent Transport Conversions">
               <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. In order to minimize the chances of such
                  breakage, signers SHOULD convert the data to a suitable
                  encoding, such as quoted-printable or base64, as described
                  in <xref
                     target="RFC2045"/> before signing. Such conversion is
                  outside the scope of DOSETA; the data SHOULD be converted to
                  7-bit prior to presentation to the DOSETA signing
                  procedure.</t>
               <t>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.
                  <!-- 
                  Therefore, a verifier SHOULD NOT validate a message that is not compliant with
                  those specifications.
                  -->
               </t>
               <t>If the data is submitted to the signer with any local
                  encoding that will be modified before transmission, that
                  modification to a canonical form MUST be done before
                  signing. 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, the signer MUST sign the data as it is
                  expected to be received by the verifier rather than in some
                  local or internal form.</t>
            </section>
            <section
               anchor="fields2sign"
               title="Determine the Header Fields to Sign">
               <t>
                  <!--
               The From Header field MUST be signed (that is, included in the "h=" tag of the
               resulting DOSETA&nbhy;Signature header field).
               -->
                  Signers SHOULD NOT sign an existing header field that is
                  likely to be legitimately modified or removed in transit.
                  <!--In particular, <xref
                     target="RFC5321"/> explicitly permits modification or removal of the
                     Return-Path header field 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=" tag 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=" tag 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=" tag 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=" tag.</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=" tag MUST
                  be the appropriately signed hash computed in the previous
                  step, signed using the algorithm specified in the "a=" tag
                  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 {rfc4871bis-02 6}">
            <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.
               <!-- This considerably simplifies things
               for the user, who can now use an existing mail user agent. Most MUAs have the ability
               to filter messages based on message Header fields or content; these filters would be
               used to implement whatever policy the user wishes with respect to unsigned mail.--></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=" tag 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=" tag, 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=" tag. If not, the DOSETA&nbhy;Signature header field
                  MUST be ignored and the verifier SHOULD return PERMFAIL
                  (domain mismatch).</t>
               <t>If the "h=" tag 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=" tag 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=" tag 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=" tag 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 order indicated -- 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=" tag, and the selector
                        from the "s=" tag.</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=" tag) that they
                        do not implement.</t>
                     <t>If the "h=" tag 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=" tag, the verifier MUST ignore
                        the key record and return PERMFAIL (inappropriate hash
                        algorithm).</t>
                     <t>If the public key data (the "p=" tag) 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=" tags 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=" tag, the
                        Content length specified in the "l=" tag, and the
                        header field names in the "h=" tag, 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=" tag against the actual
                        message header field, comparisons MUST be
                        case-insensitive.</t>
                     <t>Based on the algorithm indicated in the "a=" tag,
                        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=" tag. 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=" tag, verify
                        the signature against the header hash using the
                        mechanism appropriate for the public key algorithm
                        described in the "a=" tag. 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=" tag 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<!-- and that the verified identity
                        matches the author identity that will be displayed by the MUA-->.
                        In particular, <!--MUA--> 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<!-- (for example, when communicating with a peer who, by prior agreement,
                  agrees to only send signed data), and the verifier runs synchronously with the
                  data transfer activity and a signature is missing or does not verify, the receiver SHOULD use a
                  550/5.7.x reply code-->.</t>
               <!--               <t>
                  <figure
                     align="left">
                     <preamble>If it is not possible to fetch the public key, perhaps because the
                        key server is not available, a temporary failure message MAY be generated
                        using a 451/4.7.5 reply code, such as: </preamble>
                     <artwork><![CDATA[451 4.7.5 Unable to verify signature - key server unavailable]]></artwork>
                  </figure>
               </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 SDID is not the same as the address in the
                  From: header field, the data system SHOULD take pains to
                  ensure that the actual SDID 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<!-- before display to the end
                  user-->.</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 {added}">
            <t>This generic template requires additional details, to define a
               specific service:<list>
                  <t><list
                        style="hanging">
                        <t
                           hangText="D-Signature Association: ">Specify the
                           means by which a DOSETA&nbhy;Signature header field
                           is associated with the data it signs. 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, 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 Signaling:  ">The means by
                           which a Consumer is to know what semantics apply
                           must be indicated. This is likely to be the same
                           means by which the Consumer knows what specific
                           service is being used. For example, different
                           service-specific DOSETA&nbhy;Signature header
                           fields might be used. "DKIM&nbhy;Signature" signals
                           a name-affixing service, while
                           "DKVM&nbhy;Signature" might signal a message
                           validation service.</t>
                        <t
                           hangText="Semantics:  ">Define the meaning of a
                           signature. 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. </t>
                        <t
                           hangText="Header/Content Mapping:  ">The mappings
                           between the generic service and data of a
                           particular service needs to be defined. For
                           example, with DKIM Header maps to the email header
                           and Content maps to the email body.</t>
                     </list></t>
               </list>
            </t>
         </section>

         <section
            anchor="parentsig"
            title="Signing by Parent Domains {rfc4871bis-02 3.8}">
            <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=" tag 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=" tag, the domain of the AUID ("i="
               flag) MUST be the same as that of the SDID (d=) domain. If this
               flag is absent, the domain of the AUID MUST be the same as, or
               a subdomain of, the SDID.</t>
         </section>
      </section>

      <section
         anchor="multisig"
         title="Semantics of Multiple Signatures {rfc4871bis-02 4}">
         <section
            title="Example Scenarios {rfc4871bis-02 4.1}">
            <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=" tag (to satisfy strict verifiers) and a second time
               with a limited set of headers and an "l=" tag (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 {rfc4871bis-02 4.2}">
            <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
                     DOSETA&nbhy;Signature Header fields. For example, if the
                     message being signed already contains three
                     DOSETA&nbhy;Signature header fields A, B, and C, it is
                     possible to sign all of them, B and C only, or C only,
                     but not A only, B only, A and B 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
         title="Considerations">


         <section
            anchor="iana"
            title="IANA Considerations {rfc4871bis-02 7, subset}">
            <t>This section carries forward the IANA registrations made by
               DKIM <xref
                  target="RFC4871"/>. The original DKIM language has been
               retained, including the use of "DKIM" in the name of these
               registries, in order to provide continuity from the original
               specification.</t>
            <t>In all cases, new values are assigned only for values that have
               been documented in a published RFC that has IETF Consensus <xref
                  target="RFC5226"/>.</t>
            <section
               title="DKIM&nbhy;Signature Tag Specifications">
               <t><list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">The content of a
                        DOSETA&nbhy;Signature structure match those in a
                        DKIM&nbhy;Signature header field.</t>
                  </list></t>
               <t>A DKIM&nbhy;Signature provides for a list of tag
                  specifications. IANA has established the DKIM&nbhy;Signature
                  Tag Specification Registry for tag specifications that can
                  be used in DKIM&nbhy;Signature fields.</t>
               <t>The initial entries in the registry comprise:</t>
               <texttable
                  anchor="sigtagreg"
                  title="DKIM&nbhy;Signature Tag Specification Registry Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> v </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> a </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> b </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> bh </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> c </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> d </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> h </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> q </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> s </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> t </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
                  <c> x </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>) </c>
               </texttable>
            </section>

            <section
               title="DKIM&nbhy;Signature Query Method Registry">
               <t>The "q=" tag-spec (specified in <xref
                     target="signeddatastruct"/>) provides for a list of query
                  methods.</t>
               <t>IANA has established the DKIM&nbhy;Signature Query Method
                  Registry for mechanisms that can be used to retrieve the key
                  that will permit validation processing of a message signed
                  using DKIM.</t>
               <t>The initial entry in the registry comprises:</t>
               <texttable
                  title="DKIM&nbhy;Signature Query Method Registry Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="center">OPTION</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> dns </c>
                  <c> txt </c>
                  <c> (this document, <xref
                        target="signeddatastruct"/>, "q=") </c>
               </texttable>
            </section>

            <section
               title="DKIM&nbhy;Signature Canonicalization Registry">
               <t>The "c=" tag-spec (specified in <xref
                     target="signeddatastruct"/>) provides for a specifier for
                  canonicalization algorithms for the header and Content.</t>
               <t> IANA has established the DKIM&nbhy;Signature
                  Canonicalization Algorithm Registry for algorithms for
                  converting a message into a canonical form before signing or
                  verifying using DKIM.</t>
               <t>The initial entries in the Header registry comprise:</t>
               <texttable
                  anchor="hdrcanonreg"
                  title="DKIM&nbhy;Signature Header Canonicalization Algorithm
               Registry                Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> simple </c>
                  <c> (this document, <xref
                        target="hdrcanon"/>) </c>
                  <c> relaxed </c>
                  <c> (this document, <xref
                        target="hdrcanon"/>) </c>
               </texttable>

               <t>The initial entries in the Content (Body) registry
                  comprise:</t>
               <texttable
                  anchor="bodcanonreg"
                  title="DKIM&nbhy;Signature Body Canonicalization Algorithm
               Registry                Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> simple </c>
                  <c> (this document, <xref
                        target="contentcanon"/>) </c>
                  <c> relaxed </c>
                  <c> (this document, <xref
                        target="contentcanon"/>) </c>
               </texttable>
            </section>

            <section
               title="_domainkey DNS TXT Record Tag Specifications">
               <t>A _domainkey DNS TXT record provides for a list of tag
                  specifications. IANA has established the DKIM _domainkey DNS
                  TXT Tag Specification Registry for tag specifications that
                  can be used in DNS TXT Records.</t>
               <t>The initial entries in the registry comprise:</t>
               <texttable
                  title="DOSETA _domainkey DNS TXT Record Tag Specification Registry
               Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> v </c>
                  <c> (this document, <xref
                        target="keydata"/>) </c>
                  <c> k </c>
                  <c> (this document, <xref
                        target="keydata"/>) </c>
                  <c> n </c>
                  <c> (this document, <xref
                        target="keydata"/>) </c>
                  <c> p </c>
                  <c> (this document, <xref
                        target="keydata"/>) </c>
               </texttable>

            </section>
            <section
               title="DKIM Key Type Registry">
               <t>The "k=" &lt;key-k-tag&gt; (specified in <xref
                     target="keydata"/>) and the "a=" &lt;sig- a-tag-k&gt;
                  (specified in <xref
                     target="signeddatastruct"/>) tags provide for a list of
                  mechanisms that can be used to decode a DKIM signature.</t>
               <t>IANA has established the DKIM Key Type Registry for such
                  mechanisms.</t>
               <t>The initial entry in the registry comprises:</t>
               <texttable
                  title="DKIM Key Type Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> rsa </c>
                  <c>
                     <xref
                        target="RFC3447"/>
                  </c>
               </texttable>
            </section>

            <section
               title="DKIM Hash Algorithms Registry">
               <t>The "h=" &lt;key-h-tag&gt; (specified in <xref
                     target="keydata"/>) and the "a=" &lt;sig- a-tag-h&gt;
                  (specified in <xref
                     target="signeddatastruct"/>) tags provide for a list of
                  mechanisms that can be used to produce a digest of message
                  data.</t>
               <t>IANA has established the DKIM Hash Algorithms Registry for
                  such mechanisms.</t>
               <t>The initial entries in the registry comprise:</t>
               <texttable
                  title="DKIM Hash Algorithms Initial Values">
                  <ttcol
                     align="center">TYPE</ttcol>
                  <ttcol
                     align="left">REFERENCE</ttcol>
                  <c> sha1 </c>
                  <c>
                     <xref
                        target="FIPS-180-2-2002"/>
                  </c>
                  <c> sha256 </c>
                  <c>
                     <xref
                        target="FIPS-180-2-2002"/>
                  </c>
               </texttable>
            </section>


         </section>


         <section
            anchor="security"
            title="Security Considerations {rfc4871bis-02 8, subset}">
            <t> It has been observed that any mechanism that is introduced
               that attempts to stem the flow of spam 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>

            <section
               title="Misappropriated Private Key">
               <t>If the private key for a user is resident on their computer
                  and is not protected by an appropriately secure mechanism,
                  it is possible for malware to send mail as that user and any
                  other user sharing the same private key. The malware would
                  not, however, be able to generate signed spoofs of other
                  signers' addresses, which would aid in identification of the
                  infected user and would limit the possibilities for certain
                  types of attacks involving socially engineered messages.
                  This threat applies mainly to MUA-based implementations;
                  protection of private keys on servers can be easily achieved
                  through the use of specialized cryptographic hardware.</t>
               <t>A larger problem occurs if malware on many users' computers
                  obtains the private keys for those users and transmits them
                  via a covert channel to a site where they can be shared. The
                  compromised users would likely not know of the
                  misappropriation until they receive "bounce" messages from
                  messages they are purported to have sent. Many users might
                  not understand the significance of these bounce messages and
                  would not take action.</t>
               <t>One countermeasure is to use a user-entered passphrase to
                  encrypt the private key, although users tend to choose weak
                  passphrases and often reuse them for different purposes,
                  possibly allowing an attack against DOSETA to be extended
                  into other domains. Nevertheless, the decoded private key
                  might be briefly available to compromise by malware when it
                  is entered, or might be discovered via keystroke logging.
                  The added complexity of entering a passphrase each time one
                  sends a message would also tend to discourage the use of a
                  secure passphrase.</t>
               <t>A somewhat more effective countermeasure is to send messages
                  through an outgoing MTA that can authenticate the submitter
                  using existing techniques (for example, SMTP
                  Authentication), possibly validate the message itself (for
                  example, verify that the header is legitimate and that the
                  content passes a spam content check), and sign the message
                  using a key appropriate for the submitter address. Such an
                  MTA can also apply controls on the volume of outgoing mail
                  each user is permitted to originate in order to further
                  limit the ability of malware to generate bulk email.</t>
            </section>

            <section
               title="Key Server Denial-of-Service Attacks">
               <t>Since the key servers are distributed (potentially separate
                  for each domain), the number of servers that would need to
                  be attacked to defeat this mechanism on an Internet-wide
                  basis is very large. Nevertheless, key servers for
                  individual domains could be attacked, impeding the
                  verification of messages from that domain. This is not
                  significantly different from the ability of an attacker to
                  deny service to the mail exchangers for a given domain,
                  although it affects outgoing, not incoming, mail.</t>
               <t>A variation on this attack is that if a very large amount of
                  mail were to be sent using spoofed addresses from a given
                  domain, the key servers for that domain could be overwhelmed
                  with requests. However, given the low overhead of
                  verification compared with handling of the email message
                  itself, such an attack would be difficult to mount.</t>
            </section>

            <section
               title="Attacks Against the DNS">
               <t>Since the DNS is a required binding for key services,
                  specific attacks against the DNS need to be considered.</t>
               <t>While the DNS is currently insecure <xref
                     target="RFC3833"/>, these security problems are the
                  motivation behind DNS Security (DNSSEC) <xref
                     target="RFC4033"/>, and all users of the DNS will reap
                  the benefit of that work.</t>
               <t>DOSETA is only intended as a "sufficient" method of proving
                  authenticity. It is not intended to provide strong
                  cryptographic proof about authorship or contents. Other
                  technologies such as OpenPGP <xref
                     target="RFC4880"/> and S/MIME <xref
                     target="RFC5751"/> address those requirements.</t>
               <t>A second security issue related to the DNS revolves around
                  the increased DNS traffic as a consequence of fetching
                  selector-based data as well as fetching signing domain
                  policy. Widespread deployment of DOSETA will result in a
                  significant increase in DNS queries to the claimed signing
                  domain. In the case of forgeries on a large scale, DNS
                  servers could see a substantial increase in queries.</t>
               <t>A specific DNS security issue that ought to be considered by
                  DOSETA verifiers is the name chaining attack described in
                  Section 2.3 of <xref
                     target="RFC3833"/>. A DOSETA verifier, while verifying a
                  DOSETA&nbhy;Signature header field, could be prompted to
                  retrieve a key record of an attacker's choosing. This threat
                  can be minimized by ensuring that name servers, including
                  recursive name servers, used by the verifier enforce strict
                  checking of "glue" and other additional information in DNS
                  responses and are therefore not vulnerable to this
                  attack.</t>
            </section>
            <section
               title="Replay Attacks">
               <t>In this attack, a spammer sends a message to be spammed to
                  an accomplice, which results in the message being signed by
                  the originating MTA. The accomplice resends the message,
                  including the original signature, to a large number of
                  recipients, possibly by sending the message to many
                  compromised machines that act as MTAs. The messages, not
                  having been modified by the accomplice, have valid
                  signatures.</t>
               <t>Partial solutions to this problem involve the use of
                  reputation services to convey the fact that the specific
                  email address is being used for spam and that messages from
                  that signer are likely to be spam. This requires a real-time
                  detection mechanism in order to react quickly enough.
                  However, such measures might be prone to abuse, if for
                  example an attacker resent a large number of messages
                  received from a victim in order to make them appear to be a
                  spammer.</t>
               <t>Large verifiers might be able to detect unusually large
                  volumes of mails with the same signature in a short time
                  period. Smaller verifiers can get substantially the same
                  volume of information via existing collaborative
                  systems.</t>
            </section>
            <section
               title="Limits on Revoking Keys">
               <t>When a large domain detects undesirable behavior on the part
                  of one of its users, it might wish to revoke the key used to
                  sign that user's messages in order to disavow responsibility
                  for messages that have not yet been verified or that are the
                  subject of a replay attack. However, the ability of the
                  domain to do so can be limited if the same key, for
                  scalability reasons, is used to sign messages for many other
                  users. Mechanisms for explicitly revoking keys on a
                  per-address basis have been proposed but require further
                  study as to their utility and the DNS load they
                  represent.</t>
            </section>
            <section
               title="Intentionally Malformed Key Records">
               <t>It is possible for an attacker to publish key records in DNS
                  that are intentionally malformed, with the intent of causing
                  a denial-of- service attack on a non-robust verifier
                  implementation. The attacker could then cause a verifier to
                  read the malformed key record by sending a message to one of
                  its users referencing the malformed record in a (not
                  necessarily valid) signature. Verifiers MUST thoroughly
                  verify all key records retrieved from the DNS and be robust
                  against intentionally as well as unintentionally malformed
                  key records.</t>
            </section>
            <section
               title="Intentionally Malformed DOSETA&nbhy;Signature Header Fields">
               <t>Verifiers MUST be prepared to receive messages with
                  malformed DOSETA&nbhy;Signature Header fields, and
                  thoroughly verify the header field before depending on any
                  of its contents.</t>
            </section>
            <section
               title="Information Leakage">
               <t>An attacker could determine when a particular signature was
                  verified by using a per-message selector and then monitoring
                  their DNS traffic for the key lookup. This would act as the
                  equivalent of a "web bug" for verification time rather than
                  when the message was read.</t>
            </section>
            <section
               title="Remote Timing Attacks">
               <t>In some cases it might be possible to extract private keys
                  using a remote timing attack <xref
                     target="BONEH03"/>. Implementations SHOULD obfuscate the
                  timing to prevent such attacks.</t>
            </section>
            <section
               title="Reordered Header Fields">
               <t>Existing standards allow intermediate MTAs to reorder Header
                  fields. If a signer signs two or more Header fields of the
                  same name, this can cause spurious verification errors on
                  otherwise legitimate messages. In particular, signers that
                  sign any existing DOSETA&nbhy;Signature fields run the risk
                  of having messages incorrectly fail to verify.</t>
            </section>
            <section
               title="RSA Attacks">
               <t>An attacker could create a large RSA signing key with a
                  small exponent, thus requiring that the verification key
                  have a large exponent. This will force verifiers to use
                  considerable computing resources to verify the signature.
                  Verifiers might avoid this attack by refusing to verify
                  signatures that reference selectors with public keys having
                  unreasonable exponents.</t>
               <t>In general, an attacker might try to overwhelm a verifier by
                  flooding it with data requiring verification. This is
                  similar to other server denial-of-service attacks and needs
                  to be dealt with in a similar fashion.</t>
            </section>
            <section
               title="Inappropriate Signing by Parent Domains">
               <t>The trust relationship described in <xref
                     target="parentsig"/> could conceivably be used by a
                  parent domain to sign messages with identities in a
                  subdomain not administratively related to the parent. For
                  example, the ".com" registry could create messages with
                  signatures using an "i=" value in the example.com domain.
                  There is no general solution to this problem, since the
                  administrative cut could occur anywhere in the domain name.
                  For example, in the domain "example.podunk.ca.us" there are
                  three administrative cuts (podunk.ca.us, ca.us, and us), any
                  of which could create messages with an identity in the full
                  domain. <list
                     style="hanging">
                     <t
                        hangText="NOTE:  ">This is considered an acceptable
                        risk for the same reason that it is acceptable for
                        domain delegation. For example, in the example above
                        any of the domains could potentially simply delegate
                        "example.podunk.ca.us" to a server of their choice and
                        completely replace all DNS-served information. Note
                        that a verifier MAY ignore signatures that come from
                        an unlikely domain such as ".com", as discussed in <xref
                           target="validatesig"/>.</t>
                  </list>
               </t>
            </section>

            <section
               title="Attacks Involving Addition of Header Fields">
               <t>Many email implementations do not enforce <xref
                     target="RFC5322"/> with strictness. As discussed in <xref
                     target="normalize"/> DOSETA processing is predicated on a
                  valid mail message as its input. However, DOSETA
                  implementers need to be aware of the potential effect of
                  having loose enforcement by email components interacting
                  with DOSETA modules.</t>
               <t>For example, a message with multiple From: Header fields
                  violates Section 3.6 of <xref
                     target="RFC5322"/>. With the intent of providing a better
                  user experience, many agents tolerate these violations and
                  deliver the message anyway. An MUA then might elect to
                  render to the user the value of the last, or "top", From:
                  field. This might also be done simply out of the expectation
                  that there is only one, where a "find first" algorithm would
                  have the same result. Such code in an MUA can be exploited
                  to fool the user if it is also known that the other From:
                  field is the one checked by arriving message filters. Such
                  is the case with DOSETA; although the From: field MUST be
                  signed, a malformed message bearing more than one From:
                  field might only have the first ("bottom") one signed, in an
                  attempt to show the message with some "DOSETA passed"
                  annotation while also rendering the From: field that was not
                  authenticated. (This can also be taken as a demonstration
                  that DOSETA is not designed to support author validation.) </t>
               <t>To resist this specific attack the signed header field list
                  can include an additional reference for each field that was
                  present at signing. For example, a proper message with one
                  From: field could be signed using "h=From:From:..." Due to
                  the way header fields are canonicalized for input to the
                  hash function, the extra field references will prevent
                  instances of the cited fields from being added after
                  signing, as doing so would render the signature invalid. </t>
               <t>The From: field is used above to illustrate this issue, but
                  it is only one of > several fields that Section 3.6 of <xref
                     target="RFC5322"/> constrains in this way. In reality any
                  agent that forgives malformations, or is careless about
                  identifying which parts of a message were authenticated, is
                  open to exploitation.</t>
            </section>

         </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="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="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="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="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="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="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="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="RFC4871">
            <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>
      </references>




      <section
         anchor="createpkey"
         title="Creating a Public Key {rfc4871bis-02 C}">
         <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="RFC4871"/>.</t>
      </section>
   </back>
</rfc>
