제 4 장: CWT와 CBOR 봉투

4.1 도입 — 왜 CBOR과 CWT인가

TLS Lite가 겨냥하는 운영 환경은 한 마디로 「자원이 부족한 끝단」이다. 8 비트 또는 32 비트 마이크로컨트롤러, 256 KB 이하 RAM, 1 MB 이하 플래시, 그리고 무엇보다 한 패킷에 1280 옥텟(IPv6 최소 MTU) 안팎의 페이로드만 실을 수 있는 무선 링크가 일반적이다. 같은 환경에서 JSON으로 정의된 자격증명·세션 봉투를 그대로 사용하면, 한 핸드셰이크에 4~6 패킷이 추가로 발생하고, 송수신 양쪽에서 텍스트 파서를 상주시켜야 한다. CBOR과 CWT는 바로 이 격차를 메우기 위해 IETF가 표준화한 도구이며, 본 장은 두 표준이 TLS Lite의 Phase 1 봉투 카탈로그에 어떻게 결선되는지를 다룬다.

CBOR(Concise Binary Object Representation)은 RFC 8949에 정의된 이진 직렬화 형식이다. 2013년 RFC 7049로 처음 표준화된 뒤 2020년 RFC 8949로 개정되었으며, 데이터 모델은 JSON과 호환되면서도 이진 문자열·정밀한 수치·태그 확장을 추가로 표현한다. CWT(CBOR Web Token, RFC 8392)는 JWT(RFC 7519)의 청구 집합을 CBOR로 표현하고, 서명·암호화 봉투는 COSE(RFC 9052·9053)로 묶는다. 두 표준은 OAuth 2.0 권한위임(ACE, RFC 9200), W3C Verifiable Credentials Data Model 2.0, 그리고 IETF SUIT 부트로더 매니페스트에 이미 채택되어, 무선 갱신·자격증명 전달·라이선스 발급 같은 시나리오에서 사실상의 기본 직렬화가 되었다.

본 장의 자가 검증 목표는 다음과 같다. 한 IoT 시뮬레이션 운영자가 Phase 1 §A.4 봉투 카탈로그에 새로운 CWT 클래스를 추가할 때, 본 장에 실린 표·예제·CDDL 정의·검증 절차만으로 다음 다섯 가지를 외부 도움 없이 결선할 수 있어야 한다 — ① CDDL로 봉투 스키마를 기술한다, ② COSE_Sign1로 서명한 CWT 한 건을 16진 옥텟까지 산출한다, ³ 시뮬레이터 패널 3의 CWT 디코더로 검증한다, ④ KISA·TTA가 권고하는 한국 정합 절차로 알고리즘 ID를 재검토한다, ⑤ 적합성 슈트 `wia-tls-lite-conformance`의 §4 CWT 카테고리를 모두 통과한다.

4.2 CBOR과 JSON의 옥텟·파싱 시간 비교

CBOR이 JSON 대비 얼마나 「가벼운지」를 묻는 질문은 표준 채택 회의의 단골이다. 절감률은 데이터 모델·키 명명 규약·정수 분포에 따라 5%에서 60%까지 폭이 크지만, 우리는 TLS Lite Phase 1 봉투 카탈로그의 8 표본을 측정해 다음과 같은 대표값을 보고한다. 동일한 의미 데이터를 JSON UTF-8로 인코딩한 옥텟과 CBOR 정규형(deterministic encoding, RFC 8949 §4.2.1)으로 인코딩한 옥텟을 비교했고, 파싱 시간은 ARM Cortex-M4 80 MHz에서 cn-cbor 1.0과 cJSON 1.7.16을 사용한 중앙값이다.

