One document matched: draft-thomson-http-content-signature-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.20 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-thomson-http-content-signature-00" category="info">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="Content-Signature">Content-Signature Header Field for HTTP</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2015"/>

    <area>ART</area>
    <workgroup>httpbis</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>A Content-Signature header field is defined for use in HTTP.  This header field
carries a signature of the payload body of a message.</t>



    </abstract>


  </front>

  <middle>


<section anchor="problems" title="Introduction">

<t>The Content-Signature header field carries a signature of the payload body of an
HTTP message <xref target="RFC7230"></xref>.  This allows for content to be protected from
modification.</t>

<t>The exchange of high-value messages via intermediaries is often necessary in
HTTP for operational reasons.  While those intermediaries might be trusted with
the information that they forward, some clients or servers might desire greater
assurances about the integrity of the information they receive.</t>

<t>No protection is provided for header fields.  If integrity is important, only
the information in the message payload can be relied upon.</t>

<t>No key management mechanism is defined.  Other specifications are expected to
describe how recipients determine what credibility is attributed to any given
signature key.</t>

<section anchor="Terminology" title="Terminology">

<t>RFC 2119 <xref target="RFC2119"></xref> defines the terms MUST, SHOULD, and MAY.</t>

</section>
<section anchor="example" title="Example">

<t>The following HTTP/1.1 response is signed.  Line wrapping is added to fit
formatting constraints.</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Date: Wed, 17 Jun 2015 17:14:17 GMT
Content-Length: 15
Encryption-Key: keyid=a;
    p256ecdsa=BDUJCg0PKtFrgI_lc5ar9qBm83cH_QJomSjXYUkIlswX
              KTdYLlJjFEWlIThQ0Y-TFZyBbUinNp-rou13Wve_Y_A
Content-Signature: keyid=a;
    p256ecdsa=Hil-_2xU6BjQcU6a8nhMCChLr-fkrek5tE6pokWlJb0
              HkQiryW045vVpljN_xBbF8sTrsWb9MiQLCdYlP1jZtA

Hello, World!
]]></artwork></figure>

</section>
</section>
<section anchor="csig" title="The Content-Signature Header Field">

<t>The Content-Signature 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[
Content-Signature = 1#csig_params
csig_params = [ parameter *( ";" parameter ) ]
]]></artwork></figure>

<t>Each content signature is separated by a comma (,) and is compromised of zero or
more colon-separated parameters.</t>

<t>The message payload is prefixed with the string “Content-Encryption:” and a
single zero-valued octet before being passed to the signature algorithm.  This
discriminator string reduces the chances that a signature is viable for reuse in
other contexts.</t>

<t>The following parameters are defined:</t>

<t><list style="hanging">
  <t hangText='keyid:'>
  This parameter identifies the key that was used to produce the signature.
This could identify a key that is carried in the Encryption-Key header field.
This parameter can always be provided together with other parameters.</t>
  <t hangText='p256ecdsa:'>
  This parameter contains an ECDSA <xref target="X.692"></xref> signature on the P-256 curve
<xref target="FIPS186"></xref>.  The signature is produced using the SHA-256 hash <xref target="FIPS180-2"></xref>.  The
resulting signature is encoded using URL-safe variant of base-64 <xref target="RFC4648"></xref>.
No parameters other than <spanx style="verb">keyid</spanx> can be specified along with the <spanx style="verb">p256ecdsa</spanx>
parameter.</t>
</list></t>

<t>Additional header field values can be defined and registered.  The parameter
MUST describe how the signature is produced and encoded.</t>

<t>Though the parameter defined in this document do not contain any optional or
parameterized features, new signature algorithms MAY use additional parameters
for conveying information about optional features.  The definition of new
parameters SHOULD describe what parameters can be combined with that parameter
and the resulting semantics.</t>

<t>The Content-Signature header field might be most efficiently produced as a
trailer field.  This allows for the production of the message body and the
signature in a single pass.</t>

</section>
<section anchor="keys" title="Describing Signature Keys">

<t>A message MAY include a signing key.  This can be used to provision trusted
keys.</t>

<t>Providing an encryption key is typically only useful where the provision of the
key can be attributed a higher level of trust than the signature.  A message
sent using out-of-band content-encoding <xref target="I-D.reschke-http-oob-encoding"/> is one
situation that benefits from the use of this header field.</t>

<t>Alternatively, explicitly including a public key can allow a verifier to
correctly identify the key that was used if the <spanx style="verb">keyid</spanx> parameter is not
sufficient.</t>

<t>This document defines a new parameter for use with the <spanx style="verb">Encryption-Key</spanx> header
field.  The <spanx style="verb">p256ecdsa</spanx> parameter conveys an uncompressed P-256 public key
<xref target="X.692"></xref> that is encoded using URL-safe variant of base-64 <xref target="RFC4648"></xref>.</t>

