9.0 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RFC 9421 — HTTP Message Signatures (official-vendor-doc) | official-doc | https://datatracker.ietf.org/doc/html/rfc9421 | https://web.archive.org/web/20260629/https://datatracker.ietf.org/doc/html/rfc9421 | raw | high |
|
|
|
2026-06-29 | 2026-06-29 |
RFC 9421 — HTTP Message Signatures (공식)
Layer:
raw/official-docs/— IETF 공식 RFC 표준 문서의 원문 발췌 및 출처 기록. Strength 분류:official-standard— IETF RFC 표준 트랙 문서 (rfc-editor.org/rfc/...).
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-webhook-outbound-contract | D1 (HMAC-SHA256 서명 스키마) 결정 시 RFC 9421 표준의 trade-off (과도한 복잡성 방지 및 vendor-standard 채택) 근거. |
컨텍스트
feature-webhook-outbound-contract 의 D1 은 아웃바운드 웹훅 서명 포맷을 설계한다. HTTP 메시지 서명 표준인 RFC 9421은 HTTP 요청과 응답의 구성요소(메서드, 경로, 헤더 등)에 대해 암호학적 서명을 부여하는 프레임워크를 제공한다. 본 문서는 RFC 9421이 정의하는 (a) 구조화된 헤더 (Signature, Signature-Input), (b) 타임스탬프, Nonce, 키 ID 파라미터화, (c) 헤더 정규화 프로세스 등을 발췌하여, 우리 프로젝트가 왜 무거운 RFC 9421 대신 실무적이고 널리 사용되는 Stripe/Svix 형태의 단순 대칭키 HMAC-SHA256 방식을 선택했는지에 대한 엔지니어링 대안 비교 근거로 사용된다.
출처 / Source
- 원본 URL: https://datatracker.ietf.org/doc/html/rfc9421
- 저자 / 조직: IETF (Internet Engineering Task Force) — R. Backman, M. Sporny, M. Richer
- 발행일: 2023년 6월
- 마지막 확인일: 2026-06-29
핵심 인용 / Key quotes (verbatim)
[§Abstract] "This document describes a mechanism for creating, encoding, and verifying cryptographic signatures over components of HTTP messages. This mechanism supports signing of HTTP headers, HTTP query parameters, and derived components of HTTP messages such as the request URI."
[§Introduction] "Because HTTP message signatures are designed to be applied to and verified from HTTP messages, they are distinct from mechanisms that sign payloads independently (e.g., JSON Web Signature (JWS) [RFC7515])."
[§2.1. Signature Metadata Parameters] "The signature metadata parameters define properties of the signature itself, such as the creation time, expiration time, key identifier, or cryptographic algorithm used to generate the signature."
[§2.1. Signature Metadata Parameters — created] "created: The time at which the signature was generated, represented as a decimal integer indicating seconds since the Unix Epoch."
[§2.1. Signature Metadata Parameters — expires] "expires: The time at which the signature is considered to expire, represented as a decimal integer indicating seconds since the Unix Epoch."
[§2.1. Signature Metadata Parameters — keyid] "keyid: The identifier for the key used to generate the signature. The value MUST be a string."
[§2.3. Derived Components] "derived components: Components of an HTTP message that are not represented by HTTP fields. Derived components include the HTTP method, the request path, the query parameters, and other metadata about the message. Derived component names start with an @ character."
[§2.5. Signature and Signature-Input Fields] "The Signature field is a Dictionary structured field containing the signature value or values. The Signature-Input field is a Dictionary structured field containing the signature parameters for each signature."
[§4. Signature Verification] "To verify a signature, the verifier reconstructs the signature input using the parameters from the Signature-Input field, resolves the key material using the keyid parameter, and validates the signature value."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RFC9421-C1 | RFC 9421은 HTTP 메시지의 헤더, 쿼리 매개변수, 파생 컴포넌트(메서드, 경로 등)를 포괄하여 암호학적 서명을 부여하는 메커니즘임 | "This document describes a mechanism for creating, encoding, and verifying cryptographic signatures over components of HTTP messages." | official-standard |
HTTP 전체 요청/응답 검증 | 애플리케이션 페일로드만을 단독 암호화 서명하는 방식 |
| RFC9421-C2 | HTTP 메시지 서명은 메시지 자체에 바인딩되므로, 페이로드 단독 서명 메커니즘(JWS 등)과는 근본적으로 성격이 다름 | "Because HTTP message signatures are designed to be applied to and verified from HTTP messages, they are distinct from mechanisms that sign payloads independently..." | official-standard |
HTTP 메시지 무결성 보호 | HTTP 메시지가 중계 서버를 거쳐 포맷팅이 변경될 때의 안전성 |
| RFC9421-C3 | 서명 메타데이터 파라미터는 생성 시간(created), 만료 시간(expires), 키 식별자(keyid), 알고리즘 등을 정의할 수 있음 |
"The signature metadata parameters define properties of the signature itself, such as the creation time, expiration time, key identifier, or cryptographic algorithm used to generate the signature." | official-standard |
서명 생명주기 및 다중 시크릿 매핑 | 구체적인 키 회전(rotation) 스토리지 구현체 |
| RFC9421-C4 | 파생 컴포넌트(Derived Components)는 @ 문자로 시작하며 HTTP 메서드(@method), 경로(@path), 쿼리 문자열 등을 의미함 |
"Derived components include the HTTP method, the request path, the query parameters... Derived component names start with an @ character." | official-standard |
HTTP 라우팅 불변성 서명 | 바디 페이로드 내 필드 추출 |
| RFC9421-C5 | 서명 정보는 구조화된 필드(Structured Fields) 스펙에 따라 Signature와 Signature-Input 헤더로 분리되어 전송됨 |
"The Signature field is a Dictionary structured field containing the signature value or values. The Signature-Input field is a Dictionary structured field containing the signature parameters..." | official-standard |
헤더 필드 규격 설계 | 쉼표 구분 단순 헤더 처리 편의성 |
| RFC9421-C6 | 서명 검증은 Signature-Input 매개변수를 기반으로 서명 대상 데이터를 재구성하고 keyid로 키를 해석하여 수행함 |
"To verify a signature, the verifier reconstructs the signature input using the parameters from the Signature-Input field, resolves the key material using the keyid parameter, and validates..." | official-standard |
서명 검증 흐름 제어 | 시크릿 키 관리 권한 설정 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
RFC9421-C1,C4: HTTP 메시지의 라우팅 정보(@method,@path)와 헤더 목록을 정규화하여 서명함으로써, 요청 전체의 변조를 막는 표준 프레임워크 제공.RFC9421-C3: Unix Epoch 단위의 생성(created) / 만료(expires) 타임스탬프 파라미터 및keyid운용.RFC9421-C5:Signature및Signature-Input딕셔너리 구조화 필드 정의.
- 이 자료가 증명하지 않는 것:
- HTTP Body Digest 표준 — RFC 9421 자체는 바디(Body) 내용의 해시 서명을 위해 별도 스펙인 RFC 9530 (
Content-Digest) 과 연계해야 하며, 단독으로 본문 해싱 알고리즘을 강제하지 않음.
- HTTP Body Digest 표준 — RFC 9421 자체는 바디(Body) 내용의 해시 서명을 위해 별도 스펙인 RFC 9530 (
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- RFC 9421은 사양이 매우 방대하고, 파싱 및 정규화 규칙이 복잡하여 외부 라이브러리(예: Tomitribe HTTP Signatures) 의존성이 요구됨.
- 범용적인 SaaS 연동(Stripe, Slack, GitHub)의 웹훅 수신부는 RFC 9421 대신 독자적인 HMAC-SHA256 방식을 채택하고 있어, 내부 B2B 아웃바운드 연동 시 복잡성 대비 표준 획득의 실익이 있는지에 대한 trade-off 분석이 필수임.
메모 / Notes
- Trade-off Decision: RFC 9421은 보안 수준이 매우 높으나, 연동 대상사 수신단 서버에서 서명 검증을 구현하기가 극도로 까다로움. 따라서 skeleton 프로젝트에서는 실무적 타협안으로 **Stripe/Svix 모델(단일 헤더에 타임스탬프, UUID, 서명을 쉼표로 연결하여 바디만을 HMAC 서명하는 스키마)**을 채택하여 연동 복잡성을 낮추기로 결정함.