HTTP 메시지 서명

이 문서에서 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 BCP 14 [RFC2119] 및 [RFC8174] 에 설명된 대로, 그리고 모두 대문자로 나타날 때에만 그렇게 해석되어야 합니다.

"HTTP 메시지", "HTTP 요청", "HTTP 응답", "대상 URI", "게이트웨이", "헤더 필드", "중계자", "요청 대상", "트레일러 필드", "발신자", "메서드", 및 "수신자"라는 용어는 [HTTP]에 정의된 대로 사용됩니다.

간결함을 위해 이 문서에서는 "서명"이라는 용어를 디지털 서명(비대칭 암호를 사용하는 경우)과 키드 MAC(대칭 암호를 사용하는 경우) 모두를 지칭하는 데 사용합니다. 유사하게 동사 "sign"은 특정 서명 베이스에 대해 디지털 서명 또는 키드 MAC 중 어느 하나를 생성하는 것을 의미합니다. "디지털 서명"이라는 한정 용어는 비대칭 암호 서명 연산의 출력을 구체적으로 지칭합니다.

이 문서는 데이터 유형을 지정하기 위해 RFC8941 섹션 3에서 사용하는 용어를 사용합니다: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, 및 Boolean.

이 문서는 ABNF를 사용하여 여러 문자열 구조를 정의하며 다음 ABNF 규칙을 사용합니다: VCHAR, SP, DQUOTE, 및 LF. 또한 [STRUCTURED-FIELDS]의 규칙인 sf-string, inner-list, 및 parameters를 사용합니다. 그리고 [HTTP] 및 [HTTP/1.1]의 field-content, obs-fold, 및 obs-text 규칙을 사용합니다.

HTTP Message Signature:

하나 이상의 HTTP 메시지 부분을 포함하는 디지털 서명 또는 키드 MAC. 특정 HTTP 메시지는 여러 개의 HTTP 메시지 서명을 포함할 수 있습니다.

Signer:

HTTP 메시지 서명을 생성하거나 생성한 엔티티. 여러 엔티티가 서명자로 동작하고 동일한 HTTP 메시지에 별도의 서명을 적용할 수 있습니다.

Verifier:

HTTP 메시지에 대해 HTTP 메시지 서명의 검증을 수행하거나 수행한 엔티티. 하나의 HTTP 메시지 서명은 여러 번, 잠재적으로 다른 엔티티에 의해 검증될 수 있습니다.

HTTP Message Component:

HTTP 메시지의 일부로, HTTP 메시지 서명에 의해 포함될 수 있는 부분.

Derived Component:

지정된 알고리즘 또는 절차를 사용하여 HTTP 메시지로부터 유도된 HTTP 메시지 구성요소. 섹션 2.2 참조.

HTTP Message Component Name:

필드 이름이나 유도된 구성요소 이름과 같이 HTTP 메시지 구성요소의 출처를 식별하는 문자열.

HTTP Message Component Identifier:

HTTP 메시지 구성요소 이름과 모든 매개변수의 조합. 이 조합은 특정 HTTP 메시지 서명 및 해당 서명이 적용되는 HTTP 메시지에 대해 특정 HTTP 메시지 구성요소를 고유하게 식별합니다.

HTTP Message Component Value:

특정 HTTP 메시지 맥락에서 주어진 구성요소 식별자에 연관된 값. 구성요소 값은 HTTP 메시지에서 유도되며 일반적으로 정규화 과정을 거칩니다.

Covered Components:

필드(섹션 2.1) 및 유도된 구성요소(섹션 2.2)에 대한 HTTP 메시지 구성요소 식별자의 순서화된 집합으로, 서명에 의해 포함되는 메시지 구성요소 세트를 나타냅니다. 이 집합은 @signature-params 식별자 자체를 포함하지 않습니다. 이 집합의 순서는 보존되어 서명자와 검증자 사이에 전달되어 서명 베이스의 재구성을 용이하게 합니다.

Signature Base:

서명자와 검증자가 Covered Components 집합과 HTTP 메시지를 사용하여 생성하는 바이트 시퀀스입니다. 서명 베이스는 암호 알고리즘에 의해 처리되어 HTTP 메시지 서명을 생성하거나 검증합니다.

HTTP Message Signature Algorithm:

서명과 검증 과정을 설명하는 암호 알고리즘으로, HTTP_SIGN 및 HTTP_VERIFY 원시를 기준으로 정의되며, 섹션 3.3에 설명되어 있습니다.

Key Material:

서명을 생성하거나 검증하는 데 필요한 키 자료. 키 자료는 종종 명시적 키 식별자와 함께 식별되어 서명자가 어떤 키를 사용했는지 검증자에게 알릴 수 있습니다.

Creation Time:

서명이 생성된 시점을 나타내는 타임스탬프로, 서명자가 주장하는 시간.

Expiration Time:

서명이 더 이상 검증자에 의해 수용되어서는 안 되는 시점을 나타내는 타임스탬프로, 서명자가 주장하는 시간.

Target Message:

HTTP 메시지 서명이 적용되는 대상 HTTP 메시지.

Signature Context:

HTTP 메시지 구성요소 값이 추출되는 데이터 소스. 이 문맥에는 대상 메시지와 서명자 또는 검증자가 가질 수 있는 추가 정보(예: 요청의 전체 대상 URI 또는 응답에 관련된 요청 메시지)가 포함될 수 있습니다.

"UNIX timestamp"라는 용어는 [POSIX.1]의 섹션 4.16이 부르는 "Epoch 이후의 초(second since the Epoch)"를 의미합니다.

이 문서에는 부분적 및 전체 HTTP 메시지의 비규범적 예시가 포함되어 있습니다. 일부 예시는 긴 값에 대해 줄 바꿈을 표시하기 위해 단일 역슬래시(\)를 사용합니다(참조: [RFC8792]). 줄 바꿈에 사용된 \ 문자와 래핑된 줄의 선행 공백은 값의 일부가 아닙니다.

HTTP는 중계자가 다양한 방식으로 메시지를 변환하는 것을 허용하며 때로는 요구합니다. 이로 인해 수신자가 원래 전송된 메시지와 비트 단위로 동일하지 않은 메시지를 받을 수 있습니다. 이런 경우 수신자는 발신자의 HTTP 메시지의 원시 바이트에 대한 무결성 보호를 검증할 수 없습니다. 디지털 서명이나 MAC를 검증하려면 서명자와 검증자가 동일한 서명 베이스를 가져야 하기 때문입니다. 메시지의 정확한 원시 바이트를 서명 베이스의 신뢰할 수 있는 소스로 간주할 수 없으므로, 서명자와 검증자는 각각의 메시지 버전에서 의미를 변경하지 않는 안전한 변경에 견고한 메커니즘을 통해 독립적으로 서명 베이스를 생성해야 합니다.

어떤 변경이 안전한 변경인지 또는 안전하지 않은 변경인지 엄격히 정의하는 것은 여러 이유로 현실적이지 않습니다. 애플리케이션은 다양한 방식으로 HTTP를 사용하고 특정 메시지의 일부(예: 메시지 콘텐츠, 메서드, 특정 헤더 필드)가 관련성이 있는지에 대해 의견이 다를 수 있습니다. 따라서 범용 솔루션은 서명자가 어떤 메시지 구성요소를 서명할지에 대해 어느 정도 제어할 수 있어야 합니다.

HTTP 애플리케이션은 브라우저의 JavaScript 환경처럼 HTTP 메시지에 대한 완전한 접근이나 제어를 제공하지 않는 환경에서 실행되거나, 프로토콜 세부를 추상화하는 라이브러리(예: Java HTTP Client (HttpClient) 라이브러리)를 사용할 수 있습니다. 이러한 애플리케이션은 HTTP 메시지에 대한 지식이 불완전하더라도 서명을 생성하고 검증할 수 있어야 합니다.

• 서로 다른 필드 이름을 가진 필드들의 순서 재배열(RFC9110 섹션 5.3).
• 같은 필드 이름을 가진 필드들의 결합(RFC9110 섹션 5.2).
• Connection 헤더 필드에 나열된 필드의 제거(RFC9110 섹션 7.6.1).
• 제어 옵션을 나타내는 필드의 추가(RFC9110 섹션 7.6.1).
• 전송 코딩의 추가 또는 제거(RFC9110 섹션 7.7).
• Via(RFC9110 섹션 7.6.3) 및 Forwarded(RFC7239 섹션 4)와 같은 필드의 추가.
• HTTP의 다른 버전 간 변환(예: HTTP/1.x에서 HTTP/2로 또는 그 반대).
• 필드 이름, 요청 URI 스킴 또는 호스트와 같은 대소문자를 구별하지 않는 구성요소의 대소문자 변경(예: "Origin" → "origin").
• 요청 대상과 권한이 함께 적용될 때 대상 URI에 변화가 생기지 않는 방식으로의 변경(참조: RFC9110 섹션 7.1).

• 필드 값에서의 선행 또는 후행 공백의 사용, 추가 또는 제거.
• 필드 값에서의 obs-fold 사용, 추가 또는 제거(RFC9112 섹션 5.2).

이러한 유형의 변환은 서명에 의해 포함된 메시지 구성요소에 대해 수행되더라도 서명 검증을 방해해서는 안 된다고 간주됩니다. 또한 서명에 포함되지 않은 구성요소에 대한 모든 변경은 서명 검증을 방해해서는 안 됩니다.

