One document matched: draft-thomson-http-mice-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>
<rfc ipr="trust200902" docName="draft-thomson-http-mice-00" category="std">
<front>
<title abbrev="MICE">Merkle Integrity Content Encoding</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2016"/>
<area>General</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This memo introduces a content-coding for HTTP that provides progressive
integrity for message contents. This integrity protection can be evaluated on a
partial representation, allowing a recipient to process a message as it is
delivered while retaining strong integrity protection. The integrity protection
can optionally be authenticated with a digital signature.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Integrity protection for HTTP content is often necessary. HTTPS <xref target="RFC2818"></xref> is
the most common form of integrity protection deployed, but that requires a
direct TLS <xref target="RFC5246"></xref> connection to a host. However, additional integrity
protection is often desirable. This might be for additional protection against
failures (e.g., <xref target="SRI"></xref>) or because content needs to traverse multiple
HTTPS-protected exchanges.</t>
<t>This document describes a “mi-sha256” content-encoding (see <xref target="encoding"/>) that
embeds a progressive, hash-based integrity check based on Merkle Hash Trees
<xref target="MERKLE"></xref>. This integrity scheme optionally supports including a digital
signature over the integrity value.</t>
<t>The means of conveying the root proof used by this content encoding will depend
on the requirements for deployment. This document defines an MI header field
(see <xref target="header"/>) that can carry an integrity proof or signatures over the proof.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<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"></xref>.</t>
</section>
</section>
<section anchor="encoding" title="The “mi-sha256” HTTP Content Encoding">
<t>A Merkle Hash Tree <xref target="MERKLE"></xref> is a structured integrity mechanism that collates
multiple integrity checks into a tree. The leaf nodes of the tree contain data
(or hashes of data) and non-leaf nodes contain hashes of the nodes below them.</t>
<t>A balanced Merkle Hash Tree is used to efficiently prove membership in large
sets (such as in <xref target="RFC6962"></xref>). However, in this case, a right-skewed tree is used
to provide a progressive integrity proof. This integrity proof is used to
establish that a given record is part of a message.</t>
<t>The hash function used for “mi-sha256” content encoding is SHA-256 <xref target="FIPS180-4"></xref>.
The integrity proof for all records other than the last is the hash of the
concatenation of the record, the integrity proof of all subsequent records, and
a single octet with a value of 0x1:</t>
<figure><artwork><![CDATA[
proof(r[i]) = r[i] || proof(r[i+1]) || 0x1
]]></artwork></figure>
<t>The integrity proof for the final record is the hash of the record with a single
octet with a value 0x0 appended:</t>
<figure><artwork><![CDATA[
proof(r[last]) = r[last] || 0x0
]]></artwork></figure>
<t><xref target="ex-proofs"/> shows the structure of the integrity proofs for a message that is
split into 4 blocks: A, B, C, D). As shown, the integrity proof for the entire
message (that is, <spanx style="verb">proof(A)</spanx>) is derived from the content of the first block
(A), plus the value of the proof for the second and subsequent blocks.</t>
<figure title="Proof structure for a message with 4 blocks" anchor="ex-proofs"><artwork><![CDATA[
proof(A)
/\
/ \
/ \
A proof(B)
/\
/ \
/ \
B proof(C)
/\
/ \
/ \
C proof(D)
|
|
D
]]></artwork></figure>
<t>The final encoded message is formed from the first record, followed by an
arbitrary number of tuples of the integrity proof of the next record and then
the record itself. Thus, in <xref target="ex-proofs"/>, the body is:</t>
<figure><artwork><![CDATA[
A || proof(B) || B || proof(C) || C || proof(D) || D
]]></artwork></figure>
<t>A message that has a content length less than or equal to the content size does
not include any inline proofs. The proof for a message with a single record is
simply the hash of the body plus a trailing zero octet.</t>
<section anchor="records" title="Content Encoding Structure">
<t>In order to produce the final content encoding the content of the message is
split into equal-sized records. The final record can contain less than the
defined record size.</t>
<t>The default record size for the “mi-sha256” content encoding is 4096 octets.
This refers to the length of each data block. The MI header field MAY contain
an “rs” parameter that describes a different record size.</t>
<t>The final encoded stream comprises of a record (“rs” octets in length), followed
by the proof for the following record (32 octets). This allows a receiver to
validate and act upon each record after receiving the proof that follows it.
The final record is not followed by a proof.</t>
<t><list style="hanging">
<t hangText='Note:'>
This content encoding increases the size of a message by 32 octets times the
length of the message divided by the record size, rounded up, less one. That
is, 32 * (ceil(length / rs) - 1).</t>
</list></t>
<t>Constructing a message with the “mi-sha256” content encoding requires processing
of the records in reverse order, inserting the proof derived from each record
before that record.</t>
<t>This structure permits the use of range requests <xref target="RFC7233"></xref>. However, to validate
a given record, a contiguous sequence of records back to the start of the
message is needed.</t>
</section>
<section anchor="validating-integrity-proofs" title="Validating Integrity Proofs">
<t>A receiver of a message with the “mi-sha256” content-encoding applied first
attempts to acquire the integrity proof for the first record. If the MI header
field is present, a value might be included there.</t>
<t>Then, the message is read into records of size “rs” (based on the value in the
MI header field) plus 32 octets. For each record:</t>
<t><list style="numbers">
<t>Hash the record using SHA-256 with a single octet appended. All records
other than the last have an octet with value 0x1 appended, and the last
record (which will be between 1 and “rs” octets in length) has an octet with
value 0x0 appended.</t>
<t>For the first record: <list style="numbers">
<t>If a signature is known for the integrity proof for the first record and
the receiver is configured to validate a signature for this message, then
the signature is validated with the output of the hash as the signed
message. If this check passes, then the signature applies to the entire
message if subsequent checks succeed.</t>
<t>If the integrity proof for the first record is known, the integrity check
passes if the output of SHA-256 is identical to the known value.</t>
<t>If an integrity proof for the first record is not available, treat the
message as not having integrity protection.</t>
</list></t>
<t>For all other records, check if the output of SHA-256 is equal to the
expected value, then the integrity check passes. The expected value is the
last 32 octets of the previous record.</t>
</list></t>
<t>If an integrity check fails, the message SHOULD be discarded and the exchange
treated as an error unless explicitly configured otherwise. For clients, treat
this as equivalent to a server error; servers SHOULD generate a 400 status code.
However, if the integrity proof for the first record is not known, this check
SHOULD NOT fail unless explicitly configured.</t>
</section>
</section>
<section anchor="header" title="The MI HTTP Header Field">
<t>The MI HTTP header field describes the message integrity content encoding(s)
that have been applied to a payload body, and therefore how those content
encoding(s) can be removed.</t>
<t>The MI header field uses the extended ABNF syntax defined in Section 1.2 of
<xref target="RFC7230"></xref> and the <spanx style="verb">parameter</spanx> rule from <xref target="RFC7231"></xref>:</t>
<figure><artwork><![CDATA[
MI = #mi_params
mi_params = [ parameter *( ";" parameter ) ]
]]></artwork></figure>
<t>If the payload is encoded more than once (as reflected by having multiple
content-codings that use the message integrity header field), each application
of the content encoding is reflected in the MI header field in the order in
which they were applied.</t>
<t>The MI header MAY be omitted if the sender intends for the receiver to acquire
the integrity proof for the first record by other means.</t>
<section anchor="mi-header-field-parameters" title="MI Header Field Parameters">
<t>The following parameters are used in validating content encoded with the
“mi-sha256” content encoding:</t>
<t><list style="hanging">
<t hangText='p:'>
The “p” parameter carries an integrity proof for the first record of the
message. This provides integrity for the entire message body. This value is
encoded using Base 64 Encoding with URL and Filename Safe Alphabet (Section 5
of <xref target="RFC4648"></xref>) with no padding.</t>
<t hangText='p256ecdsa:'>
The “p256ecdsa” parameter carries an ECDSA signature over the integrity proof
for the first record of the message using P-256 <xref target="FIPS186"></xref> encoded as defined
in <xref target="X9.62"></xref> then further encoded using Base 64 Encoding with URL and Filename
Safe Alphabet (Section 5 of <xref target="RFC4648"></xref>) with no padding. If the receiver is
expected to validate this signature, the “p” parameter MAY be ignored and
omitted. Note that this document doesn’t describe how a receiver might
determine that a particular key is acceptable.
The input to the signature is the UTF-8 encoded string “MI: p256ecdsa”, a
single zero-valued octet, and the integrity proof for the first record. That
is:</t>
</list></t>
<figure><artwork><![CDATA[
SignInput = "MI: p256ecdsa" || 0x0 || proof(r[0])
]]></artwork></figure>
<t>Multiple values of this parameter might be provided. If the “keyid” parameter
is used to identify a key for each of these, the first “keyid” parameter to
precede the “p256ecdsa” parameter is used.</t>
<t><list style="hanging">
<t hangText='keyid:'>
The “keyid” parameter optionally identifies the key that was used to generate
a signature.</t>
<t hangText='rs:'>
The “rs” parameter contains a positive decimal integer that describes the
record size in octets. This value MUST be greater than 0. If the “rs”
parameter is absent, the record size defaults to 4096 octets.</t>
</list></t>
</section>
</section>
<section anchor="examples" title="Examples">
<section anchor="simple-example" title="Simple Example">
<t>The following example contains a short message. This contains just a single
record, so there are no inline integrity proofs, just a single value in a MI
header field.</t>
<figure><artwork><![CDATA[
HTTP/1.1 200 OK
MI: p=dcRDgR2GM35DluAV13PzgnG6-pvQwPywfFvAu1UeFrs
Content-Length: 41
When I grow up, I want to be a watermelon
]]></artwork></figure>
</section>
<section anchor="signature-example" title="Signature Example">
<t>The following example includes a signature over the integrity proof for the
first record. The public key for the signer is included in a Crypto-Key header
field <xref target="I-D.ietf-httpbis-encryption-encoding"></xref> using the uncompressed form
<xref target="X9.62"></xref>. The example shows the value for the integrity proof in the MI header
field, but this could be omitted if the client anticipates that the server will
verify the signature.</t>
<figure><artwork><![CDATA[
PUT /test HTTP/1.1
Host: example.com
Crypto-Key: keyid=x;
p256ecdsa=BIy6-8mZ48aKJpB54By_dK0pTv94s86yIVef6JhEC_bS
Q-AnXQMX1oYG9dmCeezgJsmzQo52qJbfJEzIXpZiBSA
MI: rs=16;
p=IVa9shfs0nyKEhHqtB3WVNANJ2Njm5KjQLjRtnbkYJ4;
p256ecdsa=3pXnQrynYwnAW2T86MHel0bd6VgidWdQgb4SPGbxGGo
vemyiAdgNx5cKYkNSgz4c3vSGFt6_UoF2GLhWRePJeA
Content-Length: 105
When I grow up,
OElbplJlPK-Rv6JNK6p5_515IaoPoZo-2elWL7OQ60A
I want to be a w
iPMpmgExHPrbEX3_RvwP4d16fWlK4l--p75PUu_KyN0
atermelon
]]></artwork></figure>
<t>The example shows the same message as above, but with a smaller record size (16
octets). This results in two integrity proofs being included in the
representation.</t>
<t>Since the inline integrity proofs contain non-printing characters, these are
shown here using the Base 64 Encoding with URL and Filename Safe Alphabet
<xref target="RFC4648"></xref> with new lines between the original text and integrity proofs. Note
that there is a single trailing space (0x20) on the first line.</t>
<t>The MI and Crypto-Key header fields are split across several lines to fit
formatting constraints.</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The integrity of an entire message body depends on the means by which the
integrity proof for the first record is protected. If this value comes from the
same place as the message, then this provides only limited protection against
transport-level errors (something that TLS provides adequate protection
against).</t>
<t>Separate protection for header fields might be provided by other means if the
first record retrieved is the first record in the message, but range requests do
not allow for this option.</t>
<section anchor="message-truncation" title="Message Truncation">
<t>This integrity scheme permits the detection of truncated messages. However, it
enables and even encourages processing of messages prior to receiving an
complete message. Actions taken on a partial message can produce incorrect
results. For example, a message could say “I need some 2mm copper cable, please
send 100mm for evaluation purposes” then be truncated to “I need some 2mm copper
cable, please send 100m”. A network-based attacker might be able to force this
sort of truncation by delaying packets that contain the remainder of the
message.</t>
<t>Whether it is safe to act on partial messages will depend on the nature of the
message and the processing that is performed.</t>
</section>
<section anchor="algorithm-agility" title="Algorithm Agility">
<t>A new content encoding type is needed in order to define the use of a hash
function other than SHA-256.</t>
<t>A new parameter name for the MI header field is needed to support new digital
signature algorithms.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<section anchor="the-mi-sha256-http-content-encoding" title="The “mi-sha256” HTTP Content Encoding">
<t>This memo registers the “mi-sha256” HTTP content-coding in the HTTP Content Codings
Registry, as detailed in <xref target="encoding"/>.</t>
<t><list style="symbols">
<t>Name: mi-sha256</t>
<t>Description: A Merkle Hash Tree based content encoding that provides
progressive integrity.</t>
<t>Reference: this specification</t>
</list></t>
</section>
<section anchor="iana-header" title="MI Header Field">
<t>This memo registers the “MI” HTTP header field in the Permanent Message
Header Registry, as detailed in <xref target="header"/>.</t>
<t><list style="symbols">
<t>Field name: MI</t>
<t>Protocol: HTTP</t>
<t>Status: Standard</t>
<t>Reference: this specification</t>
<t>Notes:</t>
</list></t>
</section>
<section anchor="mi-registry" title="The HTTP MI Parameter Registry">
<t>This memo establishes a registry for parameters used by the “MI” header field
under the “Hypertext Transfer Protocol (HTTP) Parameters” grouping. The
“Hypertext Transfer Protocol (HTTP) MI Parameters” registry operates under an
“Specification Required” policy <xref target="RFC5226"></xref>.</t>
<t>Entries in this registry are expected to include the following information:</t>
<t><list style="symbols">
<t>Parameter Name: The name of the parameter.</t>
<t>Purpose: A brief description of the purpose of the parameter.</t>
<t>Reference: A reference to a specification that defines the semantics of the parameter.</t>
</list></t>
<t>The initial contents of this registry are:</t>
<section anchor="p-parameter" title="p parameter">
<t><list style="symbols">
<t>Parameter Name: p</t>
<t>Purpose: The value of the integrity proof for the first record.</t>
<t>Reference: this document</t>
</list></t>
</section>
<section anchor="keyid-parameter" title="keyid parameter">
<t><list style="symbols">
<t>Parameter Name: keyid</t>
<t>Purpose: An identifier for the key that is used for signature over the integrity proof for the first record.</t>
<t>Reference: this document</t>
</list></t>
</section>
<section anchor="p256ecdsa-parameter" title="p256ecdsa parameter">
<t><list style="symbols">
<t>Parameter Name: p256ecdsa</t>
<t>Purpose: An ECDSA signature using P-256 over the integrity proof for the first record.</t>
<t>Reference: this document</t>
</list></t>
</section>
<section anchor="rs-parameter" title="rs parameter">
<t><list style="symbols">
<t>Parameter Name: rs</t>
<t>Purpose: The size of the records used for progressive integrity protection.</t>
<t>Reference: this document</t>
</list></t>
</section>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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. 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='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC4648' target='http://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC5226' target='http://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<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 may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, 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 namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434. 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='26'/>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>
<reference anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>
<reference anchor='RFC7231' target='http://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>
<reference anchor='RFC7233' target='http://www.rfc-editor.org/info/rfc7233'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='Y.' surname='Lafon' fullname='Y. Lafon' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.</t></abstract>
</front>
<seriesInfo name='RFC' value='7233'/>
<seriesInfo name='DOI' value='10.17487/RFC7233'/>
</reference>
<reference anchor="FIPS180-4" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
<front>
<title>NIST FIPS 180-4, Secure Hash Standard</title>
<author initials="National Institute of Standards and Technology, U.S." surname="Department of Commerce" fullname="NIST">
<organization></organization>
</author>
<date year="2012" month="March"/>
</front>
</reference>
<reference anchor="MERKLE" >
<front>
<title>A Digital Signature Based on a Conventional Encryption Function</title>
<author initials="R." surname="Merkle">
<organization></organization>
</author>
<date year="1987"/>
</front>
<seriesInfo name="International Crytology Conference - CRYPTO" value=""/>
</reference>
<reference anchor="FIPS186" >
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="NIST PUB 186-4" value=""/>
</reference>
<reference anchor="X9.62" >
<front>
<title>Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author >
<organization>ANSI</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ANSI X9.62" value=""/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>
<reference anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<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'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>
<reference anchor='RFC6962' target='http://www.rfc-editor.org/info/rfc6962'>
<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'><organization /></author>
<date year='2013' month='June' />
<abstract><t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t><t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6962'/>
<seriesInfo name='DOI' value='10.17487/RFC6962'/>
</reference>
<reference anchor="SRI" target="https://w3c.github.io/webappsec-subresource-integrity/">
<front>
<title>Subresource Integrity</title>
<author initials="D." surname="Akhawe">
<organization></organization>
</author>
<author initials="F." surname="Braun">
<organization></organization>
</author>
<author initials="F." surname="Marier">
<organization></organization>
</author>
<author initials="J." surname="Weinberger">
<organization></organization>
</author>
<date year="2015" month="November" day="13"/>
</front>
<seriesInfo name="W3C CR" value=""/>
</reference>
<reference anchor='I-D.ietf-httpbis-encryption-encoding'>
<front>
<title>Encrypted Content-Encoding for HTTP</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='December' day='23' year='2015' />
<abstract><t>This memo introduces a content-coding for HTTP that allows message payloads to be encrypted.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-encryption-encoding-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-encryption-encoding-00.txt' />
</reference>
</references>
<section anchor="acknowledgements" title="Acknowledgements">
<t>David Benjamin and Erik Nygren both separately suggested that something like
this might be valuable.</t>
</section>
<section anchor="faq" title="FAQ">
<t><list style="numbers">
<t>Why not include the first proof in the encoding? <vspace blankLines='1'/>
The requirements for the integrity proof for the first record require a great
deal more flexibility than this allows for. Transferring the proof
separately is sometimes necessary. Separating the value out allows for that
to happen more easily.</t>
<t>Why do messages have to be processed in reverse to construct them? <vspace blankLines='1'/>
The final integrity value, no matter how it is derived, has to depend on
every bit of the message. That means that there are three choices: both
sender and receiver have to process the whole message, the sender has to work
backwards, or the receiver has to work backwards. The current form is the
best option of the three. The expectation is that this will be useful for
content that is generated once and sent multiple times, since the onerous
backwards processing requirement can be amortized.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:04 |