</section>
<section anchor="security" title="Security Considerations">

<t>Determining whether a signature is valid is only a small part of authenticating
a message. This document doesn’t describe a complete solution for identifying
which signing keys are accepted.</t>

<t>This scheme does not authenticate header fields, or other request or response
metadata.  A recipient of a signed payload needs to be especially careful that
decisions that rely on authenticating the payload do not take any
unauthenticated material as input.  In particular, the request URI and the
<spanx style="verb">Content-Type</spanx> header field are not authenticated by this scheme.</t>

<t>No replay protection is offered for signatures.  This means that valid messages
can be captured and replayed.  Since there is no binding between the identity of
a resource and the signature, the content of a message can be replayed for a
request or response to a different resource; requests can be replayed as
responses; and messages can be replayed at different times.</t>

<t>Replay protection can be provided by including information in the message
payload itself that binds the content to a specific resource, time or any other
contextual information.</t>

</section>
<section anchor="iana" title="IANA Considerations">

<section anchor="content-signature-header-field" title="Content-Signature Header Field">

<t>This memo registers the <spanx style="verb">Content-Signature</spanx> HTTP header field in the Permanent
Message Header Registry, as detailed in <xref target="csig"/>.</t>

<t><list style="symbols">
  <t>Field name: Content-Signature</t>
  <t>Protocol: HTTP</t>
  <t>Status: Standard</t>
  <t>Reference: <xref target="csig"/> of this specification</t>
  <t>Notes:</t>
</list></t>

</section>
<section anchor="content-signature-parameter-registry" title="Content-Signature Parameter Registry">

<t>A registry is established for parameters used by the <spanx style="verb">Content-Signature</spanx> header
field under the “Hypertext Transfer Protocol (HTTP) Parameters” grouping.  The
“Hypertext Transfer Protocol (HTTP) Encryption Parameters” operates under an
“Specification Required” policy <xref target="RFC5226"></xref>.  The designated expert is advised to
consider the guidance in <xref target="csig"/> when reviewing new registrations.</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="keyid" title="keyid">

<t><list style="symbols">
  <t>Parameter Name: keyid</t>
  <t>Purpose: Identify the key that is in use.</t>
  <t>Reference: <xref target="csig"/> of this document</t>
</list></t>

</section>
<section anchor="p256ecdsa" title="p256ecdsa">

<t><list style="symbols">
  <t>Parameter Name: p256ecdsa</t>
  <t>Purpose: Conveys a signature using P-256, ECDSA and SHA-256 as described in
<xref target="csig"/> of this document.</t>
  <t>Reference: <xref target="csig"/> of this document</t>
</list></t>

</section>
</section>
<section anchor="the-p256ecdsa-parameter-for-the-encryption-key-header-field" title="The p256ecdsa Parameter for the Encryption-Key Header Field">

<t>The <spanx style="verb">p256ecdsa</spanx> parameter is registered in the “Hypertext Transfer Protocol
(HTTP) Encryption Parameters” registry established in
<xref target="I-D.thomson-http-encryption"></xref>, with the following values:</t>

<t><list style="symbols">
  <t>Parameter Name: p256ecdsa</t>
  <t>Purpose: Conveys a signing key for use with the parameter of the same name on
the <spanx style="verb">Content-Signature</spanx> header field.</t>
  <t>Reference: <xref target="keys"/> of this document</t>
</list></t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott 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 year='1997' month='March' />
<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 type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='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' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.txt' />
</reference>



<reference anchor='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' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>



<reference anchor='RFC7230'>

<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'>
<organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'>
<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' />
<format type='TXT' octets='205947' target='http://www.rfc-editor.org/rfc/rfc7230.txt' />
</reference>



<reference anchor='RFC7231'>

<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'>
<organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'>
<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' />
<format type='TXT' octets='235053' target='http://www.rfc-editor.org/rfc/rfc7231.txt' />
</reference>


<reference anchor="X.692" >
  <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>
<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="FIPS180-2" >
  <front>
    <title>NIST FIPS 180-2, 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="2002" month="August"/>
  </front>
</reference>




<reference anchor='I-D.thomson-http-encryption'>
<front>
<title>Encrypted Content-Encoding for HTTP</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='July' day='1' 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-thomson-http-encryption-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-http-encryption-01.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.reschke-http-oob-encoding'>
<front>
<title>'Out-Of-Band' Content Coding for HTTP</title>

<author initials='J' surname='Reschke' fullname='Julian Reschke'>
    <organization />
</author>

<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
    <organization />
</author>

<date month='June' day='4' year='2015' />

<abstract><t>This document describes an Hypertext Transfer Protocol (HTTP) content coding that can be used to describe the location of a secondary resource that contans the payload.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-reschke-http-oob-encoding-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-reschke-http-oob-encoding-00.txt' />
</reference>




    </references>



  </back>
</rfc>