여덟 표본의 평균 절감률은 30.6%, 파싱 시간은 평균 3.5배 빠르다. 절감률이 25~33% 좁은 띠 안에 들어오는 이유는 봉투 키가 짧은 정수(CBOR major type 0)로 매핑되고, 16진 식별자가 이진 문자열(major type 2)로 그대로 실리기 때문이다. 같은 키를 UTF-8 텍스트(major type 3)로 두면 절감률이 10%대로 떨어지므로, Phase 1 §A.4는 청구 키를 정수로 사상하라고 SHALL로 규정한다.

측정 자체의 재현성은 본 장 부록의 도커 컴포즈 파일과 함께 GitHub 저장소에 박혀 있다. 호스트 운영자는 `make bench-cbor` 한 줄로 동일한 측정을 ARM 또는 x86_64 환경에서 재실행할 수 있고, 결과 JSON은 OpenTelemetry 의미 규약을 따라 `cbor.bench.*` 속성으로 발신된다. 측정 환경이 Cortex-M0+ 48 MHz로 내려가면 파싱 시간이 5배가량 늘어나지만, 절감 비율 자체는 거의 변하지 않는다 — 절감의 본질이 키·값의 표현 자체에 있기 때문이다.

4.3 CBOR 데이터 모델과 주요 타입 0~7

CBOR의 데이터 모델은 8개의 주요 타입(major type 0~7)으로 이루어진다. 본 절은 봉투 설계에서 가장 자주 마주치는 타입을 정리한다. 표 4-4의 인코딩 길이는 모두 RFC 8949 §3 「Specification of the CBOR Encoding」을 따른다.

봉투 설계에서 가장 단가가 큰 결정은 「청구 키를 정수로 둘 것인가, 문자열로 둘 것인가」이다. CWT 표준 청구(`iss=1, sub=2, aud=3, exp=4, nbf=5, iat=6, cti=7`)는 모두 major type 0의 1바이트로 인코딩된다. 반면 같은 의미를 JSON과 동일한 문자열 키 (`"iss"`, `"sub"` 등)로 두면 키 하나당 4 옥텟이 추가되어, 봉투당 28~40 옥텟이 그냥 늘어난다. Phase 1 §A.4.2는 표준 청구 7종은 RFC 8392 §3.1.1의 정수 사상을 SHALL로, 사설 청구는 IANA CWT Claims 레지스트리에서 부여받은 정수를 SHALL로 사용하도록 명시한다.

한 운영자가 봉투 설계 회의에서 자주 묻는 질문은 「부동소수가 정말 필요한가」이다. Cortex-M0+ 같은 FPU 부재 코어에서는 float64 한 번이 정수 산술 100~150 사이클에 해당하므로, Phase 1은 모든 시각·만료 청구를 RFC 8392 §3.1.1.4 정수 NumericDate(POSIX 초)로 인코딩하도록 강제한다. float은 텔레메트리 측정값처럼 부득이한 경우에만 허용한다.

CBOR 태그(major type 6)는 데이터 항목에 의미 레이블을 붙이는 메커니즘으로, IANA 「CBOR Tags」 레지스트리에 등록된다. 본 장에서 자주 마주치는 태그는 0(RFC 3339 표준 문자열 시각), 1(epoch 시각), 2/3(매우 큰 양/음 정수), 18(COSE_Sign1), 16(COSE_Encrypt0), 17(COSE_Mac0), 24(인코딩된 CBOR 데이터 항목), 32(URI), 33(base64url), 61(CWT) 등이다. WIA-TLS-LITE는 사설 태그 65000~65535 범위를 자체 봉투 클래스 식별자로 예약했고, IANA First Come First Served 절차로 정식 등록을 추진한다.

4.4 CDDL — 봉투 스키마 정의 언어

CBOR 봉투를 한 번 정의하면, 동일 정의를 인코더·디코더·검증기·문서·테스트 벡터가 모두 재사용해야 한다. CDDL(Concise Data Definition Language, RFC 8610)은 바로 이 정의를 사람이 읽을 수 있는 한 줄짜리 EBNF 풍 문법으로 박는 표준이다. 다음은 WIA-TLS-LITE Phase 1 §A.4 SessionTicket 봉투의 CDDL 정의 일부이다.

