다이제스트 필드

• 새로운 요청 및 응답 헤더와 트레일러 필드 정의.

  • 섹션 2 (Content-Digest),
  • 섹션 3 (Repr-Digest), 및
  • 섹션 4 (Want-Content-Digest 및 Want-Repr-Digest).

• 표현 데이터 무결성에 특화된 고려사항.

  • 섹션 3.1 (상태 변경 요청),
  • 섹션 3.2 (Content-Location),
  • 부록 A에는 메시지 교환에서의 표현 데이터 예제가 포함되어 있으며,
  • 부록 B 및 C에는 Repr-Digest 및 Want-Repr-Digest 필드의 예제가 포함되어 있습니다.
• 섹션 5는 해시 알고리즘 고려사항을 제시하고 향후 항목 등록 절차를 정의합니다.

이 문서에서 정의된 HTTP 필드는 HTTP 무결성에 사용될 수 있습니다. 송신자는 해싱 알고리즘을 선택하고 HTTP 메시지와 관련된 입력으로부터 다이제스트를 계산합니다. 알고리즘 식별자와 다이제스트는 HTTP 필드로 전송됩니다. 수신자는 무결성 목적으로 다이제스트를 검증할 수 있습니다. 해싱 알고리즘은 "Hash Algorithms for HTTP Digest Fields" 레지스트리에 등록됩니다(참조: 섹션 7.2).

다이제스트를 계산할 데이터 선택은 HTTP 메시지의 사용 사례에 따라 달라집니다. 이 문서는 HTTP 표현 데이터와 HTTP 콘텐츠를 위한 서로 다른 필드를 제공합니다.

간단히 HTTP 콘텐츠 바이트의 다이제스트가 필요한 사용 사례가 있습니다. 이를 위해 Content-Digest 요청 및 응답 헤더와 트레일러 필드를 정의합니다(참조: Section 6.4 of [HTTP]); 자세한 내용은 섹션 2를 참조하십시오.

보다 고급 사용 사례를 위해, 선택된 표현 데이터에 해싱 알고리즘을 적용하여 계산된 다이제스트 값을 포함하는 Repr-Digest 요청 및 응답 헤더와 트레일러 필드를 정의합니다(참조: 섹션 3). 표현을 기반으로 Repr-Digest를 정의하면, 메시지 콘텐츠가 표현으로 간주되기 위해 일부 조작이 필요한 경우나 범위 요청과 같이 부분 표현을 전달하는 경우에 적용하기가 용이합니다(참조: Section 8.1, Section 14 of [HTTP]).

Content-Digest와 Repr-Digest는 해싱 알고리즘 유연성을 지원합니다. Want-Content-Digest 및 Want-Repr-Digest 필드는 각기 Content-Digest와 Repr-Digest에 대한 관심을 표현하고 알고리즘 선호도를 나타낼 수 있게 합니다.

Content-Digest와 Repr-Digest를 통틀어 "Integrity fields"라고 합니다. Want-Content-Digest와 Want-Repr-Digest는 통틀어 "Integrity preference fields"라고 합니다.

무결성 필드는 Content-Encoding 및 Content-Type 헤더 필드와 연계됩니다. 따라서 동일한 리소스는 HTTP로 전송될 때 서로 다른 다이제스트 값을 가질 수 있습니다.

무결성 필드는 HTTP 메시지 콘텐츠 또는 HTTP 표현에 적용되며, HTTP 메시지 자체나 헤더 필드에는 적용되지 않습니다. 다만 디지털 서명과 같은 메타데이터를 보호하는 다른 메커니즘과 결합하여 HTTP 교환의 일부 또는 전부를 보호할 수 있습니다. 예를 들어 HTTP Message Signatures([SIGNATURES])는 무결성 필드를 서명하는 데 사용될 수 있어 HTTP 콘텐츠 또는 표현 데이터에 대한 적용 범위를 제공할 수 있습니다.

이 규격은 인증, 권한 부여 또는 프라이버시 수단을 정의하지 않습니다.

