Visual RFC.
ALL RFCs / RFC 9530
Read the RFC ↗
RFC 9530 / HTTP INTEGRITY

Separate integrity from trust

06

A matching digest checks a relationship between bytes and a conveyed value. It does not by itself authenticate a sender or protect HTTP metadata.

RFC 9530 · § 6.1EXAMPLE
4 / 4
Separate integrity from trustA matching digest checks a relationship between bytes and a conveyed value. It does not by itself authenticate a sender or protect HTTP metadata. TLS protects a connection, while a suitable validated signature can protect selected fields. Include relevant representation metadata with digest fields; neither a bare digest nor the illustrated boundary is a complete security protocol.A matching digest is not sender identityTLS protects a connectionSignature scope must be consideredProtect digest + relevant metadataNo TLS or signature implementation shownRFC9530 · chapter6 · state4 · published/illustrative values
04
Protect the relevant scope

TLS protects a connection, while a suitable validated signature can protect selected fields. Include relevant representation metadata with digest fields; neither a bare digest nor the illustrated boundary is a complete security protocol.

Source for this drawing: RFC 9530 · Read RFC section 6.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

An attacker able to alter both content and its digest can substitute a matching pair. These fields alone are not general protection against malicious message tampering.

  • An attacker able to alter both content and its digest can substitute a matching pair. These fields alone are not general protection against malicious message tampering.
  • Active algorithms are RECOMMENDED. Deprecated algorithms MAY detect accidental corruption but MUST NOT be used in potentially adversarial settings; accepting a weak algorithm can permit downgrade attacks.
  • Complementary TLS or signatures can protect data or fields within their scope. A signature covering an Integrity field without relevant representation metadata can still be vulnerable. Validation also needs appropriate resource limits.
DETAILS

Here the registry key sha denotes SHA-1, not all SHA algorithms. No authentication, authorization or privacy mechanism is specified by RFC 9530. This guide does not implement TLS or signatures. Algorithm agility and validation budgets require explicit policy; adding many digests is not automatic downgrade protection.

Read the RFC section ↗

All chapters in RFC 9530

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