1.1. 요구사항 용어

이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 및 "OPTIONAL"은 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석됩니다.¶

1.3. JOSE와의 설계 변경 사항

• 암호화, 서명 및 MAC 적용 메시지를 쉽게 식별하고 일관된 관점을 유지할 수 있도록 단일한 전체 메시지 구조가 정의되었습니다.¶
• 서명된 메시지는 콘텐츠와 관련된 보호 및 비보호 헤더 매개변수와, 서명과 관련된 보호 및 비보호 헤더 매개변수를 구분합니다.¶
• MAC 적용 메시지는 서명된 메시지와 분리됩니다.¶
• MAC 적용 메시지는 MAC 인증 키를 얻기 위해 엔벨로프 메시지와 동일한 수신자 알고리즘 집합을 사용할 수 있습니다.¶
• 이진 데이터를 인코딩하기 위해 base64url 인코딩이 아니라 이진 인코딩이 사용됩니다.¶
• 암호화 알고리즘의 인증 태그가 암호문과 결합되었습니다.¶
• 암호학적 알고리즘 집합은 일부 방향으로는 확장되고 다른 방향으로는 축소되었습니다.¶

1.4. CBOR 데이터 구조를 위한 CDDL 문법

COSE가 처음 작성되었을 때 간결한 데이터 정의 언어(Concise Data Definition Language, CDDL) [RFC8610]는 아직 RFC로 게시되지 않았으므로 COSE가 사용하는 CBOR 데이터 구조를 규범적으로 설명하는 데이터 설명 언어로 사용할 수 없었습니다. 이러한 이유로 여기에서 정의된 CBOR 데이터 객체는 산문으로 설명됩니다. COSE 데이터 객체에 대한 추가적인 비규범 설명은 아래에 설명된 CDDL의 부분집합으로 제공됩니다.¶

이 문서는 먼저 문법을 작업한 다음 그에 맞는 산문을 개발하는 방식으로 작성되었습니다. 그 결과물로서, 산문은 간결한 데이터 정의 언어(CDDL) [RFC8610]가 정의한 원시 타입 문자열을 사용하여 작성되었습니다. 이 명세에서는 다음 원시 타입이 사용됩니다:¶

any:

모든 CBOR 값을 여기에 배치할 수 있게 하는 비특정 값입니다.¶

bool:

불리언 값입니다(true: 주 타입 7, 값 21; false: 주 타입 7, 값 20).¶

bstr:

바이트 문자열(주 타입 2)입니다.¶

int:

부호 없는 정수 또는 음의 정수입니다.¶

nil:

null 값입니다(주 타입 7, 값 22).¶

nint:

음의 정수(주 타입 1)입니다.¶

tstr:

UTF-8 텍스트 문자열(주 타입 3)입니다.¶

uint:

부호 없는 정수(주 타입 0)입니다.¶

이 문서에는 CDDL의 세 가지 구문이 약식 표기로 나타납니다. 이들은 다음과 같습니다:¶

FOO / BAR:

FOO 또는 BAR 중 하나가 여기에 나타날 수 있음을 나타냅니다.¶

[+ FOO]:

타입 FOO가 배열에서 한 번 이상 나타남을 나타냅니다.¶

* FOO:

타입 FOO가 0번 이상 나타남을 나타냅니다.¶

CDDL이 정의한 제약 두 가지도 이 문서에서 사용됩니다. 이들은 다음과 같습니다:¶

type1 .cbor type2:

일반적으로 bstr인 type1의 내용이 type2의 값을 포함함을 나타냅니다.¶

type1 .size integer:

type1의 내용이 integer 바이트 길이임을 나타냅니다.¶

산문 설명과 함께, CBOR 데이터 구조에 대한 문법이 앞서 설명한 CDDL의 부분집합으로 제시됩니다. CDDL 문법은 정보성이고, 산문 설명은 규범적입니다.¶

수집된 CDDL은 아래 XPath 표현식을 통해 이 문서의 XML 버전에서 추출할 수 있습니다. (사용하는 XPath 평가기에 따라 >를 엔터티로 처리해야 할 수도 있습니다.)¶

//sourcecode[@type='cddl']/text()

CDDL은 초기 비단말 기호가 파일의 첫 번째 기호일 것을 기대합니다. 이러한 이유로 CDDL의 첫 번째 조각이 여기에 제시됩니다.¶

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; This is defined to make the tool quieter:
Internal_Types = Sig_structure / Enc_structure / MAC_structure

비단말 Internal_Types는 이 문서 작성 중 사용된 자동화된 검증 도구를 처리하기 위해 정의됩니다. 이는 보안 계산에는 사용되지만 전송을 위해 방출되지는 않는 비단말들을 참조합니다.¶

1.5. CBOR 관련 용어

JSON에서는 맵을 객체라고 부르며, 맵 키의 종류는 텍스트 문자열 하나뿐입니다. COSE에서는 텍스트 문자열, 음의 정수 및 부호 없는 정수를 맵 키로 사용합니다. 정수는 인코딩의 간결성과 쉬운 비교를 위해 사용됩니다. 텍스트 문자열을 포함하면 짧게 인코딩된 값의 추가 범위를 사용할 수도 있습니다. "key"라는 단어는 주로 암호학적 키라는 다른 의미로 사용되므로, 맵 키로서의 이 용례에는 "label"이라는 용어를 사용합니다.¶

이 명세가 정의하는 CBOR 맵에서 텍스트 문자열도 정수도 아닌 label이 존재하는 것은 오류입니다. 애플리케이션은 처리를 실패시킬 수도 있고 잘못된 label을 무시하여 메시지를 처리할 수도 있습니다. 그러나 애플리케이션은 잘못된 label이 있는 메시지를 생성해서는 MUST NOT 됩니다.¶

CDDL 문법 조각은 앞 문단에서와 같이 "label" 비단말과, 임의의 값을 사용할 수 있게 하는 "values"를 정의합니다.¶

label = int / tstr
values = any

3.1. 공통 COSE 헤더 매개변수

이 섹션은 공통 헤더 매개변수 집합을 정의합니다. 이러한 헤더 매개변수의 요약은 표 3에서 찾을 수 있습니다. 이 표는 label의 값과 값의 타입을 결정할 때 참조해야 합니다.¶

이 섹션에서 정의되는 헤더 매개변수 집합은 다음과 같습니다:¶

