[RFC 홈] [TEXT|PDF|HTML] [추적기] [IPR] [정오표] [정보 페이지]
제안
표준
업데이트: 9864
정오표 있음
인터넷 엔지니어링 태스크 포스(IETF) M. Jones
의견 요청: 7518 Microsoft
범주: 표준 트랙 2015년 5월
ISSN: 2070-1721
JSON 웹 알고리즘(JWA)
초록
이 명세는 JSON Web Signature(JWS), JSON Web Encryption
(JWE) 및 JSON Web Key(JWK) 명세와 함께 사용할 암호화 알고리즘과
식별자를 등록합니다. 또한 이러한 식별자를 위한 여러
IANA 레지스트리를 정의합니다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서입니다.
이 문서는 인터넷 엔지니어링 태스크 포스
(IETF)의 산출물입니다. 이 문서는 IETF 커뮤니티의 합의를 나타냅니다. 공개
검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)의
출판 승인을 받았습니다. 인터넷 표준에 대한 자세한 정보는
RFC 5741의 섹션 2에서 확인할 수 있습니다.
이 문서의 현재 상태, 정오표 및
이 문서에 대한 의견을 제공하는 방법에 관한 정보는
http://www.rfc-editor.org/info/rfc7518에서 확인할 수 있습니다.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones 표준 트랙 [페이지 1]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 표기 규칙 . . . . . . . . . . . . . . . . . . . . . . 4
2. 용어 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 디지털 서명 및 MAC용 암호화 알고리즘 . . . . . . . . . . 6
3.1. JWS용 "alg"(알고리즘) 헤더 매개변수 값 . . . . . . . 6
3.2. SHA-2 함수를 사용하는 HMAC . . . . . . . . . . . . . . 7
3.3. RSASSA-PKCS1-v1_5를 사용하는 디지털 서명 . . . . . . 8
3.4. ECDSA를 사용하는 디지털 서명 . . . . . . . . . . . . 9
3.5. RSASSA-PSS를 사용하는 디지털 서명 . . . . . . . . . . 10
3.6. "none" 알고리즘 사용 . . . . . . . . . . . . . . . . 11
4. 키 관리용 암호화 알고리즘 . . . . . . . . . . . . . . . . 11
4.1. JWE용 "alg"(알고리즘) 헤더 매개변수 값 . . . . . . . 12
4.2. RSAES-PKCS1-v1_5를 사용한 키 암호화 . . . . . . . . 13
4.3. RSAES OAEP를 사용한 키 암호화 . . . . . . . . . . . 14
4.4. AES Key Wrap을 사용한 키 래핑 . . . . . . . . . . . 14
4.5. 공유 대칭 키를 사용한 직접 암호화 . . . . . . . . . 15
4.6. Elliptic Curve Diffie-Hellman
Ephemeral Static(ECDH-ES)을 사용한 키 합의 . . . . . . . . . 15
4.6.1. ECDH 키 합의에 사용되는 헤더 매개변수 . . . . . 16
4.6.1.1. "epk"(임시 공개 키) 헤더 매개변수 . . . . . 16
4.6.1.2. "apu"(Agreement PartyUInfo) 헤더 매개변수 . 17
4.6.1.3. "apv"(Agreement PartyVInfo) 헤더 매개변수 . 17
4.6.2. ECDH 키 합의를 위한 키 파생 . . . . . . . . . . 17
4.7. AES GCM을 사용한 키 암호화 . . . . . . . . . . . . . 18
4.7.1. AES GCM 키 암호화에 사용되는 헤더 매개변수 . . 19
4.7.1.1. "iv"(초기화 벡터) 헤더 매개변수 . . . . . . 19
4.7.1.2. "tag"(인증 태그) 헤더 매개변수 . . . . . . 19
4.8. PBES2를 사용한 키 암호화 . . . . . . . . . . . . . . 20
4.8.1. PBES2 키 암호화에 사용되는 헤더 매개변수 . . . 20
4.8.1.1. "p2s"(PBES2 솔트 입력) 헤더 매개변수 . . . 21
4.8.1.2. "p2c"(PBES2 횟수) 헤더 매개변수 . . . . . 21
5. 콘텐츠 암호화용 암호화 알고리즘 . . . . . . . . . . . . 21
5.1. JWE용 "enc"(암호화 알고리즘) 헤더 매개변수 값
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 알고리즘 . . . . . . . . . . . . . 22
5.2.1. AES_CBC_HMAC_SHA2 정의에 사용되는 규칙 . . . . 23
5.2.2. 일반 AES_CBC_HMAC_SHA2 알고리즘 . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 암호화 . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 복호화 . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . 26
5.2.6. AES_CBC_HMAC_SHA2를 사용한 콘텐츠 암호화 . . . 26
5.3. AES GCM을 사용한 콘텐츠 암호화 . . . . . . . . . . 27
6. 키용 암호화 알고리즘 . . . . . . . . . . . . . . . . . . 27
6.1. "kty"(키 유형) 매개변수 값 . . . . . . . . . . . . 28
Jones 표준 트랙 [페이지 2]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
6.2. 타원 곡선 키의 매개변수 . . . . . . . . . . . . . . 28
6.2.1. 타원 곡선 공개 키의 매개변수 . . . . . . . . . 28
6.2.1.1. "crv"(곡선) 매개변수 . . . . . . . . . . . . 28
6.2.1.2. "x"(X 좌표) 매개변수 . . . . . . . . . . . 29
6.2.1.3. "y"(Y 좌표) 매개변수 . . . . . . . . . . . 29
6.2.2. 타원 곡선 개인 키의 매개변수 . . . . . . . . . 29
6.2.2.1. "d"(ECC 개인 키) 매개변수 . . . . . . . . . 29
6.3. RSA 키의 매개변수 . . . . . . . . . . . . . . . . . 30
6.3.1. RSA 공개 키의 매개변수 . . . . . . . . . . . . 30
6.3.1.1. "n"(모듈러스) 매개변수 . . . . . . . . . . . 30
6.3.1.2. "e"(지수) 매개변수 . . . . . . . . . . . . 30
6.3.2. RSA 개인 키의 매개변수 . . . . . . . . . . . . 30
6.3.2.1. "d"(개인 지수) 매개변수 . . . . . . . . . 30
6.3.2.2. "p"(첫 번째 소인수) 매개변수 . . . . . . . 31
6.3.2.3. "q"(두 번째 소인수) 매개변수 . . . . . . . 31
6.3.2.4. "dp"(첫 번째 인수 CRT 지수) 매개변수 . . 31
6.3.2.5. "dq"(두 번째 인수 CRT 지수) 매개변수 . . 31
6.3.2.6. "qi"(첫 번째 CRT 계수) 매개변수 . . . . . 31
6.3.2.7. "oth"(기타 소수 정보) 매개변수 . . . . . . 31
6.4. 대칭 키의 매개변수 . . . . . . . . . . . . . . . . 32
6.4.1. "k"(키 값) 매개변수 . . . . . . . . . . . . . . 32
7. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . 32
7.1. JSON 웹 서명 및 암호화 알고리즘 레지스트리 . . . . 33
7.1.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . 34
7.1.2. 초기 레지스트리 내용 . . . . . . . . . . . . . 35
7.2. 헤더 매개변수 이름 등록 . . . . . . . . . . . . . . 42
7.2.1. 레지스트리 내용 . . . . . . . . . . . . . . . . 42
7.3. JSON 웹 암호화 압축 알고리즘 레지스트리 . . . . . 43
7.3.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . 43
7.3.2. 초기 레지스트리 내용 . . . . . . . . . . . . . 44
7.4. JSON 웹 키 유형 레지스트리 . . . . . . . . . . . . 44
7.4.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . 44
7.4.2. 초기 레지스트리 내용 . . . . . . . . . . . . . 45
7.5. JSON 웹 키 매개변수 등록 . . . . . . . . . . . . . 45
7.5.1. 레지스트리 내용 . . . . . . . . . . . . . . . . 46
7.6. JSON 웹 키 타원 곡선 레지스트리 . . . . . . . . . 48
7.6.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . 48
7.6.2. 초기 레지스트리 내용 . . . . . . . . . . . . . 49
8. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . 49
8.1. 암호화 민첩성 . . . . . . . . . . . . . . . . . . . . 50
8.2. 키 수명 . . . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 보안 고려 사항 . . . . . . . . . 50
8.4. AES GCM 보안 고려 사항 . . . . . . . . . . . . . . 50
8.5. 비보안 JWS 보안 고려 사항 . . . . . . . . . . . . . 51
8.6. 서비스 거부 공격 . . . . . . . . . . . . . . . . . . 51
8.7. 키 암호화 시 키 자료 재사용 . . . . . . . . . . . . 51
8.8. 비밀번호 고려 사항 . . . . . . . . . . . . . . . . . 52
8.9. 키 엔트로피와 난수 값 . . . . . . . . . . . . . . . 52
Jones 표준 트랙 [페이지 3]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
8.10. 디지털 서명과 MAC의 차이 . . . . . . . . . . . . . 52
8.11. 일치하는 알고리즘 강도 사용 . . . . . . . . . . . 53
8.12. 적응형 선택 암호문 공격 . . . . . . . . . . . . . 53
8.13. 타이밍 공격 . . . . . . . . . . . . . . . . . . . . 53
8.14. RSA 개인 키 표현 및 블라인딩 . . . . . . . . . . 53
9. 국제화 고려 사항 . . . . . . . . . . . . . . . . . . . . 53
10. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . 53
10.2. 참고용 참고 문헌 . . . . . . . . . . . . . . . . . 56
부록 A. 알고리즘 식별자 상호 참조 . . . . . . . . . . . . 59
A.1. 디지털 서명/MAC 알고리즘 식별자 상호
참조 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2. 키 관리 알고리즘 식별자 상호 참조 . . . . . . . . 61
A.3. 콘텐츠 암호화 알고리즘 식별자 상호 참조 . . . . . . . . 62
부록 B. AES_CBC_HMAC_SHA2 알고리즘 테스트 사례 . . . . 62
B.1. AES_128_CBC_HMAC_SHA_256 테스트 사례 . . . . . . . 63
B.2. AES_192_CBC_HMAC_SHA_384 테스트 사례 . . . . . . . 64
B.3. AES_256_CBC_HMAC_SHA_512 테스트 사례 . . . . . . . 65
부록 C. ECDH-ES 키 합의 계산 예시 . . . . . . . . . . . 66
감사의 글 . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1. 소개
이 명세는 JSON Web Signature(JWS) [JWS], JSON Web
Encryption(JWE) [JWE] 및 JSON Web Key(JWK) [JWK] 명세와 함께
사용할 암호화 알고리즘과 식별자를 등록합니다. 또한 이러한 식별자를 위한 여러
IANA 레지스트리를 정의합니다. 이들 모든 명세는 JSON 기반
[RFC7159] 데이터 구조를 사용합니다. 이
명세는 또한 이러한 알고리즘과 키 유형에
특화된 의미와 연산을 설명합니다.
알고리즘과 식별자를 JWS, JWE 및 JWK 명세 자체가 아니라
여기에 등록하는 것은 시간이 지남에 따라 필수, 권고,
선택 사항 및 사용 중단 알고리즘 집합이 변경되더라도 해당 명세들을
변경하지 않고 유지할 수 있도록 하기 위한 것입니다. 또한 이를 통해
이 문서를 변경하지 않고 JWS, JWE 및 JWK 명세를 변경할 수
있습니다.
이 명세에서 정의하는 이름은 결과 표현을 간결하게 만드는 것이
핵심 목표이므로 짧습니다.
1.1. 표기 규칙
이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 및
"OPTIONAL"이라는 핵심 단어는
"요구 사항 수준을 나타내기 위해 RFC에서 사용하는 핵심 단어" [RFC2119]에
설명된 대로 해석해야 합니다.
Jones 표준 트랙 [페이지 4]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
이러한 해석은 해당 용어가 모두 대문자로
나타날 때에만 적용해야 합니다.
BASE64URL(OCTETS)는 [JWS]의 섹션 2에 따른
OCTETS의 base64url 인코딩을 나타냅니다.
UTF8(STRING)은 STRING의 UTF-8 [RFC3629] 표현의 옥텟을
나타내며, 여기서 STRING은 0개 이상의 Unicode
[UNICODE] 문자 시퀀스입니다.
ASCII(STRING)은 STRING의 ASCII [RFC20] 표현의 옥텟을
나타내며, 여기서 STRING은 0개 이상의 ASCII
문자 시퀀스입니다.
두 값 A와 B의 연결은 A || B로 나타냅니다.
2. 용어
"JSON Web Signature (JWS)", "Base64url Encoding", "Header
Parameter", "JOSE Header", "JWS Payload", "JWS Protected Header",
"JWS Signature", "JWS Signing Input" 및 "Unsecured JWS"라는 용어는
JWS 명세 [JWS]에서 정의합니다.
"JSON Web Encryption (JWE)", "Additional Authenticated Data
(AAD)", "Authentication Tag", "Content Encryption Key (CEK)", "Direct
Encryption", "Direct Key Agreement", "JWE Authentication Tag", "JWE
Ciphertext", "JWE Encrypted Key", "JWE Initialization Vector", "JWE
Protected Header", "Key Agreement with Key Wrapping", "Key
Encryption", "Key Management Mode" 및 "Key Wrapping"이라는 용어는
JWE 명세 [JWE]에서 정의합니다.
"JSON Web Key (JWK)" 및 "JWK Set"이라는 용어는 JWK
명세 [JWK]에서 정의합니다.
"Ciphertext", "Digital Signature", "Initialization Vector",
"Message Authentication Code (MAC)" 및 "Plaintext"라는 용어는
"인터넷 보안 용어집, 버전 2" [RFC4949]에서 정의합니다.
다음 용어는 이 명세에서 정의합니다.
Base64urlUInt
양수 또는 0인 정수 값을, 해당 값의 부호 없는 빅 엔디언
표현을 옥텟 시퀀스로 나타낸 뒤 base64url 인코딩한
표현입니다. 옥텟 시퀀스는 해당 값을 표현하는 데 필요한
최소 개수의 옥텟을 반드시 사용해야 합니다. 0은 BASE64URL(값이 0인
단일 옥텟)로 표현되며, 이는 "AA"입니다.
Jones 표준 트랙 [페이지 5]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
3. 디지털 서명 및 MAC용 암호화 알고리즘
JWS는 JWS Protected Header 및 JWS Payload의 콘텐츠에 디지털
서명하거나 MAC을 생성하기 위해 암호화 알고리즘을 사용합니다.
3.1. JWS용 "alg"(알고리즘) 헤더 매개변수 값
아래 표는 이 명세에서 JWS와 함께 사용하도록 정의한
"alg"(알고리즘) 헤더 매개변수 값의 집합이며, 각 값은
다음 절에서 더 자세히 설명합니다.
+--------------+-------------------------------+--------------------+
| "alg" 매개변수 | 디지털 서명 또는 MAC | 구현 |
| 값 | 알고리즘 | 요구 사항 |
+--------------+-------------------------------+--------------------+
| HS256 | SHA-256을 사용하는 HMAC | 필수 |
| HS384 | SHA-384를 사용하는 HMAC | 선택 사항 |
| HS512 | SHA-512를 사용하는 HMAC | 선택 사항 |
| RS256 | SHA-256을 사용하는 | 권고 |
| | RSASSA-PKCS1-v1_5 | |
| RS384 | SHA-384를 사용하는 | 선택 사항 |
| | RSASSA-PKCS1-v1_5 | |
| RS512 | SHA-512를 사용하는 | 선택 사항 |
| | RSASSA-PKCS1-v1_5 | |
| ES256 | P-256 및 SHA-256을 사용하는 ECDSA | 권고+ |
| ES384 | P-384 및 SHA-384를 사용하는 ECDSA | 선택 사항 |
| ES512 | P-521 및 SHA-512를 사용하는 ECDSA | 선택 사항 |
| PS256 | SHA-256 및 SHA-256을 사용하는 | 선택 사항 |
| | MGF1을 사용하는 RSASSA-PSS | |
| PS384 | SHA-384 및 SHA-384를 사용하는 | 선택 사항 |
| | MGF1을 사용하는 RSASSA-PSS | |
| PS512 | SHA-512 및 SHA-512를 사용하는 | 선택 사항 |
| | MGF1을 사용하는 RSASSA-PSS | |
| none | 디지털 서명 또는 MAC을 | 선택 사항 |
| | 수행하지 않음 | |
+--------------+-------------------------------+--------------------+
구현 요구 사항 열에서 "+"를 사용하는 것은
향후 명세 버전에서 요구 수준이 높아질 가능성이
있음을 나타냅니다.
이 명세에서 정의한 JWS 디지털 서명 및 MAC "alg"(알고리즘)
값을 다른 표준 및 소프트웨어 패키지에서 사용하는 동등한
식별자와 상호 참조하는 표는 부록 A.1을 참조하십시오.
Jones 표준 트랙 [페이지 6]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
3.2. SHA-2 함수를 사용하는 HMAC
해시 기반 메시지 인증 코드(HMAC)를 사용하면 비밀값과
암호화 해시 함수를 사용하여 MAC을 생성할 수 있습니다. 이를 통해
MAC을 생성한 주체가 MAC 키를 보유하고 있었음을
입증할 수 있습니다. HMAC을 구현하고 검증하는 알고리즘은
RFC 2104 [RFC2104]에 제공됩니다.
이 알고리즘에는 해시 출력과 동일한 크기(예: "HS256"의 경우
256비트) 이상의 키를 반드시 사용해야 합니다. (이
요구 사항은 NIST SP 800-117 [NIST.800-107]의 섹션 5.3.4(HMAC
키의 보안 효과)에 근거하며, 여기서는
유효 보안 강도가 키의 보안 강도와
내부 해시 값 크기의 두 배 중 작은 값이라고 명시합니다.)
HMAC SHA-256 MAC은 RFC 2104에 따라 생성되며, SHA-256을
해시 알고리즘 "H"로, JWS Signing Input을 "text" 값으로,
공유 키를 사용합니다. HMAC 출력 값이 JWS
Signature입니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS Signature가 해당 알고리즘을 사용하여 계산된
HMAC 값임을 나타내는 데 사용합니다.
+-------------------+--------------------+
| "alg" 매개변수 값 | MAC 알고리즘 |
+-------------------+--------------------+
| HS256 | SHA-256 사용 HMAC |
| HS384 | SHA-384 사용 HMAC |
| HS512 | SHA-512 사용 HMAC |
+-------------------+--------------------+
JWS용 HMAC SHA-256 MAC은 RFC 2104에 따라 HMAC
값을 계산하여 검증합니다. SHA-256을 해시 알고리즘 "H"로 사용하고,
수신한 JWS Signing Input을 "text" 값으로 사용하며,
공유 키를 사용합니다. 그런 다음 계산된 HMAC 값을
수신한 인코딩된 JWS Signature 값을 base64url 디코딩한 결과와 비교합니다.
타이밍 공격을 방지하기 위해 계산된 HMAC 값과 JWS Signature 값의
비교는 반드시 상수 시간 방식으로 수행해야 합니다.
또는 계산된 HMAC 값을 base64url 인코딩하여
수신한 인코딩된 JWS Signature 값과 비교할 수 있습니다(역시
상수 시간 방식). 이 비교는 인코딩되지 않은 값을
비교하는 것과 동일한 결과를 생성합니다. 두 경우 모두 값이 일치하면
HMAC이 검증된 것입니다.
Jones 표준 트랙 [페이지 7]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
HMAC SHA-384 및 HMAC SHA-512 알고리즘을 사용한 콘텐츠 보호와
검증은 HMAC SHA-256 절차와 동일하게 수행되며, 단지
각각 더 큰 최소 키 크기와 결과 값을 갖는 해당 해시 알고리즘을
사용합니다. HMAC SHA-384의 경우 각각 384비트이고,
HMAC SHA-512의 경우 각각 512비트입니다.
이 알고리즘을 사용하는 예시는 [JWS]의 부록 A.1에 나와 있습니다.
3.3. RSASSA-PKCS1-v1_5를 사용하는 디지털 서명
이 절에서는 RFC 3447의 섹션 8.2 [RFC3447]에
정의된 RSASSA-PKCS1-v1_5 디지털 서명 알고리즘
(일반적으로 PKCS #1으로 알려짐)을 SHA-2 [SHS] 해시 함수와 함께
사용하는 방법을 정의합니다.
이러한 알고리즘에는 2048비트 이상의 키를 반드시 사용해야 합니다.
RSASSA-PKCS1-v1_5 SHA-256 디지털 서명은 다음과 같이
생성합니다. 원하는 개인 키와 SHA-256 해시 함수를 사용하여
RSASSA-PKCS1-v1_5-SIGN으로 JWS Signing Input의 디지털 서명을
생성합니다. 이것이 JWS Signature 값입니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS Signature가 해당 알고리즘을 사용하여 계산된 디지털 서명
값임을 나타내는 데 사용합니다.
+-------------------+---------------------------------+
| "alg" 매개변수 값 | 디지털 서명 알고리즘 |
+-------------------+---------------------------------+
| RS256 | SHA-256 사용 RSASSA-PKCS1-v1_5 |
| RS384 | SHA-384 사용 RSASSA-PKCS1-v1_5 |
| RS512 | SHA-512 사용 RSASSA-PKCS1-v1_5 |
+-------------------+---------------------------------+
JWS용 RSASSA-PKCS1-v1_5 SHA-256 디지털 서명은
다음과 같이 검증합니다. JWS Signing Input, JWS
Signature 및 서명자가 사용한 개인 키에 대응하는 공개 키를
SHA-256을 해시 함수로 사용하는
RSASSA-PKCS1-v1_5-VERIFY 알고리즘에 전달합니다.
RSASSA-PKCS1-v1_5 SHA-384 및 RSASSA-
PKCS1-v1_5 SHA-512 알고리즘을 사용한 서명과 검증은
RSASSA-PKCS1-v1_5 SHA-256 절차와 동일하게 수행하며,
SHA-256 대신 해당 해시 알고리즘을 사용합니다.
이 알고리즘을 사용하는 예시는 [JWS]의 부록 A.2에 나와 있습니다.
Jones 표준 트랙 [페이지 8]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
3.4. ECDSA를 사용하는 디지털 서명
타원 곡선 디지털 서명 알고리즘(ECDSA) [DSS]은
타원 곡선 암호화를 사용할 수 있게 하며, 이는 더 짧은 키 크기를
사용하면서 RSA 암호화와 동등한 보안을 제공하고
많은 연산에서 더 빠른 처리 속도를 제공할 수 있습니다. 즉,
ECDSA 디지털 서명은 동등한 강도의 RSA 디지털 서명보다
길이 측면에서 상당히 작습니다.
이 명세는 P-256 곡선과 SHA-256 암호화 해시 함수를 사용하는 ECDSA,
P-384 곡선과 SHA-384 해시 함수를 사용하는 ECDSA,
P-521 곡선과 SHA-512 해시 함수를 사용하는 ECDSA를 정의합니다.
P-256, P-384 및 P-521 곡선은
[DSS]에 정의되어 있습니다.
ECDSA P-256 SHA-256 디지털 서명은 다음과 같이 생성합니다.
1. 원하는 개인 키로 ECDSA P-256 SHA-256을 사용하여
JWS Signing Input의 디지털 서명을 생성합니다. 출력은
(R, S) 쌍이며, R과 S는 256비트 부호 없는 정수입니다.
2. R과 S를 빅 엔디언 순서의 옥텟 시퀀스로 변환하며, 각
배열의 길이는 32옥텟이어야 합니다. 값에 포함된 선행 0
옥텟을 생략하기 위해 옥텟 시퀀스 표현을
단축해서는 안 됩니다.
3. 두 옥텟 시퀀스를 R, 그다음 S 순서로 연결합니다.
(많은 ECDSA 구현은 이 연결 결과를
출력으로 직접 생성한다는 점에 유의하십시오.)
4. 결과로 얻은 64옥텟 시퀀스가 JWS Signature 값입니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS Signature가 해당 알고리즘을 사용하여 계산된 디지털 서명
값임을 나타내는 데 사용합니다.
+-------------------+-------------------------------+
| "alg" 매개변수 값 | 디지털 서명 알고리즘 |
+-------------------+-------------------------------+
| ES256 | P-256 및 SHA-256 사용 ECDSA |
| ES384 | P-384 및 SHA-384 사용 ECDSA |
| ES512 | P-521 및 SHA-512 사용 ECDSA |
+-------------------+-------------------------------+
Jones 표준 트랙 [페이지 9]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
JWS용 ECDSA P-256 SHA-256 디지털 서명은 다음과 같이
검증합니다.
1. JWS Signature 값은 반드시 64옥텟 시퀀스여야 합니다.
64옥텟 시퀀스가 아니면 검증은 실패합니다.
2. 64옥텟 시퀀스를 두 개의 32옥텟 시퀀스로 나눕니다.
첫 번째 옥텟 시퀀스는 R을, 두 번째는 S를 나타냅니다.
R 및 S 값은 SEC1 [SEC1]의 섹션 2.3.7에 정의된 Integer-to-
OctetString Conversion을 사용하여 옥텟 시퀀스로 표현합니다
(빅 엔디언 옥텟 순서).
3. JWS Signing Input, R, S 및 공개 키 (x, y)를
ECDSA P-256 SHA-256 검증기에 전달합니다.
ECDSA P-384 SHA-384 및 ECDSA P-521
SHA-512 알고리즘을 사용한 서명과 검증은
ECDSA P-256 SHA-256 절차와 동일하게 수행하되, 해당 해시 알고리즘과
이에 맞는 더 큰 결과 값을 사용합니다. ECDSA P-384 SHA-384의 경우
R과 S는 각각 384비트이므로 96옥텟 시퀀스가 됩니다.
ECDSA P-521 SHA-512의 경우 R과 S는 각각 521비트이므로
132옥텟 시퀀스가 됩니다. (R과 S를 옥텟 시퀀스로
표현하는 데 사용되는 SEC1 [SEC1]의 섹션 2.3.7에 정의된 Integer-to-OctetString Conversion은
크기를 8비트의 배수로 반올림하는 데 필요할 경우
상위에 값이 0인 패딩 비트를 추가하므로, 각 521비트
정수는 66옥텟의 528비트를 사용하여 표현됩니다.)
이러한 알고리즘을 사용하는 예시는 [JWS]의
부록 A.3 및 A.4에 나와 있습니다.
3.5. RSASSA-PSS를 사용하는 디지털 서명
이 절에서는 RFC 3447의 섹션 8.1 [RFC3447]에 정의된
RSASSA-PSS 디지털 서명 알고리즘을 MGF1 마스크 생성 함수 및
SHA-2 해시 함수와 함께 사용하는 방법을 정의하며, RSASSA-PSS
해시 함수와 MGF1 해시 함수 모두에 항상 동일한 해시 함수를
사용합니다. 솔트 값의 크기는 해시 함수 출력과 동일합니다.
다른 모든 알고리즘 매개변수는
RFC 3447의 부록 A.2.3에 지정된 기본값을 사용합니다.
이 알고리즘에는 2048비트 이상의 키를 반드시 사용해야 합니다.
RSASSA-PSS SHA-256 디지털 서명은 다음과 같이 생성합니다.
원하는 개인 키를 사용하여 RSASSA-
PSS-SIGN, SHA-256 해시 함수 및 SHA-256을 사용하는 MGF1 마스크 생성
함수로 JWS Signing Input의 디지털 서명을 생성합니다. 이것이 JWS
Signature 값입니다.
Jones 표준 트랙 [페이지 10]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS Signature가 해당 알고리즘을 사용하여 계산된 디지털 서명
값임을 나타내는 데 사용합니다.
+-------------------+-----------------------------------------------+
| "alg" 매개변수 값 | 디지털 서명 알고리즘 |
+-------------------+-----------------------------------------------+
| PS256 | SHA-256 및 SHA-256을 사용하는 MGF1을 사용한 |
| | RSASSA-PSS |
| PS384 | SHA-384 및 SHA-384를 사용하는 MGF1을 사용한 |
| | RSASSA-PSS |
| PS512 | SHA-512 및 SHA-512를 사용하는 MGF1을 사용한 |
| | RSASSA-PSS |
+-------------------+-----------------------------------------------+
JWS용 RSASSA-PSS SHA-256 디지털 서명은 다음과 같이
검증합니다. JWS Signing Input, JWS Signature 및
서명자가 사용한 개인 키에 대응하는 공개 키를
SHA-256을 해시 함수로 사용하고 SHA-256과 함께 MGF1을
마스크 생성 함수로 사용하는 RSASSA-PSS-VERIFY 알고리즘에 전달합니다.
RSASSA-PSS SHA-384 및 RSASSA-PSS
SHA-512 알고리즘을 사용한 서명과 검증은
RSASSA-PSS SHA-256 절차와 동일하게 수행하며, 두 역할 모두에
해당하는 다른 해시 알고리즘을 사용합니다.
3.6. "none" 알고리즘 사용
무결성 보호를 제공하지 않는 JWS도 생성할 수 있습니다.
이러한 JWS를 비보안 JWS라고 합니다. 비보안 JWS는
"alg" 값 "none"을 사용하며 다른 JWS와 동일한 형식이지만,
JWS Signature 값으로 빈 옥텟 시퀀스를 반드시 사용해야 합니다.
수신자는 JWS Signature 값이 빈 옥텟 시퀀스인지
반드시 확인해야 합니다.
비보안 JWS를 지원하는 구현은 애플리케이션이
특정 객체에 무결성 보호가 없어도 허용된다고 지정하지 않는 한
그러한 객체를 유효한 것으로 받아들여서는 안 됩니다.
구현은 기본적으로 비보안 JWS를 받아들여서는 안 됩니다.
다운그레이드 공격을 완화하기 위해 애플리케이션은
전역 수준에서 비보안 JWS의 수락을 신호해서는 안 되며,
객체별로 수락 여부를 신호하는 것이 좋습니다. 이 알고리즘 사용과 관련된
보안 고려 사항은 섹션 8.5를 참조하십시오.
4. 키 관리용 암호화 알고리즘
JWE는 Content Encryption Key(CEK)를 암호화하거나 결정하기 위해
암호화 알고리즘을 사용합니다.
Jones 표준 트랙 [페이지 11]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
4.1. JWE용 "alg"(알고리즘) 헤더 매개변수 값
아래 표는 이 명세에서 JWE와 함께 사용하도록 정의한
"alg"(알고리즘) 헤더 매개변수 값의 집합입니다.
이러한 알고리즘은 CEK를 암호화하여 JWE
Encrypted Key를 생성하거나 키 합의를 사용하여 CEK에 합의하는 데 사용합니다.
+--------------------+--------------------+--------+----------------+
| "alg" 매개변수 값 | 키 관리 | 추가 | 구현 |
| | 알고리즘 | 헤더 | 요구 사항 |
| | | 매개변수 | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (없음) | 권고- |
| RSA-OAEP | 기본 매개변수를 | (없음) | 권고+ |
| | 사용하는 RSAES OAEP | | |
| RSA-OAEP-256 | SHA-256 및 | (없음) | 선택 사항 |
| | SHA-256을 사용하는 | | |
| | MGF1 사용 RSAES OAEP | | |
| A128KW | 기본 초기값과 | (없음) | 권고 |
| | 128비트 키를 | | |
| | 사용하는 | | |
| | AES Key Wrap | | |
| A192KW | 기본 초기값과 | (없음) | 선택 사항 |
| | 192비트 키를 | | |
| | 사용하는 | | |
| | AES Key Wrap | | |
| A256KW | 기본 초기값과 | (없음) | 권고 |
| | 256비트 키를 | | |
| | 사용하는 | | |
| | AES Key Wrap | | |
| dir | 공유 대칭 키를 | (없음) | 권고 |
| | CEK로 직접 | | |
| | 사용 | | |
| ECDH-ES | 타원 곡선 | "epk", | 권고+ |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | 키 합의 | | |
| | Concat KDF 사용 | | |
| ECDH-ES+A128KW | Concat KDF와 CEK를 | "epk", | 권고 |
| | 사용하고 | "apu", | |
| | "A128KW"로 래핑한 | "apv" | |
| | ECDH-ES | | |
| ECDH-ES+A192KW | Concat KDF와 CEK를 | "epk", | 선택 사항 |
| | 사용하고 | "apu", | |
| | "A192KW"로 래핑한 | "apv" | |
Jones 표준 트랙 [페이지 12]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
| ECDH-ES+A256KW | Concat KDF와 CEK를 | "epk", | 권고 |
| | 사용하고 | "apu", | |
| | "A256KW"로 래핑한 | "apv" | |
| | ECDH-ES | | |
| A128GCMKW | 128비트 키를 | "iv", | 선택 사항 |
| | 사용하는 AES GCM | "tag" | |
| | 키 래핑 | | |
| A192GCMKW | 192비트 키를 | "iv", | 선택 사항 |
| | 사용하는 AES GCM | "tag" | |
| | 키 래핑 | | |
| A256GCMKW | 256비트 키를 | "iv", | 선택 사항 |
| | 사용하는 AES GCM | "tag" | |
| | 키 래핑 | | |
| PBES2-HS256+A128KW | HMAC SHA-256 및 | "p2s", | 선택 사항 |
| | "A128KW" 래핑을 | "p2c" | |
| | 사용하는 PBES2 | | |
| PBES2-HS384+A192KW | HMAC SHA-384 및 | "p2s", | 선택 사항 |
| | "A192KW" 래핑을 | "p2c" | |
| | 사용하는 PBES2 | | |
| PBES2-HS512+A256KW | HMAC SHA-512 및 | "p2s", | 선택 사항 |
| | "A256KW" 래핑을 | "p2c" | |
| | 사용하는 PBES2 | | |
+--------------------+--------------------+--------+----------------+
추가 헤더 매개변수 열은 모든 알고리즘이 사용하는 "alg" 외에
해당 알고리즘이 사용하는 추가 헤더 매개변수를 나타냅니다.
"dir" 및 "ECDH-ES"를 제외한 모든 알고리즘은 JWE Encrypted Key 값도 생성합니다.
구현 요구 사항 열에서 "+"는 향후 명세 버전에서
요구 수준이 높아질 가능성이 있음을 나타냅니다.
"-"는 향후 명세 버전에서 요구 수준이 낮아질
가능성이 있음을 나타냅니다.
이 명세에서 정의한 JWE "alg"(알고리즘) 값을
다른 표준 및 소프트웨어 패키지에서 사용하는 동등한 식별자와
상호 참조하는 표는 부록 A.2를 참조하십시오.
4.2. RSAES-PKCS1-v1_5를 사용한 키 암호화
이 절에서는 RSAES-PKCS1-v1_5 [RFC3447]를 사용하여 JWE CEK를
암호화하는 구체적인 방법을 정의합니다. 이 알고리즘에는
"alg"(알고리즘) 헤더 매개변수 값 "RSA1_5"를 사용합니다.
이 알고리즘에는 2048비트 이상의 키를 반드시 사용해야 합니다.
이 알고리즘을 사용하는 예시는 [JWE]의 부록 A.2에 나와 있습니다.
Jones 표준 트랙 [페이지 13]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
4.3. RSAES OAEP를 사용한 키 암호화
이 절에서는 Optimal Asymmetric Encryption Padding(OAEP)
[RFC3447]를 사용하는 RSAES로 JWE CEK를 암호화하는 구체적인 방법을 정의합니다.
서로 다른 해시 함수를 사용하는 두 가지 OAEP 매개변수 집합을
정의합니다. 첫 번째 경우에는
RFC 3447의 부록 A.2.1에 지정된 기본 매개변수를 사용합니다. (해당 기본 매개변수는
SHA-1 해시 함수와 SHA-1을 사용하는 MGF1 마스크 생성
함수입니다.) 두 번째 경우에는 SHA-256 해시 함수와
SHA-256을 사용하는 MGF1 마스크 생성 함수를 사용합니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWE Encrypted Key가 해당 알고리즘을 사용하여
CEK를 암호화한 결과임을 나타내는 데 사용합니다.
+-------------------+-----------------------------------------------+
| "alg" 매개변수 값 | 키 관리 알고리즘 |
+-------------------+-----------------------------------------------+
| RSA-OAEP | 기본 매개변수를 사용하는 RSAES OAEP |
| RSA-OAEP-256 | SHA-256 및 SHA-256을 사용하는 MGF1을 사용한 |
| | RSAES OAEP |
+-------------------+-----------------------------------------------+
이러한 알고리즘에는 2048비트 이상의 키를 반드시 사용해야 합니다.
(이 요구 사항은 NIST SP 800-57 [NIST.800-57]의 표 4(보안 강도 기간)에
근거하며, 신규 사용에는 112비트의 보안이 필요하다고 하며,
동일 문서의 표 2(비교 가능한 강도)는
2048비트 RSA 키가 112비트의 보안을 제공한다고 명시합니다.)
기본 매개변수를 사용하는 RSAES OAEP 예시는
[JWE]의 부록 A.1에 나와 있습니다.
4.4. AES Key Wrap을 사용한 키 래핑
이 절에서는 해당 문서의 섹션 2.2.3.1에 지정된
기본 초기값과 함께 Advanced Encryption Standard(AES) Key Wrap
Algorithm [RFC3394]을 사용하여 JWE CEK를 암호화하는
구체적인 방법을 정의합니다.
Jones 표준 트랙 [페이지 14]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWE Encrypted Key가 해당 알고리즘 및 키 크기를 사용하여
CEK를 암호화한 결과임을 나타내는 데 사용합니다.
+-----------------+-------------------------------------------------+
| "alg" 매개변수 | 키 관리 알고리즘 |
| 값 | |
+-----------------+-------------------------------------------------+
| A128KW | 128비트 키와 기본 초기값을 사용하는 |
| | AES Key Wrap |
| A192KW | 192비트 키와 기본 초기값을 사용하는 |
| | AES Key Wrap |
| A256KW | 256비트 키와 기본 초기값을 사용하는 |
| | AES Key Wrap |
+-----------------+-------------------------------------------------+
이 알고리즘을 사용하는 예시는 [JWE]의 부록 A.3에 나와 있습니다.
4.5. 공유 대칭 키를 사용한 직접 암호화
이 절에서는 키 래핑 단계를 수행하지 않고 대칭
키 암호화를 직접 수행하는 구체적인 방법을 정의합니다. 이 경우
공유 대칭 키를 "enc" 알고리즘의 Content Encryption
Key(CEK) 값으로 직접 사용합니다. JWE Encrypted Key 값으로는
빈 옥텟 시퀀스를 사용합니다. 이 경우 "alg"(알고리즘) 헤더
매개변수 값 "dir"을 사용합니다.
직접 암호화를 사용할지 고려할 때 키 수명에 관한
섹션 8.2와 AES GCM에 관한 섹션 8.4의 보안 고려 사항을
참조하십시오.
4.6. Elliptic Curve Diffie-Hellman Ephemeral Static을 사용한 키 합의
(ECDH-ES)
이 절에서는 [NIST.800-56A]의 섹션 5.8.1에 정의된
Concat KDF와 함께 Elliptic Curve Diffie-Hellman Ephemeral Static
[RFC6090]을 사용한 키 합의의 구체적인 방법을 정의합니다.
키 합의 결과는 다음 두 가지 방법 중 하나로 사용할 수 있습니다.
1. Direct Key Agreement 모드에서 "enc" 알고리즘의
Content Encryption Key(CEK)로 직접 사용하거나,
2. Key Agreement with Key Wrapping 모드에서 CEK를 "A128KW",
"A192KW" 또는 "A256KW" 알고리즘으로 래핑하는 데 사용하는
대칭 키로 사용합니다.
각 키 합의 연산마다 새로운 임시 공개 키 값을
반드시 생성해야 합니다.
Jones 표준 트랙 [페이지 15]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
Direct Key Agreement 모드에서는 Concat KDF의 출력이
"enc" 알고리즘에서 사용하는 키와 동일한 길이의 키여야 합니다.
이 경우 JWE Encrypted Key 값으로 빈 옥텟 시퀀스를
사용합니다. Direct Key Agreement 모드에서는
"alg"(알고리즘) 헤더 매개변수 값 "ECDH-ES"를 사용합니다.
Key Agreement with Key Wrapping 모드에서는 Concat KDF의 출력이
지정된 키 래핑 알고리즘에 필요한 길이의 키여야 합니다.
이 경우 JWE Encrypted Key는 합의된 키로 래핑한 CEK입니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWE Encrypted Key가 키 합의 알고리즘의 결과를
해당 키 래핑 알고리즘용 키 암호화 키로 사용하여
CEK를 암호화한 결과임을 나타내는 데 사용합니다.
+-----------------+-------------------------------------------------+
| "alg" 매개변수 | 키 관리 알고리즘 |
| 값 | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | Concat KDF를 사용하고 CEK를 "A128KW"로 래핑한 |
| | ECDH-ES |
| ECDH-ES+A192KW | Concat KDF를 사용하고 CEK를 "A192KW"로 래핑한 |
| | ECDH-ES |
| ECDH-ES+A256KW | Concat KDF를 사용하고 CEK를 "A256KW"로 래핑한 |
| | ECDH-ES |
+-----------------+-------------------------------------------------+
4.6.1. ECDH 키 합의에 사용되는 헤더 매개변수
다음 헤더 매개변수 이름은 아래에 정의된 키 합의에
사용합니다.
4.6.1.1. "epk"(임시 공개 키) 헤더 매개변수
"epk"(임시 공개 키) 값은 키 합의 알고리즘에서 사용하기 위해
발신자가 생성한 값입니다. 이 키는 JSON Web Key
[JWK] 공개 키 값으로 표현됩니다. 공개 키
매개변수만 포함해야 하며, 키를 표현하는 데 필요한 최소 JWK
매개변수만 포함하는 것이 좋습니다. 포함된 다른 JWK 매개변수는
일관성을 검사하여 존중하거나 무시할 수 있습니다. 이러한
알고리즘을 사용할 때 구현은 이 헤더 매개변수를 반드시 포함하고
이해하여 처리해야 합니다.
Jones 표준 트랙 [페이지 16]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
4.6.1.2. "apu"(Agreement PartyUInfo) 헤더 매개변수
"apu"(agreement PartyUInfo) 값은 이를 사용하는 키 합의 알고리즘
(예: "ECDH-ES")을 위한 값이며, base64url로 인코딩된
문자열로 표현됩니다. 사용되는 경우 PartyUInfo 값에는
생성자에 관한 정보가 포함됩니다. 이 헤더 매개변수의 사용은 선택 사항입니다.
이러한 알고리즘을 사용할 때 구현은 이 헤더 매개변수를
반드시 이해하고 처리해야 합니다.
4.6.1.3. "apv"(Agreement PartyVInfo) 헤더 매개변수
"apv"(agreement PartyVInfo) 값은 이를 사용하는 키 합의 알고리즘
(예: "ECDH-ES")을 위한 값이며, base64url로 인코딩된
문자열로 표현됩니다. 사용되는 경우 PartyVInfo 값에는
수신자에 관한 정보가 포함됩니다. 이 헤더 매개변수의 사용은 선택 사항입니다.
이러한 알고리즘을 사용할 때 구현은 이 헤더 매개변수를
반드시 이해하고 처리해야 합니다.
4.6.2. ECDH 키 합의를 위한 키 파생
키 파생 과정은 [NIST.800-56A]의
섹션 6.2.2.2에 따라 ECDH 알고리즘을 통해 설정된
공유 비밀 Z로부터 합의된 키를 파생합니다.
키 파생은 [NIST.800-56A]의 섹션 5.8.1에 정의된
Concat KDF를 사용하여 수행하며, Digest Method는 SHA-256입니다.
Concat KDF 매개변수는 다음과 같이 설정합니다.
Z
공유 비밀 Z의 옥텟 시퀀스 표현으로 설정합니다.
keydatalen
원하는 출력 키의 비트 수로 설정합니다.
"ECDH-ES"의 경우 "enc" 알고리즘에서 사용하는 키의 길이입니다.
"ECDH-ES+A128KW", "ECDH-ES+A192KW" 및 "ECDH-ES+A256KW"의 경우
각각 128, 192 및 256입니다.
AlgorithmID
AlgorithmID 값은 Datalen || Data 형식이며, Data는
0개 이상의 옥텟으로 이루어진 가변 길이 문자열이고 Datalen은
Data의 길이(옥텟 단위)를 나타내는 고정 길이의
빅 엔디언 32비트 카운터입니다. Direct Key Agreement의 경우
Data는 "enc" 헤더 매개변수 값의 ASCII 표현에 대한
옥텟으로 설정합니다. Key Agreement with Key Wrapping의 경우
Data는 "alg"(알고리즘) 헤더 매개변수 값의 ASCII 표현에 대한
옥텟으로 설정합니다.
Jones 표준 트랙 [페이지 17]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
PartyUInfo
PartyUInfo 값은 Datalen || Data 형식이며, Data는
0개 이상의 옥텟으로 이루어진 가변 길이 문자열이고 Datalen은
Data의 길이(옥텟 단위)를 나타내는 고정 길이의
빅 엔디언 32비트 카운터입니다. "apu"(agreement PartyUInfo) 헤더
매개변수가 있으면 Data는 "apu" 값을 base64url
디코딩한 결과로 설정하고 Datalen은 Data의 옥텟 수로
설정합니다. 그렇지 않으면 Datalen은 0으로, Data는
빈 옥텟 시퀀스로 설정합니다.
PartyVInfo
PartyVInfo 값은 Datalen || Data 형식이며, Data는
0개 이상의 옥텟으로 이루어진 가변 길이 문자열이고 Datalen은
Data의 길이(옥텟 단위)를 나타내는 고정 길이의
빅 엔디언 32비트 카운터입니다. "apv"(agreement PartyVInfo) 헤더
매개변수가 있으면 Data는 "apv" 값을 base64url
디코딩한 결과로 설정하고 Datalen은 Data의 옥텟 수로
설정합니다. 그렇지 않으면 Datalen은 0으로, Data는
빈 옥텟 시퀀스로 설정합니다.
SuppPubInfo
keydatalen을 32비트 빅 엔디언 정수로 표현한 값으로
설정합니다.
SuppPrivInfo
빈 옥텟 시퀀스로 설정합니다.
애플리케이션은 해당 애플리케이션에서 "apu" 및 "apv" 헤더
매개변수를 어떻게 사용할지 지정해야 합니다. "apu"와 "apv" 값은
사용되는 경우 서로 달라야 합니다. [NIST.800-56A]를 준수하려는 애플리케이션은
해당 문서의 요구 사항을 충족하는 값을 제공해야 하며,
예를 들어 생성자와 소비자를 식별하는 값을 사용할 수 있습니다.
또는 애플리케이션은 "Diffie-Hellman Key Agreement Method" [RFC2631]와
유사한 방식으로 키 파생을 수행할 수 있습니다.
이 경우 "apu" 매개변수는 생략하거나 임의의 512비트 값
(RFC 2631의 Ephemeral-Static 모드에서 PartyAInfo와 유사한 값)을
나타낼 수 있으며, "apv" 매개변수는 존재하지 않는 것이 좋습니다.
이 방법을 사용하는 키 합의 계산의 예시는
부록 C를 참조하십시오.
4.7. AES GCM을 사용한 키 암호화
이 절에서는 Galois/Counter Mode(GCM)의
Advanced Encryption Standard(AES)([AES] 및 [NIST.800-38D])를 사용하여
JWE Content Encryption Key(CEK)를 암호화하는 구체적인 방법을 정의합니다.
Jones 표준 트랙 [페이지 18]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
이 알고리즘에는 96비트 크기의 초기화 벡터(IV)를
반드시 사용해야 합니다. IV는 base64url로 인코딩된 형태로
"iv"(initialization vector) 헤더 매개변수 값에 표현합니다.
사용되는 Additional Authenticated Data 값은 빈 옥텟
문자열입니다.
요청되는 Authentication Tag 출력 크기는 키 크기와 관계없이
반드시 128비트여야 합니다.
JWE Encrypted Key 값은 암호문 출력입니다.
Authentication Tag 출력은 base64url로 인코딩된
형태로 "tag"(authentication tag) 헤더 매개변수 값에 표현합니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWE Encrypted Key가 해당 알고리즘 및 키 크기를 사용하여
CEK를 암호화한 결과임을 나타내는 데 사용합니다.
+-------------------+---------------------------------------------+
| "alg" 매개변수 값 | 키 관리 알고리즘 |
+-------------------+---------------------------------------------+
| A128GCMKW | 128비트 키를 사용하는 AES GCM 키 래핑 |
| A192GCMKW | 192비트 키를 사용하는 AES GCM 키 래핑 |
| A256GCMKW | 256비트 키를 사용하는 AES GCM 키 래핑 |
+-------------------+---------------------------------------------+
4.7.1. AES GCM 키 암호화에 사용되는 헤더 매개변수
다음 헤더 매개변수는 AES GCM 키 암호화에 사용합니다.
4.7.1.1. "iv"(초기화 벡터) 헤더 매개변수
"iv"(initialization vector) 헤더 매개변수 값은
키 암호화 연산에 사용되는 96비트 IV 값을
base64url로 인코딩한 표현입니다. 이러한 알고리즘을 사용할 때
이 헤더 매개변수는 반드시 존재해야 하며 구현은 이를
반드시 이해하고 처리해야 합니다.
4.7.1.2. "tag"(인증 태그) 헤더 매개변수
"tag"(authentication tag) 헤더 매개변수 값은
키 암호화 연산으로 생성된 128비트 Authentication Tag 값을
base64url로 인코딩한 표현입니다. 이러한 알고리즘을 사용할 때
이 헤더 매개변수는 반드시 존재해야 하며 구현은 이를
반드시 이해하고 처리해야 합니다.
Jones 표준 트랙 [페이지 19]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
4.8. PBES2를 사용한 키 암호화
이 절에서는 먼저 [RFC2898]의 섹션 6.2에 지정된
PBES2 방식을 사용하여 사용자가 제공한 비밀번호로부터 키 암호화 키를
파생한 다음, 파생된 키로 JWE CEK를 암호화함으로써
JWE CEK에 비밀번호 기반 암호화를 수행하는 구체적인 방법을 정의합니다.
이러한 알고리즘은 PBKDF2 키 파생의 의사난수 함수(PRF)로
HMAC SHA-2 알고리즘을 사용하며, 암호화 방식에는 AES Key Wrap
[RFC3394]을 사용합니다. PBES2 비밀번호 입력은
옥텟 시퀀스입니다. 사용할 비밀번호가 옥텟 시퀀스가 아니라
텍스트 문자열로 표현되는 경우 해당 텍스트 문자열의 UTF-8 인코딩을
옥텟 시퀀스로 반드시 사용해야 합니다. 솔트 매개변수는 아래의
"p2s" 정의에 지정된 대로 "p2s"(PBES2 salt input) 헤더 매개변수 값과
"alg"(알고리즘) 헤더 매개변수 값으로부터 반드시 계산해야 합니다.
반복 횟수 매개변수는 "p2c"(PBES2 count) 헤더 매개변수 값으로
반드시 제공해야 합니다. 각 알고리즘은 각각 HMAC SHA-256,
HMAC SHA-384 및 HMAC SHA-512를 PRF로 사용하고 128비트,
192비트 및 256비트 AES Key Wrap 키를 사용합니다.
파생 키 길이는 각각 16, 24 및 32옥텟입니다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWE Encrypted Key가 해당 비밀번호 기반 암호화
알고리즘의 결과를 해당 키 래핑 알고리즘용 키 암호화 키로
사용하여 CEK를 암호화한 결과임을 나타내는 데 사용합니다.
+--------------------+----------------------------------------------+
| "alg" 매개변수 값 | 키 관리 알고리즘 |
+--------------------+----------------------------------------------+
| PBES2-HS256+A128KW | HMAC SHA-256 및 "A128KW" 래핑을 사용하는 |
| | PBES2 |
| PBES2-HS384+A192KW | HMAC SHA-384 및 "A192KW" 래핑을 사용하는 |
| | PBES2 |
| PBES2-HS512+A256KW | HMAC SHA-512 및 "A256KW" 래핑을 사용하는 |
| | PBES2 |
+--------------------+----------------------------------------------+
"PBES2-HS256+A128KW"를 사용하는 키 암호화 계산의 예시는
JWK 명세 [JWK]의 부록 C를 참조하십시오.
4.8.1. PBES2 키 암호화에 사용되는 헤더 매개변수
다음 헤더 매개변수는 PBES2를 사용하는 키 암호화에
사용합니다.
Jones 표준 트랙 [페이지 20]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
4.8.1.1. "p2s"(PBES2 솔트 입력) 헤더 매개변수
"p2s"(PBES2 salt input) 헤더 매개변수는 PBKDF2 솔트 값의
일부로 사용되는 Salt Input 값을 인코딩합니다. "p2s"
값은 BASE64URL(Salt Input)입니다. 이러한 알고리즘을 사용할 때
이 헤더 매개변수는 반드시 존재해야 하며 구현은 이를
반드시 이해하고 처리해야 합니다.
솔트는 주어진 비밀번호로부터 파생할 수 있는 가능한 키의 범위를
확장합니다. 8옥텟 이상을 포함하는 Salt Input 값을 반드시
사용해야 합니다. 모든 암호화 연산마다 새로운 Salt Input 값을
무작위로 생성해야 합니다. 난수 값 생성에 관한 고려 사항은
RFC 4086 [RFC4086]을 참조하십시오. 사용되는 솔트 값은
(UTF8(Alg) || 0x00 || Salt Input)이며, 여기서 Alg는
"alg"(알고리즘) 헤더 매개변수 값입니다.
4.8.1.2. "p2c"(PBES2 횟수) 헤더 매개변수
"p2c"(PBES2 count) 헤더 매개변수는 PBKDF2
반복 횟수를 포함하며 양의 JSON 정수로 표현됩니다. 이러한
알고리즘을 사용할 때 이 헤더 매개변수는 반드시 존재해야 하며
구현은 이를 반드시 이해하고 처리해야 합니다.
반복 횟수는 계산 비용을 추가하며, 이상적으로는
솔트가 도입하는 가능한 키 범위와 결합되어 효과가 증대됩니다.
최소 반복 횟수로 1000을 사용하는 것이 권고됩니다.
5. 콘텐츠 암호화용 암호화 알고리즘
JWE는 평문을 암호화하고 무결성을 보호하며
Additional Authenticated Data의 무결성을
보호하기 위해 암호화 알고리즘을 사용합니다.
Jones 표준 트랙 [페이지 21]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
5.1. JWE용 "enc"(암호화 알고리즘) 헤더 매개변수 값
아래 표는 이 명세에서 JWE와 함께 사용하도록 정의한
"enc"(암호화 알고리즘) 헤더 매개변수 값의 집합입니다.
+---------------+----------------------------------+----------------+
| "enc" 매개변수 | 콘텐츠 암호화 알고리즘 | 구현 |
| 값 | | 요구 사항 |
+---------------+----------------------------------+----------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | 필수 |
| | 인증된 암호화 | |
| | 알고리즘, 섹션 | |
| | 5.2.3에 정의됨 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | 선택 사항 |
| | 인증된 암호화 | |
| | 알고리즘, 섹션 | |
| | 5.2.4에 정의됨 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | 필수 |
| | 인증된 암호화 | |
| | 알고리즘, 섹션 | |
| | 5.2.5에 정의됨 | |
| A128GCM | 128비트 키를 사용하는 AES GCM | 권고 |
| A192GCM | 192비트 키를 사용하는 AES GCM | 선택 사항 |
| A256GCM | 256비트 키를 사용하는 AES GCM | 권고 |
+---------------+----------------------------------+----------------+
모두 JWE Initialization Vector 값도 사용하고 JWE
Ciphertext 및 JWE Authentication Tag 값을 생성합니다.
이 명세에서 정의한 JWE "enc"(암호화 알고리즘) 값을
다른 표준 및 소프트웨어 패키지에서 사용하는 동등한 식별자와
상호 참조하는 표는 부록 A.3을 참조하십시오.
5.2. AES_CBC_HMAC_SHA2 알고리즘
이 절에서는 Cipher Block Chaining(CBC) 모드
[NIST.800-38A]의 AES [AES]와
[RFC5652]의 섹션 6.3에 따른 PKCS #7 패딩 연산 및
HMAC([RFC2104] 및 [SHS]) 연산을 조합하여 구성한
인증된 암호화 알고리즘 계열을 정의합니다. 이 알고리즘 계열을
AES_CBC_HMAC_SHA2라고 합니다. 또한 이 계열의 세 가지 인스턴스를
정의합니다. 첫 번째는 128비트 CBC 키와 HMAC SHA-256을,
두 번째는 192비트 CBC 키와 HMAC SHA-384를, 세 번째는
256비트 CBC 키와 HMAC SHA-512를 사용합니다. 이러한 알고리즘의
테스트 사례는 부록 B에서 확인할 수 있습니다.
Jones 표준 트랙 [페이지 22]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
이러한 알고리즘은 "Authenticated Encryption with AES-
CBC and HMAC-SHA" [AEAD-CBC-SHA]를 기반으로 하며 동일한 암호화
계산을 수행하지만, 출력 표현에서 Initialization Vector(IV) 및
Authentication Tag 값을 암호문 값과 연결하지 않고
별도로 유지합니다.
이 선택 사항은 해당 명세의 부록 B에서 논의합니다.
이 알고리즘 계열은 [AEAD-CBC-SHA]의 알고리즘 계열을 일반화한 것이며
해당 알고리즘을 구현하는 데 사용할 수 있습니다.
5.2.1. AES_CBC_HMAC_SHA2 정의에 사용되는 규칙
다음 표기 규칙을 사용합니다.
CBC-PKCS7-ENC(X, P)는 키 X를 사용하는 암호로 PKCS
#7 패딩을 적용하여 P를 AES-CBC 암호화하는 것을 나타냅니다.
MAC(Y, M)은 키 Y를 사용하여 메시지 M에 MAC을
적용하는 것을 나타냅니다.
5.2.2. 일반 AES_CBC_HMAC_SHA2 알고리즘
이 절에서는 사용할 AES-CBC 키 크기 또는 해시 함수와
독립적인 방식으로 AES_CBC_HMAC_SHA2를 정의합니다.
섹션 5.2.2.1 및 5.2.2.2에서는 일반 암호화 및
복호화 알고리즘을 정의합니다. 섹션 5.2.3부터 5.2.5까지는
이러한 세부 사항을 지정하는 AES_CBC_HMAC_SHA2 인스턴스를 정의합니다.
5.2.2.1. AES_CBC_HMAC_SHA2 암호화
인증된 암호화 알고리즘은 네 개의 옥텟 문자열을 입력으로
받습니다. 비밀 키 K, 평문 P, Additional Authenticated Data
A 및 Initialization Vector IV입니다. 인증된 암호문
값 E와 Authentication Tag 값 T가 출력으로 제공됩니다.
평문의 데이터는 암호화되고 인증되며,
Additional Authenticated Data는 인증되지만 암호화되지는 않습니다.
암호화 과정은 다음과 같거나 이와 동등한 단계 집합을
사용합니다.
1. 보조 키 MAC_KEY 및 ENC_KEY는 입력 키 K로부터
다음과 같이 생성합니다. 이 두 키는 각각 옥텟
문자열입니다.
MAC_KEY는 K의 처음 MAC_KEY_LEN개 옥텟으로
순서대로 구성됩니다.
ENC_KEY는 K의 마지막 ENC_KEY_LEN개 옥텟으로
순서대로 구성됩니다.
Jones 표준 트랙 [페이지 23]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
입력 키 K의 옥텟 수는 반드시
MAC_KEY_LEN과 ENC_KEY_LEN의 합이어야 합니다. 이러한 매개변수의 값은
섹션 5.2.3부터 5.2.5까지의 인증된 암호화 알고리즘에서
지정합니다. MAC 키가 입력 키 K에서 암호화 키보다
앞에 온다는 점에 유의하십시오. 이는 식별자
"AES_CBC_HMAC_SHA2"의 알고리즘 이름 순서와 반대입니다.
2. 사용되는 IV는 암호에서 사용하기 위해 무작위 또는
의사무작위로 생성한 128비트 값입니다.
3. ENC_KEY를 키로, IV를 사용하여 PKCS #7 패딩을 적용한
CBC 방식으로 평문을 암호화합니다. 이 단계의 암호문 출력을
E라고 나타냅니다.
4. 옥텟 문자열 AL은 Additional Authenticated Data A의
비트 수를 64비트 부호 없는 빅 엔디언 정수로
표현한 값과 같습니다.
5. 다음 데이터에 순서대로 HMAC [RFC2104]을 적용하여
메시지 Authentication Tag T를 계산합니다.
Additional Authenticated Data A,
Initialization Vector IV,
이전 단계에서 계산한 암호문 E, 그리고
위에서 정의한 옥텟 문자열 AL.
문자열 MAC_KEY를 MAC 키로 사용합니다. 이 단계에서 계산된
MAC 출력을 M이라고 나타냅니다. M의 처음 T_LEN개 옥텟을
T로 사용합니다.
6. 암호문 E와 Authentication Tag T를 인증된 암호화의
출력으로 반환합니다.
암호화 과정은 다음과 같이 나타낼 수 있습니다. 여기서 K, P, A,
IV 및 E는 각각 키, 평문, Additional Authenticated Data,
Initialization Vector 및 암호문을 나타냅니다.
MAC_KEY = K의 처음 MAC_KEY_LEN개 옥텟,
ENC_KEY = K의 마지막 ENC_KEY_LEN개 옥텟,
E = CBC-PKCS7-ENC(ENC_KEY, P),
M = MAC(MAC_KEY, A || IV || E || AL),
T = M의 처음 T_LEN개 옥텟.
Jones 표준 트랙 [페이지 24]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
5.2.2.2. AES_CBC_HMAC_SHA2 복호화
인증된 복호화 연산에는 위에서 정의한 K, A, IV, E 및 T의
다섯 가지 입력이 있습니다. 출력은 하나뿐이며, 평문 값 P 또는
입력이 인증되지 않았음을 나타내는 특수 기호 FAIL입니다.
인증된 복호화 알고리즘은 다음과 같거나 이와 동등한
단계 집합을 사용합니다.
1. 보조 키 MAC_KEY와 ENC_KEY를 섹션 5.2.2.1의
1단계와 동일하게 입력 키 K로부터 생성합니다.
2. A와 E의 무결성과 진위를
섹션 5.2.2.1의 5단계와 동일한 입력으로 HMAC을 계산하여
확인합니다. 이전 단계의 값 T를
HMAC 출력의 처음 MAC_KEY 길이 비트와 비교합니다.
이 값들이 동일하면 A와 E가 유효한 것으로 간주하고
처리를 계속합니다. 그렇지 않으면 MAC 검증에 사용한 모든
데이터를 폐기하고 인증된 복호화 연산은
실패했음을 나타내는 값을 반환한 뒤 연산을 중단합니다.
(단, 타이밍 공격 방지와 관련된 보안 고려 사항은 [JWE]의
섹션 11.5를 참조하십시오.)
3. 값 E를 복호화하고 PKCS #7 패딩을 검사한 후
제거합니다. 값 IV를 Initialization Vector로 사용합니다.
값 ENC_KEY를 복호화 키로 사용합니다.
4. 평문 값을 반환합니다.
5.2.3. AES_128_CBC_HMAC_SHA_256
이 알고리즘은 위의 일반
AES_CBC_HMAC_SHA2 알고리즘을 구체화한 인스턴스입니다.
메시지 인증을 제공하기 위해 SHA-256 해시 함수 [SHS]와 함께
HMAC 메시지 인증 코드 [RFC2104]를 사용하며,
HMAC 출력은 [RFC4868]에 정의된 HMAC-SHA-256-128 알고리즘에 대응하도록
128비트로 잘라냅니다. 암호화에는
[NIST.800-38A]의 섹션 6.2에 정의된 CBC 동작 모드의 AES를
PKCS #7 패딩 및 128비트 IV 값과 함께 사용합니다.
AES_128_CBC_HMAC_SHA_256에 특화된 AES_CBC_HMAC_SHA2
매개변수는 다음과 같습니다.
입력 키 K의 길이는 32옥텟입니다.
ENC_KEY_LEN은 16옥텟입니다.
MAC_KEY_LEN은 16옥텟입니다.
HMAC에는 SHA-256 해시 알고리즘을 사용합니다.
HMAC-SHA-256 출력은 마지막 16옥텟을 제거하여
T_LEN=16옥텟으로 잘라냅니다.
Jones 표준 트랙 [페이지 25]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
5.2.4. AES_192_CBC_HMAC_SHA_384
AES_192_CBC_HMAC_SHA_384는 AES_128_CBC_HMAC_SHA_256을 기반으로 하지만
다음과 같은 차이가 있습니다.
입력 키 K의 길이는 32옥텟 대신 48옥텟입니다.
ENC_KEY_LEN은 16옥텟 대신 24옥텟입니다.
MAC_KEY_LEN은 16옥텟 대신 24옥텟입니다.
HMAC에는 SHA-256 대신 SHA-384를 사용합니다.
HMAC SHA-384 값은 16옥텟 대신 T_LEN=24옥텟으로
잘라냅니다.
5.2.5. AES_256_CBC_HMAC_SHA_512
AES_256_CBC_HMAC_SHA_512는 AES_128_CBC_HMAC_SHA_256을 기반으로 하지만
다음과 같은 차이가 있습니다.
입력 키 K의 길이는 32옥텟 대신 64옥텟입니다.
ENC_KEY_LEN은 16옥텟 대신 32옥텟입니다.
MAC_KEY_LEN은 16옥텟 대신 32옥텟입니다.
HMAC에는 SHA-256 대신 SHA-512를 사용합니다.
HMAC SHA-512 값은 16옥텟 대신 T_LEN=32옥텟으로
잘라냅니다.
5.2.6. AES_CBC_HMAC_SHA2를 사용한 콘텐츠 암호화
이 절에서는 AES_CBC_HMAC_SHA2 알고리즘을 사용하여
인증된 암호화를 수행하는 구체적인 방법을 정의합니다.
CEK를 비밀 키 K로 사용합니다.
다음 "enc"(암호화 알고리즘) 헤더 매개변수 값은
JWE Ciphertext 및 JWE Authentication Tag 값이 해당 알고리즘을
사용하여 계산되었음을 나타내는 데 사용합니다.
+---------------+---------------------------------------------------+
| "enc" 매개변수 | 콘텐츠 암호화 알고리즘 |
| 값 | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 인증된 암호화 알고리즘 |
| | 섹션 5.2.3에 정의됨 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 인증된 암호화 알고리즘 |
| | 섹션 5.2.4에 정의됨 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 인증된 암호화 알고리즘 |
| | 섹션 5.2.5에 정의됨 |
+---------------+---------------------------------------------------+
Jones 표준 트랙 [페이지 26]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
5.3. AES GCM을 사용한 콘텐츠 암호화
이 절에서는 Galois/Counter Mode(GCM)의 AES
([AES] 및 [NIST.800-38D])를 사용하여 인증된
암호화를 수행하는 구체적인 방법을 정의합니다.
CEK를 암호화 키로 사용합니다.
이 알고리즘에는 96비트 크기의 IV를 반드시 사용해야 합니다.
요청되는 Authentication Tag 출력 크기는 키 크기와 관계없이
반드시 128비트여야 합니다.
다음 "enc"(암호화 알고리즘) 헤더 매개변수 값은
JWE Ciphertext 및 JWE Authentication Tag 값이
해당 알고리즘 및 키 크기를 사용하여 계산되었음을
나타내는 데 사용합니다.
+-------------------+------------------------------+
| "enc" 매개변수 값 | 콘텐츠 암호화 알고리즘 |
+-------------------+------------------------------+
| A128GCM | 128비트 키를 사용하는 AES GCM |
| A192GCM | 192비트 키를 사용하는 AES GCM |
| A256GCM | 256비트 키를 사용하는 AES GCM |
+-------------------+------------------------------+
이 알고리즘을 사용하는 예시는 [JWE]의 부록 A.1에 나와 있습니다.
6. 키용 암호화 알고리즘
JSON Web Key(JWK) [JWK]는 암호화 키를 나타내는 JSON
데이터 구조입니다. 이러한 키는 비대칭 또는 대칭일 수 있습니다.
키에 대한 공개 정보와 개인 정보를 모두 포함할 수 있습니다.
이 절에서는 이 문서에서 지정한 알고리즘을 사용하는
키의 매개변수를 정의합니다.
Jones 표준 트랙 [페이지 27]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
6.1. "kty"(키 유형) 매개변수 값
아래 표는 이 명세에서 JWK에 사용하도록 정의한
"kty"(키 유형) 매개변수 값의 집합입니다.
+-------------+--------------------------------+--------------------+
| "kty" 매개변수 | 키 유형 | 구현 |
| 값 | | 요구 사항 |
+-------------+--------------------------------+--------------------+
| EC | 타원 곡선 [DSS] | 권고+ |
| RSA | RSA [RFC3447] | 필수 |
| oct | 옥텟 시퀀스(대칭 키를 | 필수 |
| | 나타내는 데 사용) | |
+-------------+--------------------------------+--------------------+
구현 요구 사항 열에서 "+"를 사용하는 것은
향후 명세 버전에서 요구 수준이 높아질 가능성이
있음을 나타냅니다.
6.2. 타원 곡선 키의 매개변수
JWK는 타원 곡선 [DSS] 키를 나타낼 수 있습니다. 이 경우
"kty" 멤버 값은 "EC"입니다.
6.2.1. 타원 곡선 공개 키의 매개변수
타원 곡선 공개 키는 유한체에서 가져온 한 쌍의 좌표로
표현되며, 두 좌표가 함께 타원 곡선 위의 한 점을 정의합니다.
모든 타원 곡선 공개 키에는 다음 멤버가 반드시
존재해야 합니다.
o "crv"
o "x"
다음 절에서 정의하는 세 곡선의 타원 곡선 공개 키에는
다음 멤버도 반드시 존재해야 합니다.
o "y"
6.2.1.1. "crv"(곡선) 매개변수
"crv"(곡선) 매개변수는 키에 사용되는 암호화 곡선을
식별합니다. 이 명세에서 사용하는 [DSS]의 곡선 값은
다음과 같습니다.
o "P-256"
o "P-384"
o "P-521"
Jones 표준 트랙 [페이지 28]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
이러한 값은 섹션 7.6에서 정의한 IANA "JSON Web Key Elliptic Curve"
레지스트리에 등록됩니다. 추가적인 "crv" 값은 다른 명세에서
등록할 수 있습니다. 추가 곡선을 등록하는 명세는
등록된 곡선의 키를 표현하는 데 어떤 매개변수를 사용하는지
정의해야 합니다. "crv" 값은 대소문자를 구분하는 문자열입니다.
SEC1 [SEC1] 점 압축은 이 세 곡선 중 어느 것에서도
지원되지 않습니다.
6.2.1.2. "x"(X 좌표) 매개변수
"x"(x 좌표) 매개변수는 타원 곡선 점의 x 좌표를
포함합니다. SEC1 [SEC1]의 섹션 2.3.5에 정의된
좌표의 옥텟 문자열 표현을 base64url로 인코딩하여
표현합니다. 이 옥텟 문자열의 길이는 "crv" 매개변수에
지정된 곡선의 좌표 전체 크기와 반드시 같아야 합니다.
예를 들어 "crv" 값이 "P-521"이면 옥텟
문자열 길이는 66옥텟이어야 합니다.
6.2.1.3. "y"(Y 좌표) 매개변수
"y"(y 좌표) 매개변수는 타원 곡선 점의 y 좌표를
포함합니다. SEC1 [SEC1]의 섹션 2.3.5에 정의된
좌표의 옥텟 문자열 표현을 base64url로 인코딩하여
표현합니다. 이 옥텟 문자열의 길이는 "crv" 매개변수에
지정된 곡선의 좌표 전체 크기와 반드시 같아야 합니다.
예를 들어 "crv" 값이 "P-521"이면 옥텟
문자열 길이는 66옥텟이어야 합니다.
6.2.2. 타원 곡선 개인 키의 매개변수
타원 곡선 공개 키를 나타내는 데 사용되는 멤버 외에도
타원 곡선 개인 키를 나타내려면 다음 멤버가
반드시 존재해야 합니다.
6.2.2.1. "d"(ECC 개인 키) 매개변수
"d"(ECC 개인 키) 매개변수는 타원 곡선
개인 키 값을 포함합니다. SEC1 [SEC1]의 섹션 2.3.7에 정의된
개인 키 값의 옥텟 문자열 표현을 base64url로 인코딩하여
표현합니다. 이 옥텟 문자열의 길이는 반드시
ceiling(log-base-2(n)/8) 옥텟이어야 합니다(여기서 n은
곡선의 차수입니다).
Jones 표준 트랙 [페이지 29]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
6.3. RSA 키의 매개변수
JWK는 RSA [RFC3447] 키를 나타낼 수 있습니다. 이 경우 "kty"
멤버 값은 "RSA"입니다. 아래에 정의된 매개변수의 의미는
RFC 3447의 섹션 3.1 및 3.2에 정의된 것과 동일합니다.
6.3.1. RSA 공개 키의 매개변수
RSA 공개 키에는 다음 멤버가 반드시 존재해야 합니다.
6.3.1.1. "n"(모듈러스) 매개변수
"n"(모듈러스) 매개변수는 RSA 공개 키의 모듈러스 값을
포함합니다. Base64urlUInt로 인코딩된 값으로 표현합니다.
구현자들은 일부 암호화 라이브러리가 반환하는 모듈러스 표현 앞에
값이 0인 추가 옥텟을 붙인다는 사실을 발견했습니다.
예를 들어 2048비트 키에 대해 256옥텟이 아니라
257옥텟을 반환할 수 있습니다. 이러한 라이브러리를 사용하는 구현은
base64url로 인코딩된 표현에서 추가 옥텟을
생략하도록 주의해야 합니다.
6.3.1.2. "e"(지수) 매개변수
"e"(지수) 매개변수는 RSA 공개 키의 지수 값을
포함합니다. Base64urlUInt로 인코딩된 값으로 표현합니다.
예를 들어 값 65537을 나타낼 때 base64url로 인코딩할
옥텟 시퀀스는 반드시 세 옥텟 [1, 0, 1]로 구성되어야 하며,
이 값의 결과 표현은 "AQAB"입니다.
6.3.2. RSA 개인 키의 매개변수
RSA 공개 키를 나타내는 데 사용되는 멤버 외에
다음 멤버는 RSA 개인 키를 나타내는 데 사용합니다.
매개변수 "d"는 RSA 개인 키에 필수입니다. 다른 매개변수는
최적화를 가능하게 하므로 RSA 개인 키를 나타내는 JWK의
생성자가 포함하는 것이 좋습니다. 생성자가 다른 개인 키
매개변수 중 하나라도 포함하면 "oth"를 제외한 나머지 모든
매개변수도 반드시 존재해야 합니다. "oth"는 두 개를 초과하는
소인수를 사용한 경우에만 반드시 존재해야 합니다.
6.3.2.1. "d"(개인 지수) 매개변수
"d"(개인 지수) 매개변수는 RSA 개인 키의 개인 지수
값을 포함합니다. Base64urlUInt로
인코딩된 값으로 표현합니다.
Jones 표준 트랙 [페이지 30]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
6.3.2.2. "p"(첫 번째 소인수) 매개변수
"p"(첫 번째 소인수) 매개변수는 첫 번째 소인수를
포함합니다. Base64urlUInt로 인코딩된 값으로 표현합니다.
6.3.2.3. "q"(두 번째 소인수) 매개변수
"q"(두 번째 소인수) 매개변수는 두 번째 소인수를
포함합니다. Base64urlUInt로 인코딩된 값으로 표현합니다.
6.3.2.4. "dp"(첫 번째 인수 CRT 지수) 매개변수
"dp"(첫 번째 인수 CRT 지수) 매개변수는 첫 번째 인수의
중국인의 나머지 정리(CRT) 지수를 포함합니다.
Base64urlUInt로 인코딩된 값으로 표현합니다.
6.3.2.5. "dq"(두 번째 인수 CRT 지수) 매개변수
"dq"(두 번째 인수 CRT 지수) 매개변수는 두 번째 인수의
CRT 지수를 포함합니다. Base64urlUInt로
인코딩된 값으로 표현합니다.
6.3.2.6. "qi"(첫 번째 CRT 계수) 매개변수
"qi"(첫 번째 CRT 계수) 매개변수는 두 번째 인수의 CRT
계수를 포함합니다. Base64urlUInt로
인코딩된 값으로 표현합니다.
6.3.2.7. "oth"(기타 소수 정보) 매개변수
"oth"(기타 소수 정보) 매개변수는 존재할 경우
세 번째 이후 소수에 관한 정보의 배열을 포함합니다.
두 개의 소수만 사용한 경우(일반적인 경우) 이 매개변수는
반드시 생략해야 합니다. 세 개 이상의 소수를 사용한 경우
배열 요소 수는 반드시 사용한 소수 수에서 2를 뺀 값이어야 합니다.
이 경우에 대한 자세한 내용은 다음 매개변수의 기반이 되는
RFC 3447의 부록 A.1.2 [RFC3447]의
OtherPrimeInfo 매개변수 설명을 참조하십시오. JWK의 소비자가
두 개를 초과하는 소수를 사용하는 개인 키를 지원하지 않는데
"oth" 매개변수를 포함한 개인 키를 만나면 해당 키를
사용해서는 안 됩니다. 각 배열 요소는 다음 멤버를 포함하는
객체여야 합니다.
6.3.2.7.1. "r"(소인수)
"oth" 배열 멤버 내의 "r"(소인수) 매개변수는
후속 소인수의 값을 나타냅니다.
Base64urlUInt로 인코딩된 값으로 표현합니다.
Jones 표준 트랙 [페이지 31]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
6.3.2.7.2. "d"(인수 CRT 지수)
"oth" 배열 멤버 내의 "d"(인수 CRT 지수) 매개변수는
해당 소인수의 CRT 지수를 나타냅니다.
Base64urlUInt로 인코딩된 값으로 표현합니다.
6.3.2.7.3. "t"(인수 CRT 계수)
"oth" 배열 멤버 내의 "t"(인수 CRT 계수) 매개변수는
해당 소인수의 CRT 계수를 나타냅니다.
Base64urlUInt로 인코딩된 값으로 표현합니다.
6.4. 대칭 키의 매개변수
JWK "kty" 멤버 값이 "oct"(옥텟 시퀀스)인 경우
멤버 "k"(섹션 6.4.1 참조)를 사용하여 대칭 키
(또는 값이 단일 옥텟 시퀀스인 다른 키)를 나타냅니다.
애플리케이션이 사용할 알고리즘을 결정하기 위한 다른 수단이나
규칙을 사용하지 않는 한, 키와 함께 사용하도록 의도된 알고리즘을
식별하기 위해 "alg" 멤버도 존재하는 것이 좋습니다.
6.4.1. "k"(키 값) 매개변수
"k"(키 값) 매개변수는 대칭 키(또는
다른 단일 값 키)의 값을 포함합니다. 키 값을 포함하는
옥텟 시퀀스를 base64url로 인코딩한 값으로 표현합니다.
7. IANA 고려 사항
이 명세에서 설정하는 모든 레지스트리에는 다음 등록
절차를 사용합니다.
값의 등록 절차는 하나 이상의 지정 전문가의 자문에 따라
jose-reg-review@ietf.org 메일링 리스트에서 3주간 검토한 후
Specification Required [RFC5226]를 따릅니다.
다만 게시 전에 값을 할당할 수 있도록,
지정 전문가는 그러한 명세가 게시될 것이라고 판단하면
등록을 승인할 수 있습니다.
검토를 위해 메일링 리스트에 보내는 등록 요청에는
적절한 제목(예: "알고리즘 등록 요청:
example")을 사용해야 합니다.
검토 기간 동안 지정 전문가는 등록 요청을 승인하거나
거부하고 그 결정을 검토 목록과 IANA에 전달합니다.
거부할 경우 설명과, 해당되는 경우 요청을 성공시키기 위한
제안을 포함해야 합니다.
Jones 표준 트랙 [페이지 32]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
21일이 넘도록 결정되지 않은 등록 요청은 해결을 위해
IESG의 주의를 끌 수 있습니다
(iesg@ietf.org 메일링 리스트 사용).
지정 전문가가 적용해야 하는 기준에는 제안된 등록이
기존 기능을 중복하는지, 일반적인 용도로 사용될 가능성이 있는지
또는 단일 애플리케이션에서만 유용한지, 등록 설명이 명확한지를
판단하는 것이 포함됩니다.
IANA는 지정 전문가로부터의 레지스트리 업데이트만 받아들여야 하며
모든 등록 요청을 검토 메일링 리스트로 보내도록
안내하는 것이 좋습니다.
이 명세를 사용하는 서로 다른 애플리케이션의 관점을
대표할 수 있는 여러 지정 전문가를 임명하여
등록 결정에 대해 폭넓은 정보를 바탕으로 검토할 수 있도록
하는 것이 좋습니다. 등록 결정이 특정 전문가에게
이해 충돌을 일으키는 것으로 인식될 수 있는 경우,
해당 전문가는 다른 전문가의 판단에
맡기는 것이 좋습니다.
7.1. JSON 웹 서명 및 암호화 알고리즘 레지스트리
이 명세는 JWS 및 JWE의 "alg"(알고리즘) 및 "enc"(암호화 알고리즘)
헤더 매개변수 값을 위한 IANA "JSON Web Signature and
Encryption Algorithms" 레지스트리를 설정합니다.
이 레지스트리는 알고리즘 이름, 알고리즘 설명,
알고리즘 사용 위치, 구현 요구 사항,
변경 제어자 및 해당 알고리즘을 정의하는 명세에 대한 참조를
기록합니다. 사용 위치 집합이 서로 겹치지 않는 경우
동일한 알고리즘 이름을 여러 번 등록할 수 있습니다.
서로 다른 길이의 키를 사용하는 알고리즘의 여러 변형을
등록하고 각 키 길이를 고정해야 하는 경우
(예: 키 파생 함수로 생성되기 때문에)
알고리즘 이름에 키 길이를 포함하는 것이 좋습니다.
이렇게 하면 JSON 텍스트를 읽는 사람이 보안 결정을
더 쉽게 내릴 수 있습니다.
지정 전문가는 등록하려는 알고리즘이 현재
암호학적으로 신뢰할 수 있다고 간주되거나
Deprecated 또는 Prohibited로 등록되는지를 합리적으로
충분히 검토하는 것이 좋습니다.
Jones 표준 트랙 [페이지 33]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
암호화 환경이 발전함에 따라 알고리즘의 구현 요구 사항은 시간이
지나면서 변경될 수 있습니다. 예를 들어 알고리즘의 상태를
사용 중단으로 변경하거나 선택 사항에서 권고+ 또는 필수로
변경할 수 있습니다. 구현 요구 사항의 변경은 지정 전문가의
검토를 거친 후 Specification Required 절차에 따라서만 허용되며,
새로운 명세에서 수정된 구현 요구 사항 수준을 정의해야 합니다.
7.1.1. 등록 템플릿
알고리즘 이름:
요청된 이름(예: "HS256")입니다. 이 이름은 대소문자를 구분하는
ASCII 문자열입니다. 지정 전문가가 예외를 허용할 충분한
이유가 있다고 명시하지 않는 한, 대소문자를 구분하지 않고
비교했을 때 다른 등록된 이름과 일치해서는 안 됩니다.
알고리즘 설명:
알고리즘에 대한 간략한 설명입니다(예: "SHA-256을 사용하는 HMAC").
알고리즘 사용 위치:
알고리즘의 사용 위치입니다. 알고리즘을 JWS 또는 JWE와 함께
사용하는 경우 "alg" 또는 "enc" 값 중 하나 이상이어야 합니다.
알고리즘 식별자가 JWK "alg" 멤버 값으로 사용되지만 JWS 또는
JWE와 함께 사용되지 않는 경우 "JWK" 값을 사용합니다. 예를 들어
인증되지 않은 암호화 알고리즘이 이에 해당할 수 있습니다.
지정 전문가의 승인을 받아 다른 값을 사용할 수도 있습니다.
JOSE 구현 요구 사항:
JWS 및 JWE의 알고리즘 구현 요구 사항이며,
필수, 권고, 선택 사항, 사용 중단 또는 금지 중 하나여야 합니다.
선택적으로 단어 뒤에 "+" 또는 "-"를 붙일 수 있습니다.
"+"는 향후 명세 버전에서 요구 수준이 높아질 가능성이
있음을 나타냅니다. "-"는 향후 명세 버전에서 요구 수준이
낮아질 가능성이 있음을 나타냅니다. 인증되지 않은 암호화
알고리즘이나 JWS 또는 JWE 알고리즘으로 직접 사용하기에
부적합한 다른 알고리즘에 등록되는 모든 식별자는
"금지"로 등록해야 합니다.
변경 제어자:
표준 트랙 RFC의 경우 "IESG"를 기재합니다. 그 외의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부 정보(예: 우편
주소, 이메일 주소, 홈페이지 URI)도 포함할 수 있습니다.
Jones 표준 트랙 [페이지 34]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
명세 문서:
매개변수를 지정하는 문서에 대한 참조이며,
가능하면 문서 사본을 가져오는 데 사용할 수 있는 URI도
포함합니다. 관련 절에 대한 표시를 포함할 수도 있지만
필수는 아닙니다.
알고리즘 분석 문서:
등록하려는 알고리즘의 암호학적 건전성을 분석한
저명한 암호학 학회, 국가 표준 기관 또는 기타 권위 있는
출처의 출판물에 대한 참조입니다. 알고리즘이 사용 중단 또는
금지로 등록되는 경우가 아니라면, 지정 전문가는 새로운
알고리즘의 암호학적 건전성에 대한 설득력 있는 증거를
등록 요청과 함께 제공하도록 요구할 수 있습니다.
이 문서에서 이루어진 초기 등록은 워킹 그룹 및 IETF 검토를
거쳤으므로 이 정보를 제공할 필요가 없습니다.
7.1.2. 초기 레지스트리 내용
o 알고리즘 이름: "HS256"
o 알고리즘 설명: SHA-256을 사용하는 HMAC
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 필수
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.2
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "HS384"
o 알고리즘 설명: SHA-384를 사용하는 HMAC
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.2
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "HS512"
o 알고리즘 설명: SHA-512를 사용하는 HMAC
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.2
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 35]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "RS256"
o 알고리즘 설명: SHA-256을 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "RS384"
o 알고리즘 설명: SHA-384를 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "RS512"
o 알고리즘 설명: SHA-512를 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ES256"
o 알고리즘 설명: P-256 및 SHA-256을 사용하는 ECDSA
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고+
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ES384"
o 알고리즘 설명: P-384 및 SHA-384를 사용하는 ECDSA
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ES512"
o 알고리즘 설명: P-521 및 SHA-512를 사용하는 ECDSA
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.4
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 36]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "PS256"
o 알고리즘 설명: SHA-256 및 SHA-256을 사용하는 MGF1을 사용한
RSASSA-PSS
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.5
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "PS384"
o 알고리즘 설명: SHA-384 및 SHA-384를 사용하는 MGF1을 사용한
RSASSA-PSS
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.5
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "PS512"
o 알고리즘 설명: SHA-512 및 SHA-512를 사용하는 MGF1을 사용한
RSASSA-PSS
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.5
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "none"
o 알고리즘 설명: 디지털 서명 또는 MAC을 수행하지 않음
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 3.6
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "RSA1_5"
o 알고리즘 설명: RSAES-PKCS1-v1_5
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고-
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.2
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 37]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "RSA-OAEP"
o 알고리즘 설명: 기본 매개변수를 사용하는 RSAES OAEP
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고+
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "RSA-OAEP-256"
o 알고리즘 설명: SHA-256 및 SHA-256을 사용하는 MGF1을 사용한
RSAES OAEP
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A128KW"
o 알고리즘 설명: 128비트 키를 사용하는 AES Key Wrap
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A192KW"
o 알고리즘 설명: 192비트 키를 사용하는 AES Key Wrap
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A256KW"
o 알고리즘 설명: 256비트 키를 사용하는 AES Key Wrap
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "dir"
o 알고리즘 설명: 공유 대칭 키 직접 사용
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.5
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 38]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "ECDH-ES"
o 알고리즘 설명: Concat KDF를 사용하는 ECDH-ES
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고+
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ECDH-ES+A128KW"
o 알고리즘 설명: Concat KDF 및 "A128KW"
래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ECDH-ES+A192KW"
o 알고리즘 설명: Concat KDF 및 "A192KW"
래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "ECDH-ES+A256KW"
o 알고리즘 설명: Concat KDF 및 "A256KW"
래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A128GCMKW"
o 알고리즘 설명: 128비트 키를 사용하는 AES GCM 키 래핑
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.7
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 39]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "A192GCMKW"
o 알고리즘 설명: 192비트 키를 사용하는 AES GCM 키 래핑
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.7
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A256GCMKW"
o 알고리즘 설명: 256비트 키를 사용하는 AES GCM 키 래핑
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.7
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "PBES2-HS256+A128KW"
o 알고리즘 설명: HMAC SHA-256 및 "A128KW"
래핑을 사용하는 PBES2
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.8
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "PBES2-HS384+A192KW"
o 알고리즘 설명: HMAC SHA-384 및 "A192KW"
래핑을 사용하는 PBES2
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.8
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "PBES2-HS512+A256KW"
o 알고리즘 설명: HMAC SHA-512 및 "A256KW"
래핑을 사용하는 PBES2
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.8
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 40]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "A128CBC-HS256"
o 알고리즘 설명: AES_128_CBC_HMAC_SHA_256 인증된
암호화 알고리즘
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 필수
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.2.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A192CBC-HS384"
o 알고리즘 설명: AES_192_CBC_HMAC_SHA_384 인증된
암호화 알고리즘
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.2.4
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A256CBC-HS512"
o 알고리즘 설명: AES_256_CBC_HMAC_SHA_512 인증된
암호화 알고리즘
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 필수
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.2.5
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A128GCM"
o 알고리즘 설명: 128비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.3
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "A192GCM"
o 알고리즘 설명: 192비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.3
o 알고리즘 분석 문서: 해당 없음
Jones 표준 트랙 [페이지 41]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 알고리즘 이름: "A256GCM"
o 알고리즘 설명: 256비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구 사항: 권고
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 5.3
o 알고리즘 분석 문서: 해당 없음
7.2. 헤더 매개변수 이름 등록
이 절에서는 이 명세의 섹션 4.6.1, 4.7.1 및 4.8.1에 정의된
헤더 매개변수 이름을 [JWS]에서 설정한 IANA "JSON Web
Signature and Encryption Header Parameters" 레지스트리에 등록합니다.
7.2.1. 레지스트리 내용
o 헤더 매개변수 이름: "epk"
o 헤더 매개변수 설명: 임시 공개 키
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6.1.1
o 헤더 매개변수 이름: "apu"
o 헤더 매개변수 설명: Agreement PartyUInfo
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6.1.2
o 헤더 매개변수 이름: "apv"
o 헤더 매개변수 설명: Agreement PartyVInfo
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.6.1.3
o 헤더 매개변수 이름: "iv"
o 헤더 매개변수 설명: 초기화 벡터
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.7.1.1
o 헤더 매개변수 이름: "tag"
o 헤더 매개변수 설명: 인증 태그
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.7.1.2
Jones 표준 트랙 [페이지 42]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 헤더 매개변수 이름: "p2s"
o 헤더 매개변수 설명: PBES2 솔트 입력
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.8.1.1
o 헤더 매개변수 이름: "p2c"
o 헤더 매개변수 설명: PBES2 횟수
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 4.8.1.2
7.3. JSON 웹 암호화 압축 알고리즘 레지스트리
이 명세는 JWE "zip" 멤버 값을 위한 IANA "JSON Web Encryption
Compression Algorithms" 레지스트리를 설정합니다. 이 레지스트리는
압축 알고리즘 값과 이를 정의하는 명세에 대한 참조를 기록합니다.
7.3.1. 등록 템플릿
압축 알고리즘 값:
요청된 이름(예: "DEF")입니다. 이 명세의 핵심 목표는
결과 표현을 간결하게 만드는 것이므로, 충분한 이유가
없는 한 이름은 8자를 넘지 않도록 짧게 하는 것이 권고됩니다.
이 이름은 대소문자를 구분합니다. 지정 전문가가 예외를
허용할 충분한 이유가 있다고 명시하지 않는 한, 대소문자를
구분하지 않고 비교했을 때 다른 등록된 이름과 일치해서는 안 됩니다.
압축 알고리즘 설명:
압축 알고리즘에 대한 간략한 설명입니다(예: "DEFLATE").
변경 제어자:
표준 트랙 RFC의 경우 "IESG"를 기재합니다. 그 외의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부 정보(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함할 수 있습니다.
명세 문서:
매개변수를 지정하는 문서에 대한 참조이며,
가능하면 문서 사본을 가져오는 데 사용할 수 있는 URI도
포함합니다. 관련 절에 대한 표시를 포함할 수도 있지만
필수는 아닙니다.
Jones 표준 트랙 [페이지 43]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
7.3.2. 초기 레지스트리 내용
o 압축 알고리즘 값: "DEF"
o 압축 알고리즘 설명: DEFLATE
o 변경 제어자: IESG
o 명세 문서: JSON 웹 암호화(JWE) [JWE]
7.4. JSON 웹 키 유형 레지스트리
이 명세는 JWK "kty"(키 유형) 매개변수 값을 위한
IANA "JSON Web Key Types" 레지스트리를 설정합니다. 이 레지스트리는
"kty" 값, 구현 요구 사항 및 이를 정의하는 명세에 대한 참조를
기록합니다.
암호화 환경이 발전함에 따라 키 유형의 구현 요구 사항은 시간이
지나면서 변경될 수 있습니다. 예를 들어 키 유형의 상태를
사용 중단으로 변경하거나 선택 사항에서 권고+ 또는 필수로
변경할 수 있습니다. 구현 요구 사항의 변경은 지정 전문가의
검토를 거친 후 Specification Required 절차에 따라서만 허용되며,
새로운 명세에서 수정된 구현 요구 사항 수준을 정의해야 합니다.
7.4.1. 등록 템플릿
"kty" 매개변수 값:
요청된 이름(예: "EC")입니다. 이 명세의 핵심 목표는
결과 표현을 간결하게 만드는 것이므로, 충분한 이유가
없는 한 이름은 8자를 넘지 않도록 짧게 하는 것이 권고됩니다.
이 이름은 대소문자를 구분합니다. 지정 전문가가 예외를
허용할 충분한 이유가 있다고 명시하지 않는 한, 대소문자를
구분하지 않고 비교했을 때 다른 등록된 이름과 일치해서는 안 됩니다.
키 유형 설명:
키 유형에 대한 간략한 설명입니다(예: "타원 곡선").
변경 제어자:
표준 트랙 RFC의 경우 "IESG"를 기재합니다. 그 외의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부 정보(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함할 수 있습니다.
Jones 표준 트랙 [페이지 44]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
JOSE 구현 요구 사항:
JWS 및 JWE의 키 유형 구현 요구 사항이며,
필수, 권고, 선택 사항, 사용 중단 또는 금지 중 하나여야 합니다.
선택적으로 단어 뒤에 "+" 또는 "-"를 붙일 수 있습니다.
"+"는 향후 명세 버전에서 요구 수준이 높아질 가능성이
있음을 나타냅니다. "-"는 향후 명세 버전에서 요구 수준이
낮아질 가능성이 있음을 나타냅니다.
명세 문서:
매개변수를 지정하는 문서에 대한 참조이며,
가능하면 문서 사본을 가져오는 데 사용할 수 있는 URI도
포함합니다. 관련 절에 대한 표시를 포함할 수도 있지만
필수는 아닙니다.
7.4.2. 초기 레지스트리 내용
이 절에서는 섹션 6.1에 정의된 값을 등록합니다.
o "kty" 매개변수 값: "EC"
o 키 유형 설명: 타원 곡선
o JOSE 구현 요구 사항: 권고+
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2
o "kty" 매개변수 값: "RSA"
o 키 유형 설명: RSA
o JOSE 구현 요구 사항: 필수
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3
o "kty" 매개변수 값: "oct"
o 키 유형 설명: 옥텟 시퀀스
o JOSE 구현 요구 사항: 필수
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.4
7.5. JSON 웹 키 매개변수 등록
이 절에서는 이 명세의 섹션 6.2,
6.3 및 6.4에 정의된 매개변수 이름을 [JWK]에서 설정한
IANA "JSON Web Key Parameters" 레지스트리에 등록합니다.
Jones 표준 트랙 [페이지 45]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
7.5.1. 레지스트리 내용
o 매개변수 이름: "crv"
o 매개변수 설명: 곡선
o 함께 사용되는 "kty" 값: "EC"
o 매개변수 정보 클래스: 공개
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.1
o 매개변수 이름: "x"
o 매개변수 설명: X 좌표
o 함께 사용되는 "kty" 값: "EC"
o 매개변수 정보 클래스: 공개
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.2
o 매개변수 이름: "y"
o 매개변수 설명: Y 좌표
o 함께 사용되는 "kty" 값: "EC"
o 매개변수 정보 클래스: 공개
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.3
o 매개변수 이름: "d"
o 매개변수 설명: ECC 개인 키
o 함께 사용되는 "kty" 값: "EC"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.2.1
o 매개변수 이름: "n"
o 매개변수 설명: 모듈러스
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 공개
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.1.1
o 매개변수 이름: "e"
o 매개변수 설명: 지수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 공개
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.1.2
Jones 표준 트랙 [페이지 46]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 매개변수 이름: "d"
o 매개변수 설명: 개인 지수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.1
o 매개변수 이름: "p"
o 매개변수 설명: 첫 번째 소인수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.2
o 매개변수 이름: "q"
o 매개변수 설명: 두 번째 소인수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.3
o 매개변수 이름: "dp"
o 매개변수 설명: 첫 번째 인수 CRT 지수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.4
o 매개변수 이름: "dq"
o 매개변수 설명: 두 번째 인수 CRT 지수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.5
o 매개변수 이름: "qi"
o 매개변수 설명: 첫 번째 CRT 계수
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.6
Jones 표준 트랙 [페이지 47]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
o 매개변수 이름: "oth"
o 매개변수 설명: 기타 소수 정보
o 함께 사용되는 "kty" 값: "RSA"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.3.2.7
o 매개변수 이름: "k"
o 매개변수 설명: 키 값
o 함께 사용되는 "kty" 값: "oct"
o 매개변수 정보 클래스: 개인
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.4.1
7.6. JSON 웹 키 타원 곡선 레지스트리
이 절에서는 JWK "crv" 멤버 값을 위한 IANA "JSON Web Key
Elliptic Curve" 레지스트리를 설정합니다. 이 레지스트리는 곡선
이름, 구현 요구 사항 및 이를 정의하는 명세에 대한 참조를
기록합니다. 이 명세는 섹션 6.2.1.1에 정의된
매개변수 이름을 등록합니다.
암호화 환경이 발전함에 따라 곡선의 구현 요구 사항은 시간이
지나면서 변경될 수 있습니다. 예를 들어 곡선의 상태를
사용 중단으로 변경하거나 선택 사항에서 권고+ 또는 필수로
변경할 수 있습니다. 구현 요구 사항의 변경은 지정 전문가의
검토를 거친 후 Specification Required 절차에 따라서만 허용되며,
새로운 명세에서 수정된 구현 요구 사항 수준을 정의해야 합니다.
7.6.1. 등록 템플릿
곡선 이름:
요청된 이름(예: "P-256")입니다. 이 명세의 핵심 목표는
결과 표현을 간결하게 만드는 것이므로, 충분한 이유가
없는 한 이름은 8자를 넘지 않도록 짧게 하는 것이 권고됩니다.
이 이름은 대소문자를 구분합니다. 지정 전문가가 예외를
허용할 충분한 이유가 있다고 명시하지 않는 한, 대소문자를
구분하지 않고 비교했을 때 다른 등록된 이름과 일치해서는 안 됩니다.
곡선 설명:
곡선에 대한 간략한 설명입니다(예: "P-256 곡선").
JOSE 구현 요구 사항:
JWS 및 JWE의 곡선 구현 요구 사항이며, 필수, 권고, 선택 사항,
사용 중단 또는 금지 중 하나여야 합니다. 선택적으로 단어 뒤에
"+" 또는 "-"를 붙일 수 있습니다.
Jones 표준 트랙 [페이지 48]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
"+"는 향후 명세 버전에서 요구 수준이
높아질 가능성이 있음을 나타냅니다. "-"는 향후 명세 버전에서
요구 수준이 낮아질 가능성이 있음을 나타냅니다.
변경 제어자:
표준 트랙 RFC의 경우 "IESG"를 기재합니다. 그 외의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부 정보(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함할 수 있습니다.
명세 문서:
매개변수를 지정하는 문서에 대한 참조이며,
가능하면 문서 사본을 가져오는 데 사용할 수 있는 URI도
포함합니다. 관련 절에 대한 표시를 포함할 수도 있지만
필수는 아닙니다.
7.6.2. 초기 레지스트리 내용
o 곡선 이름: "P-256"
o 곡선 설명: P-256 곡선
o JOSE 구현 요구 사항: 권고+
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.1
o 곡선 이름: "P-384"
o 곡선 설명: P-384 곡선
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.1
o 곡선 이름: "P-521"
o 곡선 설명: P-521 곡선
o JOSE 구현 요구 사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서: RFC 7518의 섹션 6.2.1.1
8. 보안 고려 사항
모든 암호화 애플리케이션과 관련된 모든 보안 문제는
JWS/JWE/JWK 에이전트가 해결해야 합니다. 이러한 문제에는
사용자의 비대칭 개인 키와 대칭 비밀 키를 보호하는 것과
다양한 공격에 대한 대응책을 사용하는 것이 포함됩니다.
[AES], [DSS], [JWE], [JWK], [JWS],
[NIST.800-38D], [NIST.800-56A], [NIST.800-107], [RFC2104], [RFC3394],
[RFC3447], [RFC5116], [RFC6090] 및 [SHS]의 보안 고려 사항이
이 명세에 적용됩니다.
Jones 표준 트랙 [페이지 49]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
8.1. 암호화 민첩성
구현자는 암호화 알고리즘이 시간이 지남에 따라 약해진다는 점을
인지해야 합니다. 새로운 암호 분석 기법이 개발되고 컴퓨팅
성능이 향상됨에 따라 특정 암호화 알고리즘을 깨는 데 필요한
작업량은 감소합니다. 따라서 구현자와 배포 환경은
지원되고 사용되는 알고리즘 집합이 시간에 따라 변경되는 것에
대비해야 합니다. 따라서 암호화 알고리즘 구현은 모듈식이어야 하며,
새로운 알고리즘을 쉽게 추가할 수 있어야 합니다.
8.2. 키 수명
많은 알고리즘에는 키 수명 및/또는 키를 사용할 수 있는
횟수와 관련된 보안 고려 사항이 있습니다. 이러한 보안 고려 사항은
해당 알고리즘을 JOSE 데이터 구조와 함께 사용할 때도 계속
적용됩니다. 키 수명에 대한 구체적인 지침은 NIST SP 800-57
[NIST.800-57]을 참조하십시오.
8.3. RSAES-PKCS1-v1_5 보안 고려 사항
RFC 3447의 섹션 8 [RFC3447]에서는 새 애플리케이션에
RSASSA-PKCS1-v1_5를 채택하지 말고 대신 RSASSA-PSS로
전환할 것을 명시적으로 요구하지만, 이 명세에는 상호 운용성
이유로 RSASSA-PKCS1-v1_5가 포함되어 있습니다. 이는
널리 구현되어 있기 때문입니다.
RSAES-PKCS1-v1_5와 함께 사용하는 키는
RFC 3447의 섹션 7.2에 있는 제약 조건을 따라야 합니다. 또한
"RSA 암호 시스템에 대한 20년간의 공격" [Boneh99]의 섹션 3에
설명된 것처럼 공개 키 지수 값이 낮은 키를 사용해서는 안 됩니다.
8.4. AES GCM 보안 고려 사항
AES GCM과 함께 사용하는 키는 [NIST.800-38D]의 섹션 8.3에 있는
제약 조건을 따라야 하며, 여기에는 "주어진 키를 사용하는
인증된 암호화 함수의 모든 IV 길이와 모든 인스턴스를 포함하여
인증된 암호화 함수의 총 호출 횟수는 2^32를 초과해서는 안 된다"고
명시되어 있습니다. 이 규칙에 따라 AES GCM은 동일한 키 값을
2^32회를 초과하여 사용해서는 안 됩니다.
동일한 AES GCM 키와 함께 같은 IV 값을 여러 번 사용해서는
절대로 안 됩니다. 이를 방지하는 한 가지 방법은 키와 함께
카운터를 저장하고 사용할 때마다 증가시키는 것입니다.
이 카운터는 위의 2^32 한도를 초과하지 않도록 하는 데도
사용할 수 있습니다.
이 보안 고려 사항은 복합 AES-CBC HMAC SHA-2 또는
AES Key Wrap 알고리즘에는 적용되지 않습니다.
Jones 표준 트랙 [페이지 50]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
8.5. 비보안 JWS 보안 고려 사항
비보안 JWS("alg" 값 "none"을 사용하는 JWS)는 무결성
보호를 제공하지 않습니다. 따라서 페이로드가 디지털 서명이나
MAC 값 이외의 수단으로 보호되는 상황 또는 보호할 필요가 없는
상황에서만 사용해야 합니다.
비보안 JWS를 기본적으로 허용하지 않도록 하는 한 가지 예는
가상의 JWS 소프트웨어 라이브러리의 "verify" 메서드가
"none"이 허용 가능한 "alg" 값인지 나타내는 Boolean
"acceptUnsecured" 매개변수를 갖도록 하는 것입니다. 또 다른 예로,
"verify" 메서드는 애플리케이션이 허용하는 알고리즘 목록을
매개변수로 받을 수 있으며, 해당 목록에 "none"이 없으면
비보안 JWS 값을 거부할 수 있습니다.
다음 예시는 비보안 JWS를 전역 수준에서 허용하지 않아야 하는
이유를 보여줍니다. 애플리케이션이 두 채널,
(1) HTTP 및 (2) 클라이언트 인증을 사용하는 HTTPS를 통해
JWS를 허용한다고 가정합니다. HTTP를 통해 수신한 객체에는
JWS Signature를 요구하지만 HTTPS에서는 비보안 JWS를 허용합니다.
애플리케이션이 "none"을 허용한다고 전역적으로 표시한다면
공격자는 HTTP를 통해 비보안 JWS를 제공하면서도 해당 객체를
성공적으로 검증되게 할 수 있습니다. 대신 애플리케이션은
HTTPS를 통해 수신한 각 객체에 대해 "none" 허용을 표시해야
하지만(예: 위의 첫 번째 가상 JWS 소프트웨어 라이브러리에서
"acceptUnsecured"를 "true"로 설정), HTTP를 통해 수신한
각 객체에 대해서는 그렇게 해서는 안 됩니다.
8.6. 서비스 거부 공격
서명을 검증하는 수신 에이전트와 메시지를 암호화하는
송신 에이전트는 이 명세에서 요구하는 크기보다 큰 키를 사용하여
서명을 검증하거나 메시지를 암호화할 때 암호화 처리 사용량에
주의해야 합니다. 공격자는 예를 들어 이 명세에서 요구하는
크기보다 큰 키와 같이 과도한 암호화 처리를 유발하는
콘텐츠를 제공할 수 있습니다. 구현은 허용하는 키 크기에
상한을 설정하고 이를 적용하는 것이 좋습니다. NIST SP 800-57
[NIST.800-57]의 섹션 5.6.1
(비교 가능한 알고리즘 강도)에는 적용할 수 있는
최대 승인 키 크기에 관한 설명이 포함되어 있습니다.
8.7. 키 암호화 시 키 자료 재사용
여러 JWK 또는 JWK Set 객체를 암호화하거나 동일한 JWK 또는
JWK Set 객체를 여러 번 암호화하는 데 동일한 전체 키 자료 집합
(Key Encryption Key, Content Encryption Key, Initialization Vector
등)을 재사용하는 것은 권고되지 않습니다. 재사용을 방지하는 한 가지
Jones 표준 트랙 [페이지 51]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
방법은 이 문서 및 RFC 4086
[RFC4086]에 명시된 고려 사항에 따라 각 암호화 연산마다
항상 최소 하나의 새로운 키 자료(예: 새로운 Content
Encryption Key, 새로운 IV 및/또는 새로운 PBES2 Salt)를
생성하는 것입니다.
8.8. 비밀번호 고려 사항
비밀번호는 여러 공격에 취약합니다. 이러한 한계 중 일부를
완화하기 위해 이 문서는 사용자가 제공한 비밀번호에서
암호화 키를 파생하는 데 RFC
2898 [RFC2898]의 원칙을 적용합니다.
그러나 비밀번호의 강도는 여전히 상당한 영향을 미칩니다.
높은 엔트로피를 가진 비밀번호는 사전 공격에 대한 저항력이 더 높습니다.
[NIST.800-63-2]에는 비밀번호 엔트로피를 추정하기 위한 지침이
포함되어 있으며, 이는 애플리케이션과 사용자가 더 강한
비밀번호를 생성하는 데 도움이 될 수 있습니다.
이상적인 비밀번호는 파생 키 길이와 같거나 그보다 긴
비밀번호입니다. 그러나 특정 알고리즘별 크기를 초과하는
비밀번호는 먼저 해시되며, 이로 인해 공격자의 유효 검색 공간이
해시 알고리즘 길이로 줄어듭니다. "PBES2-HS256+A128KW"에
사용하는 비밀번호는 16옥텟보다 짧지 않고 128옥텟보다
길지 않도록 하는 것이 권고되며, "PBES2-HS512+A256KW"에
사용하는 비밀번호는 32옥텟보다 짧지 않고 128옥텟보다
길지 않도록 하는 것이 권고됩니다.
그럼에도 비밀번호 기반 암호화를 어디에서 어떻게 사용할지
주의해야 합니다. 반복 횟수가 너무 작으면 이러한 알고리즘은
여전히 사전 기반 공격에 취약할 수 있습니다. 이는 특히
파일 시스템에 저장된 보호 데이터처럼 공격자가 보호를 우회하려는
시도를 무제한으로 수행할 수 있는 데이터를 보호하는 데 이러한
알고리즘을 사용하는 경우 특히 문제가 됩니다.
8.9. 키 엔트로피와 난수 값
키 엔트로피 및 난수 값에 대한 보안 고려 사항은
[JWS]의 섹션 10.1을 참조하십시오.
8.10. 디지털 서명과 MAC의 차이
디지털 서명과 MAC의 차이에 대한 보안 고려 사항은
[JWS]의 섹션 10.5를 참조하십시오.
Jones 표준 트랙 [페이지 52]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
8.11. 일치하는 알고리즘 강도 사용
일치하는 알고리즘 강도 사용에 대한 보안 고려 사항은
[JWE]의 섹션 11.3을 참조하십시오.
8.12. 적응형 선택 암호문 공격
적응형 선택 암호문 공격에 대한 보안 고려 사항은
[JWE]의 섹션 11.4를 참조하십시오.
8.13. 타이밍 공격
타이밍 공격에 대한 보안 고려 사항은 [JWS]의 섹션 10.9 및
[JWE]의 섹션 11.5를 참조하십시오.
8.14. RSA 개인 키 표현 및 블라인딩
RSA 개인 키 표현 및 블라인딩에 대한 보안 고려 사항은
[JWK]의 섹션 9.3을 참조하십시오.
9. 국제화 고려 사항
사용자로부터 얻은 비밀번호는 서로 다른 입력 장치, 로캘 등에서
생성되는 옥텟 시퀀스의 차이를 고려하기 위해 준비 및
정규화가 필요할 가능성이 높습니다. 애플리케이션은 키 파생 및
암호화를 수행하기 전에 사용자가 직접 제공한 비밀번호를 준비하기
위해 [PRECIS]에 설명된 단계를 수행하는 것이 권고됩니다.
10. 참고 문헌
10.1. 규범적 참고 문헌
[AES] 미국 국립표준기술연구소(NIST),
"Advanced Encryption Standard(AES)", FIPS PUB 197,
2001년 11월, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[Boneh99] "RSA 암호 시스템에 대한 20년간의 공격", 미국
수학회(AMS) Notices, Vol. 46,
No. 2, pp. 203-213, 1999, <http://crypto.stanford.edu/
~dabo/pubs/papers/RSA-survey.pdf>.
Jones 표준 트랙 [페이지 53]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
[DSS] 미국 국립표준기술연구소(NIST),
"디지털 서명 표준(DSS)", FIPS PUB 186-4, 2013년 7월,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[JWE] Jones, M. 및 J. Hildebrand, "JSON 웹 암호화(JWE)",
RFC 7516, DOI 10.17487/RFC7516, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON 웹 키(JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J. 및 N. Sakimura, "JSON 웹
서명(JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015년
5월, <http://www.rfc-editor.org/info/rfc7515>.
[NIST.800-38A]
미국 국립표준기술연구소(NIST),
"블록 암호 동작 모드에 대한 권고", NIST
Special Publication 800-38A, 2001년 12월,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[NIST.800-38D]
미국 국립표준기술연구소(NIST),
"블록 암호 동작 모드에 대한 권고:
Galois/Counter Mode(GCM) 및 GMAC", NIST Special
Publication 800-38D, 2001년 12월,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[NIST.800-56A]
미국 국립표준기술연구소(NIST),
"이산 로그 암호화를 사용하는 쌍별 키 설정 방식에
대한 권고", NIST Special
Publication 800-56A, Revision 2, 2013년 5월,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[NIST.800-57]
미국 국립표준기술연구소(NIST),
"키 관리에 대한 권고 - 파트 1: 일반
(개정 3)", NIST Special Publication 800-57, Part 1,
Revision 3, 2012년 7월, <http://csrc.nist.gov/publications/
nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
Jones 표준 트랙 [페이지 54]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
[RFC20] Cerf, V., "네트워크 교환을 위한 ASCII 형식", STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969년 10월,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2104] Krawczyk, H., Bellare, M. 및 R. Canetti, "HMAC:
메시지 인증을 위한 키 지정 해싱", RFC 2104,
DOI 10.17487/RFC2104, 1997년 2월,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "요구 사항 수준을 나타내기 위해 RFC에서
사용하는 핵심 단어", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: 비밀번호 기반 암호화
명세 버전 2.0", RFC 2898,
DOI 10.17487/RFC2898, 2000년 9월,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC3394] Schaad, J. 및 R. Housley, "Advanced Encryption Standard
(AES) Key Wrap 알고리즘", RFC 3394, DOI 10.17487/RFC3394,
2002년 9월, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. 및 B. Kaliski, "공개 키 암호화
표준(PKCS) #1: RSA 암호화 명세
버전 2.1", RFC 3447, DOI 10.17487/RFC3447, 2003년
2월, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "ISO 10646의 변환 형식인
UTF-8", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003년
11월, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4868] Kelly, S. 및 S. Frankel, "IPsec에서 HMAC-SHA-256,
HMAC-SHA-384 및 HMAC-SHA-512 사용", RFC 4868,
DOI 10.17487/RFC4868, 2007년 5월,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "인터넷 보안 용어집, 버전 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007년 8월,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "암호화 메시지 구문(CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, 2009년 9월,
<http://www.rfc-editor.org/info/rfc5652>.
Jones 표준 트랙 [페이지 55]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
[RFC6090] McGrew, D., Igoe, K. 및 M. Salter, "기본 타원 곡선
암호화 알고리즘", RFC 6090,
DOI 10.17487/RFC6090, 2011년 2월,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., 편집자, "JavaScript 객체 표기법(JSON) 데이터
교환 형식", RFC 7159, DOI 10.17487/RFC7159, 2014년
3월, <http://www.rfc-editor.org/info/rfc7159>.
[SEC1] 효율적 암호화를 위한 표준 그룹, "SEC 1:
타원 곡선 암호화", 버전 2.0, 2009년 5월,
<http://www.secg.org/sec1-v2.pdf>.
[SHS] 미국 국립표준기술연구소(NIST),
"보안 해시 표준(SHS)", FIPS PUB 180-4, 2012년 3월,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[UNICODE] Unicode Consortium, "Unicode 표준",
<http://www.unicode.org/versions/latest/>.
10.2. 참고용 참고 문헌
[AEAD-CBC-SHA]
McGrew, D., Foley, J. 및 K. Paterson, "AES-CBC 및
HMAC-SHA를 사용한 인증된 암호화", 작업 진행 중,
draft-mcgrew-aead-aes-cbc-hmac-sha2-05, 2014년 7월.
[CanvasApp]
Facebook, "Canvas 애플리케이션", 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JCA] Oracle, "Java Cryptography Architecture(JCA) 참조
가이드", 2014, <http://docs.oracle.com/javase/8/docs/techno
tes/guides/security/crypto/CryptoSpec.html>.
[JSE] Bradley, J. 및 N. Sakimura(편집자), "JSON Simple
Encryption", 2010년 9월,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. 및 J. Hildebrand, "JavaScript 메시지
보안 형식", 작업 진행 중,
draft-rescorla-jsms-00, 2011년 3월.
[JSS] Bradley, J. 및 N. Sakimura, 편집자, "JSON Simple Sign 1.0",
초안 01, 2010년 9월, <http://jsonenc.info/jss/1.0/>.
Jones 표준 트랙 [페이지 56]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
[JWE-JWK] Miller, M., "JSON 웹 키(JWK) 객체를 보호하기 위한
JavaScript 객체 표기법(JSON) 웹 암호화(JWE)
사용", 작업 진행 중,
draft-miller-jose-jwe-protected-jwk-02, 2013년 6월.
[MagicSignatures]
Panzer, J., 편집자, Laurie, B. 및 D. Balfanz, "Magic
Signatures", 2011년 1월,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[NIST.800-107]
미국 국립표준기술연구소(NIST),
"승인된 해시 알고리즘을 사용하는 애플리케이션에
대한 권고", NIST Special Publication 800-107, Revision 1,
2012년 8월, <http://csrc.nist.gov/publications/
nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-63-2]
미국 국립표준기술연구소(NIST),
"전자 인증 지침", NIST Special
Publication 800-63-2, 2013년 8월,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-2.pdf>.
[PRECIS] Saint-Andre, P. 및 A. Melnikov, "사용자 이름과 비밀번호를
나타내는 국제화 문자열의 준비,
적용 및 비교", 작업 진행 중,
draft-ietf-precis-saslprepbis-16, 2015년 4월.
[RFC2631] Rescorla, E., "Diffie-Hellman 키 합의 방법",
RFC 2631, DOI 10.17487/RFC2631, 1999년 6월,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J. 및 D. Solo, "(확장 가능한
마크업 언어) XML 서명 구문 및 처리",
RFC 3275, DOI 10.17487/RFC3275, 2002년 3월,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J. 및 S. Crocker,
"보안을 위한 무작위성 요구 사항", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005년 6월,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "인증된 암호화를 위한 인터페이스 및
알고리즘", RFC 5116, DOI 10.17487/RFC5116, 2008년 1월,
<http://www.rfc-editor.org/info/rfc5116>.
Jones 표준 트랙 [페이지 57]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
[RFC5226] Narten, T. 및 H. Alvestrand, "RFC의 IANA 고려 사항
절 작성 지침", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5226>.
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler,
T., Yiu, K., Datta, P. 및 S. Cantor, "XML 서명
구문 및 처리 버전 2.0", World Wide Web
Consortium Note NOTE-xmldsig-core2-20130411, 2013년 4월,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. 및 J. Reagle, "XML 암호화 구문 및
처리", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, 2002년 12월,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F. 및 T. Roessler,
"XML 암호화 구문 및 처리 버전 1.1", World
Wide Web Consortium Recommendation REC-xmlenc-
core1-20130411, 2013년 4월,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones 표준 트랙 [페이지 58]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
부록 A. 알고리즘 식별자 상호 참조
이 부록에는 이 명세에 정의된 암호화 알고리즘 식별자 값과
다른 표준 및 소프트웨어 패키지에서 사용하는 동등한 식별자를
상호 참조하는 표가 포함되어 있습니다.
해당 문서에서 정의한 이름에 대한 자세한 내용은 XML DSIG [RFC3275],
XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411],
XML Encryption [W3C.REC-xmlenc-core-20021210],
XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] 및
Java Cryptography Architecture
[JCA]를 참조하십시오.
Jones 표준 트랙 [페이지 59]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
A.1. 디지털 서명/MAC 알고리즘 식별자 상호 참조
이 절에는 이 명세에서 정의한 JWS 디지털 서명 및
MAC "alg"(알고리즘) 값과 다른 표준 및 소프트웨어 패키지에서
사용하는 동등한 식별자를 상호 참조하는 표가 포함되어 있습니다.
+-------------------------------------------------------------------+
| JWS | XML DSIG |
| | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 |
| | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 |
| | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 |
| | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 |
| | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 |
| | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 |
| | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 |
| | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 |
| | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 |
| | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 |
| | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 |
| | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
Jones 표준 트랙 [페이지 60]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
A.2. 키 관리 알고리즘 식별자 상호 참조
이 절에는 이 명세에서 정의한 JWE "alg"(알고리즘) 값과
다른 표준 및 소프트웨어 패키지에서 사용하는 동등한
식별자를 상호 참조하는 표가 포함되어 있습니다.
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| RSA1_5 | http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
| | RSA/ECB/PKCS1Padding | 1.2.840.113549.1.1.1 |
+-------------------------------------------------------------------+
| RSA-OAEP | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
| | RSA/ECB/OAEPWithSHA-1AndMGF1Padding | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| RSA-OAEP-256 | http://www.w3.org/2009/xmlenc11#rsa-oaep |
| | & http://www.w3.org/2009/xmlenc11#mgf1sha256 |
| | RSA/ECB/OAEPWithSHA-256AndMGF1Padding | |
| | & MGF1ParameterSpec.SHA256 | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| ECDH-ES | http://www.w3.org/2009/xmlenc11#ECDH-ES |
| | ECDH | 1.3.132.1.12 |
+-------------------------------------------------------------------+
| A128KW | http://www.w3.org/2001/04/xmlenc#kw-aes128 |
| | AESWrap | 2.16.840.1.101.3.4.1.5 |
+-------------------------------------------------------------------+
| A192KW | http://www.w3.org/2001/04/xmlenc#kw-aes192 |
| | AESWrap | 2.16.840.1.101.3.4.1.25 |
+-------------------------------------------------------------------+
| A256KW | http://www.w3.org/2001/04/xmlenc#kw-aes256 |
| | AESWrap | 2.16.840.1.101.3.4.1.45 |
+-------------------------------------------------------------------+
Jones 표준 트랙 [페이지 61]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
A.3. 콘텐츠 암호화 알고리즘 식별자 상호 참조
이 절에는 이 명세에서 정의한 JWE "enc"(암호화 알고리즘)
값과 다른 표준 및 소프트웨어 패키지에서 사용하는 동등한
식별자를 상호 참조하는 표가 포함되어 있습니다.
복합 알고리즘 "A128CBC-HS256", "A192CBC-HS384" 및
"A256CBC-HS512"의 경우 해당 AES-CBC 알고리즘 식별자가
나열됩니다.
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| A128CBC-HS256 | http://www.w3.org/2001/04/xmlenc#aes128-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.2 |
+-------------------------------------------------------------------+
| A192CBC-HS384 | http://www.w3.org/2001/04/xmlenc#aes192-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.22 |
+-------------------------------------------------------------------+
| A256CBC-HS512 | http://www.w3.org/2001/04/xmlenc#aes256-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.42 |
+-------------------------------------------------------------------+
| A128GCM | http://www.w3.org/2009/xmlenc11#aes128-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.6 |
+-------------------------------------------------------------------+
| A192GCM | http://www.w3.org/2009/xmlenc11#aes192-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.26 |
+-------------------------------------------------------------------+
| A256GCM | http://www.w3.org/2009/xmlenc11#aes256-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.46 |
+-------------------------------------------------------------------+
부록 B. AES_CBC_HMAC_SHA2 알고리즘 테스트 사례
다음 테스트 사례는 섹션 5.2에 정의된
AES_CBC_HMAC_SHA2 알고리즘 구현을 검증하는 데 사용할 수 있습니다.
또한 향후 [AEAD-CBC-SHA] 버전에 나타날 수 있는 테스트 사례에
대응하도록 의도되었으며, 수행되는 암호화 계산이 동일함을
보여줍니다.
변수 이름은 섹션 5.2에 정의된 것과 같습니다. 모든 값은
16진수입니다.
Jones 표준 트랙 [페이지 62]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
B.1. AES_128_CBC_HMAC_SHA_256 테스트 사례
AES_128_CBC_HMAC_SHA_256
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79
a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9
a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2
fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36
09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8
6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b
38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f
bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5
4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
M = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
e6 e5 45 82 47 65 15 f0 ad 9f 75 a2 b7 1c 73 ef
T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
Jones 표준 트랙 [페이지 63]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
B.2. AES_192_CBC_HMAC_SHA_384 테스트 사례
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5
d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db
00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6
57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21
4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b
3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21
05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a
c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27
f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
M = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7 45 94 f8 86 b3 fa af d4
86 f2 5c 71 31 e3 28 1e 36 c7 a2 d1 30 af de 57
T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7
Jones 표준 트랙 [페이지 64]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
B.3. AES_256_CBC_HMAC_SHA_512 테스트 사례
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2
e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b
36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1
1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3
a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e
31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
M = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07
53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c
T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
Jones 표준 트랙 [페이지 65]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
부록 C. ECDH-ES 키 합의 계산 예시
이 예시에서는 섹션 4.6에 설명된 방식으로 CEK를 파생하기 위해
ECDH-ES Key Agreement와 Concat KDF를 사용합니다. 이 예시에서는
ECDH-ES Direct Key Agreement 모드("alg" 값 "ECDH-ES")를 사용하여
128비트 키를 사용하는 AES GCM("enc" 값 "A128GCM")용
합의된 키를 생성합니다.
이 예시에서 생성자 Alice는 소비자 Bob에게 콘텐츠를
암호화합니다. 생성자(Alice)는 키 합의 계산을 위해 임시 키를
생성합니다. 이 예시의 키 합의 계산에 사용되는 Alice의
임시 키(JWK 형식, 개인 부분 포함)는 다음과 같습니다.
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
}
이 예시의 키 합의 계산에 사용되는 소비자(Bob)의 키
(JWK 형식, 개인 부분 포함)는 다음과 같습니다.
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
이 예시에서 사용하는 헤더 매개변수 값은 다음과 같습니다.
"apu"(agreement PartyUInfo) 헤더 매개변수 값은 UTF-8 문자열
"Alice"를 base64url로 인코딩한 값이고, "apv"(agreement
PartyVInfo) 헤더 매개변수 값은 UTF-8 문자열 "Bob"을
base64url로 인코딩한 값입니다. "epk"(임시 공개 키) 헤더
매개변수는 생성자(Alice)의 임시 공개 키 값을
소비자(Bob)에게 전달하는 데 사용합니다.
Jones 표준 트랙 [페이지 66]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
결과 Concat KDF [NIST.800-56A] 매개변수 값은 다음과 같습니다.
Z
ECDH-ES 키 합의 출력으로 설정합니다. (이 값은 NIST 보안
요구 사항 때문에 라이브러리에서 직접 노출되지 않는 경우가
많으며 KDF의 입력으로만 사용됩니다.) 이 예시에서 Z는
다음 옥텟 시퀀스입니다(JSON 배열 표기법 사용).
[158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132,
38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121,
140, 254, 144, 196].
keydatalen
이 값은 128이며, 원하는 출력 키의 비트 수입니다
("A128GCM"이 128비트 키를 사용하기 때문입니다).
AlgorithmID
AlgorithmID 콘텐츠 "A128GCM"의 옥텟 수인
32비트 빅 엔디언 값 7을 나타내는 옥텟
[0, 0, 0, 7]로 설정한 다음, ASCII 문자열
"A128GCM"을 나타내는 옥텟 [65, 49, 50, 56, 71, 67, 77]을
이어 붙입니다.
PartyUInfo
PartyUInfo 콘텐츠 "Alice"의 옥텟 수인
32비트 빅 엔디언 값 5를 나타내는 옥텟
[0, 0, 0, 5]로 설정한 다음, UTF-8 문자열
"Alice"를 나타내는 옥텟 [65, 108, 105, 99, 101]을 이어 붙입니다.
PartyVInfo
PartyUInfo 콘텐츠 "Bob"의 옥텟 수인
32비트 빅 엔디언 값 3을 나타내는 옥텟
[0, 0, 0, 3]으로 설정한 다음, UTF-8 문자열 "Bob"을
나타내는 옥텟 [66, 111, 98]을 이어 붙입니다.
Jones 표준 트랙 [페이지 67]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
SuppPubInfo
32비트 빅 엔디언 값 128을 나타내는 옥텟
[0, 0, 0, 128], 즉 keydatalen 값으로 설정합니다.
SuppPrivInfo
빈 옥텟 시퀀스로 설정합니다.
AlgorithmID부터 SuppPubInfo까지의 매개변수를 연결하면
다음 OtherInfo 값이 생성됩니다.
[0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105,
99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
라운드 번호 1([0, 0, 0, 1]), Z 및 OtherInfo 값을 연결하면
다음과 같은 Concat KDF 라운드 1 해시 입력이 생성됩니다.
[0, 0, 0, 1,
158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38,
156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140,
254, 144, 196,
0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99,
101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
결과로 파생된 키는 라운드 1 해시 출력의 처음 128비트이며
다음과 같습니다.
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26]
이 파생 키를 base64url로 인코딩한 표현은 다음과 같습니다.
VqqN6vgjbSBcIijNcacQGg
Jones 표준 트랙 [페이지 68]
RFC 7518 JSON 웹 알고리즘(JWA) 2015년 5월
감사의 글
JSON 콘텐츠의 서명 및 암호화를 위한 해결 방법은 이전에
"Magic Signatures" [MagicSignatures], "JSON Simple Sign
1.0" [JSS], "Canvas Applications" [CanvasApp], "JSON Simple
Encryption" [JSE] 및 "JavaScript Message Security Format" [JSMS]에서
탐구되었으며, 이들 모두가 이 문서에 영향을 주었습니다.
AES_CBC_HMAC_SHA2 알고리즘의 기반이 되는
"Authenticated Encryption with AES-CBC and HMAC-SHA"
[AEAD-CBC-SHA] 명세는 David A. McGrew와 Kenny
Paterson이 작성했습니다. AES_CBC_HMAC_SHA2의 테스트 사례는
John Foley가 작성한 [AEAD-CBC-SHA]의 테스트 사례를 기반으로 합니다.
Matt Miller는 이 문서의 비밀번호 기반 암호화 내용의
기반이 된 "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects"
[JWE-JWK]을 작성했습니다.
이 명세는 수십 명의 적극적이고 헌신적인 참가자가 참여한
JOSE 워킹 그룹의 작업 결과입니다. 특히 다음 사람들이
이 명세에 영향을 준 아이디어, 피드백 및 문구를
제공했습니다.
Dirk Balfanz, Richard Barnes, Carsten Bormann, John Bradley, Brian
Campbell, Alissa Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni
Even, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand,
Jeff Hodges, Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John
Panzer, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,
Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad와 Karen O'Donoghue는 JOSE 워킹 그룹의 의장을 맡았으며,
Sean Turner, Stephen Farrell 및 Kathleen Moriarty는 이 명세가
작성되는 동안 보안 영역 디렉터로 활동했습니다.
저자 주소
Michael B. Jones
Microsoft
이메일: mbj@microsoft.com
URI: http://self-issued.info/
Jones 표준 트랙 [페이지 69]