이러한 종류의 변환 예시와 그것이 메시지 서명에 미치는 영향은 부록 B.4에서 찾을 수 있습니다.

반면에, 유도된 구성요소의 값을 변경하거나 포함된 구성요소의 필드 값들을 파싱하고 재직렬화하는 것과 같은 다른 변환은 서명이 대상 메시지에 대해 더 이상 유효하지 않게 만들 수 있습니다. 이 명세를 적용하는 애플리케이션은 기대되는 변환이 Covered Components의 선택으로 적절히 처리되는지 주의해야 합니다.

• Covered Components 목록(섹션 2) 및 요구되거나 기대되는 서명 매개변수(섹션 2.3)의 집합. 예를 들어, 인증 프로토콜은 Authorization 필드를 포함하도록 요구하여 인증 자격 증명을 보호하고 서명 매개변수에 created 매개변수(섹션 2.3)를 포함하도록 요구할 수 있습니다. 반면에 의미상 관련된 HTTP 메시지 콘텐츠를 기대하는 API는 [DIGEST]에 정의된 Content-Digest 필드의 존재 및 포함을 요구하고, API 고유의 tag 매개변수 값을 요구할 수도 있습니다.
• 필수 또는 기대되는 Covered Component 필드나 매개변수의 예상된 Structured Field 타입([STRUCTURED-FIELDS]).
• 서명을 검증하는 데 사용될 키 재료를 검색하는 수단. 애플리케이션은 일반적으로 서명 매개변수(섹션 2.3)의 keyid 매개변수를 사용하고, 그로부터 키를 해석하는 규칙을 정의하지만, 적절한 키가 서명자의 키 사전 등록과 같은 다른 수단으로 알려져 있을 수도 있습니다.
• 서명자가 사용하고 검증자가 수용할 허용 가능한 서명 알고리즘의 집합.
• 검증자가 서명 검증에 사용된 서명 알고리즘이 키 재료와 메시지 문맥에 적합한지 결정하는 수단. 예를 들어 서명 매개변수의 alg 매개변수를 사용하여 알고리즘을 명시적으로 명시하거나, 키 재료로부터 알고리즘을 유도하거나, 서명자와 검증자가 합의한 사전 구성된 알고리즘을 사용할 수 있습니다.
• 주어진 서명에 사용된 키와 알고리즘이 메시지 문맥에 적합한지 결정하는 수단. 예를 들어 ECDSA 서명만 기대하는 서버는 RSA 서명을 거부해야 한다는 것을 알아야 하고, 비대칭 암호만 기대하는 서버는 대칭 암호를 거부해야 합니다.
• HTTP 메시지와 그 애플리케이션 문맥으로부터 메시지 구성요소를 유도할 문맥을 결정하는 수단. 일반적으로 이것은 대상 HTTP 메시지 자체이지만, 문맥은 외부 호스트명과 같은 구성으로 애플리케이션이 알고 있는 추가 정보를 포함할 수 있습니다.
• 섹션 2.4에 제공된 메커니즘을 사용하여 요청과 응답 간 바인딩을 필요로 하는 경우, 그러한 바인딩의 속성을 제공하는 데 필요한 요청 메시지 및 응답 메시지의 모든 요소.
• 서명이 유효하지 않거나 키 재료가 부적절하거나 유효 시간 창이 명세를 벗어나거나 구성요소 값을 계산할 수 없거나 서명 검증 과정 중 기타 오류가 발생할 때 검증자가 서명자에게 반환하는 오류 메시지와 코드. 예를 들어 서명이 인증 메커니즘으로 사용되는 경우 HTTP 상태 코드 401(Unauthorized) 또는 403(Forbidden)이 적절할 수 있습니다. HTTP API의 응답이라면 400(Bad Request)과 같은 상태 코드와 함께 [RFC7807], [RFC9457]와 같은 문제 세부 정보를 포함하여 잘못된 키 재료 사용을 나타낼 수 있습니다.

이러한 매개변수를 선택할 때, 애플리케이션의 검증자가 서명 베이스를 재생성하는 데 필요한 모든 정보에 접근할 수 있어야 한다는 점을 보장해야 합니다. 예를 들어 리버스 프록시 뒤의 서버는 리버스 프록시가 변경한 것처럼 보이는 경우에도 유도된 구성요소 @target-uri를 사용하려면 원래 요청 URI를 알아야 합니다(참조: 섹션 7.4.3). 또한 응답에 서명을 사용하는 애플리케이션은 클라이언트가 서버가 req ("request-response") 매개변수를 사용하여 서명한 요청의 모든 서명된 부분에 접근할 수 있도록 해야 합니다 (섹션 2.4).

이러한 유형의 프로파일링에 대한 세부 사항은 애플리케이션의 권한 범위에 속하며 이 명세의 범위를 벗어납니다. 그러나 몇 가지 추가 고려사항이 섹션 7에서 논의됩니다. 특히 필수 구성요소 식별자 집합을 선택할 때 적용 범위가 애플리케이션에 충분한지 확인하는 주의가 필요합니다(참조: 섹션 7.2.1 및 섹션 7.2.8). 이 명세는 애플리케이션을 위한 전체 보안 시스템의 일부만을 정의합니다. HTTP 메시지 서명을 기반으로 전체 보안 시스템을 구축할 때는 해당 시스템 전체에 대한 보안 분석을 수행하는 것이 중요합니다. AWS Signature Version 4와 같은 역사적 시스템([AWS-SIGv4])은 유사한 메커니즘을 애플리케이션에 적용하는 예시와 영감을 제공할 수 있지만, 이런 과거 시스템의 검토가 HTTP 메시지 서명 적용에 대한 보안 분석의 필요성을 면제하지는 않습니다.

HTTP 필드의 구성요소 이름은 RFC 9110 섹션 5.1에 정의된 필드 이름의 소문자 형태입니다. HTTP 필드 이름은 대소문자를 구분하지 않지만, 구현체는 구성요소 이름으로 사용할 때 소문자 필드 이름(예: content-type, date, etag)을 사용해야 MUST 합니다.

HTTP 필드의 구성요소 값은 대상 메시지의 명명된 헤더 필드에서 가져온 필드 값입니다(자세한 내용은 RFC 9110 섹션 5.5 참조). 필드 값은 추가 매개변수 및 규칙(예: 아래의 req 및 tr 플래그)에 의해 재정의되지 않는 한 대상 메시지의 명명된 헤더 필드에서 가져와야 MUST 합니다. 대부분의 필드에서 필드 값은 [HTTP]에서 권장하는 대로 ASCII 문자열이며, 구성요소 값은 정확히 그 문자열입니다. 일부 구현에서는 다른 인코딩이 존재할 수 있으며, 모든 비-ASCII 필드 값은 서명 베이스에 추가되기 전에 ASCII로 인코딩되어야 MUST 합니다. 섹션 2.1.3에 설명된 bs 매개변수는 이러한 문제가 있는 필드 값을 래핑하는 방법을 제공합니다.

추가 매개변수 및 규칙으로 재정의되지 않는 한, HTTP 필드 값은 RFC 9110 섹션 5.2에서 정의된 대로 단일 값으로 결합되어 구성요소 값을 만들어야 MUST 합니다. 구체적으로, 다중으로 전송된 HTTP 필드는 각 값들을 단일 쉼표와 단일 공백(", ")로 연결하여 결합해야 MUST 합니다. 중계자는 쉼표 사이에 임의의 양의 공백을 넣어 값을 결합할 수 있으며, 검증자가 이 동작을 고려하지 않으면 서명이 실패할 수 있습니다. 강건성을 위해 서명된 메시지는 서명에 포함된 어떤 필드든 단일 인스턴스만 포함하도록 하는 것이 RECOMMENDED 됩니다. 특히 리스트 기반 필드의 값은 아래 엄격한 알고리즘을 사용해 직렬화하는 것이 권장됩니다. 이 접근법은 중계자를 통해 필드 값이 변경될 가능성을 줄입니다. 불가능한 경우 여러 인스턴스가 별도로 전송되어야 할 때에는, 서명자와 검증자는 리스트 기반 필드의 각 개별 필드 값을 모두 취하여 엄격한 알고리즘에 따라 결합하도록 처리하는 것이 RECOMMENDED 됩니다. 해당 필드가 List 또는 Dictionary 타입의 Structured Field라면, 섹션 2.1.1에 설명된 엄격한 Structured Field 직렬화를 요구함으로써 이 효과를 보다 직접적으로 달성할 수 있습니다.

Set-Cookie와 같은 일부 HTTP 필드([COOKIE]) 는 이러한 방식으로 필드 값을 결합하는 문법을 따르지 않아(여러 입력으로부터 결합된 출력이 모호해질 수 있음) 주의가 필요합니다. 구성요소 값은 메시지 서명 처리 과정에서 파싱되지 않고 서명 베이스의 일부로만 사용되지만(섹션 2.5 참조), 이러한 필드를 서명에 포함할 때는 결합된 값이 모호해질 수 있으므로 주의해야 합니다. bs 매개변수(섹션 2.1.3)는 그러한 문제 필드를 래핑하는 방법을 제공합니다. 이 문제에 대한 추가 논의는 섹션 7.5.6을 참조하세요.