alg:

이 헤더 매개변수는 보안 처리에 사용되는 알고리즘을 나타내는 데 사용됩니다. 이 헤더 매개변수는 그렇게 할 수 있는 능력이 존재하는 경우 인증되어야 MUST 합니다. 이 지원은 AEAD 알고리즘 또는 구성 (예: COSE_Sign 및 COSE_Mac0)에 의해 제공됩니다. 이 인증은 헤더 매개변수를 protected-header-parameters 버킷에 배치하거나 외부에서 제공된 데이터(섹션 4.3)의 일부로 배치하여 수행할 수 있습니다. 값은 "COSE Algorithms" 레지스트리([COSE.Algorithms] 참조)에서 가져옵니다.¶

crit:

이 헤더 매개변수는 메시지를 처리하는 애플리케이션이 이해해야 하는 보호 헤더 매개변수를 나타내는 데 사용됩니다. 이 문서에서 정의된 헤더 매개변수는 모든 구현이 이해해야 하므로 포함될 필요가 없습니다. 또한 [RFC8152]에서 정의한 "counter signature" 헤더 매개변수(label 7)는, 해당 문서를 준수하고 모든 구현이 이를 이해한다고 가정하는 송신자와의 호환성을 유지하기 위해 새 구현이 반드시 이해해야 합니다. "crit" 헤더 매개변수가 존재하는 경우, protected-header-parameters 버킷에 배치되어야 MUST 합니다. 배열에는 적어도 하나의 값이 있어야 MUST 합니다.¶

모든 헤더 매개변수 label이 "crit" 헤더 매개변수에 포함될 필요는 없습니다. 어떤 헤더 매개변수를 배열에 배치할지 결정하는 규칙은 다음과 같습니다:¶

• 0부터 7까지의 범위에 있는 정수 label은 생략하는 것이 SHOULD 됩니다.¶
• -1부터 -128까지의 범위에 있는 정수 label은 생략할 수 있습니다. 알고리즘은 label의 내용을 처리할 수 있는 능력이 알고리즘 구현의 핵심으로 간주되는 경우 이 범위에 label을 할당할 수 있습니다. 알고리즘은 이 범위 밖의 label을 할당하고, label의 내용을 처리할 수 있는 능력이 알고리즘의 핵심 기능으로 간주되지는 않지만 이 인스턴스를 올바르게 처리하기 위해 이해되어야 하는 경우 이를 "crit" 헤더 매개변수에 포함할 수 있습니다. -129부터 -65536까지의 범위에 있는 정수 label은 일반적으로 지원되지 않을 수 있는 덜 일반적인 헤더 매개변수이므로 포함하는 것이 SHOULD 됩니다.¶
• 애플리케이션에 필요한 헤더 매개변수의 label은 생략될 수 MAY 있습니다. 애플리케이션은 label을 생략할 수 있는지 여부를 선언하는 진술을 가져야 합니다.¶

"crit"로 표시된 헤더 매개변수는 보안 라이브러리 코드 또는 보안 라이브러리를 사용하는 애플리케이션이 처리할 수 있습니다. 유일한 요구사항은 헤더 매개변수가 처리된다는 것입니다. "crit" 값 목록에 protected-header-parameters 버킷에 없는 헤더 매개변수에 대한 label이 포함되어 있으면, 이는 메시지 처리에서 치명적인 오류입니다.¶

content type:

이 헤더 매개변수는 "payload" 또는 "ciphertext" 필드에 있는 데이터의 콘텐츠 유형을 나타내는 데 사용됩니다. 정수는 "CoAP Content-Formats" IANA 레지스트리 표 [COAP.Formats]에서 옵니다. 텍스트 값은 "<type-name>/<subtype-name>" 구문을 따르며, 여기서 <type-name> 및 <subtype-name>은 섹션 4.2 of [RFC6838]에 정의되어 있습니다. 앞뒤 공백은 허용되지 않습니다. 텍스트 콘텐츠 유형 값은 매개변수 및 하위 매개변수와 함께 IANA "Media Types" 레지스트리를 사용하여 찾을 수 있습니다. 콘텐츠 구조가 잠재적으로 모호한 경우 애플리케이션은 이 헤더 매개변수를 제공하는 것이 SHOULD 됩니다.¶

kid:

이 헤더 매개변수는 필요한 암호학적 키를 찾기 위한 입력으로 사용할 수 있는 데이터 조각 하나를 식별합니다. 이 헤더 매개변수의 값은 COSE_Key 구조의 "kid" 멤버와 대조될 수 있습니다. 다른 키 배포 방법은 대조할 동등한 필드를 정의할 수 있습니다. 애플리케이션은 "kid" 값이 고유하다고 가정해서는 MUST NOT 됩니다. 같은 "kid" 값을 가진 키가 둘 이상 있을 수 있으므로, 이 "kid"와 연관된 모든 키를 확인해야 할 수도 있습니다. "kid" 값의 내부 구조는 정의되어 있지 않으며 애플리케이션이 이에 의존할 수 없습니다. 키 식별자 값은 어떤 키를 사용할지에 대한 힌트입니다. 이는 보안에 중요한 필드가 아닙니다. 이러한 이유로 비보호 헤더 매개변수 버킷에 배치할 수 있습니다.¶

IV:

이 헤더 매개변수는 초기화 벡터(IV) 값을 보관합니다. 일부 대칭 암호화 알고리즘에서는 이를 nonce라고 부를 수 있습니다. AE 및 AEAD 알고리즘의 경우 IV를 수정하면 복호화가 실패하므로, IV는 비보호 버킷에 배치할 수 있습니다.¶

Partial IV:

이 헤더 매개변수는 IV 값의 일부를 보관합니다. COSE_Encrypt0 구조를 사용할 때 IV의 일부는 키와 연관된 context(Context IV)의 일부가 될 수 있고, 일부는 각 메시지마다 변경될 수 있습니다(Partial IV). 이 필드는 각 메시지마다 IV가 변경되도록 하는 값을 전달하는 데 사용됩니다. 값을 수정하면 복호화가 쉽게 감지할 수 있는 깨진 평문을 산출하므로 Partial IV는 비보호 버킷에 배치할 수 있습니다. "Initialization Vector" 및 "Partial Initialization Vector" 헤더 매개변수는 같은 보안 계층에 둘 다 존재해서는 MUST NOT 됩니다.¶