[RFC3230]는 HTTP 무결성을 위한 Digest 및 Want-Digest 필드를 정의했습니다. 또한 선택된 표현 데이터와 같은 개념을 설명하기 위해 "instance"와 "instance manipulation"이라는 용어를 도입했는데, 이는 현재 HTTP 의미론(semantics)으로 더 보편적으로 정의되고 구현되고 있습니다.

경험적으로 [RFC3230]의 구현체들이 "instance"의 의미를 일관되게 해석하지 않아 상호운용성 문제가 발생하는 것으로 나타났습니다. 가장 흔한 문제는 다이제스트를 원래 의도된 표현 데이터가 아니라 (현재 우리가 "메시지 콘텐츠"라고 부르는) 메시지 콘텐츠를 사용해 계산하는 실수입니다. 흥미롭게도 메시지 콘텐츠의 다이제스트가 일부 사용 사례에서는 유용할 수 있음이 입증되어, 비준수인지 의도적 비준수인지 판별하기 어려운 경우도 발생했습니다.

이러한 불일치와 모호성을 해결하기 위해 본 문서는 [RFC3230]를 폐지합니다. 본 문서에서 정의된 Integrity 필드(섹션 2 및 3)와 Integrity 선호 필드(섹션 4)는 현재의 HTTP 의미론과 더 잘 맞추어져 있으며 의도된 사용법을 보다 명확하게 전달하는 이름을 갖고 있습니다.

문서 내에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"라는 핵심 단어들은 대문자로 표기된 경우에 한해 BCP 14(RFC2119, RFC8174)에서 설명된 대로 해석됩니다.

이 문서는 [RFC5234]에서 정의된 확장 ABNF를 사용하며 [RFC7405]에 의해 업데이트된 규칙을 따릅니다. 여기에는 CR, LF 및 CRLF 규칙이 포함됩니다.

이 문서는 구문 및 파싱을 지정하기 위해 Section 3 of [STRUCTURED-FIELDS]의 용어(예: Boolean, Byte Sequence, Dictionary, Integer, List)를 사용합니다.

이 문서에서 "representation", "selected representation", "representation data", "representation metadata", "user agent", 및 "content"의 정의는 [HTTP]에 따라 해석됩니다.

이 문서는 [FOLDING]에 설명된 줄 접기 전략을 사용합니다.

해싱 알고리즘 이름은 정의 문서에서 사용된 대소문자를 존중합니다(예: SHA-1, CRC32c).

HTTP 메시지는 알고리즘 키(Algorithm Key)를 사용하여 해싱 알고리즘을 표시합니다. 문서에서 알고리즘 키를 산문으로 언급할 때는 인용 부호로 표시합니다(예: "sha", "crc32c").

"checksum"라는 용어는 바이트 시퀀스에 알고리즘을 적용하여 생성된 출력을 설명하는 데 사용되며, "digest"는 필드에 포함된 값과 관련하여만 사용됩니다.

"Integrity fields"는 Content-Digest 및 Repr-Digest의 통칭입니다.

"Integrity preference fields"는 Want-Repr-Digest 및 Want-Content-Digest의 통칭입니다.

상태 변경 요청에 포함된 표현이 대상 리소스를 설명하지 않는 경우, 표현 다이제스트는 표현 데이터에 대해 계산되어야 하며 이는 필수입니다(MUST). 이는 표현 다이제스트가 완전한 표현 메타데이터를 필요로 하기 때문에 가능한 유일한 선택입니다(참조: 섹션 3).

응답의 경우,

• 만약 포함된 표현이 요청의 상태를 설명한다면, Repr-Digest는 해당 포함 표현에 대해 계산되어야 합니다(MUST)(참조: 부록 B.8);
• 참조된 리소스가 있는 경우, Repr-Digest는 참조된 리소스의 선택된 표현에 대해 계산되어야 하며, 이는 대상 리소스와 다를 수 있습니다. 이 경우 포함된 표현에 대해 Repr-Digest를 계산할 수도 있고 아닐 수도 있습니다.