1. 메시지에서 필드의 각 인스턴스의 필드 값들을 그들이 발생하는 순서(또는 메시지에서 발생할 순서)로 정렬된 리스트로 만듭니다.
2. 리스트의 각 항목에서 앞뒤의 공백을 제거합니다. HTTP 필드 값은 선행 및 후행 공백을 포함할 수 없으므로, 규격 준수 구현에서는 이 단계가 no-op가 됩니다.
3. 행 내의 오래된 줄 접기(obs-fold)를 제거하고 이를 단일 공백(" ")으로 대체합니다. 이 동작은 RFC 9112 섹션 5.2에 설명된 대로입니다. 이 동작은 HTTP/1.1에 특화된 것이며 내부 줄 접기를 허용하지 않는 다른 HTTP 버전에는 적용되지 않습니다.
4. 값들의 리스트를 각 항목 사이에 단일 쉼표(",")와 단일 공백(" ")을 두고 연결합니다.

그 결과 문자열이 해당 필드의 구성요소 값입니다.

일부 HTTP 필드는 대소문자 구분이 불가능한 값처럼 중간자에 의해 변경될 수 있는 여러 유효 직렬화가 있고 의미적으로 동등한 경우가 있습니다. 이러한 필드를 서명하고 처리하는 애플리케이션은 서명자와 검증자가 동일한 값을 유도할 수 있도록 어떻게 처리할지 고려해야 하며, 이에 대한 논의는 섹션 7.5.2를 참조하세요.

Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
X-OWS-Header:   Leading and trailing whitespace.
X-Obs-Fold-Header: Obsolete
    line folding.
Cache-Control: max-age=60
Cache-Control:    must-revalidate
Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)

"host": www.example.com
"date": Tue, 20 Apr 2021 02:07:56 GMT
"x-ows-header": Leading and trailing whitespace.
"x-obs-fold-header": Obsolete line folding.
"cache-control": max-age=60, must-revalidate
"example-dict": a=1,    b=2;x=1;y=2,   c=(a   b   c)

X-Empty-Header:(SP)

서명 베이스 생성 알고리즘(섹션 2.5)에 의해 콜론과 구성요소 식별자 뒤에 추가된 공백 다음에 빈 문자열 값으로 직렬화됩니다.

"x-empty-header":(SP)

sf

Structured Field 값의 엄격 직렬화(섹션 2.1.1)를 사용하여 구성요소 값이 직렬화되었음을 나타내는 부울 플래그입니다.

key

Dictionary Structured Field에서 단일 멤버 값을 선택하는 데 사용되는 문자열 매개변수(섹션 2.1.2).

bs

개별 필드 값들이 결합되기 전에 Byte Sequence 데이터 구조를 사용해 인코딩됨을 나타내는 부울 플래그(섹션 2.1.3).

req

서명된 응답에서 구성요소 값이 응답 메시지 자체가 아니라 이 응답을 유발한 요청으로부터 유도되었음을 나타내는 부울 플래그. 이 매개변수는 요청을 대상으로 하는 유도된 구성요소 식별자에도 적용될 수 있습니다(섹션 2.4).

tr

필드 값이 RFC 9110 섹션 6.5에 정의된 메시지의 트레일러에서 가져와야 함을 나타내는 부울 플래그입니다. 이 플래그가 없으면 필드 값은 메시지의 헤더 필드에서 가져옵니다(자세한 내용은 섹션 6.3 및 섹션 2.1.4 참조).

여러 매개변수는 함께 지정될 수 MAY 있지만, 일부 조합은 중복되거나 호환되지 않습니다. 예를 들어 key 매개변수가 Dictionary 항목에 사용될 때 그 기능은 이미 포함되어 있으므로 sf 매개변수의 기능은 중복됩니다. 필드 값의 원시 바이트가 요구되는 bs 매개변수는 필드 값을 결합한 이후의 파싱된 데이터 구조를 요구하는 sf 또는 key 매개변수와 호환되지 않습니다.

추가 매개변수는 섹션 6.5에 설정된 "HTTP Signature Component Parameters" 레지스트리에 정의될 수 있습니다.

HTTP 필드 외에도, 제어 데이터, 서명 문맥 또는 서명되는 HTTP 메시지의 다른 측면에서 유도될 수 있는 다양한 구성요소들이 있습니다. 이러한 유도된 구성요소는 구성요소 이름, 가능한 매개변수, 메시지 대상 및 그 구성요소 값의 유도 방법을 정의함으로써 서명 베이스에 포함될 수 있습니다.

유도된 구성요소 이름은 @ 문자로 시작해야 MUST 합니다. 이는 유도된 구성요소 이름을 @ 문자를 포함할 수 없는 HTTP 필드 이름과 구별하기 위함입니다(RFC 9110 섹션 5.1 참조). HTTP 메시지 서명 처리기는 유도된 구성요소 이름을 필드 이름과 별도로 처리해야 MUST 합니다(자세한 내용은 섹션 7.5.1 참조).

@method

요청에 사용된 메서드(섹션 2.2.1).

@target-uri

요청의 전체 대상 URI(섹션 2.2.2).

@authority

요청 대상 URI의 authority(섹션 2.2.3).

@scheme

요청 대상 URI의 스킴(섹션 2.2.4).

@request-target

요청 대상(섹션 2.2.5).

@path

요청 대상 URI의 절대 경로 부분(섹션 2.2.6).

@query

요청 대상 URI의 쿼리 부분(섹션 2.2.7).

@query-param

요청 대상 URI의 파싱되고 인코딩된 개별 쿼리 매개변수(섹션 2.2.8).

@status

응답의 상태 코드(섹션 2.2.9).

추가 유도된 구성요소 이름은 "HTTP Signature Derived Component Names" 레지스트리(섹션 6.4)에 정의됩니다.

유도된 구성요소 값은 서명의 대상 메시지 문맥에서 가져옵니다. 이 문맥은 제어 데이터와 같이 메시지 자체에 대한 정보뿐 아니라 서명자 또는 검증자가 보유한 추가 상태와 문맥 정보를 포함할 수 있습니다. 특히 응답을 서명할 때, 서명자는 req 매개변수를 사용하여 원래 요청에서 유도된 구성요소를 포함할 수 있습니다(섹션 2.4).

request:

RFC 9110 섹션 3.4에 설명된 대로 HTTP 요청 메시지에서 유도된 값 및 그 결과. 서명의 대상 메시지가 응답인 경우, 요청을 대상으로 하는 유도된 구성요소는 req 매개변수를 사용하여 포함될 수 있습니다(섹션 2.4 참조).

response:

HTTP 응답 메시지에서 유도된 값 및 그 결과(RFC 9110 섹션 3.4 참조).

request, response:

요청 메시지 또는 응답 메시지 중 어느 것으로부터 유도된 값.

유도된 구성요소 정의는 적용될 수 있는 모든 대상 메시지 타입을 정의해야 MUST 합니다.

유도된 구성요소 값은 인쇄 가능한 문자와 공백으로 제한되어야 MUST 하고, 줄 바꿈 문자를 포함해서는 MUST NOT 합니다. 또한 유도된 구성요소 값은 공백 문자로 시작하거나 끝나서는 MUST NOT 합니다.

HTTP 메시지 서명에는 서명의 생성 및 검증과 관련된 메타데이터 속성이 있으며, 여기에는 covered components의 순서화된 집합과 매개변수의 순서화된 집합이 포함됩니다. 매개변수에는 서명 생성 시점의 타임스탬프, 검증 키 자료 식별자, 기타 유틸리티가 포함될 수 있습니다. 이 메타데이터는 서명 베이스에서 서명 매개변수용 특수 메시지 구성요소로 표현되며, 이 특수한 메시지 구성요소는 다른 구성요소들과 약간 다르게 취급됩니다. 구체적으로, 서명 매개변수 메시지 구성요소는 서명 베이스의 마지막 라인으로서 포함되는 것이 REQUIRED 하며(섹션 2.5), 구성요소 식별자 집합 내에서 해당 구성요소 식별자 자체를 포함해서는 MUST NOT 합니다.

서명 매개변수 구성요소 이름은 @signature-params입니다.

created:

정수 타입의 UNIX 타임스탬프로서 생성 시간. 서브초 정밀도는 지원되지 않습니다. 이 매개변수의 포함은 RECOMMENDED 됩니다.

expires:

정수 타입의 UNIX 타임스탬프로서 만료 시간. 서브초 정밀도는 지원되지 않습니다.

nonce:

이 서명을 위해 생성된 무작위 고유 값의 문자열 값.

alg:

"HTTP Signature Algorithms" 레지스트리의 HTTP 메시지 서명 알고리즘을 문자열 값으로 지정.

keyid:

키 자료 식별자를 문자열 값으로 지정.

tag:

애플리케이션-특정 태그로서 문자열 값. 이 값은 특정 애플리케이션 또는 프로토콜과 관련된 서명을 식별하는 데 사용됩니다.

추가 매개변수는 "HTTP Signature Metadata Parameters" 레지스트리(섹션 6.3)에 정의될 수 있습니다. 매개변수들은 일반적인 순서가 정해져 있지 않지만, 주어진 매개변수 집합에 대해 순서를 선택하면 그 순서를 변경하지 않는 한 서명 매개변수 값이 변경되지 않습니다.