메시지 IV는 다음 단계에 의해 생성됩니다:¶

1. Partial IV를 IV의 길이(알고리즘에 의해 결정됨)에 맞춰 왼쪽에 0을 채웁니다.¶
2. 채워진 Partial IV를 Context IV와 XOR합니다.¶

이 섹션에서 정의된 헤더 매개변수 집합을 나타내는 CDDL 조각이 아래에 제시되어 있습니다. 각 헤더 매개변수는 모든 맵에 있을 필요가 없기 때문에 선택 사항으로 표시되어 있습니다. 특정 맵에서 필요한 헤더 매개변수는 위에서 논의됩니다.¶

Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? ( 5 => bstr //    ; IV
        6 => bstr )     ; Partial IV
)

4.1. 하나 이상의 서명자로 서명하기

COSE_Sign 구조는 하나 이상의 서명이 메시지 페이로드에 적용될 수 있게 합니다. 콘텐츠와 관련된 헤더 매개변수 및 서명과 관련된 헤더 매개변수는 서명 자체와 함께 전달됩니다. 이러한 헤더 매개변수는 서명으로 인증될 수도 있고, 단순히 존재할 수도 있습니다. 콘텐츠에 대한 헤더 매개변수의 예는 content type 헤더 매개변수입니다. 서명에 대한 헤더 매개변수의 예는 서명을 만드는 데 사용된 알고리즘과 키입니다.¶

[RFC5652]는 다음과 같이 나타냅니다:¶

둘 이상의 서명이 존재하는 경우, 주어진 서명자와 연결된 하나의 서명이 성공적으로 검증되면 일반적으로 그 서명자가 성공적으로 서명한 것으로 처리됩니다. 그러나 다른 규칙이 필요한 애플리케이션 환경도 있습니다. 각 서명자에 대해 하나의 유효한 서명 이외의 규칙을 사용하는 애플리케이션은 해당 규칙을 명시해야 합니다. 또한 서명자 식별자를 단순히 일치시키는 것만으로는 서명이 동일한 서명자에 의해 생성되었는지 판단하기에 충분하지 않은 경우, 애플리케이션 명세는 어떤 서명이 동일한 서명자에 의해 생성되었는지 판단하는 방법을 설명해야 합니다. 서로 다른 수신자 커뮤니티를 지원하는 것이 서명자가 둘 이상의 서명을 포함하도록 선택하는 주된 이유입니다.¶

예를 들어, COSE_Sign 구조는 Edwards-curve Digital Signature Algorithm(EdDSA) [RFC8032] 및 Elliptic Curve Digital Signature Algorithm(ECDSA) [DSS]로 생성된 서명을 포함할 수 있습니다. 이를 통해 수신자는 한 알고리즘 또는 다른 알고리즘과 연결된 서명을 검증할 수 있습니다. 다중 서명 평가에 대한 더 자세한 정보는 [RFC5752]에서 찾을 수 있습니다.¶

서명 구조는 사용될 context에 따라 태그가 지정된 형식 또는 태그가 지정되지 않은 형식으로 인코딩될 수 있습니다. 태그가 지정된 COSE_Sign 구조는 CBOR 태그 98로 식별됩니다. 이를 나타내는 CDDL 조각은 다음과 같습니다:¶

COSE_Sign_Tagged = #6.98(COSE_Sign)

COSE Signed Message는 두 부분으로 정의됩니다. 본문과 메시지에 대한 정보를 전달하는 CBOR 객체를 COSE_Sign 구조라고 합니다. 서명과 서명에 대한 정보를 전달하는 CBOR 객체를 COSE_Signature 구조라고 합니다. COSE Signed Message의 예는 부록 C.1에서 찾을 수 있습니다.¶

COSE_Sign 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

payload:

이 필드는 서명될 직렬화된 콘텐츠를 포함합니다. payload가 메시지에 존재하지 않는 경우, 애플리케이션은 payload를 별도로 제공해야 합니다. payload는 변경 없이 전송되도록 보장하기 위해 bstr로 래핑됩니다. payload가 별도로 전송되는 경우("분리된 콘텐츠"), 이 위치에는 nil CBOR 객체가 배치되며, 변경 없이 전송되도록 보장하는 것은 애플리케이션의 책임입니다.¶

참고: 메시지 복구 알고리즘을 사용하는 서명(섹션 8.1)이 사용되는 경우, 복구될 수 있는 최대 바이트 수는 원래 payload의 길이입니다. 인코딩된 payload의 크기는 복구될 바이트 수만큼 줄어듭니다. 원래 payload의 모든 바이트가 소비되는 경우, 전송되는 payload는 존재하지 않는 것으로 인코딩되는 것이 아니라 길이가 0인 바이트 문자열로 인코딩됩니다.¶

signatures:

이 필드는 서명의 배열입니다. 각 서명은 COSE_Signature 구조로 표현됩니다.¶

COSE_Sign에 대한 위 텍스트를 나타내는 CDDL 조각은 다음과 같습니다.¶

COSE_Sign = [
    Headers,
    payload : bstr / nil,
    signatures : [+ COSE_Signature]
]

COSE_Signature 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

signature:

이 필드는 계산된 서명 값을 포함합니다. 필드의 타입은 bstr입니다. 알고리즘은 서명 값이 8비트의 배수가 아닌 경우 패딩을 명시해야 MUST 합니다.¶

COSE_Signature에 대한 위 텍스트를 나타내는 CDDL 조각은 다음과 같습니다.¶

COSE_Signature =  [
    Headers,
    signature : bstr
]

4.3. 외부에서 제공된 데이터

COSE가 제공하는 기능 중 하나는 애플리케이션이 인증되어야 하지만 COSE 객체의 일부로는 전달되지 않는 추가 데이터를 제공할 수 있는 능력입니다. 이를 지원하는 주된 이유는 CoAP 메시지 구조 [RFC7252]를 살펴보면 알 수 있는데, 여기에는 옵션이 payload 앞에 전달될 수 있는 기능이 존재합니다. 이 위치에 배치될 수 있는 데이터의 예로는 CoAP 코드 또는 CoAP 옵션이 있습니다. 데이터가 CoAP 메시지의 헤더에 있으면, 프록시가 프록시 작업을 수행하는 데 도움을 주기 위해 이를 사용할 수 있습니다. 예를 들어, Accept 옵션은 적절한 값이 프록시의 캐시에 있는지 프록시가 결정하는 데 사용될 수 있습니다. 송신자는 additional-data 기능을 사용하여 프록시 또는 공격자가 Accept 값 집합에 가한 변경을 감지할 수 있게 할 수 있습니다. 필드를 외부에서 제공된 데이터에 포함하면, 이후 수정은 서버의 메시지 처리가 실패하도록 만듭니다.¶

