<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="no"?>

<?rfc tocindent="yes"?>

<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<?rfc inline="yes"?>

<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>



<rfc category="info" docName="draft-crocker-strint-workshop-messaging-00" ipr="trust200902">
   <front>
      <title abbrev="STRINT: Opportunistic Messaging Privacy">STRINT Workshop Position Paper: Levels
         of Opportunistic Privacy Protection for Messaging-Oriented Architectures</title>
      <author fullname="Dave Crocker" initials="D." surname="Crocker">
         <organization>Brandenburg InternetWorking</organization>
         <address>
            <postal>
               <street>675 Spruce Drive</street>
               <city>Sunnyvale</city>
               <region>CA</region>
               <code>94086</code>
               <country>USA</country>
            </postal>
            <phone>+1.408.246.8253</phone>
            <email>dcrocker@bbiw.net</email>
         </address>
      </author>
      <author fullname="Pete Resnick" initials="P." surname="Resnick">
         <organization>Qualcomm Technologies, Inc.</organization>

         <address>
				<postal>
					<street>5775 Morehouse Drive</street>
					<city>San Diego</city>
					<region>CA</region>
					<country>US</country>
					<code>92121</code>
				</postal>
				<phone>+1 858 6511 4478</phone>
				<email>presnick@qti.qualcomm.com</email>
			</address>
      </author>
      <date day="" month="" year="2014" />
      <area />
      <workgroup />
      <keyword />
      <abstract>
         <t>Given a concern for pervasive monitoring, messaging information needing protection
            includes primary payload, descriptive meta-data, and traffic-related analysis. Complete
            protection against pervasive monitoring (PM), for traffic through complex handling
            sequences, has not yet been achieved reliably in real-world operation. Consequently, it
            is reasonable to consider a range of mechanisms, for protecting differing amounts of
            information and against monitoring of different kinds. Although channel-based encryption
            can be helpful, it is not sufficient. This paper considers pursuing different levels of
            end-to-end protection, referencing examples of component mechanisms that already have
            encouraging field experience.</t>
      </abstract>
   </front>
   <middle>


      <section title="Background">

         <t>Concern for pervasive monitoring motivates the deployment of strong mechanisms that will
            protect against intrusive disclosure of information. Information needing protection can
            be primary payload, descriptive meta-data, or traffic-related analysis. Most Internet
            services operate according to a relatively simple, two-party client/server model, with
            the server holding primary data and performing primary actions, and the user having a
            direct relationship with the service being provided. For these arrangements, concerns
            over privacy violations tend to focus on wiretapping of the data transfer mechanism and
            on server compromise.</t>

         <t> In contrast messaging architectures, such as for email <xref target="MAILARCH" />, can
            be highly distributed, with any number of application-level store-and-forward
            intermediaries. This can produce complex sequences through many independent
            administrative authorities, possibly unknown to either the user or the recipient.
            Because multi-hop store-and-forward messaging can involve several systems not under the
            administrative control of either end of the messaging transaction, compromise of any of
            the intermediate systems can expose messages to monitoring past the first, or before the
            last, hop. Therefore end-to-end encryption is still highly desirable. Key distribution
            and validation is one of the greatest impediments to deployment.</t>

         <t> Current multi-hop store-and-forward messaging on the Internet uses primarily two
            security technologies: <list style="numbers">
               <t>Channel encryption between the submitter and its submission server and final
                  recipient and its receiving server, respectively, that encryption generally
                  relying on CAs for authentication; and</t>
               <t>End-to-end content encryption that relies on pre-authenticated certificates
                  available to the end-points.</t>

            </list> The former is used, but does not provide sufficient protection against certain
            kinds of pervasive monitoring, and the latter is rarely used because of deployment and
            use barriers. More opportunistic mechanisms might have a higher likelihood of
            deployment, with minimal effect on services, and therefore should be attempted. Further
            if these opportunistic mechanisms do gain success, they can be used for further
            minimization of some forms of abuse.</t>

         <t> Complete protection against pervasive monitoring (PM), for traffic through complex
            handling sequences, has not yet been achieved reliably in real-world operation.
            Consequently, it is reasonable to consider a range of mechanisms, for protecting
            differing amounts of information and against monitoring of different kinds. The premises
            are that one or more of these might prove more effective than others and that some
            protection is better than none. </t>

         <t> Given the scale and urgency of community need for this protection, mechanisms should be
            based on established technologies, where possible. While innovation is needed, it should
            be kept as modest as possible. So the major challenge should be system design, rather
            than component invention, where possible and practical.</t>

         <t> There are four types of data to be considered for protection in a distributed messaging
            architecture: <list style="symbols">
               <t>Message Content</t>
               <t>Header Content</t>
               <t>Envelope meta-data</t>
               <t>Handling meta-data</t>
            </list> Message content is considered the primary payload; for email this is the body of
            the message. However messaging often contains additional content in a header, such as
            the names and addresses of authors and recipient, content summary, such as a Subject
            field, date of posting, and so on. Envelope meta-data is the information used by the
            transit service, including recipient and return addresses. Handling information is
            created during transit, such as for recording processing tags by intermediaries. The
            placement of these bits of information can vary, so that distinguishing among them can
            sometimes be confusing. As an example email relay handling meta-data is placed into the
            message header.</t>

         <t> Almost all efforts to protect messages have focused on the primary message content,
            with two well-known capabilities being standardized. <xref target="OPENPGP" /><xref
               target="SMIME" /> However after twenty-five years of these efforts to protect
            messages that are in transit, nearly all such traffic is still sent in the clear. </t>

         <t> In the absence of a success scenario for end-to-end payload privacy protection, it is
            not possible to be certain which barriers are critical, nor how to overcome them. In
            current discussions, the primary culprits are believed to be key administration and end
            user interface design and performance complexity. Both are deemed to require too much
            human effort, and a common view is to essentially remove humans from needing to
            configure their services or choose to use them.</t>

         <t> Channel encryption is low-hanging fruit when it comes to messaging security, though it
            only offers minimal protections against pervasive monitoring in its current use. Right
            now, messaging-related channel encryption is almost exclusively used between end clients
            and their directly-associated servers, mostly for purposes of protecting the login
            credentials from monitoring. It does result in clear message contents also being
            protected from snooping on the channel between the end client and server, and it
            protects envelope information (which is not otherwise protected by end-to-end content
            encryption.) However this protection only operates for the first and last message hops
            and leaves intermediate hops unprotected. So the addition of channel security at every
            hop is still desirable. Authentication can be recorded in the envelope if it takes
            place, presumably in a way that allows the recipient to confirm that the authentication
            took place, but authentication is not necessary for a large increase in security. For
            intermediate hops opportunistic encryption would be a significant improvement and would
            be deemed sufficient for most cases. The intermediate servers can simply do key exchange
            in-band. </t>

      </section>

      <section title="Incremental End-to-End Protection">

         <t>Channel encryption can not protect against some of the PM activities that have been
            documented. So the more challenging concern is protection against collaborating or
            compromised intermediate nodes and even source and destination servers. Ideally
            protection therefore must be end-to-end, defined in terms of the author's and
            recipient's independent user agents. The difficulty of achieving this is exacerbated by
            the degree of existing Internet messaging activity that has all user agent behavior on,
            or controlled by, end-system web servers, rather than by independent software that is
            solely under the control of the author or recipient. Hence the best end-to-end
            protection that will be achievable for many users is between originating server and
            receiving server. </t>

         <t> This highlights the need for incremental mechanisms that provide increasing protection.
            Greater user independence should be able to permit greater user protection. Another
            benefit of this incremental approach is that it is likely to provide some useful
            protection while still permitting exposure information necessary to legitimate
            management. Of course, balancing between protecting against problematic monitoring and
            facilitating legitimate monitoring (management) requires agreement on the trade-offs and
            explicit choices amongst them. The discussion and agreement remain an open and
            challenging task.</t>

         <t> An observation about focusing on PM protection is that use of encryption for that
            purpose does not necessarily carry the usual, accompanying requirement for strong
            authentication of one or both principals in the interaction. In the extreme, this might
            mean that typical man-in-the-middle scenarios are not a concern, but it also can mean
            that authentication related to an agent -- rather than to the user -- is sufficient. </t>

         <t> This well might permit opportunistic privacy protection without direct user
            involvement, possibly with unauthenticated encryption and no human configuration, and
            for authentication to take place as a separate piece of user interface when that is
            desirable. To the extent that human involvement is needed for the basic setup, it might
            be limited to service administrators, rather than end users. The obvious appeal of this
            is that there are orders of magnitude fewer administrators than there are users, and
            administrators typically have far more technical skill.</t>

         <t> Key discovery is the most significant challenge during operation of a protection
            mechanism. A promising approach that already has some field experience achieves key
            distribution through the <xref target="DNS" />. The core requirement, of course, is
            determining what domain name to query. The most obvious choice in a messaging service is
            the domain name of the recipient's address. Enhancing this to permit DNS queries on an
            entire email address would be the refinement to attempt. </t>

         <t> A DNS-based mechanism would facilitate query, but would not deal with key
            administration. Although there is activity in this space, easy key generation remain an
            open issue for the Internet. However note that by making the critical actors for this
            service be operators, the scale of this challenge is dramatically smaller than if end
            users need to be involved.</t>

         <t> Given a basic key-discovery ability, the question then is what to encrypt? Simply
            encrypting a message body is appealing, but leaves exposed all of the message header, as
            well as associated handling and envelope information. This is where the "levels"
            reference in the paper's title comes in. Additional mechanisms or services can protect
            increasing amounts of message-related information. However, a pragmatic basis for
            choosing different levels is likely to prove challenging, since users cannot be relied
            on to make such decision. Still it will be worth pursuing an activity to describe the
            choices. Essentially, they are: <list style="symbols">
               <t>Content</t>
               <t>Content + Header</t>
               <t>Content + Header + Envelope</t>
            </list></t>

         <t> For email, one challenge in encrypting the message header is that the header is
            modified in transit. A plausible approach is to encapsulate the original message as a
               <xref target="MIME" /> attachment, so that the visible message header is only a form
            of envelope. </t>

         <t> In order to obscure the origin/receiver envelope information, the message in transit
            needs to use different envelope data. Given that the information is essential to message
            transit, this will require an overlay relay service, designed to hide actual
            author/recipient information. It is worth considering enhancements, to integrate it more
            seamlessly for well-motivated users.</t>

      </section>


      <section title="Exemplars to Demonstrate Feasibility">


         <t>Although it is easy to offer appealing design ideas, estimating their real-world
            feasibility and utility can be challenging. This paper is not intended to formulate
            detailed solutions, but it does need to provide some basis for comfort with the basic
            approaches it suggests. The discussion in this section is therefore intended to provide
            some substance, to that end.</t>

         <t>Rather than consider whether a detail discussed in this section is good or bad, or
            whether one approach is better or worse than another, the reader is encouraged merely to
            review the examples in terms of existing deployment experience and the likely pragmatics
            of incremental engineering and operations that is described. While it is likely that
            superior designs can be specified, the requirement now is to develop a reasonable degree
            of comfort that the basic approaches are plausible.</t>


         <section title="Administrators vs. Users">
            <t>There is considerable field experience with the difference between the administrative
               skills of professional operators, versus end-users. With respect to key
               administration, specific examples include <xref target="DNSSEC" /> and <xref
                  target="DKIM" />. The experience shows that key administration tends to be
               daunting even for professionals, but is infeasible for most end users.</t>
            <t>A related point is the greater deployment and use success that is likely when
               providing protection between servers rather than between end-users. An exemplar of
               this approach being successful for a security mechanism is <xref target="DKIM" /> as
               compared against the problematic deployment histories of <xref target="OPENPGP" />
               and <xref target="SMIME" />. However the obvious concern is that the end-users must
               rely on the safety of their server operations.</t>
         </section>

         <section title="Key Discovery">

            <t>Key discovery through the DNS already has several examples, including <xref
                  target="DNSSEC" />, <xref target="DANE" /> and <xref target="DKIM" />. In the
               aggregate they demonstrate that this basic approach is operationally reasonable.</t>
         </section>

         <section title="Per-User Keys">
            <t>The history of per-user key administration is particularly disheartening. To the
               extent that key discovery via domain names has established a strong proof of concept,
               it is appealing to consider extending it to the granularity of complete email
               addresses. Although there have been some attempts at doing this, they gained no
               large-scale traction. </t>

            <t> Historically, there has been a basic incompatibility between email address encoding
               and domain name encoding. A domain name is an undifferentiated sequence, whereas an
               email address is structured into two, semantically-distinct parts (separated by the
               "@" sign.) A recent, popular enhancement to DNS naming is the use of an
               underscore-based node name, such as <xref target="SRVDNS" /> for information that
               does not need to be treated as a hostname. The application of this enhancement could
               produce a query name in the style of: <figure>
                  <artwork align="center">Mailbox._at.example.net</artwork>
               </figure> Hence, key query would be for a domain name, where the name might be a
               hostname or might be an encoded email address. Although this would be a new
               mechanism, it entails no enhancement to infrastructure services and it re-uses a
               well-established and reasonably inexpensive form of DNS-based mechanism.</t>
         </section>

         <section title="Message Encapsulation">
            <t>Protecting the message header means that it needs to be hidden during transit, in
               spite of the header's being modified in transit, for email. One approach to solving
               this is to encapsulate the entire message as a MIME attachment; the visible header
               therefore would only contain handling information. This model of encapsulation only
               requires adoption by author (or originating server) and recipient (or receiving
               server) and is transparent to the message-handling infrastructure. Architecturally,
               it is identical with the way MIME was propagated, in the 1990s, so it's viability has
               been well demonstrated. Also, encapsulating an entire message as an attachment has
               already been enabled through <xref target="BSMTP" />.</t>
         </section>

         <section title="Protecting Envelope Meta-Data">
            <t>If envelope data is to be hidden during transit, it must be encapsulated in a message
               with different envelope data, and processed by special, trusted relays that hide
               addressing and transit information, and ensure that none is associated with the
               message when it is finally delivered. This is in the spirit of <xref target="TOR"
                />.</t>
         </section>

      </section>


      <section title="Security Considerations">
         <t>Everything in this draft related to security, and especially to confidentiality in the
            service of privacy protection.</t>
      </section>

      <section title="IANA Considerations">
         <t>There are no IANA considerations for this draft.</t>
         <t>Note to RFC Editor: Please remove the entire IANA Considerations section, prior to
            publication</t>
      </section>
   </middle>
   <back>
      <references title="References - Informative">
         <reference anchor="BSMTP">
            <front>
               <title abbrev="Batch SMTP Media Type">The Batch SMTP Media Type</title>
               <author fullname="Ned Freed" initials="N." surname="Freed">
                  <organization>Innosoft International, Inc.</organization>
                  <address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country></postal>