1. 출력을 빈 문자열로 둡니다.
2. 서명에 포함될 구성요소 식별자들의 순서를 정합니다(자기 자신인 @signature-params 는 제외). 이 순서는 한 번 정해지면 변경할 수 없습니다. 이 순서는 서명 베이스를 생성할 때 사용된 순서(섹션 2.5)와 동일해야 MUST 합니다.
3. covered components의 구성요소 식별자들을 각자의 매개변수를 포함하여 RFC 8941의 Inner List of String 값 규칙에 따라 직렬화한 후 출력에 추가합니다. 구성요소 식별자들은 자체 매개변수를 가질 수 있으며, 이 매개변수들은 순서화된 집합입니다. 구성요소의 매개변수에 대해 순서를 선택하면 해당 순서는 변경할 수 없습니다.
4. 서명 매개변수들에 대한 순서를 정합니다. 이 순서 또한 선택되면 변경할 수 없습니다.
5. 사용 가능한 매개변수들을 RFC 8941의 규칙에 따라 Inner List에 순서대로 추가합니다(이 메시지 서명에 사용되지 않거나 이용할 수 없는 매개변수는 건너뜁니다).
6. 출력은 서명 매개변수 구성요소 값을 포함합니다.

참고로, covered component 값에는 List 직렬화 대신 Inner List 직렬화가 사용되며(이는 섹션 4.1에서 Signature-Input 필드에 이 값을 포함하는 것과의 병렬성을 용이하게 하기 위함입니다), 이는 RFC 8941의 관련 섹션에 설명된 대로입니다.

NOTE: '\' line wrapping per RFC 8792

("@target-uri" "@authority" "date" "cache-control")\
  ;keyid="test-key-rsa-pss";alg="rsa-pss-sha512";\
  created=1618884475;expires=1618884775

하나의 HTTP 메시지가 여러 서명을 포함할 수 있지만(섹션 4.3 참조), 특정 서명에 대해 사용된 서명 매개변수만 해당 서명 매개변수 항목에 포함됩니다.

요청 메시지가 서명된 응답 메시지를 초래할 때, 서명자는 구성요소 식별자에 req 매개변수를 추가하여 요청 메시지의 부분을 서명 베이스에 포함할 수 있습니다.

req

구성요소 값이 응답 메시지 자체가 아니라 이 응답을 유발한 요청에서 유도되었음을 나타내는 부울 플래그입니다.

이 매개변수는 요청을 대상으로 하는 유도된 구성요소와 HTTP 필드 모두에 적용될 수 있으며, 동일한 의미를 갖습니다. 이 매개변수를 사용하는 메시지 구성요소의 구성요소 값은 일반적으로 계산되는 방식과 동일하지만 데이터는 서명이 적용되는 대상 응답 메시지 대신 요청 메시지에서 가져옵니다.

동일한 구성요소 이름은 req 매개변수와 함께 또는 없이 단일 서명 베이스에 포함될 수 MAY 하며, 이는 요청 메시지와 응답 메시지의 동일한 이름 구성요소를 각각 나타냅니다.

req 매개변수는 Dictionary 필드에 대한 key 매개변수와 같이 구성요소 식별자에 적절하게 다른 매개변수들과 결합될 수 MAY 합니다.

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:

{"busy": true, "message": "Your call is very important to us"}

서버는 자체 키로 응답에 서명하면서 이 응용에 대해 합리적인 양의 응답을 포함하는 여러 헤더 필드를 covered components에 포함합니다. 또한 서버는 이 응답을 유발한 원래 요청 메시지에서 유도된 몇몇 구성요소도 포함합니다. 이 예에서는 서버가 요청의 메서드, authority, 경로 및 Content-Digest를 응답 서명의 covered components에 포함합니다. 요청과 응답 모두의 Content-Digest가 응답 서명에 포함됩니다. 이 응용에서는 쿼리가 응답에 관련이 없는 것으로 간주되어 포함되지 않았습니다. 다른 애플리케이션은 섹션 1.4에 논의된 바와 같이 애플리케이션 필요에 따라 다른 결정을 내릴 것입니다.

NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\
  4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:

{"busy": true, "message": "Your call is very important to us"}

여기서 사용된 ECDSA 서명 알고리즘은 비결정적(non-deterministic)이므로, 알고리즘을 실행할 때마다 다른 서명 값이 생성된다는 점을 주의하세요. 제공된 서명 값은 주어진 키로 검증될 수 있으나, 새로 생성된 서명 값이 예시와 일치할 것으로 기대되지는 않습니다(자세한 내용은 섹션 7.3.5 참조).

요청의 구성요소 값이 응답에 반복되어 포함되지 않으므로, 요청자는 응답에서 이 구성요소 식별자 매개변수를 사용하는 서명을 검증할 수 있을 만큼 원래 메시지 구성요소 값을 충분히 오래 보관해야 MUST 합니다. 대부분의 경우 이는 요청자가 원래 요청 메시지를 보관해야 함을 의미합니다. 서명자가 응용의 필요에 따라 요청의 어떤 부분이든 응답에 포함하도록 선택할 수 있기 때문입니다. 중계자가 서버에서 처리되기 전에 요청 메시지를 변경할 수 있으므로, 애플리케이션은 클라이언트가 결과적으로 검증할 수 없게 될 변경된 값을 서명하지 않도록 주의해야 합니다.

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" "@query" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\
  t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\
  d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\
  2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\
  5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\
  0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"@query";req: ?param=Value&Pet=dog
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type";req: application/json
"content-length";req: 18
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\
  dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:

{"busy": true, "message": "Your call is very important to us"}

여기서도 사용된 ECDSA 서명 알고리즘은 비결정적이므로, 알고리즘을 실행할 때마다 다른 서명 값이 생성됩니다. 제공된 서명 값은 주어진 키로 검증될 수 있으나 새로 생성된 서명 값이 예시와 일치할 것으로 기대되지는 않습니다(섹션 7.3.5 참조).

서명된 요청에 응답하여 응답에 서명하는 애플리케이션은 충돌 공격 클래스에 대한 충분한 커버리지와 보호를 제공하기 위해 요청 서명 값의 모든 구성요소를 서명하는 것이 SHOULD 권장됩니다(자세한 내용은 섹션 7.3.7 참조). 이 예의 서버는 클라이언트의 요청에 대한 Signature-Input 필드에 나열된 모든 구성요소를 응답 서명에 포함시켰습니다.

요청 메시지의 Signature 및 Signature-Input 필드를 응답의 서명 구성요소로 포함하는 것이 문법적으로는 가능하지만, 이는 NOT RECOMMENDED 됩니다. 이는 서명들의 서명이 기대하는 것처럼 포함된 구성요소에 대한 전이적((transitive)) 커버리지를 제공하지 않으며 여러 공격에 취약하기 때문입니다(자세한 내용은 섹션 7.3.7 참조). 서명 처리가 성공적으로 이루어졌음을 신호할 필요가 있는 애플리케이션은 그러한 신호를 안전하게 전송하기 위한 대체 메커니즘을 신중히 규정해야 합니다.

이 플래그를 사용할 때 응답 서명이 요청 메시지에 포함된 내용만을 커버할 수 있으므로, 응용이 요청의 메시지 콘텐츠를 응답 서명에 포함할 필요가 있다면 클라이언트는 Content-Digest 필드와 같이 해당 콘텐츠를 커버할 수 있는 수단을 포함해야 합니다. 자세한 내용은 섹션 7.2.8를 참조하세요.

req 매개변수는 요청 메시지를 대상으로 하는 서명에서 어떤 구성요소에도 사용되어서는 MUST NOT 합니다.

서명 베이스는 서명으로 포함된 정규화된 HTTP 메시지 구성요소를 포함하는 ASCII 문자열[ASCII]입니다. 서명 베이스 생성 알고리즘의 입력은 순서화된 covered component 식별자 집합과 그에 연관된 값들, 그리고 섹션 2.3에서 설명된 추가 서명 매개변수들입니다.

구성요소 식별자는 [STRUCTURED-FIELDS]의 엄격한 직렬화 규칙(섹션 4)을 사용하여 직렬화됩니다. 구성요소 식별자는 구성요소 이름을 가지며, 이는 sf-string ABNF 규칙을 사용해 직렬화된 String Item 값입니다. 구성요소 식별자는 또한 parameters ABNF 규칙을 사용해 직렬화되는 정의된 매개변수를 포함할 MAY 있습니다. 섹션 2.3에 정의된 서명 매개변수 라인도 동일한 패턴을 따르지만, 그 구성요소 식별자는 고정 값의 String Item이고 매개변수가 없으며, 구성요소 값은 항상 선택적 매개변수를 가진 Inner List입니다.

이는 구성요소 이름 자체의 직렬화가 큰따옴표로 둘러싸여 있고, 매개변수는 세미콜론으로 구분된 목록으로 따름을 의미합니다. 예: "cache-control", "@authority", "@signature-params", 또는 "example-dictionary";key="foo".

signature-base = *( signature-base-line LF ) signature-params-line
signature-base-line = component-identifier ":" SP
    ( derived-component-value / *field-content )
    ; no obs-fold nor obs-text
component-identifier = component-name parameters
component-name = sf-string
derived-component-value = *( VCHAR / SP )
signature-params-line = DQUOTE "@signature-params" DQUOTE
     ":" SP inner-list