이 문서는 외부에서 제공된 인증 데이터의 바이트 배열을 사용하는 절차를 설명합니다. 바이트 배열을 구성하는 방법은 애플리케이션의 함수입니다. 이 기능을 사용하는 애플리케이션은 외부에서 제공된 인증 데이터가 어떻게 구성될지를 정의해야 합니다. 그러한 구성은 다음 문제들을 고려해야 합니다:¶

• 여러 항목이 포함되는 경우, 애플리케이션은 서로 다른 입력이 동일한 바이트 문자열을 생성할 수 없도록 보장해야 합니다. 문제가 되는 시나리오가 발생할 수 있는 예는 텍스트 문자열 "AB"와 "CDE"를 연결하거나 텍스트 문자열 "ABC"와 "DE"를 연결하는 것입니다. 이는 보통 필드를 고정 폭으로 만들거나, 필드의 길이를 출력의 일부로 인코딩함으로써 해결됩니다. CoAP [RFC7252]의 옵션을 예로 들면, 이러한 필드는 TLV 구조를 사용하므로 문제 없이 연결될 수 있습니다.¶
• 여러 항목이 포함되는 경우, 항목에 대한 순서가 정의되어야 합니다. CoAP의 옵션을 예로 들면, 애플리케이션은 필드가 옵션 번호에 따라 정렬되어야 한다고 명시할 수 있습니다.¶
• 애플리케이션은 바이트 문자열이 양쪽에서 동일할 것임을 보장해야 합니다. CoAP의 옵션을 사용하면 같은 상대 번호가 유지되는 경우 문제가 생길 수 있습니다. 중간 노드가 옵션을 삽입하거나 제거하여 상대 번호가 수행되는 방식을 변경할 수 있습니다. 애플리케이션은 상대 번호가 외부 데이터에 있는 옵션에 대해서만 상대적이도록 다시 인코딩되어야 한다고 명시해야 합니다.¶

4.4. 서명 및 검증 프로세스

서명을 생성하려면 잘 정의된 바이트 문자열이 필요합니다. Sig_structure는 정규 형식을 만드는 데 사용됩니다. 이 서명 및 검증 프로세스는 본문 정보(COSE_Sign 또는 COSE_Sign1), 서명자 정보 (COSE_Signature), 그리고 애플리케이션 데이터(외부 소스)를 입력으로 받습니다. Sig_structure는 CBOR 배열입니다. Sig_structure의 필드는 순서대로 다음과 같습니다:¶

1. 서명의 context를 식별하는 context 텍스트 문자열입니다. context 텍스트 문자열은 다음과 같습니다:¶

   • COSE_Signature 구조를 사용하는 서명의 경우 "Signature"입니다.¶
   • COSE_Sign1 구조를 사용하는 서명의 경우 "Signature1"입니다.¶
2. 본문 구조의 보호 속성으로, bstr 타입으로 인코딩됩니다. 보호 속성이 없는 경우, 길이가 0인 바이트 문자열이 사용됩니다.¶
3. 서명자 구조의 보호 속성으로, bstr 타입으로 인코딩됩니다. 보호 속성이 없는 경우, 길이가 0인 바이트 문자열이 사용됩니다. 이 필드는 COSE_Sign1 서명 구조에서는 생략됩니다.¶
4. 애플리케이션에서 외부로 제공한 데이터로, bstr 타입으로 인코딩됩니다. 이 필드가 제공되지 않으면 기본값은 길이가 0인 바이트 문자열입니다. (이 필드를 구성하는 데 대한 애플리케이션 지침은 섹션 4.3을 참조하십시오.)¶
5. 서명될 payload로, bstr 타입으로 인코딩됩니다. 전송 방식과 무관하게 전체 payload가 여기에서 사용됩니다.¶

위 텍스트를 설명하는 CDDL 조각은 다음과 같습니다:¶

Sig_structure = [
    context : "Signature" / "Signature1",
    body_protected : empty_or_serialized_map,
    ? sign_protected : empty_or_serialized_map,
    external_aad : bstr,
    payload : bstr
]

서명을 계산하는 방법:¶

1. Sig_structure를 생성하고 적절한 필드로 채웁니다.¶
2. 섹션 9에 설명된 인코딩을 사용하여 Sig_structure를 바이트 문자열로 인코딩함으로써 ToBeSigned 값을 생성합니다.¶
3. 서명 생성 알고리즘을 호출하여 K(서명에 사용할 키), alg(서명에 사용할 알고리즘), ToBeSigned(서명할 값)를 전달합니다.¶
4. 결과 서명 값을 올바른 위치에 배치합니다. 이는 COSE_Signature 또는 COSE_Sign1 구조의 "signature" 필드입니다.¶

서명을 검증하는 단계는 다음과 같습니다:¶

1. Sig_structure를 생성하고 적절한 필드로 채웁니다.¶
2. 섹션 9에 설명된 인코딩을 사용하여 Sig_structure를 바이트 문자열로 인코딩함으로써 ToBeSigned 값을 생성합니다.¶
3. 서명 검증 알고리즘을 호출하여 K(검증에 사용할 키), alg(서명에 사용된 알고리즘), ToBeSigned(서명할 값), sig(검증할 서명)를 전달합니다.¶

서명 검증을 수행하는 것에 더해, 애플리케이션은 작업을 수행하기 전에 키가 서명 신원과 올바르게 짝지어져 있는지, 그리고 서명 신원이 권한을 부여받았는지 보장하기 위한 적절한 검사를 수행합니다.¶

5.1. 엔벨로프 COSE 구조

