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