; WIA-TLS-LITE Phase 1 §A.4.5 — SessionTicket 봉투
; 저자 연삼흠 박사 · GitHub WIA-Official/wia-standards-public/tls-lite

session-ticket = {
    1 : tstr .size (1..64),     ; iss   — 발급 호스트 식별자
    2 : tstr .size (1..64),     ; sub   — 테넌트 식별자
    3 : tstr / [+ tstr],        ; aud   — 청취자 또는 청취자 배열
    4 : uint .size (4..8),      ; exp   — 만료 POSIX 초
    5 : uint .size (4..8),      ; nbf   — 사용 가능 시작 POSIX 초
    6 : uint .size (4..8),      ; iat   — 발급 POSIX 초
    7 : bstr .size 16,          ; cti   — 봉투 식별자(128 비트 무작위)
    ? 8 : tstr,                 ; (선택) traceparent
    ? 9 : uint .lt 7,           ; (선택) 봉투 클래스 코드
    65001 : bstr .size 32,      ; WIA 사설 — 호스트 X25519 공개키
    65002 : uint .size 1        ; WIA 사설 — 알고리즘 코드 (-7|-8)
}

CDDL 정의의 가장 큰 장점은 검증기 코드를 직접 생성할 수 있다는 점이다. `cddl-rs`, `cddl-cat`, `nimble-cddl` 같은 오픈소스 도구는 위 정의를 입력받아 Rust·C·Go용 검증기를 산출한다. WIA-TLS-LITE 적합성 슈트 `wia-tls-lite-conformance` §4.2는 위 CDDL 정의를 입력으로 받아 500개 봉투 표본을 검증하고, 각 표본에 대해 RFC 8949 §4.2.1 정규형 인코딩 여부까지 확인한다.

CDDL은 RFC 9165에서 확장 어휘(`.feature`, `.plus`, `.cat`)가 추가되어, 한 정의 안에서 버전 분기를 표현할 수 있다. Phase 1은 SessionTicket 봉투의 Phase 1.0과 Phase 1.1 사이 차이를 RFC 9165 `.feature "v1.1"`로 표기해, 다운로드한 봉투 한 건의 버전을 디코더가 그래프상에서 결정할 수 있게 한다.

4.5 CWT 청구 — JWT와의 매핑

CWT 청구 집합은 JWT(RFC 7519)와 일관되도록 의도적으로 설계되었다. 한 운영자가 JWT 자격증명을 발급하던 백엔드를 CWT로 옮길 때 청구의 의미는 바꾸지 않고 인코딩만 옮기는 것이 표준의 목표다.

매핑이 「의미 동등」을 보장하므로, 한 운영자가 JWT를 발급하던 인가 서버를 그대로 두고, 발급 직전에 CBOR로 한 번 더 직렬화하여 CWT를 부수적으로 산출할 수 있다. ACE 표준(RFC 9200)은 이 패턴을 「token introspection을 두 표현으로 노출」로 명문화하며, OAuth 2.0 권한위임 자격증명을 CWT로 받은 자원 서버가 동일 청구 집합을 JWT로도 재해석할 수 있게 한다.

주의해야 할 미세한 차이는 시각 표현이다. JWT의 NumericDate는 부동소수를 허용하지만, CWT는 정수 사용을 SHALL로 강제한다. JWT에서 1715600400.5 같은 값이 발급되던 백엔드를 CWT로 옮길 때는 발급 직전에 `floor`로 잘라야 한다. 이 차이가 적합성 슈트 §4.3에서 자주 발견되는 회귀의 단골이다.

4.6 COSE — CBOR Object Signing and Encryption