엔벨로프 구조는 메시지의 하나 이상의 수신자를 허용합니다. 메시지에는 콘텐츠에 대한 헤더 매개변수와 수신자 정보에 대한 헤더 매개변수가 전달될 수 있는 장치가 있습니다. 콘텐츠와 연결된 보호 헤더 매개변수는 콘텐츠 암호화 알고리즘에 의해 인증됩니다. 수신자와 연결된 보호 헤더 매개변수는 알고리즘이 이를 지원하는 경우 수신자 알고리즘에 의해 인증됩니다. 콘텐츠에 대한 헤더 매개변수의 예로는 콘텐츠의 유형과 콘텐츠 암호화 알고리즘이 있습니다. 수신자에 대한 헤더 매개변수의 예로는 수신자의 키 식별자와 수신자의 암호화 알고리즘이 있습니다.¶

평문과 키를 암호화하는 데 동일한 기법과 거의 동일한 구조가 사용됩니다. 이는 콘텐츠 계층과 수신자 계층에 서로 다른 구조를 사용하는 "Cryptographic Message Syntax (CMS)" [RFC5652] 및 "JSON Web Encryption (JWE)" [RFC7516]의 접근 방식과 다릅니다. 두 구조가 정의됩니다. 암호화된 콘텐츠를 보관하는 COSE_Encrypt와 수신자에 대한 암호화된 키를 보관하는 COSE_recipient입니다. 엔벨로프 메시지의 예는 부록 C.3에서 찾을 수 있습니다.¶

COSE_Encrypt 구조는 사용될 context에 따라 태그가 지정된 형식 또는 태그가 지정되지 않은 형식으로 인코딩될 수 있습니다. 태그가 지정된 COSE_Encrypt 구조는 CBOR 태그 96으로 식별됩니다. 이를 나타내는 CDDL 조각은 다음과 같습니다:¶

COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)

COSE_Encrypt 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

ciphertext:

이 필드는 bstr로 인코딩된 암호문을 포함합니다. 암호문이 암호화 프로세스에 대한 제어 정보와 독립적으로 전송되어야 하는 경우(즉, 분리된 콘텐츠), 필드는 nil 값으로 인코딩됩니다.¶

recipients:

이 필드는 수신자 정보 구조의 배열을 포함합니다. 수신자 정보 구조의 타입은 COSE_recipient입니다.¶

위 텍스트에 대응하는 CDDL 조각은 다음과 같습니다:¶

COSE_Encrypt = [
    Headers,
    ciphertext : bstr / nil,
    recipients : [+COSE_recipient]
]

COSE_recipient 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

ciphertext:

이 필드는 bstr로 인코딩된 암호화된 키를 포함합니다. 모든 인코딩된 키는 대칭 키이며, 키의 이진 값이 콘텐츠입니다. 암호화된 키가 없는 경우, 이 필드는 nil 값으로 인코딩됩니다.¶

recipients:

이 필드는 수신자 정보 구조의 배열을 포함합니다. 수신자 정보 구조의 타입은 COSE_recipient입니다(이에 대한 예는 부록 B에서 찾을 수 있습니다). 수신자 정보 구조가 없는 경우, 이 요소는 존재하지 않습니다.¶

COSE_recipient에 대한 위 텍스트에 대응하는 CDDL 조각은 다음과 같습니다:¶

COSE_recipient = [
    Headers,
    ciphertext : bstr / nil,
    ? recipients : [+COSE_recipient]
]

5.2. 단일 수신자 암호화

COSE_Encrypt0 암호화 구조에는 메시지의 수신자를 명시하는 기능이 없습니다. 이 구조는 객체의 수신자가 메시지를 복호화하는 데 사용할 키의 신원을 이미 알고 있다고 가정합니다. 수신자에게 키를 식별해 줄 필요가 있다면, 엔벨로프 구조가 사용되어야 합니다.¶

암호화된 메시지의 예는 부록 C.4에서 찾을 수 있습니다.¶

COSE_Encrypt0 구조는 사용될 context에 따라 태그가 지정된 형식 또는 태그가 지정되지 않은 형식으로 인코딩될 수 있습니다. 태그가 지정된 COSE_Encrypt0 구조는 CBOR 태그 16으로 식별됩니다. 이를 나타내는 CDDL 조각은 다음과 같습니다:¶

COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

COSE_Encrypt0 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

ciphertext:

이는 섹션 5.1에 설명된 것과 같습니다.¶

위 텍스트에 대응하는 COSE_Encrypt0에 대한 CDDL 조각은 다음과 같습니다:¶

COSE_Encrypt0 = [
    Headers,
    ciphertext : bstr / nil,
]

5.3. AEAD 알고리즘을 위한 암호화 및 복호화 방법

AEAD 알고리즘을 위한 암호화 알고리즘은 상당히 단순합니다. 첫 번째 단계는 인증된 데이터 구조에 대해 일관된 바이트 문자열을 만드는 것입니다. 이를 위해 Enc_structure를 사용합니다. Enc_structure는 CBOR 배열입니다. Enc_structure의 필드는 순서대로 다음과 같습니다:¶

1. 인증된 데이터 구조의 context를 식별하는 context 텍스트 문자열입니다. context 텍스트 문자열은 다음과 같습니다:¶

   • COSE_Encrypt0 데이터 구조의 콘텐츠 암호화에는 "Encrypt0"입니다.¶
   • COSE_Encrypt 데이터 구조의 첫 번째 계층(즉, 콘텐츠 암호화)에는 "Encrypt"입니다.¶
   • COSE_Encrypt 데이터 구조에 배치될 수신자 인코딩에는 "Enc_Recipient"입니다.¶
   • MAC 적용 메시지 구조에 배치될 수신자 인코딩에는 "Mac_Recipient"입니다.¶
   • 수신자 구조에 배치될 수신자 인코딩에는 "Rec_Recipient"입니다.¶
2. 본문 구조의 보호 속성으로, bstr 타입으로 인코딩됩니다. 보호 속성이 없는 경우, 길이가 0인 바이트 문자열이 사용됩니다.¶
3. 애플리케이션에서 외부로 제공한 데이터로, bstr 타입으로 인코딩됩니다. 이 필드가 제공되지 않으면 기본값은 길이가 0인 바이트 문자열입니다. (이 필드를 구성하는 데 대한 애플리케이션 지침은 섹션 4.3을 참조하십시오.)¶

위 텍스트를 설명하는 CDDL 조각은 다음과 같습니다:¶

Enc_structure = [
    context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
        "Mac_Recipient" / "Rec_Recipient",
    protected : empty_or_serialized_map,
    external_aad : bstr
]

메시지를 암호화하는 방법:¶

