Internet-Draft HTTP Problem Types for Digest Fields July 2024
Kleidl & Pardue Expires 9 January 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-kleidl-digest-fields-problem-types-00
Published:
Intended Status:
Informational
Expires:
Authors:
M. Kleidl
Transloadit
L. Pardue
Cloudflare

HTTP Problem Types for Digest Fields

Abstract

This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://tus.github.io/draft-digest-fields-problem-types/draft-kleidl-digest-fields-problem-types.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kleidl-digest-fields-problem-types/.

Source for this draft and an issue tracker can be found at https://github.com/tus/draft-digest-fields-problem-types.

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 https://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 9 January 2025.

Table of Contents

1. Introduction

[DIGEST] by design does not define, require or recommend any specific behavior for error handling relating to integrity. The responsibility is instead delegated to applications. This draft defines a set of problem types [PROBLEM] that can be used by server applications to indicate that a problem was encountered while dealing with a request carrying integrity fields and integrity preference fields.

For example, a request message may include content alongside Content-Digest and Repr-Digest header fields that use a digest algorithm the server does not support. An application could decide to reject this request because it cannot validate the integrity. Using a problem type, the server can provide machine-readable error details to aid debugging or error reporting, as shown in the following example.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Want-Content-Digest: sha-512=3, sha-256=10

{
  "type": "https://iana.org/assignments/http-problem-types#unsupported-hashing-algorithm",
  "title": "hashing algorithm is not supported",
  "unsupported-algorithm": "foo"
}

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The terms "integrity fields" and "integrity preference fields" are from [DIGEST].

3. Problem Types

3.1. Unsupported Hashing Algorithm

This section defines the "https://iana.org/assignments/http-problem-types#unsupported-hashing-algorithm" problem type [PROBLEM]. A server MAY use this problem type when responding to a request, whose integrity or integrity preference fields reference a hashing algorithm that the server can not or does not want to support for this request, and if the server wants to indicate this problem to the sender.

For this problem type, the unsupported-algorithm is defined as the only extension member. It SHOULD be populated in a response using this problem type, with its value being the algorithm key of the unsupported algorithm from the request. The response SHOULD include the corresponding integrity preference field to indicate the server's algorithm support and preference.

The following example shows a response for a request with an integrity field utilizing an unsupported hashing algorithm foo. The response also includes a list of supported algorithms.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Want-Content-Digest: sha-512=3, sha-256=10

{
  "type": "https://iana.org/assignments/http-problem-types#unsupported-hashing-algorithm",
  "title": "hashing algorithm is not supported",
  "unsupported-algorithm": "foo"
}

This problem type is a hint to the client about algorithm support, which the client could use to retry the request with a different algorithm supported by the server.

3.2. Invalid Digest Value

This section defines the "https://iana.org/assignments/http-problem-types#invalid-digest-value" problem type [PROBLEM]. A server MAY use this problem type when responding to a request, whose integrity fields include a digest value, that cannot be generated by the corresponding hashing algorithm. For example, if the digest value of the sha-512 hashing algorithm is not 64 bytes long, it cannot be a valid digest value and the server can skip computing the digest value. This problem type MUST NOT be used if the server is not able to parse the integrity fields according to Section 4.5 of [STRUCTURED-FIELDS], for example because of a syntax error in the field value.

The server SHOULD include a human-readable description why the value is considered invalid in the title member.

The following example shows a response for a request with an invalid digest value.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#invalid-digest-value",
  "title": "digest value for sha-512 is not 64 bytes long"
}

This problem type indicates a fault in the sender's calculation or encoding of the digest value. A retry of the same request without modification will likely not yield a successful response.

3.3. Mismatching Digest Value

This section defines the "https://iana.org/assignments/http-problem-types#mismatching-digest-value" problem type [PROBLEM]. A server MAY use this problem type when responding to a request, whose integrity fields include a digest value that does not match the digest value that the server calculated for the request content or representation.

Three problem type extension members are defined: the algorithm, provided-digest, and calculated-digest members. A response using this problem type SHOULD populate all members, with the value of algorithm being the algorithm key of the used hashing algorithm, with the value of provided-digest being the digest value taken from the request's integrity fields, and the value of calculated-digest being the calculated digest. The digest values MUST BE serialized as byte sequences as described in Section 4.1.8 of [STRUCTURED-FIELDS].

The following example shows a response for a request with a mismatching SHA-256 digest value.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#mismatching-digest-value",
  "title": "digest value fromr request does not match expected value",
  "algorithm": "sha-256",
  "provided-digest": ":RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:",
  "calculated-digest": ":d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:"
}

If the sender receives this problem type, the request might be modified unintentionally by an intermediary. The sender could use this information to retry the request without modification to address temporary transmission issues.

4. Security Considerations

Although an error appeared while handling the digest fields, the server may choose to not disclose this error to the sender to avoid lacking implementation details. Similar, the server may choose a general problem type for the response even in a more specific problem type is defined if it prefers to hide the details of the error from the sender.

5. IANA Considerations

IANA is asked to register the following entry in the "HTTP Problem Types" registry:

Type URI:

https://iana.org/assignments/http-problem-types#unsupported-hashing-algorithm

Title:

Unsupported Hashing Algorithm

Recommended HTTP status code:

400

Reference:

This document

IANA is asked to register the following entry in the "HTTP Problem Types" registry:

Type URI:

https://iana.org/assignments/http-problem-types#invalid-digest-value

Title:

Invalid Digest Value

Recommended HTTP status code:

400

Reference:

This document

IANA is asked to register the following entry in the "HTTP Problem Types" registry:

Type URI:

https://iana.org/assignments/http-problem-types#mismatching-digest-value

Title:

Mismatching Digest Value

Recommended HTTP status code:

400

Reference:

This document

6. Normative References

[DIGEST]
Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, , <https://www.rfc-editor.org/rfc/rfc9530>.
[PROBLEM]
Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, , <https://www.rfc-editor.org/rfc/rfc9457>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, , <https://www.rfc-editor.org/rfc/rfc8941>.

Acknowledgments

This document is based on ideas from a discussion with Roberto Polli, so thanks to him for his valuable input and feedback on this topic.

Authors' Addresses

Marius Kleidl
Transloadit
Lucas Pardue
Cloudflare