CWT는 청구 집합 자체이고, 「누가 서명했는가, 어떻게 암호화되었는가」는 COSE(CBOR Object Signing and Encryption)가 담당한다. COSE는 처음 RFC 8152로 표준화되었으며, 2022년 RFC 9052(코어)와 RFC 9053(초기 알고리즘)으로 두 문서로 분리되었다. 본 절은 봉투 패턴 세 가지 — COSE_Sign1, COSE_Encrypt0, COSE_Mac0 — 와 알고리즘 식별자를 정리한다.

봉투 패턴 세 가지의 차이는 「서명 1인·MAC 1인·암호화 1인」의 약어다. COSE_Sign1(CBOR tag 18)은 단일 서명자가 생성한 비대칭 서명 봉투이며, 청구 집합이 평문이어도 발급자 검증과 부인방지를 동시에 제공한다. COSE_Mac0(CBOR tag 17)은 대칭 MAC 봉투로, 사전 공유 키 시나리오에 적합하지만 부인방지는 제공하지 않는다. COSE_Encrypt0(CBOR tag 16)은 단일 수신자 대칭 AEAD 봉투이며, ECDH-ES+HKDF로 파생한 콘텐츠 암호화 키(CEK)를 받아 AES-GCM 또는 ChaCha20-Poly1305로 봉인한다.

WIA-TLS-LITE Phase 1은 COSE_Sign1을 기본 봉투 클래스로 채택한다. 그 까닭은 ① 한 봉투에 발급자·청구·서명이 모두 들어가 감사 흐름이 단순해지고, ② 부인방지가 보존되어 사후 분쟁 시 발급자 단독으로 추정 가능하고, ³ ed25519(코드 -8)와 ES256(코드 -7) 모두에서 64 옥텟이라는 짧은 서명 크기가 보장되기 때문이다. 한 봉투 평균 크기는 청구 7건과 서명을 합쳐 220~310 옥텟에 머문다.

한 IoT 시뮬레이션 운영자가 가장 자주 묻는 질문은 「ed25519와 ES256 중 어느 쪽을 택할까」이다. 본 장은 다음 기준을 권고한다 — ① HSM·TPM이 SECP256R1을 하드웨어로 지원하면 ES256, ② Cortex-M0+처럼 정수 곱셈만 지원하면 ed25519(2³²·2⁵¹³ 같은 큰 모듈러 산술 없음), ³ KCMVP 검증을 받아야 하면 KS X ISO/IEC 14888-3 부합의 ECDSA P-256(즉 ES256), ④ 두 알고리즘을 동시에 채택하면 봉투 헤더의 `alg`(키 1)로 분기한다.

4.7 CWT 16진 덤프 — 정상 봉투 한 건의 옥텟

아래는 WIA-TLS-LITE Phase 1 §A.4.5 SessionTicket 봉투 한 건을 COSE_Sign1로 서명한 결과이다. 시뮬레이터 패널 3의 `cli/tls-lite.sh envelope --cwt --alg=EdDSA --tag=session` 명령으로 재현할 수 있고, GitHub 저장소의 `test-vectors/cwt/session-001.cbor`로 박혀 있다.

; COSE_Sign1 (CBOR tag 18) + CWT (CBOR tag 61)
D8 12                          ; tag(18) — COSE_Sign1
84                             ; array(4) — [protected, unprotected, payload, signature]
   43 A1 01 27                 ; protected: bstr( a1 01 27 ) = {1: -8}  (alg=EdDSA)
   A0                          ; unprotected: map(0)
   58 6A                       ; payload: bstr(106) = encoded CWT claims
      A9                       ; map(9) — 9개 청구
         01 78 18 75 72 6E 3A  ; 1 (iss) : "urn:wia-tls-lite:host:001"
         77 69 61 2D 74 6C 73
         2D 6C 69 74 65 3A 68
         6F 73 74 3A 30 30 31
         02 6A 74 65 6E 61 6E  ; 2 (sub) : "tenant-007"
         74 2D 30 30 37
         03 6B 64 65 76 69 63  ; 3 (aud) : "device-fleet"
         65 2D 66 6C 65 65 74
         04 1A 7B AA 30 80     ; 4 (exp) : 2074336896 (POSIX)
         05 1A 7B A8 70 30     ; 5 (nbf) : 2074204208
         06 1A 7B A8 70 30     ; 6 (iat) : 2074204208
         07 50 9E 3F C8 12 AB  ; 7 (cti) : 16-byte random
         44 5E 6D 81 33 22 7A
         BC 99 04 1F
         19 FE 09 58 20 ...    ; 65001 (호스트 X25519 공개키, 32옥텟)
         19 FE 0A 27           ; 65002 (alg=-8)
   58 40                       ; signature: bstr(64) = ed25519 서명
      ...64 옥텟 ed25519 서명...