1. Enc_structure를 생성하고 적절한 필드로 채웁니다.¶
2. 섹션 9에 설명된 인코딩을 사용하여 Enc_structure를 바이트 문자열(Additional Authenticated Data(AAD))로 인코딩합니다.¶

3. 암호화 키(K)를 결정합니다. 이 단계는 사용 중인 수신자 알고리즘의 클래스에 따라 달라집니다. 다음의 경우:¶

   No Recipients:

   사용할 키는 현재 계층의 알고리즘과 키에 의해 결정됩니다. 예로는 key wrap 키(섹션 8.5.2)와 사전 공유 비밀이 있습니다.¶

   Direct Encryption and Direct Key Agreement:

   키는 수신자 구조의 키와 알고리즘에 의해 결정됩니다. 사용할 암호화 알고리즘과 키의 크기는 수신자에 대해 사용되는 KDF의 입력입니다. (direct의 경우 KDF는 항등 연산으로 생각할 수 있습니다.) 이러한 알고리즘의 예는 [RFC9053]의 섹션 6.1 및 6.3에서 찾을 수 있습니다.¶

   Other:

   키는 무작위로 생성됩니다.¶

4. K(암호화 키), P(평문), AAD를 사용하여 암호화 알고리즘을 호출합니다. 반환된 암호문을 구조의 "ciphertext" 필드에 배치합니다.¶
5. non-direct 알고리즘을 사용하는 메시지 수신자에 대해, K(암호화 키)를 평문으로 사용하여 해당 수신자에 대한 암호화 알고리즘을 재귀적으로 수행합니다.¶

메시지를 복호화하는 방법:¶

1. Enc_structure를 생성하고 적절한 필드로 채웁니다.¶
2. 섹션 9에 설명된 인코딩을 사용하여 Enc_structure를 바이트 문자열(AAD)로 인코딩합니다.¶

3. 복호화 키를 결정합니다. 이 단계는 사용 중인 수신자 알고리즘의 클래스에 따라 달라집니다. 다음의 경우:¶

   No Recipients:

   사용할 키는 현재 계층의 알고리즘과 키에 의해 결정됩니다. 예로는 key wrap 키(섹션 8.5.2)와 사전 공유 비밀이 있습니다.¶

   Direct Encryption and Direct Key Agreement:

   키는 수신자 구조의 키와 알고리즘에 의해 결정됩니다. 사용할 암호화 알고리즘과 키의 크기는 수신자에 대해 사용되는 KDF의 입력입니다. (direct의 경우 KDF는 항등 연산으로 생각할 수 있습니다.)¶

   Other:

   키는 수신자 구조 중 하나를 디코딩하고 복호화하여 결정됩니다.¶

4. K(사용할 복호화 키), C(암호문), AAD를 사용하여 복호화 알고리즘을 호출합니다.¶

5.4. AE 알고리즘을 위한 암호화 및 복호화 방법

메시지를 암호화하는 방법:¶

1. "protected" 필드가 길이가 0인 바이트 문자열인지 확인합니다.¶
2. 이 작업에 대해 외부 추가 인증 데이터가 제공되지 않았는지 확인합니다.¶

3. 암호화 키를 결정합니다. 이 단계는 사용 중인 수신자 알고리즘의 클래스에 따라 달라집니다. 다음의 경우:¶

   No Recipients:

   사용할 키는 현재 계층의 알고리즘과 키에 의해 결정됩니다. 예로는 key wrap 키(섹션 8.5.2)와 사전 공유 비밀이 있습니다.¶

   Direct Encryption and Direct Key Agreement:

   키는 수신자 구조의 키와 알고리즘에 의해 결정됩니다. 사용할 암호화 알고리즘과 키의 크기는 수신자에 대해 사용되는 KDF의 입력입니다. (direct의 경우 KDF는 항등 연산으로 생각할 수 있습니다.) 이러한 알고리즘의 예는 [RFC9053]의 섹션 6.1 및 6.3에서 찾을 수 있습니다.¶

   Other:

   키는 무작위로 생성됩니다.¶

4. K(사용할 암호화 키)와 P(평문)를 사용하여 암호화 알고리즘을 호출합니다. 반환된 암호문을 구조의 "ciphertext" 필드에 배치합니다.¶
5. non-direct 알고리즘을 사용하는 메시지 수신자에 대해, K(암호화 키)를 평문으로 사용하여 해당 수신자에 대한 암호화 알고리즘을 재귀적으로 수행합니다.¶

메시지를 복호화하는 방법:¶

1. "protected" 필드가 길이가 0인 바이트 문자열인지 확인합니다.¶
2. 이 작업에 대해 외부 추가 인증 데이터가 제공되지 않았는지 확인합니다.¶

3. 복호화 키를 결정합니다. 이 단계는 사용 중인 수신자 알고리즘의 클래스에 따라 달라집니다. 다음의 경우:¶

   No Recipients:

   사용할 키는 현재 계층의 알고리즘과 키에 의해 결정됩니다. 예로는 key wrap 키(섹션 8.5.2)와 사전 공유 비밀이 있습니다.¶

   Direct Encryption and Direct Key Agreement:

   키는 수신자 구조의 키와 알고리즘에 의해 결정됩니다. 사용할 암호화 알고리즘과 키의 크기는 수신자에 대해 사용되는 KDF의 입력입니다. (direct의 경우 KDF는 항등 연산으로 생각할 수 있습니다.) 이러한 알고리즘의 예는 [RFC9053]의 섹션 6.1 및 6.3에서 찾을 수 있습니다.¶

   Other:

   키는 수신자 구조 중 하나를 디코딩하고 복호화하여 결정됩니다.¶

4. K(사용할 복호화 키)와 C(암호문)를 사용하여 복호화 알고리즘을 호출합니다.¶

6.1. 수신자가 있는 MAC 적용 메시지

다중 수신자 MAC 적용 메시지는 두 구조를 사용합니다. 본문을 전달하기 위해 이 섹션에서 정의한 COSE_Mac 구조를 사용하고, MAC 계산에 사용되는 키를 보관하기 위해 COSE_recipient 구조(섹션 5.1)를 사용합니다. MAC 적용 메시지의 예는 부록 C.5에서 찾을 수 있습니다.¶

MAC 구조는 사용될 context에 따라 태그가 지정된 형식 또는 태그가 지정되지 않은 형식으로 인코딩될 수 있습니다. 태그가 지정된 COSE_Mac 구조는 CBOR 태그 97로 식별됩니다. 이를 나타내는 CDDL 조각은 다음과 같습니다:¶