후자의 경우는 주어진 메서드의 HTTP 의미론에 따라 수행되며, 예를 들어 Content-Location 헤더 필드를 사용하는 방식입니다(참조: Section 8.7 of [HTTP]). 반면에 Location 헤더 필드는 표현 메타데이터가 아니므로 Repr-Digest에 영향을 주지 않습니다.

예를 들어 PATCH 요청에서는 표현 메타데이터가 패치 문서를 가리키므로 표현 다이제스트는 패치 문서에 대해 계산됩니다(참조: Section 2 of [PATCH]). 반면 응답에서는 표현 다이제스트가 패치된 리소스의 선택된 표현에 대해 계산됩니다.

상태 변경 메서드가 Content-Location 헤더 필드를 반환하는 경우, 포함된 표현은 그 값으로 식별된 리소스를 가리키며 Repr-Digest는 이에 따라 계산됩니다. 예시는 부록 B.7에 제공되어 있습니다.

이 문서는 HTTP 표현 데이터 또는 콘텐츠의 무결성을 특정 종류의 손상으로부터 보호하는 데이터 무결성 메커니즘을 명세하지만, HTTP 헤더 및 트레일러 필드는 보호하지 않습니다.

무결성 필드는 HTTP 메시지에 대한 악의적 변조에 대한 일반적 보호를 제공하도록 설계된 것이 아닙니다. 추가적인 보안 메커니즘이 없는 경우, 경로 상의 악의적 행위자는 다이제스트 값을 완전히 제거하거나 조작된 표현 데이터나 콘텐츠에 대해 새로 계산한 다이제스트로 대체할 수 있습니다. 이러한 공격은 TLS나 디지털 서명(예: HTTP Message Signatures [SIGNATURES])과 같은 다른 접근법과 결합하여 완화할 수 있습니다.

무결성 필드는 구현 오류, 원치 않는 "변환 프록시"(참조: RFC 9110 섹션 7.7) 또는 데이터가 여러 홉이나 시스템 경계를 지날 때 발생하는 기타 조작으로 인한 표현 데이터 또는 콘텐츠 변경을 탐지하는 데 도움이 될 수 있습니다. 단순한 종단 간 표현 데이터 무결성 메커니즘도, 사용자 에이전트가 리소스 검색이 성공했음을 확인한 후 HTML 파서나 비디오 플레이어 등으로 넘겨줄 수 있게 해주므로 가치가 있습니다.

이러한 메커니즘만으로는 메타데이터가 어느 단계에서든 조작될 수 있기 때문에 다수 홉에 걸친 HTTP 메시지의 종단 간 무결성을 제공하지 못한다는 점에 유의하십시오. 메타데이터를 보호하는 방법은 섹션 6.3에서 논의됩니다.

디지털 서명은 체크섬과 함께 널리 사용되어 메시지 출처의 확인을 제공합니다(참조: [FIPS186-5]). 이러한 서명은 하나 이상의 HTTP 필드를 보호할 수 있으며, 무결성 필드가 포함될 때 추가 고려사항이 있습니다.

무결성 필드와 함께 사용할 수 있는 디지털 서명의 유형이나 형식에 대한 제한은 없습니다. 한 가지 가능한 접근법은 이를 HTTP Message Signatures와 결합하는 것입니다([SIGNATURES]).

다이제스트는 명시적으로 "표현 메타데이터"(예: Content-Type, Content-Encoding 등)의 값에 의존합니다. 무결성 필드는 보호하되 다른 "표현 메타데이터"는 보호하지 않는 서명은 통신을 변조에 노출시킬 수 있습니다. 예를 들어, 행위자가 Content-Type 필드 값을 조작하여 수신자 쪽에서 다이제스트 검증 실패를 일으켜 애플리케이션이 표현에 접근하지 못하도록 할 수 있습니다. 이러한 공격은 양쪽 엔드포인트의 자원을 소모시킵니다. 또한 섹션 3.2도 참조하십시오.