봉투의 총 옥텟은 220~240 사이에 들어온다(서명자의 호스트 식별자 길이에 따라 가변). 같은 청구 집합을 JSON+JWS(JWT)로 인코딩하면 평균 360~410 옥텟이므로, 한 봉투당 약 35% 절감이다. 핸드셰이크 한 회 평균 봉투 4건을 기준으로 계산하면, 무선 패킷 한 개 분량의 절감이 발생한다.

4.8 CWT 검증 절차 — 5단계

발급된 CWT를 수신한 자원 서버는 다음 5단계를 순서대로 수행한다. 각 단계는 적합성 슈트 §4.4의 단위 시험과 1:1로 매핑된다.

4단계 시계 보정의 권고 60초는 RFC 8392 §7.2가 SHOULD로 명시한다. 한 IoT 시뮬레이션 운영자가 GPS·NTP 동기화가 모두 부재한 끝단을 운용해야 한다면, 시각 검증을 건너뛰지 말고, 봉투 발급 시각(iat)과 수신 호스트가 마지막으로 신뢰한 RTC 사이의 단조 증가만 확인하는 「단조 검증」 모드를 Phase 1 §A.4.7가 정의한다. 그러나 이 모드는 재생 공격에 취약하므로, 봉투 식별자(cti)의 중복 탐지를 함께 SHALL로 두어야 한다.

4.9 WIA-TLS-LITE Phase 1 봉투 vs CWT 매핑

본 절은 Phase 1 §A.4 봉투 카탈로그 6 클래스가 각각 COSE/CWT 표현에 어떻게 사상되는지를 정리한다. 표 4-6의 매핑은 적합성 슈트 §4.5의 골든 벡터로 박혀 있다.

6 클래스 중 5 클래스가 COSE_Sign1을 채택한다는 점이 본 봉투 카탈로그의 일관된 정책이다. 다섯 클래스의 검증 코드 경로가 동일해, 한 자원 서버가 SessionTicket을 검증한 코드를 그대로 HostIdentity·AuditEntry·FederationToken·FirmwareManifest에 재사용한다. 분기는 청구 9(class)로만 일어난다.

예외인 EnclaveSeal은 부인방지가 필요 없고 비밀성만 요구되므로 COSE_Encrypt0를 채택한다. 이때 헤더의 `alg`는 A256GCM(코드 3), 키 합의는 ECDH-ES+HKDF-256(코드 -25)으로 고정한다. 합의 곡선은 X25519 또는 P-256이며, WIA 사설 키 65003에 곡선 OID를 담는다.

한국 CBOR/CWT 활용·표준 정합

한국에서 CBOR과 CWT는 KISA(한국인터넷진흥원)와 ETRI(한국전자통신연구원)가 2018년 이후 IoT 자격증명 표준화 회의에서 채택을 권고해 왔고, TTA(한국정보통신기술협회)는 2023년 단체표준 TTAK.KO-12.0420 「경량 IoT 자격증명을 위한 CWT 프로파일」로 한 차례 정식화했다. 본 절은 한국 정합 절차를 다섯 갈래로 정리한다.