COSE_Mac_Tagged = #6.97(COSE_Mac)

COSE_Mac 구조는 CBOR 배열입니다. 배열의 필드는 순서대로 다음과 같습니다:¶

protected:

이는 섹션 3에 설명된 것과 같습니다.¶

unprotected:

이는 섹션 3에 설명된 것과 같습니다.¶

payload:

이 필드는 MAC이 적용될 직렬화된 콘텐츠를 포함합니다. payload가 메시지에 존재하지 않는 경우, 애플리케이션은 payload를 별도로 제공해야 합니다. payload는 변경 없이 전송되도록 보장하기 위해 bstr로 래핑됩니다. payload가 별도로 전송되는 경우(즉, 분리된 콘텐츠), 이 위치에는 nil CBOR 값이 배치되며, 변경 없이 전송되도록 보장하는 것은 애플리케이션의 책임입니다.¶

tag:

이 필드는 MAC 값을 포함합니다.¶

recipients:

이는 섹션 5.1에 설명된 것과 같습니다.¶

COSE_Mac에 대한 위 텍스트를 나타내는 CDDL 조각은 다음과 같습니다.¶

COSE_Mac = [
   Headers,
   payload : bstr / nil,
   tag : bstr,
   recipients : [+COSE_recipient]
]

7.1. COSE Key 공통 매개변수

이 문서는 COSE Key 객체를 위한 공통 매개변수 집합을 정의합니다. 표 4는 이 섹션에서 정의된 매개변수의 요약을 제공합니다. 특정 키 유형에 대해 정의된 매개변수도 있습니다. 키 유형별 매개변수는 [RFC9053]에서 찾을 수 있습니다.¶

kty:

이 매개변수는 이 구조에 대한 키의 패밀리, 따라서 찾을 키 유형별 매개변수 집합을 식별하는 데 사용됩니다. 이 문서에서 정의한 값 집합은 [COSE.KeyTypes]에서 찾을 수 있습니다. 이 매개변수는 키 객체에 존재해야 MUST 합니다. 구현은 처리 중인 알고리즘에 키 유형이 적절한지 검증해야 MUST 합니다. 키 유형은 신뢰 결정 프로세스의 일부로 포함되어야 MUST 합니다.¶

alg:

이 매개변수는 키와 함께 사용되는 알고리즘을 제한하는 데 사용됩니다. 이 매개변수가 키 구조에 존재하는 경우, 애플리케이션은 이 알고리즘이 해당 키가 사용되는 알고리즘과 일치하는지 검증해야 MUST 합니다. 알고리즘이 일치하지 않으면, 이 키 객체는 암호학적 작업을 수행하는 데 사용되어서는 MUST NOT 안 됩니다. 같은 키가 서로 다른 알고리즘이 지정된, 또는 알고리즘이 지정되지 않은 다른 키 구조에 있을 수 있음에 유의하십시오. 그러나 이는 좋지 않은 보안 관행으로 간주됩니다.¶

kid:

이 매개변수는 키에 대한 식별자를 제공하는 데 사용됩니다. 식별자는 구조화되어 있지 않으며, 사용자가 제공한 바이트 문자열부터 키의 공개 부분에 대해 계산된 값까지 무엇이든 될 수 있습니다. 이 필드는 검사해야 할 키 집합을 줄이기 위해 메시지의 "kid" 매개변수와 대조하기 위한 것입니다. 식별자의 값은 고유한 값이 아니며, 서로 다른 키에 대해서도 다른 키 객체에 나타날 수 있습니다.¶

key_ops:

이 매개변수는 키가 사용될 작업 집합을 제한하도록 정의됩니다. 필드의 값은 표 5의 값 배열입니다. 알고리즘은 나타날 수 있고 특정 작업에 필요한 key ops 값을 정의합니다. 값 집합은 [RFC7517] 및 [W3C.WebCrypto]의 값과 일치합니다.¶

Base IV:

이 매개변수는 IV의 기본 부분을 전달하도록 정의됩니다. 이는 섹션 3.1에서 정의된 Partial IV 헤더 매개변수와 함께 사용되도록 설계되었습니다. 이 필드는 키와 Base IV를 연결하고, 이후 메시지별로 Partial IV로 수정할 수 있는 기능을 제공합니다.¶

애플리케이션에서 Base IV를 사용할 때는 극도의 주의가 필요합니다. 많은 암호화 알고리즘은 동일한 IV가 두 번 사용되면 보안을 잃습니다.¶

각 송신자에 대해 서로 다른 키가 유도되는 경우, 동일한 Base IV에서 시작하는 것은 이 조건을 만족할 가능성이 큽니다. 여러 송신자에게 동일한 키가 사용되는 경우, 애플리케이션은 송신자 간에 IV 공간을 나누는 방법을 제공해야 합니다. 이는 시작할 다른 기본 지점을 제공하거나, 시작할 다른 Partial IV를 제공하고, 재키잉 전에 보낼 메시지 수를 제한함으로써 수행될 수 있습니다.¶

11.1. COSE Header Parameters 레지스트리

"COSE Header Parameters" 레지스트리는 [RFC8152]에서 정의되었습니다. IANA는 이 레지스트리의 참조가 [RFC8152] 대신 이 문서를 가리키도록 갱신했습니다. IANA는 또한 "counter signature" 및 "CounterSignature0"을 제외하고 [RFC8152]를 참조하던 모든 항목을 이 문서를 참조하도록 갱신했습니다. "counter signature" 및 "CounterSignature0"에 대한 참조는 계속해서 [RFC8152]를 참조합니다.¶

11.2. COSE Key Common Parameters 레지스트리

"COSE Key Common Parameters" 레지스트리 [COSE.KeyParameters]는 [RFC8152]에서 정의되었습니다. IANA는 이 레지스트리의 참조가 [RFC8152] 대신 이 문서를 가리키도록 갱신했습니다. IANA는 또한 [RFC8152]를 참조하던 항목들이 이 문서를 참조하도록 갱신했습니다.¶

11.6. 전문가 검토 지침

[RFC8152]가 설정한 모든 IANA 레지스트리는 적어도 부분적으로 Expert Review [RFC8126]로 정의됩니다. 이 섹션은 전문가들이 무엇을 살펴봐야 하는지에 대한 몇 가지 일반 지침을 제공하지만, 그들은 이유가 있어 전문가로 지정되므로 상당한 재량이 주어져야 합니다.¶