서명은 무결성 필드를 적용할 때 적대적 환경으로 간주되는 경우가 많습니다; 참조: 섹션 5. Repr-Digest는 서명과 결합될 때 흥미로운 가능성을 제공합니다. 전송할 콘텐츠가 없을 때 빈 문자열의 다이제스트를 메시지에 포함하고 이를 서명하면, 수신자는 우발적이거나 의도적 조작으로 인해 콘텐츠가 추가되었는지 탐지하는 데 도움을 받을 수 있습니다. 반대의 경우도 지원됩니다; 콘텐츠에 대한 무결성 필드를 포함하고 이를 서명하면 수신자는 콘텐츠가 제거된 경우를 탐지할 수 있습니다.

무결성 필드의 어떤 변형은 서명 검증에 영향을 줄 수 있습니다. 이러한 변형의 예로는 다이제스트 중복 제거나 서로 다른 필드 값을 결합하는 것이 있습니다(참조: RFC 9110 섹션 5.2).

무결성 필드를 트레일러 섹션에 전송하기 전에, 발신자는 중계자가 어떤 트레일러든 명시적으로 삭제할 수 있다는 점을 고려해야 합니다(참조: RFC 9110 섹션 6.5.2).

트레일러 섹션에서 무결성 필드가 사용되는 경우, 필드 값은 콘텐츠 이후에 수신됩니다. 트레일러 섹션 이전에 콘텐츠를 조기 처리하면 다이제스트 검증이 불가능하게 되어 유효하지 않은 데이터를 처리하게 될 수 있습니다.

트레일러 섹션에서 무결성 필드를 사용하는 이점 중 하나는 전송 중에 바이트를 해시할 수 있다는 점입니다. 그러나 콘텐츠를 처리하는 방식 때문에 이러한 이점이 무효화되는 해싱 알고리즘을 설계할 수도 있습니다. 예를 들어 Merkle Integrity Content Encoding([MICE])은 콘텐츠를 역순으로 처리해야 하므로 전체 데이터가 필요하게 되어 트레일러 대신 헤더에 무결성 필드를 보내는 것과 처리 차이가 거의 없어집니다.

콘텐츠 코딩 메커니즘은 서로 다른 인코딩 매개변수를 지원할 수 있으므로 동일한 입력 콘텐츠가 서로 다른 출력을 생성할 수 있습니다. 예를 들어 GZIP은 여러 압축 수준을 지원합니다. 이러한 인코딩 매개변수는 일반적으로 표현 메타데이터로 전달되지 않습니다. 예컨대 다양한 압축 수준은 모두 동일한 "Content-Encoding: gzip" 필드를 사용합니다. 또 다른 예로는 aes128gcm 콘텐츠 코딩([RFC8188])처럼 논스(nonce)나 타임스탬프에 의존하는 인코딩이 있습니다.

콘텐츠 코딩 내에 변동이 있을 수 있으므로, 무결성 필드가 전달하는 체크섬은 전체 콘텐츠가 보존되지 않는 한 "휴지 상태에서의 무결성(proof of integrity 'at rest')"을 제공하는 데 사용할 수 없습니다.

해싱 알고리즘의 보안 속성은 고정되어 있지 않습니다. 알고리즘 유연성(참조: [RFC7696])은 구현이 IANA "Hash Algorithms for HTTP Digest Fields" 레지스트리에서 알고리즘을 선택할 수 있는 유연성을 제공함으로써 달성됩니다; 참조: 섹션 7.2.

약한 알고리즘으로부터의 전환은 Want-Content-Digest 또는 Want-Repr-Digest를 이용한 해싱 알고리즘 협상(참조: 섹션 4)이나 수신자가 선택할 수 있도록 여러 다이제스트를 보내는 방식으로 지원됩니다. 보안에 다이제스트에 의존하는 수신자는 수락하는 가장 약한 알고리즘에 대한 공격에 취약해집니다. 엔드포인트는 여러 값을 전송하는 것이 수신자가 이를 무시하면 낭비되는 자원을 소비한다는 점을 유의해야 합니다(참조: 섹션 3).

알고리즘 유연성은 더 강력한 알고리즘으로의 마이그레이션을 허용하지만 약한 알고리즘의 사용을 막지는 않습니다. 무결성 필드는 해싱 알고리즘의 다운그레이드나 대체 공격을 완화하지 못합니다(참조: RFC 6211 섹션 1). 이러한 공격을 방지하려면 엔드포인트가 지원 가능한 알고리즘 집합을 강한 알고리즘으로 제한하고 TLS 및/또는 디지털 서명을 사용하여 필드 값을 보호할 수 있습니다.