서명 베이스를 생성하려면, 서명자 또는 검증자는 서명의 covered components에 있는 각 구성요소 식별자(및 그 매개변수)에 대한 항목을 다음 알고리즘을 사용해 연결합니다. 아래에 설명된 모든 오류는 즉시 알고리즘을 실패하게 하며 서명 베이스를 출력해서는 안 됩니다.

1. 출력을 빈 문자열로 둡니다.

2. covered components 집합의 각 메시지 구성요소 항목(순서대로)에 대해:

   11.

   구성요소 식별자(매개변수 포함)가 이미 서명 베이스에 추가된 경우, 오류를 발생시킵니다.

   12.

   component-identifier ABNF 규칙에 따라 직렬화된 해당 covered component의 구성요소 식별자를 추가합니다. 이 직렬화는 구성요소 이름을 큰따옴표로 감싸고 매개변수를 따옴표 밖에 붙입니다.

   13.

   단일 콜론(:)을 추가합니다.

   14.

   단일 공백(" ")을 추가합니다.

   15.

   구성요소 식별자에 대한 구성요소 값을 결정합니다.

   • 구성요소 식별자에 이해하지 못하는 매개변수가 있으면 오류를 발생시킵니다.
   • bs와 sf처럼 상호 호환되지 않는 매개변수가 함께 있으면 오류를 발생시킵니다.
   • 구성요소 식별자에 req 매개변수가 있고 대상 메시지가 요청이면 오류를 발생시킵니다.
   • 구성요소 식별자에 req 매개변수가 있고 대상 메시지가 응답이면, 구성요소 값의 문맥은 대상 응답 메시지의 관련 요청 메시지입니다. 그렇지 않으면 구성요소 값의 문맥은 대상 메시지입니다.
   • 구성요소 이름이 @ 문자로 시작하면, 유도된 구성요소에 대해 정의된 특정 규칙에 따라 메시지에서 값을 유도합니다(섹션 2.2 참조). 알려진 유효 매개변수 처리를 포함합니다. 유도된 구성요소 이름을 알 수 없거나 값을 유도할 수 없으면 오류를 발생시킵니다.
   • 구성요소 이름이 @ 문자로 시작하지 않으면, 해당 HTTP 필드 값을 섹션 2.1에 설명된 대로 정규화하고 알려진 유효 매개변수 처리를 포함합니다. 필드를 메시지에서 찾을 수 없거나 문맥에서 값을 얻을 수 없으면 오류를 발생시킵니다.

   16.

   covered component의 정규화된 구성요소 값을 추가합니다.

   17.

   단일 개행(\n)을 추가합니다.

3. 다음과 같이 서명 매개변수 구성요소를 signature-params-line 규칙에 따라 추가합니다:

   11.

   정확한 값 "@signature-params"(큰따옴표 포함)인 서명 매개변수에 대한 구성요소 식별자를 component-identifier 규칙에 따라 직렬화하여 추가합니다.

   12.

   단일 콜론(:)을 추가합니다.

   13.

   단일 공백(" ")을 추가합니다.

   14.

   섹션 2.3에 정의된 대로 서명 매개변수의 정규화된 구성요소 값을 추가합니다(즉, 매개변수를 가진 Inner List Structured Field 값).

4. 출력 문자열에 비ASCII 문자가 포함되어 있으면 오류를 발생시킵니다([ASCII]).
5. 출력 문자열을 반환합니다.

• 서명자나 검증자가 유도된 구성요소 이름을 이해하지 못하는 경우.
• 구성요소 이름이 메시지에 존재하지 않거나 값이 잘못된 필드를 식별하는 경우.
• 구성요소 식별자가 알 수 없거나 해당 구성요소 식별자에 적용되지 않는 매개변수를 포함하는 경우.
• sf 매개변수를 통해 Structured Field 직렬화가 사용된다고 표시되었지만 해당 필드가 Structured Field가 아니거나 Structured Field 타입을 구현체가 모르는 경우.
• 구성요소 식별자가 Dictionary 멤버 식별자인데, 메시지에 해당 필드가 없거나 Dictionary Structured Field가 아니거나 값이 잘못된 경우.
• 구성요소 식별자가 Dictionary 멤버 식별자 또는 명명된 쿼리 매개변수 식별자인데, 해당 멤버가 구성요소 값에 존재하지 않거나 값이 잘못된 경우(예: 식별자가 "example-dict";key="c"인데 Example-Dict 헤더 필드의 값이 a=1, b=2로 c 값이 없는 경우).

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}

위 예시 서명 베이스는 표시된 예시를 끝내는 최종 개행을 포함하지 않으며, 이 명세의 다른 예시 서명 베이스들도 마찬가지입니다.

HTTP 메시지 서명의 생성은 서명 문맥(대상 메시지를 포함)과 애플리케이션 요구사항을 입력으로 받아 서명 값과 서명 매개변수 집합을 출력으로 내보내며, 이는 메시지에 추가되어 검증자에게 전달될 수 있습니다.

1. 서명자는 애플리케이션이 정한 잠재적 서명 알고리즘 집합에서 HTTP 서명 알고리즘과 서명에 사용할 키 자료를 선택합니다. 서명자는 알고리즘의 요구사항(예: 키 크기나 형식)에 적합한 키 자료를 선택해야 MUST 합니다. 알고리즘과 키 자료 선택 메커니즘은 이 문서의 범위를 벗어납니다.
2. 서명자는 서명의 생성 시간을 현재 시각으로 설정합니다.
3. 해당하면, 서명자는 서명이 만료될 시각으로 서명의 만료 시간 속성을 설정합니다. 만료 시간은 검증자에 대한 힌트이며, 서명자가 더 이상 서명을 보증하지 않는 시점을 표현합니다. 적절한 만료 길이와 이 매개변수의 처리 요구사항은 애플리케이션별입니다.

4. 서명자는 서명이 포함할 메시지 구성요소를 나타내는 구성요소 식별자들의 순서화된 집합을 생성하고 이 집합에 서명 메타데이터 매개변수를 첨부합니다. 이 집합의 직렬화 값은 이후 섹션 4.1에 설명된 Signature-Input 필드의 값으로 사용됩니다.

   • covered components의 순서를 한 번 선택하면, 그 순서는 서명의 수명 동안 변경해서는 MUST NOT 합니다.
   • 각 covered component 식별자는 서명 문맥에서 (1) HTTP 필드(섹션 2.1)이거나 (2) 섹션 2.2 또는 "HTTP Signature Derived Component Names" 레지스트리에 등재된 유도된 구성요소여야 MUST 합니다.
   • 요청 서명의 서명자들은 @method, @authority, @target-uri 등과 같은 메시지 제어 데이터를 covered components에 일부 또는 전부 포함하는 것이 SHOULD 권장됩니다.
   • 서명자들은 서명이 생성된 시점을 나타내기 위해 created 서명 메타데이터 매개변수를 포함하는 것이 SHOULD 권장됩니다.
   • @signature-params 유도된 구성요소 식별자는 covered component 식별자 목록에 존재해서는 MUST NOT 합니다. 이 유도된 구성요소는 항상 서명 베이스의 마지막 라인이 되어야 하며, 이를 통해 서명이 항상 자신의 메타데이터를 포함하고 메타데이터를 대체할 수 없도록 보장합니다.
   • 이 집합에 무엇을 포함할지 및 어떤 순서로 할지에 대한 추가 지침은 이 문서의 범위를 벗어납니다.
5. 서명자는 이러한 매개변수들과 함께 서명 베이스 생성 알고리즘(섹션 2.5)을 사용하여 서명 베이스를 생성합니다.
6. 서명자는 선택한 서명 알고리즘과 서명자가 선택한 키 자료를 사용하여 HTTP_SIGN 원시 함수를 이용해 서명 베이스에 서명합니다. HTTP_SIGN 원시와 몇 가지 구체적 서명 알고리즘의 적용은 섹션 3.3에 정의되어 있습니다.
7. 서명 함수의 바이트 배열 출력은 섹션 4.2에 정의된 Signature 필드에 포함될 HTTP 메시지 서명 출력 값입니다.

여기서 사용된 RSA-PSS 알고리즘은 비결정적이므로 알고리즘을 실행할 때마다 다른 서명 값이 생성됩니다. 제공된 서명 값은 주어진 키로 검증될 수 있지만, 새로 생성된 서명 값이 예시와 일치할 것으로 기대되지는 않습니다. 자세한 내용은 섹션 7.3.5를 참조하세요.

HTTP 메시지 서명의 검증은 서명 문맥(대상 메시지, 특히 그 Signature 및 Signature-Input 필드를 포함)과 애플리케이션 요구사항을 입력으로 받아 수행되는 과정입니다. 검증의 출력은 성공적인 검증(긍정) 또는 오류입니다.

1. 섹션 4.1 및 4.2에 설명된 대로 Signature 및 Signature-Input 필드를 파싱하고, 검증할 서명들과 그 레이블을 추출합니다.

   11.

   서명 값이 둘 이상 존재하면, 검증자의 정책 및 구성에 따라 이 메시지에 대해 처리할 서명을 결정합니다. 적용 가능한 서명이 발견되지 않으면 오류를 발생시킵니다.

   12.

   선택된 Signature 필드 값에 대응하는 Signature-Input 필드 값(동일한 레이블을 가진 값)이 없으면 오류를 발생시킵니다.

