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]