무결성 필드 검증은 계산 자원을 소비합니다. 자원 고갈을 피하기 위해 구현체는 알고리즘 유형, 검증 횟수 또는 콘텐츠 크기를 제한할 수 있습니다. 이러한 경우 검증을 완전히 건너뛰거나 더 선호되는 알고리즘의 검증 실패를 무시하면 다운그레이드 공격 가능성이 남아 있습니다(참조: 섹션 6.6).

IANA는 새로운 "Hash Algorithms for HTTP Digest Fields" 레지스트리를 <https://www.iana.org/assignments/http-digest-hash-alg/>에 생성하고 표 2의 항목들로 채웠습니다. 새로운 등록 절차는 섹션 5에 제공됩니다.

이 레지스트리는 Digest 및 Want-Digest 필드와 함께 사용되는 알고리즘을 나열하고 있는 관계로 RFC 9530에 의해 폐지된 [RFC3230]를 참조하므로 더 이상 권장되지 않습니다. 등록이 닫히지는 않았지만, 새로운 등록은 대신 Hash Algorithms for HTTP Digest Fields 레지스트리를 사용하는 것이 권장됩니다.

이 예제에서 메시지 콘텐츠는 완전한 표현 데이터를 전달합니다. 즉 응답에서 Content-Digest와 Repr-Digest는 모두 JSON 객체 {"hello": "world"} (LF 포함)에 대해 계산되므로 동일한 값을 가집니다.

이 예제에서는 HEAD 요청을 사용하여 리소스의 체크섬을 조회합니다.

응답의 Content-Digest 필드 값은 빈 콘텐츠에 대해 계산됩니다. Repr-Digest는 JSON 객체 {"hello": "world"} (LF 포함)에 대해 계산되며, 콘텐츠가 없기 때문에 표시되지 않습니다.

이 예제에서 클라이언트는 범위 요청을 하고 서버는 부분 콘텐츠로 응답합니다.

NOTE: '\' line wrapping per RFC 8792

Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

NOTE: '\' line wrapping per RFC 8792

Content-Digest: \
  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:

요청에는 포함된 표현에 대해 계산된 Repr-Digest 필드 값이 포함됩니다. 또한 클라이언트가 Brotli 인코딩을 지원함을 알리는 Accept-Encoding: br 헤더 필드를 포함합니다.

응답에는 선택된 표현이 Brotli로 인코딩되었음을 나타내는 Content-Encoding: br가 포함됩니다. 따라서 Repr-Digest 필드 값은 요청과 다릅니다.

표현을 위해 응답 본문은 비인쇄 문자를 포함하므로 16진수로 인코딩된 바이트 시퀀스로 표시됩니다.

요청의 Repr-Digest 필드 값은 포함된 콘텐츠에 대해 계산됩니다. 이 콘텐츠는 LF가 뒤따르는 JSON 객체 {"hello": "world"}입니다.

응답의 Repr-Digest 필드 값은 응답이 콘텐츠를 포함하지 않더라도 Content-Encoding: br를 포함한 표현 메타데이터 헤더 필드에 따라 달라집니다.

NOTE: '\' line wrapping per RFC 8792

PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19
Accept-Encoding: br
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

{"hello": "world"}

응답에는 서로 다른 알고리즘을 사용한 두 개의 다이제스트 값이 포함됩니다.

표현을 위해 응답 본문은 비인쇄 문자를 포함하므로 16진수로 인코딩된 바이트 시퀀스로 표시됩니다.

요청의 Repr-Digest 필드 값은 포함된 표현에 대해 계산됩니다(참조: 섹션 3.1). 이 표현은 LF가 뒤따르는 JSON 객체 {"title": "New Title"}입니다.