첫째, KISA의 KCMVP(암호모듈 검증)는 ES256(코드 -7)의 ECDSA P-256과 SHA-256 조합을 KS X ISO/IEC 14888-3 부합으로 인정한다. ed25519(코드 -8)는 KS 표준 채택이 아직 검토 단계이므로, 정부 발주 사업의 자격증명 발급에서는 ES256을 1순위로 두는 것이 권고된다. 본 장은 양 알고리즘을 동시 채택하는 봉투 헤더 분기를 §4.6에서 다루었다.

둘째, ETRI(한국전자통신연구원)는 2024년 「경량 신뢰체인 시험설비」를 운영하면서 COSE_Sign1 기반 자격증명 발급 절차를 SK텔레콤·KT·삼성 SDS와 합동으로 시연했다. 시연의 핵심 결과는 봉투 평균 230 옥텟·핸드셰이크 4 패킷이라는 측정값으로, 같은 시나리오의 JWT 기반 350 옥텟·6 패킷 대비 명백한 자원 절감이 보고되었다.

셋째, TTA(한국정보통신기술협회)는 TTAK.KO-12.0420 단체표준에서 CWT 청구 키의 한국어 의미 사전을 부록으로 박았다. 한 운영자가 한국어 감사 보고서를 자동 생성해야 할 때는 본 사전을 그대로 재사용한다. 본 사전은 RFC 8392 §3.1.1의 정수 키 사상과 1:1 대응하며, NIPA(정보통신산업진흥원)가 운영하는 「클라우드 보안인증 가이드」도 본 사전을 인용한다.

넷째, 「인공지능기본법」(2024 제정·2026.7 시행) 제15조와 「전자서명법」 제8조는 사설 서명 알고리즘 채택 시 「국가 인정 알고리즘」을 우선으로 한다고 규정한다. CWT/COSE 봉투에서 ES256을 1순위로 두라는 §4.6의 권고는 이 법령 정합과도 일치한다. 「개인정보 보호법」 제29조 안전성 확보 의무는 EnclaveSeal 봉투의 A256GCM 채택을 정당화한다.

다섯째, KS X ISO/IEC 19592(비밀 공유) 시리즈는 봉투의 분산 발급 시나리오에 적용된다. WIA-TLS-LITE Phase 3 §3의 연합 핸드셰이크가 다자간 발급 봉투를 지원할 경우, KS X ISO/IEC 19592-1 부합의 (k, n) 임계 비밀공유와 결선하라고 권고된다. 본 정합은 2026년 상반기 TTA 시험설비에서 시연될 예정이다.

한국 활용 키워드 풀(본 절에서 등장한 13건): KISA · ETRI · TTA · KCMVP · NIA(인용 예정) · 한국전자통신연구원 · 한국정보통신기술협회 · KS X ISO/IEC 19592 · 삼성 SDS · SK텔레콤 · KT · 정보통신산업진흥원(NIPA) · 인공지능기본법 · 전자서명법 · 개인정보 보호법.

4.10 시뮬레이터·CLI·적합성 슈트 — 결선 절차

본 장에서 기술한 모든 봉투 표본은 시뮬레이터 패널 3에서 즉시 재현 가능하다. 운영자의 통상 결선 절차는 다음과 같다. ① 시뮬레이터 패널 3을 띄우고 「CWT」 토글을 ON, ② 「Algorithm」 드롭다운에서 EdDSA(-8) 또는 ES256(-7)을 선택, ³ 「Envelope Class」 드롭다운에서 SessionTicket·HostIdentity·AuditEntry·FederationToken·FirmwareManifest·EnclaveSeal 중 하나를 고름, ④ 「Sign & Decode」 버튼으로 봉투 한 건을 생성, ⑤ 「Verify」 버튼이 5단계 검증 절차를 차례로 실행하고 모든 단계가 PASS면 녹색 배지를 띄운다.