2. 선택된 Signature-Input 필드의 값을 매개변수화된 Inner List로 파싱하여 검증할 서명의 순서화된 covered components 목록과 서명 매개변수를 얻습니다.
3. 해당 Signature 필드의 값을 파싱하여 검증할 서명의 바이트 배열 값을 얻습니다.
4. 서명 매개변수를 검사하여 서명이 이 문서에 기술된 요구사항과, 애플리케이션이 정의한 추가 요구사항(예: 어떤 메시지 구성요소가 서명되어야 하는지 등)을 충족하는지 확인합니다(섹션 3.2.1 참조).
5. 이 서명에 대한 검증 키 자료를 결정합니다. 키 자료가 정적 구성이나 외부 프로토콜 협상과 같은 외부 수단으로 알려져 있으면, 검증자는 해당 기법으로 키 자료를 얻습니다. 키가 서명 매개변수에 식별되어 있으면 검증자는 그 키 식별자를 역참조하여 적절한 키 자료를 얻습니다. 검증자는 이 컨텍스트에서 키 자료의 신뢰성을 결정해야 합니다. 검증자가 알지 못하거나 신뢰하지 않거나 사전 구성된 것과 일치하지 않는 키가 식별되면 검증은 MUST 실패합니다.

6. 검증에 적용할 알고리즘을 결정합니다:

   11.

   애플리케이션이 알고 있는 허용 가능한 알고리즘 집합으로 시작합니다. 다음 단계 중 어느 하나가 이 집합에 없는 알고리즘을 선택하면 서명 검증은 실패합니다.

   12.

   알고리즘이 정적 구성이나 외부 프로토콜 협상과 같은 외부 수단으로 알려져 있으면, 검증자는 그 알고리즘을 사용합니다.

   13.

   키 자료 자체에 알고리즘 필드가 있어 알고리즘을 결정할 수 있으면, 검증자는 그 알고리즘을 사용합니다.

   14.

   알고리즘이 서명 매개변수에 섹션 2.3의 "HTTP Signature Algorithms" 레지스트리 값을 사용하여 명시되어 있으면, 검증자는 그 알고리즘을 사용합니다.

   15.

   알고리즘이 여러 곳에서 지정된 경우(예: 정적 구성, alg 서명 매개변수, 키 자료 자체의 조합), 해결된 알고리즘들은 동일해야 MUST 합니다. 동일하지 않으면 검증자는 검증을 MUST 실패시킵니다.

7. 수신된 HTTP 메시지와 파싱된 서명 매개변수를 사용하여 섹션 2.5에 정의된 알고리즘을 사용해 서명 베이스를 재생성합니다. @signature-params 입력의 값은 이 서명의 Signature-Input 필드 값이며 섹션 2.3에서 설명된 규칙에 따라 직렬화됩니다. 여기에는 Signature-Input 필드의 레이블은 포함되지 않습니다.
8. 키 자료가 알고리즘에 적합하면, 재생성된 서명 베이스, 키 자료, 서명 값에 대해 적절한 HTTP_VERIFY 암호 검증 알고리즘을 적용합니다. HTTP_VERIFY 원시와 몇 가지 구체적 알고리즘은 섹션 3.3에 정의되어 있습니다.
9. 검증 알고리즘 함수의 결과가 암호 검증의 최종 결과입니다.

위 단계들 중 어느 하나라도 실패하거나 오류를 발생시키면 서명 검증은 실패합니다.

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig1=:HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrl\
  FrCGUDih47vAxi4L2YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxH\
  LMCy8uqK488o+9jrptQ+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSf\
  SvzPuBCh+ARHBmWuNo1UzVVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y\
  9TP5FsZYzHvDqbInkTNigBcE9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7\
  aXq6Am6sfOrpIC49yXjj3ae6HRalVc/g==:

{"hello": "world"}

적어도 method, authority, path, content-digest, content-length, content-type 항목들이 서명되어야 하고, 서명 생성 타임스탬프가 검증 시점에 충분히 최근이어야 한다는 추가 요구사항이 주어지면, 검증은 통과합니다.

HTTP 메시지 서명은 키 자료, 환경, 서명자와 검증자의 요구에 적합한 암호화적 디지털 서명 또는 MAC 방식을 사용해야 MUST 합니다. 이 명세는 사용할 수 있는 서명 알고리즘을 엄격히 제한하지 않으며, 이러한 기본 요구사항을 충족하는 모든 서명 알고리즘은 HTTP 메시지 서명 애플리케이션에서 MAY 사용될 수 있습니다.

HTTP_SIGN (M, Ks)  ->  S

HTTP_VERIFY (M, Kv, S) -> V

다음 섹션들은 몇몇 일반적인 서명 알고리즘을 포함하며, 이러한 암호 원시가 위의 HTTP_SIGN 및 HTTP_VERIFY 정의에 어떻게 대응되는지를 보여줍니다. 어떤 방법을 사용할지는 alg 서명 매개변수(섹션 2.3)에 의해 명시되거나, 키 자료를 참조하거나, 서명자와 검증자 간의 상호 합의로 전달될 수 있습니다. alg 매개변수로 선택된 서명 알고리즘은 "HTTP Signature Algorithms" 레지스트리(섹션 6.2)의 값을 사용해야 MUST 합니다.

NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  created=1618884475;keyid="test-key-rsa-pss"

서명 검증을 용이하게 하기 위해 Signature-Input 필드 값은 서명 베이스의 @signature-params 값 생성에 사용된 동일한 직렬화 값을 반드시 포함해야 MUST 합니다(섹션 2.3 참조). 구조화된 필드 값에서는 리스트 순서와 매개변수 순서를 보존해야 합니다.

서명자는 서명이 메시지 내용을 처리한 이후에 메시지를 서명하기 위해 Signature-Input 필드를 트레일러로 포함할 수 MAY 있습니다. 그러나 중계자는 [HTTP]에 따라 트레일러를 삭제할 수 있으므로, Signature-Input 필드를 서명이 실수로 제거되는 것을 피하기 위해 가능한 경우 헤더 필드로만 포함하는 것이 RECOMMENDED 됩니다.

하나의 HTTP 메시지에 여러 개의 Signature-Input 필드를 포함할 수 MAY 있습니다. 서명 레이블은 모든 필드 값 전반에 걸쳐 고유해야 합니다(MUST).

NOTE: '\' line wrapping per RFC 8792

Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\
  1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\
  C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\
  gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\
  Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\
  BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==:

서명자는 서명이 메시지 내용을 처리한 이후에 메시지를 서명하기 위해 Signature 필드를 트레일러로 포함할 수 MAY 있습니다. 그러나 중계자는 [HTTP]에 따라 트레일러를 삭제할 수 있으므로, Signature 필드를 서명이 실수로 제거되는 것을 피하기 위해 가능한 경우 헤더 필드로만 포함하는 것이 RECOMMENDED 됩니다.

하나의 HTTP 메시지에 여러 개의 Signature 필드를 포함할 수 MAY 있습니다. 서명 레이블은 모든 필드 값 전반에 걸쳐 고유해야 합니다(MUST).

하나의 메시지에 서로 다른 여러 서명을 포함할 수 MAY 있습니다. 각 서로 다른 서명은 고유한 레이블을 가져야 MUST 합니다. 이러한 다중 서명은 동일 서명자가 모두 추가할 수도 있고 여러 다른 서명자들로부터 올 수도 있습니다. 예를 들어, 동일한 메시지 구성요소를 서로 다른 키나 알고리즘으로 서명하여 다양한 검증자 역량을 지원하거나, 리버스 프록시가 클라이언트의 원래 서명 값을 포함하여 서비스 호스트로 요청을 전달할 때 클라이언트에 대한 정보를 필드에 포함시킬 수 있습니다.

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@authority": origin.host.internal.example
"@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type": application/json
"content-length": 18
"forwarded": for=192.0.2.123;host=example.com;proto=https
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length" "forwarded")\
  ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
  ;expires=1618884540

NOTE: '\' line wrapping per RFC 8792

S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\
5o0LV/g==

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
    "content-digest" "content-type" "content-length")\
    ;created=1618884475;keyid="test-key-ecc-p256", \
  proxy_sig=("@method" "@authority" "@path" "content-digest" \
    "content-type" "content-length" "forwarded")\
    ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
    ;expires=1618884540
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
    +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \
  proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\
    JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\
    wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\
    LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\
    lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\
    Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:

{"hello": "world"}

프록시는 또한 원래 메시지의 Signature 및 Signature-Input 필드 값을 새 서명의 covered components에 포함시킬 수 있지만, 이는 서명 값을 서명하는 데 알려진 약점 때문에 NOT RECOMMENDED 됩니다(섹션 7.3.7 참조). 프록시는 클라이언트의 서명을 검증할 수 있는 위치에 있고, 프록시가 메시지에 가하는 변경은 원본 서버가 메시지를 볼 때 기존 서명을 무효화할 것입니다. 이 예에서 원본 서버는 authority 변경을 설명할 추가 정보를 자신의 서명 문맥에 가질 수 있지만, 이는 추가 구성과 각별한 주의를 요구합니다(자세한 내용은 섹션 7.4.4 참조). 다른 애플리케이션에서는 원본 서버가 원래 서명을 직접 검증할 수 없지만, 프록시가 클라이언트 서명을 적절히 검증했음을 확인하기를 원할 수 있습니다. 서명의 성공적인 처리 또는 수신을 신호해야 하는 애플리케이션은 그러한 신호를 안전하게 전송하기 위한 대체 메커니즘을 신중히 규정해야 합니다.