응답에 포함된 표현은 여러 줄의 JSON 객체(뒤따르는 LF)이며 Content-Location 값으로 식별된 리소스를 참조합니다(참조: RFC 9110 섹션 6.4.2). 따라서 애플리케이션은 Content-Location으로 참조된 리소스와 연관하여 Repr-Digest를 사용할 수 있습니다.

요청의 Repr-Digest 필드 값은 포함된 표현에 대해 계산됩니다(참조: 섹션 3.1). 이 표현은 LF가 뒤따르는 JSON 객체 {"title": "New Title"}입니다.

응답에 포함된 표현은 요청의 상태를 설명하므로 해당 포함 표현에 대해 Repr-Digest가 계산됩니다. 이는 여러 줄의 JSON 객체(뒤따르는 LF)입니다.

응답의 Repr-Digest는 Location으로 참조된 리소스와 명시적 관계가 없습니다.

이 경우는 대상 리소스가 대상 URI를 반영하는 POST 요청과 유사합니다.

PATCH 요청은 application/merge-patch+json 미디어 타입을 사용합니다(참조: [RFC7396]). Repr-Digest는 패치 문서에 해당하는 콘텐츠( LF가 뒤따르는 JSON 객체 {"title": "New Title"})에 대해 계산됩니다.

응답의 Repr-Digest 필드 값은 패치된 리소스의 완전한 표현에 대해 계산됩니다. 이는 여러 줄의 JSON 객체(뒤따르는 LF)입니다.

콘텐츠 없이 동일한 Repr-Digest 필드 값을 가진 204 No Content 응답도 정당할 수 있다는 점에 유의하십시오. 그 경우 Content-Digest는 빈 콘텐츠에 대해 계산되었을 것입니다.

오류 응답에서는 표현 데이터가 반드시 대상 리소스를 참조하지 않을 수 있습니다. 대신 오류의 표현을 참조합니다.

다음 예제에서 클라이언트는 그림 26의 동일한 요청을 /books/123에 패치하려 보냅니다. 그러나 리소스가 존재하지 않아 서버는 [RFC9457]에 따라 오류를 설명하는 본문과 함께 404 응답을 생성합니다.

응답의 Repr-Digest 필드 값은 이 포함된 표현에 대해 계산됩니다. 이는 여러 줄의 JSON 객체(뒤따르는 LF)입니다.

오리진 서버가 스트리밍 중에 다이제스트 값을 계산할 수 있도록 Repr-Digest을 트레일러 필드로 전송합니다. 이렇게 하면 리소스 소비를 완화할 수 있습니다. Repr-Digest 필드 값은 부록 B.1의 것과 동일합니다. Repr-Digest는 하나 이상의 전송 코딩의 사용과 무관하도록 설계되었기 때문입니다(참조: 섹션 3).

아래 응답 콘텐츠에서 문자열 "\r\n"은 CRLF 바이트를 나타냅니다.

클라이언트는 다이제스트를 요청하고 "sha"를 선호합니다. 그러나 서버는 어쨌든 "sha-256"으로 응답할 수 있습니다.

클라이언트는 자신이 지원하는 유일한 알고리즘인 "sha" 다이제스트를 요청합니다. 서버는 반드시 "sha" 다이제스트를 포함한 응답을 생성할 의무가 없으며 대신 다른 알고리즘을 사용할 수 있습니다.

부록 C.2는 서버가 클라이언트의 선호 다이제스트 알고리즘을 무시하는 예시입니다. 대안으로, 서버는 요청을 거부하고 4xx 또는 5xx와 같은 오류 상태 코드를 포함한 응답을 반환할 수 있습니다. 이 규격은 상태 코드 선택에 대해 어떠한 요구사항도 규정하지 않으며, 아래 예제는 가능한 한 옵션을 보여줍니다.

이 예제에서 클라이언트는 "sha" Repr-Digest를 요청하고, 서버는 콘텐츠에 문제 세부정보([RFC9457])를 포함한 오류를 반환합니다. 문제 세부정보에는 서버가 지원하는 해싱 알고리즘 목록이 포함됩니다. 이는 단지 예시일 뿐이며, 이 규격은 그러한 콘텐츠의 형식이나 요구사항을 정의하지 않습니다.