전문가 검토자는 다음을 고려해야 합니다:¶

• 포인트 선점은 억제되어야 합니다. 검토자는 사용이 기존 등록과 중복되지 않고 해당 코드 포인트가 배포에서 사용될 가능성이 있음을 보장하기 위해 등록 요청에 대한 충분한 정보를 얻도록 권장됩니다. private use로 표시된 범위는 테스트 목적 및 폐쇄 환경을 위한 것입니다. 다른 범위의 코드 포인트는 테스트용으로 할당되어서는 안 됩니다.¶
• Standards Action 범위에 코드 포인트를 등록하려면 Standards Track 또는 BCP RFC가 필요합니다. Specification Required 범위에는 명세가 존재해야 하지만, RFC가 제공되기 전의 조기 할당은 허용 가능한 것으로 간주됩니다. 포인트가 폐쇄 환경 밖에서 상호운용 가능한 방식으로 사용될 것으로 예상되는 경우 first-come, first-served 범위에도 명세가 필요합니다. 명세가 제공되지 않는 경우, 제공되는 설명은 해당 포인트가 무엇에 사용되는지 식별할 수 있을 만큼 충분한 정보를 가져야 합니다.¶
• 전문가는 코드 포인트 할당을 승인할 때 필드의 예상 사용을 고려해야 합니다. Standards Action 범위가 Standards Track 문서에만 제공된다는 사실이 Standards Track 문서가 그 범위 밖에서 포인트를 할당받을 수 없다는 뜻은 아닙니다. 인코딩된 값의 길이는 해당 길이의 코드 포인트가 얼마나 남아 있는지, 그리고 그것이 사용될 장치의 크기와 비교하여 평가되어야 합니다.¶
• 알고리즘이 등록될 때, 과시적 등록은 억제되어야 합니다. 이를 수행하는 한 가지 방법은 등록이 알고리즘의 보안 분석에 대한 추가 문서를 제공하도록 요구하는 것입니다. 고려해야 할 또 다른 사항은 Crypto Forum Research Group(CFRG)에 알고리즘에 대한 의견을 요청하는 것입니다. 알고리즘은 등록에 적합하려면 커뮤니티의 보안 요구사항과 메시지 구조의 요구사항을 충족해야 합니다.¶

C.1. 서명된 메시지의 예

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ]
    ]
  ]
)

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ],
      [
        / protected h'a1013823' / << {
            / alg / 1:-36 / ECDSA 521 /
          } >> ,
        / unprotected / {
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297'
      ]
    ]
  ]
)

98(
  [
    / protected h'a2687265736572766564f40281687265736572766564' /
    << {
        "reserved":false,
        / crit / 2:[
          "reserved"
        ]
      } >>,
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
18aba9d1fad1bd9c'
      ]
    ]
  ]
)

C.2. 단일 서명자 예제

18(
  [
    / protected h'a10126' / << {
        / alg / 1:-7 / ECDSA 256 /
      } >>,
    / unprotected / {
      / kid / 4:'11'
    },
    / payload / 'This is the content.',
    / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36'
  ]
)

C.3. 엔벨로프 메시지의 예

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >>,
    / unprotected / {
      / iv / 5:h'c9cf4df2fe6c632bf7886413'
    },
    / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
    / recipients / [
      [
        / protected h'a1013818' / << {
            / alg / 1:-25 / ECDH-ES + HKDF-256 /
          } >>,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:1,
            / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
            / y / -3:true
          },
          / kid / 4:'meriadoc.brandybuck@buckland.example'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >>,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a76c'
    },
    / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847',
    / recipients / [
      [
        / protected h'a10129' / << {
            / alg / 1:-10
          } >>,
        / unprotected / {
          / salt / -20:'aabbccddeeffgghh',
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'02d1f7e6f26c43d4868d87ce'
    },
    / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
e5f0165eee976b4a5f6c6f09d',
    / recipients / [
      [
        / protected / h'a101381f' / {
            \ alg \ 1:-32 \ ECDH-SS+A128KW \
          } / ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'0101'
        },
        / ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
e1c62'
      ]
    ]
  ]
)

C.4. 암호화된 메시지의 예

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a78c'
    },
    / ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
460ffb569'
  ]
)

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / partial iv / 6:h'61a7'
    },
    / ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca'
  ]
)

C.5. MACed 메시지의 예

97(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'9e1226ba1f81b848',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-6 / direct /,
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41',
    / recipients / [
      [
        / protected h'a101381a' / << {
            / alg / 1:-27 / ECDH-SS + HKDF-256 /
          } >> ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a1010e' / << {
        / alg / 1:14 / AES-CBC-MAC-128//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'36f5afaf0bab5d43',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
b6eb0'
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
1e49e9323e',
    / recipients / [
      [
        / protected h'a101381c' / << {
            / alg / 1:-29 / ECDH-ES+A128KW /
          } >> ,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:3,
            / x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
d613574e7dc242f79c3',
            / y / -3:true
          },
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
      ],
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
518e7736549e998370695e6d6a83b4ae507bb'
      ]
    ]
  ]
)

C.6. MAC0 메시지의 예

17(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'726043745027214f'
  ]
)

C.7. COSE Key

[
  {
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    1:2,
    2:'meriadoc.brandybuck@buckland.example'
  },
  {
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    1:2,
    2:'11'
  },
  {
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    1:2,
    2:'bilbo.baggins@hobbiton.example'
  },
  {
    -1:1,
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    1:2,
    2:'peregrin.took@tuckborough.example'
  }
]

[
  {
    1:2,
    2:'meriadoc.brandybuck@buckland.example',
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    -4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
208cf'
  },
  {
    1:2,
    2:'11',
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    -4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
7b4d3'
  },
  {
    1:2,
    2:'bilbo.baggins@hobbiton.example',
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    -4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
eb26d'
  },
  {
    1:4,
    2:'our-secret',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  },
  {
    1:2,
    -1:1,
    2:'peregrin.took@tuckborough.example',
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    -4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
df1c3'
  },
  {
    1:4,
    2:'our-secret2',
    -1:h'849b5786457c1491be3a76dcea6c4271'
  },
  {
    1:4,
    2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  }
]