[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

httpbis                                                       M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Informational                              July 2, 2015
Expires: January 3, 2016


                Content-Signature Header Field for HTTP
                draft-thomson-http-content-signature-00

Abstract

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Thomson                  Expires January 3, 2016                [Page 1]


Internet-Draft              Content-Signature                  July 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The Content-Signature Header Field  . . . . . . . . . . . . .   3
   3.  Describing Signature Keys . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Content-Signature Header Field  . . . . . . . . . . . . .   5
     5.2.  Content-Signature Parameter Registry  . . . . . . . . . .   5
       5.2.1.  keyid . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.2.  p256ecdsa . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  The p256ecdsa Parameter for the Encryption-Key Header
           Field . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Content-Signature header field carries a signature of the payload
   body of an HTTP message [RFC7230].  This allows for content to be
   protected from modification.

   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.

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

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

1.1.  Terminology

   RFC 2119 [RFC2119] defines the terms MUST, SHOULD, and MAY.








Thomson                  Expires January 3, 2016                [Page 2]


Internet-Draft              Content-Signature                  July 2015


1.2.  Example

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

   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!

2.  The Content-Signature Header Field

   The Content-Signature header field uses the extended ABNF syntax
   defined in Section 1.2 of [RFC7230] and the "parameter" rule from
   [RFC7231].

   Content-Signature = 1#csig_params
   csig_params = [ parameter *( ";" parameter ) ]

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

   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.

   The following parameters are defined:

   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.

   p256ecdsa:  This parameter contains an ECDSA [X.692] signature on the
      P-256 curve [FIPS186].  The signature is produced using the
      SHA-256 hash [FIPS180-2].  The resulting signature is encoded
      using URL-safe variant of base-64 [RFC4648].  No parameters other
      than "keyid" can be specified along with the "p256ecdsa"
      parameter.




Thomson                  Expires January 3, 2016                [Page 3]


Internet-Draft              Content-Signature                  July 2015


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

   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.

   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.

3.  Describing Signature Keys

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

   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
   [I-D.reschke-http-oob-encoding] is one situation that benefits from
   the use of this header field.

   Alternatively, explicitly including a public key can allow a verifier
   to correctly identify the key that was used if the "keyid" parameter
   is not sufficient.

   This document defines a new parameter for use with the "Encryption-
   Key" header field.  The "p256ecdsa" parameter conveys an uncompressed
   P-256 public key [X.692] that is encoded using URL-safe variant of
   base-64 [RFC4648].

4.  Security Considerations

   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.

   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 "Content-Type" header field are
   not authenticated by this scheme.





Thomson                  Expires January 3, 2016                [Page 4]


Internet-Draft              Content-Signature                  July 2015


   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.

   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.

5.  IANA Considerations

5.1.  Content-Signature Header Field

   This memo registers the "Content-Signature" HTTP header field in the
   Permanent Message Header Registry, as detailed in Section 2.

   o  Field name: Content-Signature

   o  Protocol: HTTP

   o  Status: Standard

   o  Reference: Section 2 of this specification

   o  Notes:

5.2.  Content-Signature Parameter Registry

   A registry is established for parameters used by the "Content-
   Signature" header field under the "Hypertext Transfer Protocol (HTTP)
   Parameters" grouping.  The "Hypertext Transfer Protocol (HTTP)
   Encryption Parameters" operates under an "Specification Required"
   policy [RFC5226].  The designated expert is advised to consider the
   guidance in Section 2 when reviewing new registrations.

   o  Parameter Name: The name of the parameter.

   o  Purpose: A brief description of the purpose of the parameter.

   o  Reference: A reference to a specification that defines the
      semantics of the parameter.

   The initial contents of this registry are:






Thomson                  Expires January 3, 2016                [Page 5]


Internet-Draft              Content-Signature                  July 2015


5.2.1.  keyid

   o  Parameter Name: keyid

   o  Purpose: Identify the key that is in use.

   o  Reference: Section 2 of this document

5.2.2.  p256ecdsa

   o  Parameter Name: p256ecdsa

   o  Purpose: Conveys a signature using P-256, ECDSA and SHA-256 as
      described in Section 2 of this document.

   o  Reference: Section 2 of this document

5.3.  The p256ecdsa Parameter for the Encryption-Key Header Field

   The "p256ecdsa" parameter is registered in the "Hypertext Transfer
   Protocol (HTTP) Encryption Parameters" registry established in
   [I-D.thomson-http-encryption], with the following values:

   o  Parameter Name: p256ecdsa

   o  Purpose: Conveys a signing key for use with the parameter of the
      same name on the "Content-Signature" header field.

   o  Reference: Section 3 of this document

6.  References

6.1.  Normative References

   [FIPS180-2]
              Department of Commerce, National., "NIST FIPS 180-2,
              Secure Hash Standard", August 2002.

   [FIPS186]  National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
              2013.

   [I-D.thomson-http-encryption]
              Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
              thomson-http-encryption-01 (work in progress), July 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Thomson                  Expires January 3, 2016                [Page 6]


Internet-Draft              Content-Signature                  July 2015


   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

   [X.692]    ANSI, "Public Key Cryptography For The Financial Services
              Industry: The Elliptic Curve Digital Signature Algorithm
              (ECDSA)", ANSI X9.62 , 1998.

6.2.  Informative References

   [I-D.reschke-http-oob-encoding]
              Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding
              for HTTP", draft-reschke-http-oob-encoding-00 (work in
              progress), June 2015.

Author's Address

   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com




















Thomson                  Expires January 3, 2016                [Page 7]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/