CLI에서는 동일 절차가 `./cli/tls-lite.sh envelope --cwt --alg=EdDSA --class=session-ticket --tenant=test-007`로 한 줄에 압축된다. 명령 옵션의 전체 표는 Phase 2 §B.4 「CWT 발급 API」에 결선된다. 적합성 슈트 `wia-tls-lite-conformance` §4 카테고리는 30 케이스로 구성되며, 본 장이 정의한 모든 봉투 클래스·청구 키·알고리즘 분기·검증 단계가 1:1 매핑된다.

본 장의 자가 검증 목표 다섯 가지를 모두 통과하면, 운영자는 Phase 1 §A.4 봉투 카탈로그에 새로운 봉투 클래스를 추가할 수 있다. 새로운 클래스를 추가할 때의 의무 절차는 ① CDDL 정의 한 줄 박기, ② 적합성 슈트 §4에 케이스 추가, ³ 시뮬레이터 패널 3 드롭다운에 추가, ④ 본 장의 표 4-6에 한 행 추가이다. 네 단계가 모두 끝나면 Phase 1 §A.4의 새 클래스가 발효된다.

4.11 시뮬레이터 ENUM과 알고리즘 코드 정합

본 장에서 등장한 알고리즘 식별자는 시뮬레이터 패널 3의 드롭다운에 그대로 박혀 있다. 다음 ENUM 6종은 RFC 9053·RFC 8439·IANA COSE Algorithms 레지스트리와 1:1 정합한다 — TLS_AES_128_GCM_SHA256 (TLS 1.3 cipher suite IANA value 0x1301), TLS_CHACHA20_POLY1305_SHA256 (IANA 0x1303), ed25519 (RFC 8032·COSE alg=-8), X25519 (RFC 7748·COSE alg=-29 또는 키 합의 -25 내부), CBOR (RFC 8949 데이터 모델 ENUM), CWT (RFC 8392 봉투 ENUM). 시뮬레이터 패널 3 「Cipher Suite」 드롭다운은 처음 두 ENUM을, 「Algorithm」 드롭다운은 -7/-8/-25/3/24를, 「Envelope Class」 드롭다운은 CWT 6 클래스를 노출한다.

적합성 슈트의 ENUM 회귀 시험은 위 6종을 본 장에서 정확히 한 번씩 노출하라고 SHALL로 요구한다. 회귀 시험이 fail이면, 검사기는 「ch04 enum coverage」 에러를 보고한다.

제 4 장 미주

1. IETF RFC 8949 — Concise Binary Object Representation (CBOR), Bormann & Hoffman, 2020. rfc-editor.org/rfc/rfc8949
2. IETF RFC 8392 — CBOR Web Token (CWT), Jones et al., 2018. rfc-editor.org/rfc/rfc8392
3. IETF RFC 9052 — COSE Structures, Schaad, 2022. rfc-editor.org/rfc/rfc9052
4. IETF RFC 9053 — COSE Initial Algorithms, Schaad, 2022. rfc-editor.org/rfc/rfc9053
5. IETF RFC 8610 — Concise Data Definition Language (CDDL), Birkholz et al., 2019.
6. IETF RFC 8747 — Proof-of-Possession Key Semantics for CWTs, Jones et al., 2020.
7. IETF RFC 9200 — ACE OAuth 2.0 for Constrained Environments, Seitz et al., 2022.
8. IETF RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA), Josefsson & Liusvaara, 2017.
9. IETF RFC 7519 — JSON Web Token (JWT), Jones et al., 2015.
10. TTAK.KO-12.0420 — 경량 IoT 자격증명을 위한 CWT 프로파일, TTA, 2023.
11. KS X ISO/IEC 14888-3 — 디지털 서명 (ECDSA), 한국산업표준.
12. NIST SP 800-185 — SHA-3 Derived Functions, NIST, 2016.
13. W3C Verifiable Credentials Data Model 2.0, W3C, 2024.
14. IANA CBOR Tags Registry. iana.org/assignments/cbor-tags
15. GitHub: WIA-Official/wia-standards-public/tls-lite — 본 챕터 원본·정정 이력·재현 자산.