Accept-Signature 필드는 Dictionary Structured Field(섹션 3.2 참조) 로, 대상 HTTP 메시지의 구성요소에서 생성될 하나 이상의 요청된 메시지 서명에 대한 메타데이터를 포함합니다. 각 멤버는 단일 메시지 서명을 설명합니다. 멤버의 키는 대상 HTTP 메시지의 문맥에서 요청된 메시지 서명을 고유하게 식별하는 레이블입니다.

NOTE: '\' line wrapping per RFC 8792

Accept-Signature: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  keyid="test-key-rsa-pss";created;tag="app-123"

구성요소 식별자 목록은 요청된 서명에 포함되어야 할 정확한 구성요소 식별자 집합과 해당되는 모든 구성요소 매개변수를 나타냅니다.

created:

서명자에게 생성 시간(created)을 생성해 포함하도록 요청합니다. 이 매개변수는 서명 요청으로 전송될 때 값이 없습니다.

expires:

서명자에게 만료 시간(expires)을 생성해 포함하도록 요청합니다. 이 매개변수는 서명 요청으로 전송될 때 값이 없습니다.

nonce:

서명자에게 이 매개변수의 값을 대상 서명의 nonce로 포함하도록 요청합니다.

alg:

서명자에게 "HTTP Signature Algorithms" 레지스트리에서 지정된 표시된 서명 알고리즘을 사용하여 대상 서명을 생성하도록 요청합니다.

keyid:

서명자에게 표시된 키 자료를 사용하여 대상 서명을 생성하도록 요청합니다.

tag:

서명자에게 이 매개변수의 값을 대상 서명의 tag로 포함하도록 요청합니다.

1. 필드 값을 Dictionary로 파싱합니다.

2. Dictionary의 각 멤버에 대해:

   11.

   키는 섹션 4.1에 명시된 대로 출력 서명의 레이블로 취합니다.

   12.

   멤버의 값을 파싱하여 covered component 식별자 집합을 얻습니다.

   13.

   covered components가 대상 메시지에 적용 가능한지 판단합니다. 적용되지 않으면 프로세스는 실패하고 오류를 반환합니다.

   14.

   요청된 매개변수(예: 서명 알고리즘 및 키 자료)를 처리합니다. 요청된 매개변수를 이행할 수 없거나 요청된 매개변수가 대상 메시지에 적절하다고 판단되는 것과 충돌하면 프로세스는 실패하고 오류를 반환합니다.

   15.

   서명을 완료하는 데 필요한 추가 매개변수를 선택하고 생성합니다.

   16.

   대상 메시지에 대해 HTTP 메시지 서명을 생성합니다.

   17.

   Signature-Input 및 Signature 필드 값을 생성하고 이를 레이블과 연결합니다.

3. 선택적으로 Accept-Signature 필드에 없는 고유한 레이블로 추가적인 Signature-Input 및 Signature 필드 값을 생성합니다.
4. 모든 레이블된 Signature-Input 및 Signature 필드 값을 결합하여 두 필드를 대상 메시지에 첨부합니다.

이 프로세스에 따라 대상 메시지에 적용된 서명은 동일한 레이블을 가져야 MUST, 동일한 covered components 집합을 포함해야 MUST, 요청된 모든 매개변수를 처리해야 하며 MAY 추가 매개변수를 가질 수 있습니다.

Accept-Signature 필드의 수신자는 애플리케이션 매개변수에 맞지 않는 서명 요청을 무시할 MAY 있습니다.

대상 메시지는 Accept-Signature 필드에 명시되지 않은 추가 서명을 포함할 수 MAY 있습니다. 예를 들어, 추가 메시지 구성요소를 커버하기 위해, 서명자는 추가 구성요소와 요청된 서명의 서명 출력을 포함하는 두 번째 서명을 생성할 수 있습니다.

이 문서는 HTTP 서명 알고리즘을 정의하며, IANA는 "HTTP Signature Algorithms"라는 새 레지스트리를 생성하고 유지합니다. 이 레지스트리의 초기 값은 섹션 6.2.2에 제시되어 있습니다. 향후 할당 및 기존 할당의 수정은 Specification Required 등록 정책을 통해 이루어집니다([RFC8126]).

이 레지스트리에 나열된 알고리즘은 이 명세와 함께 애플리케이션이 사용할 수 있는 일부 암호화 알고리즘을 식별하지만, 항목은 가능한 알고리즘의 전체 목록을 나타내지 않으며 특정 애플리케이션에 대한 적합성을 나타내지 않습니다. 애플리케이션은 서명자와 검증자가 안전하고 결정론적으로 알고리즘 매개변수에 합의할 수 있는 한 필요에 맞는 어떤 알고리즘이라도 구현할 수 있습니다. 애플리케이션이 런타임에 alg 서명 매개변수를 사용해 특정 알고리즘의 사용을 신호해야 할 때, 이 레지스트리는 해당 매개변수 값과 특정 알고리즘 간의 매핑을 제공합니다. 그러나 alg 매개변수의 사용은 알고리즘 혼동 및 대체 공격을 피하기 위해 주의해서 다루어져야 합니다(자세한 내용은 섹션 7 참조).

Status 값은 표준화 상태와 IETF 또는 보안 관련 표준 개발 기구(SDO)와 같은 관련 이해관계자들의 광범위한 의견을 반영해야 합니다. 알고리즘이 처음 등록될 때 지정 전문가는(Designated Expert) 알고리즘이 일반적으로 안전하다고 권고될 합의가 있으면 Status 필드를 "Active"로, 합의가 이루어지지 않은 실험적 알고리즘이라면 "Provisional"로 설정해야 합니다. "Provisional"은 알고리즘이 알려진 취약점이 있음을 의미하지 않으며 단지 보안 속성이 충분히 검증되지 않았음을 나타냅니다. 향후 등록된 알고리즘에 결함이 발견되면 레지스트리 항목을 업데이트하고 "Deprecated" 로 표시할 수 있습니다. 이는 애플리케이션이 특정 알고리즘을 사용할 수 없게 하지는 않지만, 알려진 문제에 대한 경고를 제공하여 고려하도록 합니다. DE는 또한 상태 값에 대한 설명과 참조를 포함하도록 보장해야 하며, 이는 Deprecated 알고리즘에 특히 중요합니다.

• 등록된 알고리즘 식별자가 참조하는 알고리즘이 모든 매개변수(예: salt, hash, 필요한 키 길이)를 완전히 정의하도록 보장합니다.
• 알고리즘 정의가 HTTP_SIGN 및 HTTP_VERIFY 원시 함수의 입력과 출력을 기저 암호 알고리즘에 어떻게 매핑하는지를 완전히 명시하도록 보장합니다.
• 기존 등록의 별칭인 등록 요청을 거부합니다.
• 모든 등록이 섹션 6.2.1에 제시된 템플릿을 따르도록 보장합니다. 여기에는 이름 길이가 지나치지 않으면서도 고유하고 인식 가능하도록 하는 것이 포함됩니다.

이 명세는 알고리즘 이름에 주요 매개변수를 포함시켜 알고리즘 이름이 고유하고 인식 가능하도록 합니다. 그러나 레지스트리의 알고리즘 식별자는 전체 문자열 값으로 해석되어야 하며 부분으로 분해해서 파싱해 매개변수를 결정해서는 안 됩니다. 즉, 구현자들은 rsa-pss-sha512를 특정 해시, 마스크, 소금 값이 정의된 하나의 알고리즘으로 이해해야 하며, 문자열의 부분을 파싱해 매개변수를 결정해서는 안 됩니다.

이 문서는 서명 매개변수 구조(섹션 2.3)를 정의하며, 여기에는 메시지 서명에 대한 메타데이터를 포함하는 매개변수가 있을 수 있습니다. IANA는 "HTTP Signature Metadata Parameters" 라는 새 레지스트리를 생성하고 유지하여 서명 매개변수 구조의 멤버 값에서 사용하기 위해 정의된 매개변수 집합을 기록하고 유지합니다. 이 레지스트리의 초기 값은 섹션 6.3.2에 제시되어 있습니다. 향후 할당 및 수정은 Expert Review 등록 정책을 통해 이루어집니다([RFC8126]).

• 이름이 섹션 6.3.1에 제시된 템플릿을 따르는지 확인합니다; 여기에는 이름의 길이가 지나치지 않으면서도 고유하고 정의된 기능에 대해 인식 가능하도록 하는 것이 포함됩니다.

• 정의된 기능이 명확하고 다른 등록된 매개변수와 충돌하지 않는지 확인합니다.

• 메타데이터 매개변수의 정의에 정상 서명 프로세스의 일부로 사용될 때와 Accept-Signature 필드에서 사용될 때의 동작을 포함하도록 합니다.