<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email></address>
               </author>
               <author fullname="Dan Newman" initials="D." surname="Newman">
                  <organization>Innosoft International, Inc.</organization>
                  <address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country></postal>
<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>dan.newman@innosoft.com</email></address>
               </author>
               <author fullname="Mark Hoy" initials="M." surname="Hoy">
                  <organization>Mainbrace Corporation</organization>
                  <address>
<postal>
<street>1136 West Evelyn Avenue</street>
<street>Sunnyvale</street>
<street>CA 94086</street></postal>
<phone>+1 408 774 5265</phone>
<facsimile>+1 408 774 5290</facsimile>
<email>mark.hoy@mainbrace.com</email></address>
               </author>
               <author>
                  <organization />
                  <address>
<email>jacques.belissent@eng.sun.com</email></address>
               </author>
               <date month="November" year="1998" />
               <area>Applications</area>
               <keyword>content-type</keyword>
               <keyword>media type</keyword>
               <keyword>multipurpose internet mail extensions</keyword>
               <keyword>security</keyword>
               <keyword>simple mail transfer protocol</keyword>
               <keyword>tunnel</keyword>
               <abstract>
                  <t> This document defines a MIME content type suitable for tunneling an ESMTP
                     [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type
                     can be used for a variety of purposes, including: Extending end-to-end
                     MIME-based security services (e.g., ) to cover message envelope information as
                     well as message content. Making it possible to use specific SMTP extensions
                     such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure.
                     Enabling the transfer of multiple separate messages in a single transactional
                     unit. </t>
               </abstract>
            </front>
            <seriesInfo name="RFC" value="2442" />
         </reference>

         <reference anchor="DANE">

            <front>
               <title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security
                  (TLS) Protocol: TLSA</title>
               <author fullname="P. Hoffman" initials="P." surname="Hoffman">
                  <organization />
               </author>
               <author fullname="J. Schlyter" initials="J." surname="Schlyter">
                  <organization />
               </author>
               <date month="August" year="2012" />
               <abstract>
                  <t>Encrypted communication on the Internet often uses Transport Layer Security
                     (TLS), which depends on third parties to certify the keys used. This document
                     improves on that situation by enabling the administrators of domain names to
                     specify the keys used in that domain's TLS servers. This requires matching
                     improvements in TLS client software, but no change in TLS server software.
                     [STANDARDS-TRACK]</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="6698" />
            <format octets="84034" target="http://www.rfc-editor.org/rfc/rfc6698.txt" type="TXT" />
         </reference>

         <reference anchor="DKIM">

            <front>
               <title>DomainKeys Identified Mail (DKIM) Signatures</title>
               <author fullname="D. Crocker" initials="D." surname="Crocker">
                  <organization />
               </author>
               <author fullname="T. Hansen" initials="T." surname="Hansen">
                  <organization />
               </author>
               <author fullname="M. Kucherawy" initials="M." surname="Kucherawy">
                  <organization />
               </author>
               <date month="September" year="2011" />
               <abstract>
                  <t>DomainKeys Identified Mail (DKIM) permits a person, role, or organization that
                     owns the signing domain to claim some responsibility for a message by
                     associating the domain with the message. This can be an author's organization,
                     an operational relay, or one of their agents. DKIM separates the question of
                     the identity of the Signer of the message from the purported author of the
                     message. Assertion of responsibility is validated through a cryptographic
                     signature and by querying the Signer's domain directly to retrieve the
                     appropriate public key. Message transit from author to recipient is through
                     relays that typically make no substantive change to the message content and
                     thus preserve the DKIM signature.&lt;/t>&lt;t> This memo obsoletes RFC 4871 and
                     RFC 5672. [STANDARDS-TRACK]</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="6376" />
            <format octets="176999" target="http://www.rfc-editor.org/rfc/rfc6376.txt" type="TXT" />
         </reference>

         <reference anchor="DNS">
            <front>
               <title abbrev="Domain Concepts and Facilities">Domain names - concepts and
                  facilities</title>
               <author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
                  <organization>Information Sciences Institute (ISI)</organization>
               </author>
               <date day="1" month="November" year="1987" />
            </front>

            <seriesInfo name="STD" value="13" />
            <seriesInfo name="RFC" value="1034" />
            <format octets="129180" target="http://www.rfc-editor.org/rfc/rfc1034.txt" type="TXT" />
         </reference>

         <reference anchor="DNSSEC">

            <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="MAILARCH">
            <front>
               <title>Internet Mail Architecture</title>
               <author fullname="D. Crocker" initials="D." surname="Crocker">
                  <organization />
               </author>
               <date month="July" year="2009" />
               <abstract>
                  <t>Over its thirty-five-year history, Internet Mail has changed significantly in
                     scale and complexity, as it has become a global infrastructure service. These
                     changes have been evolutionary, rather than revolutionary, reflecting a strong
                     desire to preserve both its installed base and its usefulness. To collaborate
                     productively on this large and complex system, all participants need to work
                     from a common view of it and use a common language to describe its components
                     and the interactions among them. But the many differences in perspective
                     currently make it difficult to know exactly what another participant means. To
                     serve as the necessary common frame of reference, this document describes the
                     enhanced Internet Mail architecture, reflecting the current service. This memo
                     provides information for the Internet community.</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="5598" />
            <format octets="115741" target="http://www.rfc-editor.org/rfc/rfc5598.txt" type="TXT" />
            <format octets="342738" target="http://www.rfc-editor.org/rfc/rfc5598.pdf" type="PDF" />
         </reference>

         <reference anchor="MIME">
            <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 message
                     content, or message body, 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 headers 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, RFC 2049, 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="OPENPGP">
            <front>
               <title>OpenPGP Message Format</title>
               <author fullname="J. Callas" initials="J." surname="Callas">
                  <organization />
               </author>
               <author fullname="L. Donnerhacke" initials="L." surname="Donnerhacke">
                  <organization />
               </author>
               <author fullname="H. Finney" initials="H." surname="Finney">
                  <organization />
               </author>
               <author fullname="D. Shaw" initials="D." surname="Shaw">
                  <organization />
               </author>
               <author fullname="R. Thayer" initials="R." surname="Thayer">
                  <organization />
               </author>
               <date month="November" year="2007" />
               <abstract>
                  <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.&lt;/t>&lt;t> OpenPGP 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. [STANDARDS-TRACK]</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="4880" />
            <format octets="203706" target="http://www.rfc-editor.org/rfc/rfc4880.txt" type="TXT" />
         </reference>


         <reference anchor="SMIME">
            <front>
               <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
                  Specification</title>
               <author fullname="B. Ramsdell" initials="B." surname="Ramsdell">
                  <organization />
               </author>
               <author fullname="S. Turner" initials="S." surname="Turner">
                  <organization />
               </author>
               <date month="January" year="2010" />
               <abstract>
                  <t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME)
                     version 3.2. 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 3851.
                     [STANDARDS-TRACK]</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="5751" />
            <format octets="98638" target="http://www.rfc-editor.org/rfc/rfc5751.txt" type="TXT" />
         </reference>


         <reference anchor="SRVDNS">
            <front>
               <title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS
                  SRV)</title>
               <author fullname="Arnt Gulbrandsen" initials="A." surname="Gulbrandsen">
                  <organization>Troll Tech</organization>
                  <address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address>
               </author>
               <author fullname="Paul Vixie" initials="P." surname="Vixie">
                  <organization>Internet Software Consortium</organization>
                  <address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address>
               </author>
               <author fullname="Levon Esibov" initials="L." surname="Esibov">
                  <organization>Microsoft Corporation</organization>
                  <address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address>
               </author>
               <date month="February" year="2000" />
               <abstract>
                  <t>This document describes a DNS RR which specifies the location of the server(s)
                     for a specific protocol and domain.</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="2782" />
            <format octets="24013" target="http://www.rfc-editor.org/rfc/rfc2782.txt" type="TXT" />
         </reference>


         <reference anchor="TLS">
            <front>
               <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
               <author fullname="T. Dierks" initials="T." surname="Dierks">
                  <organization />
               </author>
               <author fullname="E. Rescorla" initials="E." surname="Rescorla">
                  <organization />
               </author>
               <date month="August" year="2008" />
               <abstract>
                  <t>This document specifies Version 1.2 of the Transport Layer Security (TLS)
                     protocol. The TLS protocol provides communications security over the Internet.
                     The protocol allows client/server applications to communicate in a way that is
                     designed to prevent eavesdropping, tampering, or message forgery.
                     [STANDARDS-TRACK]</t>
               </abstract>
            </front>

            <seriesInfo name="RFC" value="5246" />
            <format octets="222395" target="http://www.rfc-editor.org/rfc/rfc5246.txt" type="TXT" />
         </reference>


         <reference anchor="TOR">
            <front>
               <title>TOR Project</title>
               <author />
               <date />

            </front>
            <seriesInfo name="WEB" value="https://www.torproject.org/" />
         </reference>

      </references>



   </back>
</rfc>