이 문서는 HTTP 메시지 구성요소를 정규화하는 방법을 정의하며, HTTP 필드 외부의 대상 메시지 문맥에서 유도할 수 있는 구성요소도 포함합니다. 이러한 유도된 구성요소는 고유한 문자열인 구성요소 이름으로 식별됩니다. 유도된 구성요소의 이름은 항상 "at"(@) 기호로 시작하여 HTTP 필드 이름과 구별됩니다. IANA는 "HTTP Signature Derived Component Names" 라는 새 레지스트리를 생성하고 유지하여 필드가 아닌 구성요소 이름들과 해당 구성요소 값을 생성하는 방법을 기록하고 유지합니다. 초기 값은 섹션 6.4.2에 제시되어 있습니다. 향후 할당 및 수정은 Expert Review 등록 정책을 통해 이루어집니다([RFC8126]).

• 이름이 섹션 6.4.1에 제시된 템플릿을 따르는지 확인합니다; 여기에는 이름 길이가 지나치지 않으면서도 고유하고 정의된 기능에 대해 인식 가능하도록 하는 것이 포함됩니다.
• 등록 요청이 나타내는 구성요소 값이 대상 HTTP 메시지에서 결정론적으로 유도될 수 있는지 확인합니다.
• 등록 요청에 대해 정의된 매개변수가 구성요소 값에 미치는 영향이 명확히 문서화되어 있는지 확인합니다.

DE는 등록이 기존 유도된 구성요소 정의와 충분히 구별되는지 확인해야 합니다.

등록된 항목의 상태를 "Deprecated"로 설정할 때 DE는 비권고 사유와 사용 중단 방법에 대한 지침을 문서화해야 합니다.

이 문서는 여러 종류의 구성요소 식별자를 정의하며, 일부는 특정 상황에서 매개변수화되어 고유한 동작을 제공할 수 있습니다. IANA는 이러한 매개변수 이름들, 이들이 연관된 구성요소 식별자들, 그리고 이 매개변수들이 구성요소 값에 가하는 수정사항을 기록·유지하기 위해 "HTTP Signature Component Parameters"라는 새 레지스트리를 생성하고 유지합니다. 매개변수의 정의는 적용 대상(예: 특정 필드 타입, 유도된 구성요소, 또는 문맥)을 반드시 정의해야 MUST 합니다. 이 레지스트리의 초기 값들은 섹션 6.5.2에 제시되어 있습니다. 향후 할당 및 기존 할당의 수정은 Expert Review 등록 정책을 통해 이루어집니다([RFC8126]).

• 이름이 섹션 6.5.1에 제시된 템플릿을 따르는지 확인합니다. 여기에는 이름의 길이가 지나치지 않으면서도 정의된 기능에 대해 고유하고 인식 가능하도록 보장하는 것이 포함됩니다.
• 등록 시점에 알려진 다른 기존 매개변수들과의 상호작용이나 비호환성이 있다면, 그 점을 필드 정의가 충분히 규정하는지 확인합니다.
• 매개변수가 구성요소 값을 변경하는 경우에는, 매개변수가 적용된 구성요소 식별자에 의해 정의된 구성요소 값이 대상 HTTP 메시지에서 결정론적으로 유도될 수 있는지 확인합니다.

서명자가 동일한 키를 여러 검증자와 함께 사용하거나 하나의 검증자와 함께 시간 경과에 걸쳐 동일한 키를 사용하는 경우, 해당 키의 지속적 사용은 메시지가 전송되는 검증자 집합 전반에 걸쳐 서명자를 추적하는 데 사용될 수 있습니다. 암호 키는 기능적으로 고유하도록 설계되므로 동일한 키를 계속 사용하는 것은 여러 메시지를 서명한 동일한 당사자를 식별하는 강한 지표가 됩니다.

많은 애플리케이션에서는 이것이 바람직한 특성으로, HTTP 메시지 서명이 서명자를 검증자에게 인증하는 데 사용될 수 있게 합니다. 그러나 이는 또한 서명자가 알지 못하는 추적으로 이어질 수 있습니다. 이를 방지하기 위해 서명자는 통신하는 각 검증자마다 다른 키를 사용할 수 있습니다. 때로는 서명자가 특정 검증자에게 메시지를 보낼 때 키를 회전(rotating)할 수도 있습니다. 이러한 접근법은 필요한 다른 추적 방지 기술의 적용을 대체하지는 않습니다.

HTTP 메시지 서명은 서명으로 보호된 정보에 대해 기밀성을 제공하지 않습니다. HTTP 메시지의 내용(모든 필드 값과 서명 값 자체 포함)은 메시지에 접근할 수 있는 모든 당사자에게 평문으로 드러납니다.

전송 수준에서 기밀성을 제공하려면 TLS 또는 동등한 메커니즘을 사용할 수 있으며, 이는 섹션 7.1.2에서 논의된 바와 같습니다.

개발자에게 오류 조건에 대해 유용한 피드백을 제공하는 필요성과 공격자에게 추가 정보를 제공하지 않는 것 사이의 균형을 맞추는 것이 중요합니다. 예를 들어 나이브하지만 유용한 서버 구현은 리소스 요청에 필요한 키 식별자(key identifier)를 표시하려 할 수 있습니다. 누군가가 해당 키를 누가 제어하는지 알게 되면 리소스의 존재와 키로 식별된 당사자 간의 상관관계를 만들 수 있습니다. 이러한 정보에 대한 접근은 공격자가 리소스의 정당한 소유자를 추가 공격 대상으로 삼는 데 사용할 수 있습니다.

이 명세의 핵심 설계 원칙은 서명으로 커버되는 모든 메시지 구성요소가 검증자가 서명 베이스를 재생성하고 서명을 검증할 수 있도록 검증자에게 제공되어야 한다는 것입니다. 결과적으로 애플리케이션이 특정 필드의 서명을 요구하면 검증자는 해당 필드의 값에 접근해야 합니다.

예를 들어, 중간 처리기가 있는 일부 복잡한 시스템에서는 프록시가 서명을 깨뜨릴까 두려워 서명을 깨지 않기 위해 메시지에서 개인정보에 민감한 정보를 제거하지 못하고 전달하는 놀라운 동작이 발생할 수 있습니다. 이 특정 상황을 완화하는 한 가지 방법은 중간자가 스스로 서명을 검증한 다음 메시지를 수정하여 개인정보 민감 정보를 제거하는 것입니다. 이 시점에서 중간자는 다음 목적지에 들어오는 서명이 검증되었음을 알리기 위해 자체 서명을 추가할 수 있으며, 이는 섹션 4.3의 예에서 보여준 바와 같습니다.

이 섹션은 문서 전반의 예제 서명에서 참조되는 암호 키들을 제공합니다. 이 키들은 테스트 목적 이외의 용도로 절대 사용해서는 안 됩니다(MUST NOT).

각 키의 키 식별자는 이 명세의 예제 전반에서 사용됩니다. 이 예제들에서는 서명자와 검증자가 여기 사용된 모든 키 식별자를 명확히 역참조할 수 있고, 사용된 키와 알고리즘이 서명이 제시되는 문맥에 적합하다고 가정합니다.

openssl pkey -text

이 명령은 OpenSSL 버전 1.1.1m으로 테스트되었습니다. 일부 시스템은 이러한 키들을 직접 생성하거나 사용하지 못할 수 있으며 추가 처리가 필요할 수 있습니다. 모든 키는 JWK 형식으로도 제공됩니다.

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Digest: sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ41Q\
  JgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
Content-Length: 23

{"message": "good dog"}

이 예제에서는 리소스 앞에 TLS 종료 리버스 프록시가 위치합니다. 클라이언트는 요청에 서명하지 않고 대신 상호 TLS로 호출합니다. 종료 프록시는 TLS 스트림을 검증하고 [CLIENT-CERT]에 따라 Client-Cert 헤더 필드로 클라이언트의 TLS 인증서를 주입한 다음 이 필드에 서명을 적용합니다. 이 헤더 필드를 서명함으로써 리버스 프록시는 초기 요청의 TLS 매개변수를 자체적으로 검증했음을 증명할 뿐만 아니라 클라이언트의 동작과 독립적으로 백엔드 시스템에 자신을 인증할 수 있습니다.

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@path": /foo
"@query": ?param=Value&Pet=dog
"@method": POST
"@authority": service.internal.example
"client-cert": :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD\
  QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDM\
  FkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXm\
  ckC8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQY\
  DVR0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8B\
  Af8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQ\
  GV4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0\
  Q6bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
"@signature-params": ("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw==

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
Signature-Input: ttrp=("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"
Signature: ttrp=:xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6\
  Mce9315T6xoklyy0yzhD9ah4JHRwMLOgmizw==:

{"hello": "world"}

내부 서비스는 프록시의 서명을 검증할 수 있으므로 클라이언트의 인증서가 적절히 처리되었음을 신뢰할 수 있습니다.

HTTP는 중계자와 애플리케이션이 메시지의 의미론을 변경하지 않으면서 HTTP 메시지를 변환할 수 있도록 허용합니다. HTTP 메시지 서명은 다양한 상황에서 이러한 변환에 대해 강건하도록 설계되었습니다.

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

"@method": GET
"@path": /demo
"@authority": example.org
"accept": application/json, */*
"@signature-params": ("@method" "@path" "@authority" "accept")\
  ;created=1618884473;keyid="test-key-ed25519"

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2&param=added HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Accept-Language: en-US,en;q=0.5
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Referer: https://developer.example.org/demo
Accept: application/json, */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Accept: application/json
Accept: */*
Date: Fri, 15 Jul 2022 14:24:55 GMT
Host: example.org
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

POST /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.com
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: */*
Accept: application/json
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: