[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 9864 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7518 Microsoft
Category: Standards Track May 2015
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 Standards Track [Page 1]
RFC 7518 JSON Web Algorithms (JWA) May 2015
목차
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 키 래핑을 이용한 키 래핑 . . . . . . . . . . . . 14
4.5. 공유 대칭 키를 이용한 직접 암호화 . . . . . . . . . 15
4.6. 타원 곡선 디피-헬만을 이용한 키 합의
임시-정적(ECDH-ES) . . . . . . . . . . . . . . . . 15
4.6.1. ECDH 키 합의에 사용되는 헤더 매개변수 . . . . . 16
4.6.1.1. "epk"(임시 공개 키) 헤더 매개변수 . . 16
4.6.1.2. "apu"(합의 PartyUInfo) 헤더 매개변수 . . 17
4.6.1.3. "apv"(합의 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 Standards Track [Page 2]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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 Standards Track [Page 3]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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 Standards Track [Page 4]
RFC 7518 JSON Web Algorithms (JWA) May 2015
이러한 해석은 해당 용어가 모두 대문자로 표시될 때에만 적용된다.
BASE64URL(OCTETS)는 [JWS]의 2절에 따라 OCTETS의
base64url 인코딩을 나타낸다.
UTF8(STRING)은 STRING의 UTF-8 [RFC3629] 표현의
옥텟을 나타내며, 여기서 STRING은 0개 이상의 유니코드
[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"라는 용어는
"Internet Security Glossary, Version 2" [RFC4949]에
의해 정의된다.
다음 용어는 이 명세에서 정의된다:
Base64urlUInt
양의 정수 또는 0 값을, 값의 부호 없는 빅엔디언
표현을 옥텟 시퀀스로 나타낸 후 이를 base64url로
인코딩한 표현이다. 옥텟 시퀀스는 해당 값을 표현하는 데
필요한 최소한의 옥텟 수를 반드시 사용해야 한다. 0은
BASE64URL(값이 0인 단일 옥텟)으로 표현되며, 이는 "AA"이다.
Jones Standards Track [Page 5]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3. 디지털 서명 및 MAC을 위한 암호 알고리즘
JWS는 JWS 보호된 헤더와 JWS 페이로드의 내용을
디지털 서명하거나 MAC을 생성하기 위해 암호 알고리즘을 사용한다.
3.1. JWS를 위한 "alg"(알고리즘) 헤더 매개변수 값
아래 표는 이 명세에서 JWS와 함께 사용하도록 정의된
"alg"(알고리즘) 헤더 매개변수 값들의 집합이며,
각각은 이후 절에서 더 자세히 설명된다:
+--------------+-------------------------------+--------------------+
| "alg" Param | 디지털 서명 또는 MAC | 구현 |
| Value | 알고리즘 | 요구 사항 |
+--------------+-------------------------------+--------------------+
| 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과 | 선택 |
| | MGF1(SHA-256)을 사용하는 | |
| | RSASSA-PSS | |
| PS384 | SHA-384과 | 선택 |
| | MGF1(SHA-384)을 사용하는 | |
| | RSASSA-PSS | |
| PS512 | SHA-512과 | 선택 |
| | MGF1(SHA-512)을 사용하는 | |
| | RSASSA-PSS | |
| none | 디지털 서명 또는 MAC 없음 | 선택 |
| | 수행되지 않음 | |
+--------------+-------------------------------+--------------------+
구현 요구 사항 열에서 "+"의 사용은,
향후 버전의 명세에서 요구 강도가 증가할 가능성이 있음을 나타낸다.
이 명세에서 정의된 JWS 디지털 서명 및 MAC "alg"(알고리즘)
값과 다른 표준 및 소프트웨어 패키지에서 사용되는
동등한 식별자를 상호 참조한 표는
부록 A.1을 참조하라.
Jones Standards Track [Page 6]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3.2. SHA-2 함수와 함께 사용하는 HMAC
해시 기반 메시지 인증 코드(HMAC)는
비밀 키와 암호 해시 함수를 사용하여 MAC을 생성할 수 있게 한다.
이는 MAC을 생성한 주체가 해당 MAC 키를
보유하고 있었음을 증명하는 데 사용될 수 있다.
HMAC을 구현하고 검증하는 알고리즘은
RFC 2104 [RFC2104]에 제공되어 있다.
이 알고리즘에는 해시 출력과 동일한 크기
(예: "HS256"의 경우 256비트) 또는 그보다 큰 키를
MUST 사용해야 한다.
(이 요구 사항은 NIST SP 800-117의
5.3.4절(HMAC 키의 보안 효과)
[NIST.800-107]에 근거한 것으로,
유효 보안 강도는 키의 보안 강도와
내부 해시 값 크기의 두 배 중 최소값이라는 점을 명시하고 있다.)
HMAC SHA-256 MAC은 RFC 2104에 따라 생성되며,
해시 알고리즘 "H"로 SHA-256을 사용하고,
"text" 값으로 JWS 서명 입력을 사용하며,
공유 키를 사용한다.
HMAC 출력 값이 JWS 서명이다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS 서명이 해당 알고리즘으로 계산된 HMAC 값임을 나타내는 데 사용된다:
+-------------------+--------------------+
| "alg" Param Value | MAC 알고리즘 |
+-------------------+--------------------+
| HS256 | SHA-256을 사용하는 |
| | HMAC |
| HS384 | SHA-384를 사용하는 |
| | HMAC |
| HS512 | SHA-512를 사용하는 |
| | HMAC |
+-------------------+--------------------+
JWS에 대한 HMAC SHA-256 MAC은 다음과 같이 검증된다.
RFC 2104에 따라 HMAC 값을 계산하되,
해시 알고리즘 "H"로 SHA-256을 사용하고,
"text" 값으로 수신된 JWS 서명 입력을 사용하며,
공유 키를 사용한다.
그런 다음 계산된 HMAC 값을
수신된 인코딩된 JWS 서명 값을 base64url 디코딩한 결과와 비교한다.
계산된 HMAC 값과 JWS 서명 값의 비교는
타이밍 공격을 방지하기 위해
MUST 상수 시간 방식으로 수행되어야 한다.
또는 계산된 HMAC 값을 base64url 인코딩하여
수신된 인코딩된 JWS 서명 값과
(마찬가지로 상수 시간 방식으로) 비교할 수도 있는데,
이는 인코딩되지 않은 값을 비교하는 것과
동일한 결과를 생성한다.
어느 경우든 값이 일치하면 HMAC은 검증된 것이다.
Jones Standards Track [Page 7]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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]
(일반적으로 PKCS #1로 알려짐)에 정의된
RSASSA-PKCS1-v1_5 디지털 서명 알고리즘을
SHA-2 [SHS] 해시 함수와 함께 사용하는 방법을 정의한다.
이 알고리즘에는 2048비트 이상의 키를
MUST 사용해야 한다.
RSASSA-PKCS1-v1_5 SHA-256 디지털 서명은 다음과 같이 생성된다:
원하는 개인 키를 사용하여
RSASSA-PKCS1-v1_5-SIGN과 SHA-256 해시 함수를 이용해
JWS 서명 입력에 대한 디지털 서명을 생성한다.
이것이 JWS 서명 값이다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS 서명이 해당 알고리즘으로 계산된
디지털 서명 값임을 나타내는 데 사용된다:
+-------------------+---------------------------------+
| "alg" Param Value | 디지털 서명 알고리즘 |
+-------------------+---------------------------------+
| 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 서명 입력, JWS 서명,
그리고 서명자가 사용한 개인 키에 대응하는 공개 키를
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 Standards Track [Page 8]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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 서명 입력에 대한 디지털 서명을 생성한다.
출력은 (R, S) 쌍이며,
R과 S는 256비트 부호 없는 정수이다.
2. R과 S를 각각 32옥텟 길이의
빅엔디언 순서의 옥텟 시퀀스로 변환한다.
값에 포함된 선행 0 옥텟을 생략하기 위해
표현을 축소해서는 MUST NOT 된다.
3. 두 옥텟 시퀀스를
R 다음에 S의 순서로 연결한다.
(많은 ECDSA 구현은
이 연결 결과를 직접 출력으로 생성한다.)
4. 결과로 생성된 64옥텟 시퀀스가
JWS 서명 값이다.
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS 서명이 해당 알고리즘으로 계산된
디지털 서명 값임을 나타내는 데 사용된다:
+-------------------+-------------------------------+
| "alg" Param Value | 디지털 서명 알고리즘 |
+-------------------+-------------------------------+
| ES256 | P-256과 SHA-256을 사용하는 |
| | ECDSA |
| ES384 | P-384와 SHA-384를 사용하는 |
| | ECDSA |
| ES512 | P-521과 SHA-512를 사용하는 |
| | ECDSA |
+-------------------+-------------------------------+
Jones Standards Track [Page 9]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JWS에 대한 ECDSA P-256 SHA-256 디지털 서명은
다음과 같이 검증된다:
1. JWS 서명 값은 64옥텟 시퀀스여야 MUST 한다.
64옥텟 시퀀스가 아니라면 검증은 실패한다.
2. 64옥텟 시퀀스를
두 개의 32옥텟 시퀀스로 분할한다.
첫 번째 옥텟 시퀀스는 R을,
두 번째는 S를 나타낸다.
R과 S 값은
SEC1 [SEC1]의
2.3.7절에 정의된
정수-옥텟 문자열 변환을 사용하여
(빅엔디언 옥텟 순서로)
옥텟 시퀀스로 표현된다.
3. JWS 서명 입력, 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옥텟 시퀀스가 된다.
(SEC1 [SEC1]의
2.3.7절에 정의된
정수-옥텟 문자열 변환은
필요할 경우 크기를 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비트 이상의 키를
MUST 사용해야 한다.
RSASSA-PSS SHA-256 디지털 서명은 다음과 같이 생성된다:
원하는 개인 키를 사용하여
SHA-256 해시 함수와
SHA-256을 사용하는 MGF1 마스크 생성 함수를 이용한
RSASSA-PSS-SIGN으로
JWS 서명 입력에 대한 디지털 서명을 생성한다.
이것이 JWS 서명 값이다.
Jones Standards Track [Page 10]
RFC 7518 JSON Web Algorithms (JWA) May 2015
다음 "alg"(알고리즘) 헤더 매개변수 값은
JWS 서명이 해당 알고리즘으로 계산된
디지털 서명 값임을 나타내는 데 사용된다:
+-------------------+-----------------------------------------------+
| "alg" Param Value | 디지털 서명 알고리즘 |
+-------------------+-----------------------------------------------+
| PS256 | SHA-256과 MGF1(SHA-256)을 사용하는 |
| | RSASSA-PSS |
| PS384 | SHA-384과 MGF1(SHA-384)을 사용하는 |
| | RSASSA-PSS |
| PS512 | SHA-512과 MGF1(SHA-512)을 사용하는 |
| | RSASSA-PSS |
+-------------------+-----------------------------------------------+
JWS에 대한 RSASSA-PSS SHA-256 디지털 서명은
다음과 같이 검증된다:
JWS 서명 입력, JWS 서명,
그리고 서명자가 사용한 개인 키에 대응하는 공개 키를
SHA-256 해시 함수와
SHA-256을 사용하는 MGF1 마스크 생성 함수를 사용하는
RSASSA-PSS-VERIFY 알고리즘에 제출한다.
RSASSA-PSS SHA-384 및
RSASSA-PSS SHA-512 알고리즘을 사용한
서명과 검증은
RSASSA-PSS SHA-256의 절차와 동일하게 수행되며,
두 역할 모두에서
대체 해시 알고리즘을 사용한다.
3.6. 알고리즘 "none"의 사용
JWS는 무결성 보호를 제공하지 않도록
생성될 수도 MAY 있다.
이러한 JWS를 비보안 JWS(Unsecured JWS)라고 한다.
비보안 JWS는 "alg" 값으로 "none"을 사용하며,
다른 JWS와 동일한 형식이지만,
JWS 서명 값으로
빈 옥텟 시퀀스를 MUST 사용해야 한다.
수신자는 JWS 서명 값이
빈 옥텟 시퀀스인지 MUST 검증해야 한다.
비보안 JWS를 지원하는 구현은,
애플리케이션이 특정 객체에 대해
무결성 보호가 허용됨을 명시적으로 지정하지 않는 한,
이러한 객체를 유효한 것으로
MUST NOT 받아들여야 한다.
구현은 기본적으로
비보안 JWS를 MUST NOT 받아들여야 한다.
다운그레이드 공격을 완화하기 위해,
애플리케이션은 전역 수준에서
비보안 JWS의 수용을 신호해서는 MUST NOT 되며,
객체별 기준으로 수용을 신호하는 것이 SHOULD 권장된다.
이 알고리즘 사용과 관련된 보안 고려 사항은
8.5절을 참조하라.
4. 키 관리용 암호 알고리즘
JWE는 콘텐츠 암호화 키(CEK)를
암호화하거나 결정하기 위해
암호 알고리즘을 사용한다.
Jones Standards Track [Page 11]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.1. JWE를 위한 "alg"(알고리즘) 헤더 매개변수 값
아래 표는 이 명세에서 JWE와 함께 사용하도록 정의된
"alg"(알고리즘) 헤더 매개변수 값들의 집합이다.
이러한 알고리즘은 CEK를 암호화하여
JWE 암호화된 키를 생성하거나,
키 합의를 사용하여 CEK에 합의하는 데 사용된다.
+--------------------+--------------------+--------+----------------+
| "alg" Param Value | 키 관리 | 추가 | 구현 |
| | 알고리즘 | 헤더 | 요구 사항 |
| | | 매개변수| |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (없음) | 권장- |
| RSA-OAEP | 기본 매개변수를 | (없음) | 권장+ |
| | 사용하는 RSAES | | |
| | OAEP | | |
| RSA-OAEP-256 | SHA-256과 MGF1 | (없음) | 선택 |
| | (SHA-256)을 | | |
| | 사용하는 RSAES | | |
| | OAEP | | |
| A128KW | 기본 초기 값을 | (없음) | 권장 |
| | 사용하는 AES 키 | | |
| | 래핑, 128비트 키 | | |
| A192KW | 기본 초기 값을 | (없음) | 선택 |
| | 사용하는 AES 키 | | |
| | 래핑, 192비트 키 | | |
| A256KW | 기본 초기 값을 | (없음) | 권장 |
| | 사용하는 AES 키 | | |
| | 래핑, 256비트 키 | | |
| dir | 공유 대칭 키를 | (없음) | 권장 |
| | CEK로 직접 사용 | | |
| ECDH-ES | Concat KDF를 | "epk", | 권장+ |
| | 사용하는 타원 곡선 | "apu", | |
| | 디피-헬만 | "apv" | |
| | 임시-고정 키 합의 | | |
| ECDH-ES+A128KW | Concat KDF를 | "epk", | 권장 |
| | 사용하는 ECDH-ES와 | "apu", | |
| | "A128KW"로 래핑된 | "apv" | |
| | CEK | | |
| ECDH-ES+A192KW | Concat KDF를 | "epk", | 선택 |
| | 사용하는 ECDH-ES와 | "apu", | |
| | "A192KW"로 래핑된 | "apv" | |
| | CEK | | |
Jones Standards Track [Page 12]
RFC 7518 JSON Web Algorithms (JWA) May 2015
| ECDH-ES+A256KW | Concat KDF를 | "epk", | 권장 |
| | 사용하는 ECDH-ES와 | "apu", | |
| | "A256KW"로 래핑된 | "apv" | |
| | CEK | | |
| A128GCMKW | AES GCM을 | "iv", | 선택 |
| | 사용하는 키 래핑, | "tag" | |
| | 128비트 키 | | |
| A192GCMKW | AES GCM을 | "iv", | 선택 |
| | 사용하는 키 래핑, | "tag" | |
| | 192비트 키 | | |
| A256GCMKW | AES GCM을 | "iv", | 선택 |
| | 사용하는 키 래핑, | "tag" | |
| | 256비트 키 | | |
| 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 암호화된 키 값을 생성한다.
구현 요구 사항 열에서 "+"의 사용은,
향후 버전의 명세에서
요구 강도가 증가할 가능성이 있음을 나타낸다.
"-"의 사용은,
향후 버전의 명세에서
요구 강도가 감소할 가능성이 있음을 나타낸다.
이 명세에서 정의된 JWE "alg"(알고리즘) 값과
다른 표준 및 소프트웨어 패키지에서 사용되는
동등한 식별자를 상호 참조한 표는
부록 A.2를 참조하라.
4.2. RSAES-PKCS1-v1_5를 사용하는 키 암호화
이 절은 RSAES-PKCS1-v1_5
[RFC3447]를 사용하여
JWE CEK를 암호화하는 구체적인 사항을 정의한다.
이 알고리즘에는
"alg"(알고리즘) 헤더 매개변수 값 "RSA1_5"가 사용된다.
이 알고리즘에는 2048비트 이상의 키를
MUST 사용해야 한다.
이 알고리즘을 사용하는 예제는
[JWE]의
부록 A.2에 제시되어 있다.
Jones Standards Track [Page 13]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.3. RSAES OAEP를 이용한 키 암호화
이 절에서는 OAEP(Optimal Asymmetric Encryption Padding) [RFC3447]를
사용하여 JWE CEK를 RSAES로 암호화하는 구체 사항을 정의한다. OAEP 사용을 위한
두 가지 파라미터 집합이 정의되어 있는데, 이는 서로 다른 해시 함수를 사용한다.
첫 번째 경우, RFC 3447 부록 A.2.1에 지정된 기본 파라미터를 사용한다.
(해당 기본 파라미터는 SHA-1 해시 함수와 SHA-1을 사용하는 MGF1 마스크 생성 함수임.)
두 번째 경우에는 SHA-256 해시 함수와 SHA-256을 사용하는 MGF1 마스크 생성 함수를 사용한다.
아래의 "alg"(알고리즘) 헤더 파라미터 값은 JWE 암호화 키가 해당 알고리즘을 이용해
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절의 기본 초기값을 사용하는
고급 암호화 표준(AES) 키 랩 알고리즘 [RFC3394]으로 JWE CEK를
암호화하는 구체 사항을 정의한다.
Jones Standards Track [Page 14]
RFC 7518 JSON Web Algorithms (JWA) May 2015
아래 "alg"(알고리즘) 헤더 파라미터 값은 JWE 암호화 키가
해당 알고리즘과 키 크기로 CEK를 암호화한 결과임을 나타낸다:
+-----------------+-------------------------------------------------+
| "alg" 값 | 키 관리 알고리즘 |
+-----------------+-------------------------------------------------+
| A128KW | 128비트 키, 기본 초기값 사용 AES 키 랩 |
| A192KW | 192비트 키, 기본 초기값 사용 AES 키 랩 |
| A256KW | 256비트 키, 기본 초기값 사용 AES 키 랩 |
+-----------------+-------------------------------------------------+
본 알고리즘 사용 예시는 [JWE] 부록 A.3에 있다.
4.5. 공유 대칭키로 직접 암호화
이 절에서는 키 래핑 과정을 거치지 않고 바로 대칭키 암호화를 수행하는
세부 사항을 정의한다. 이 경우, 공유 대칭키가 "enc" 알고리즘에서 직접
콘텐츠 암호화 키(CEK)로 쓰인다. JWE 암호화 키 값으로는 빈 옥텟 시퀀스를 사용한다.
이때 "alg"(알고리즘) 헤더 파라미터 값은 "dir"로 지정한다.
직접 암호화 사용 시 8.2절의 키 수명과
8.4절의 AES GCM 보안 유의점을 참고해야 한다.
4.6. 타원곡선 디피-헬만 임시-정적(ECDH-ES) 키 합의
본 절에서는 타원 곡선 디피-헬만 임시-정적 [RFC6090]과
[NIST.800-56A] 5.8.1절에 정의된 Concat KDF를
조합해 키 합의를 수행하는 절차를 정의한다. 키 합의 결과는 두 가지 방식으로 사용할 수 있다:
1. 직접 키 합의 모드: Concat KDF 출력값을 "enc" 알고리즘에 사용할
콘텐츠 암호화 키(CEK)로 바로 사용
2. 키 합의 및 키 래핑 모드: 합의된 대칭키로 CEK를 "A128KW", "A192KW",
또는 "A256KW" 알고리즘으로 랩핑
매 키 합의 연산마다 새로운 임시 공개키 값을 생성해야 한다.
Jones Standards Track [Page 15]
RFC 7518 JSON Web Algorithms (JWA) May 2015
직접 키 합의 모드에서는 Concat KDF의 출력이 반드시 "enc" 알고리즘이
사용하는 키 길이와 같아야 한다. 이 경우 JWE 암호화 키 값으로 빈 옥텟 시퀀스를 쓴다.
직접 키 합의 모드의 "alg"(알고리즘) 헤더 파라미터 값은 "ECDH-ES"이다.
키 합의 및 키 래핑 모드에서는 Concat KDF의 출력이 지정 래핑 알고리즘에
필요한 키 길이와 같아야 한다. 이 경우 JWE 암호화 키는 합의한 키로 랩핑한 CEK이다.
아래 "alg"(알고리즘) 헤더 파라미터 값은 JWE 암호화 키가
해당 키 합의 알고리즘 결과물을 키 암호화 키로 삼아, 지정 키 래핑 알고리즘으로
CEK를 암호화한 결과임을 뜻한다:
+-----------------+-------------------------------------------------+
| "alg" 값 | 키 관리 알고리즘 |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | Concat KDF, "A128KW"로 랩핑한 ECDH-ES |
| ECDH-ES+A192KW | Concat KDF, "A192KW"로 랩핑한 ECDH-ES |
| ECDH-ES+A256KW | Concat KDF, "A256KW"로 랩핑한 ECDH-ES |
+-----------------+-------------------------------------------------+
4.6.1. ECDH 키 합의용 헤더 파라미터
다음 헤더 파라미터 명칭은 아래와 같이 키 합의에서 사용된다.
4.6.1.1. "epk"(Ephemeral Public Key) 헤더 파라미터
"epk"(임시 공개키) 값은 키 합의 알고리즘에 사용하기 위해 생성자의
임시 공개키를 의미한다. 이 키는 JSON Web Key [JWK] 공개키 값으로 표현된다.
반드시 공개키 파라미터만 포함해야 하며, 키 표현에 꼭 필요한 최소한의
JWK 파라미터만 담는 것이 좋다. 포함된 나머지 JWK 파라미터는 일관성 확인 후
채택하거나 무시할 수 있다. 이 헤더 파라미터는 반드시 존재해야 하며,
해당 알고리즘 사용 시 구현체에서 이해 후 처리해야 한다.
Jones Standards Track [Page 16]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.6.1.2. "apu"(Agreement PartyUInfo) 헤더 파라미터
"apu"(합의 PartyUInfo) 값은 이를 사용하는 키 합의 알고리즘
(예: "ECDH-ES")에 대해 base64url 인코딩 문자열로 표현된다.
사용시 PartyUInfo 값은 생성자의 정보를 담는다.
이 헤더 파라미터는 선택 사항이다. 이 파라미터가 사용될 때
구현체에서 이해 후 처리해야 한다.
4.6.1.3. "apv"(Agreement PartyVInfo) 헤더 파라미터
"apv"(합의 PartyVInfo) 값은 이를 사용하는 키 합의 알고리즘
(예: "ECDH-ES")에 대해 base64url 인코딩 문자열로 표현된다.
사용시 PartyVInfo 값은 수신자의 정보를 담는다.
이 헤더 파라미터는 선택 사항이다. 이 파라미터가 사용될 때
구현체에서 이해 후 처리해야 한다.
4.6.2. ECDH 키 합의용 키 도출
키 도출 과정은 ECDH 알고리즘을 통해 설정된 공유 비밀 Z로부터
합의된 키를 도출한다. [NIST.800-56A] 6.2.2.2절 참고.
키 도출은 [NIST.800-56A] 5.8.1절의 Concat KDF를 사용하여
수행되며, 다이제스트 방식으로는 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비트 빅엔디언 카운터이다. 직접 키 합의 시
Data에는 "enc" 헤더 파라미터 값의 ASCII 옥텟을,
키 합의 및 래핑 시에는 "alg"(알고리즘) 헤더 파라미터 값의 ASCII 옥텟을 사용한다.
Jones Standards Track [Page 17]
RFC 7518 JSON Web Algorithms (JWA) May 2015
PartyUInfo
PartyUInfo 값은 Datalen || Data이다. Data는 0개 이상의
옥텟으로 구성된 가변 길이 문자열, Datalen은 Data 길이(옥텟 단위)의
고정 길이 32비트 빅엔디언 값이다. "apu"(합의 PartyUInfo) 헤더 파라미터가 있으면,
Data는 "apu" 값을 base64url 디코딩한 결과를, Datalen은 옥텟 수를 사용.
없으면 Datalen은 0, Data는 빈 옥텟 시퀀스.
PartyVInfo
PartyVInfo 값은 Datalen || Data이다. Data는 0개 이상의
옥텟으로 구성된 가변 길이 문자열, Datalen은 Data 길이(옥텟 단위)의
고정 길이 32비트 빅엔디언 값이다. "apv"(합의 PartyVInfo) 헤더 파라미터가 있으면,
Data는 "apv" 값을 base64url 디코딩한 결과를, Datalen은 옥텟 수를 사용.
없으면 Datalen은 0, Data는 빈 옥텟 시퀀스.
SuppPubInfo
이는 keydatalen을 32비트 빅엔디언 정수로 표현한 값이다.
SuppPrivInfo
이는 빈 옥텟 시퀀스이다.
애플리케이션은 해당 용도에 "apu" 및 "apv" 헤더 파라미터 사용 방식을
명시해야 한다. "apu", "apv"는 같이 사용할 경우 반드시 서로 달라야 한다.
[NIST.800-56A] 준수를 원한다면, 생산자와 수신자를 식별할 수 있는
값을 쓰는 등 해당 문서 요건을 충족해야 한다. 또는 "Diffie-Hellman Key Agreement Method"
[RFC2631] 방식처럼 "apu"를 생략하거나,
512비트 난수값(PartyAInfo 역할)으로 주고 "apv"는 포함하지 않을 수 있다.
해당 방식 키 합의 연산 예시는 부록 C 참고.
4.7. AES GCM을 이용한 키 암호화
본 절에서는 고급 암호화 표준(AES)의 갈루아/카운터 모드(GCM)
([AES], [NIST.800-38D])로
JWE 콘텐츠 암호화 키(CEK)를 암호화하는 구체 사항을 정의한다.
Jones Standards Track [Page 18]
RFC 7518 JSON Web Algorithms (JWA) May 2015
이 알고리즘을 사용할 때는 96비트 크기의 초기화 벡터(IV) 사용이 필수입니다.
IV는 base64url로 인코딩되어 "iv"(초기화 벡터) 헤더 파라미터 값으로 나타냅니다.
추가 인증 데이터 값은 빈 옥텟 문자열입니다.
인증 태그 출력값의 요청 크기는 키 길이와 관계없이
반드시 128비트여야 합니다.
JWE 암호화 키 값은 암호문 출력값입니다.
인증 태그 출력값은 base64url로 인코딩되어
"tag"(인증 태그) 헤더 파라미터 값으로 나타냅니다.
JWE 암호화 키가 CEK를 해당 알고리즘 및 키 크기로 암호화한 결과임을 나타내기 위해
다음 "alg"(알고리즘) 헤더 파라미터 값을 사용합니다:
+-------------------+---------------------------------------------+
| "alg" Param Value | 키 관리 알고리즘 |
+-------------------+---------------------------------------------+
| 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"(초기화 벡터) 헤더 파라미터 값은
키 암호화 작업에 사용된 96비트 IV 값을 base64url로 인코딩한 표현입니다.
이 헤더 파라미터는 반드시 존재해야 하며,
해당 알고리즘을 사용할 때 구현체가 반드시 이해하고 처리해야 합니다.
4.7.1.2. "tag"(인증 태그) 헤더 파라미터
"tag"(인증 태그) 헤더 파라미터 값은
키 암호화 작업에서 생성된 128비트 인증 태그 값을 base64url로 인코딩한 표현입니다.
이 헤더 파라미터는 반드시 존재해야 하며,
해당 알고리즘을 사용할 때 구현체가 반드시 이해하고 처리해야 합니다.
Jones Standards Track [Page 19]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8. PBES2를 이용한 키 암호화
이 절에서는 사용자 제공 비밀번호로부터 PBES2 방식을 사용해
JWE CEK의 암호화용 키를 먼저 파생한 뒤,
파생된 키로 JWE CEK를 암호화하여,
비밀번호 기반 암호화 수행 세부사항을 정의합니다.
PBES2 방식은 [RFC2898] 6.2절에 정의되어 있습니다.
이 알고리즘들은 PBKDF2 키 파생 시 의사난수 함수(PRF)로 HMAC SHA-2 알고리즘을 사용하며,
암호화 방식에는 AES Key Wrap
[RFC3394]을 사용합니다. PBES2 비밀번호 입력은
옥텟 시퀀스이며, 사용해야 할 비밀번호가 옥텟 시퀀스가 아닌 텍스트 문자열로
표현된 경우에는 반드시 해당 문자열을 UTF-8로 인코딩하여 옥텟 시퀀스로 사용해야 합니다.
salt 파라미터는 반드시 아래 "p2s" 정의에 따라
"p2s"(PBES2 salt input) 헤더 파라미터 값과 "alg"(algorithm) 헤더 파라미터 값을
이용해 산출해야 합니다. 반복 횟수 파라미터는 반드시
"p2c"(PBES2 count) 헤더 파라미터 값으로 지정해야 합니다. 알고리즘들은 각각
PRF로 HMAC SHA-256, HMAC SHA-384, HMAC SHA-512를 사용하며,
128, 192, 256비트 AES Key Wrap 키를 사용합니다.
파생된 키의 길이는 각각 16, 24, 32 옥텟입니다.
JWE 암호화 키가 해당 비밀번호 기반 암호화 알고리즘의 결과를
키 암호화 키로 사용해 CEK를 암호화한 결과임을 나타내기 위해
다음 "alg"(알고리즘) 헤더 파라미터 값이 사용됩니다:
+--------------------+----------------------------------------------+
| "alg" Param Value | 키 관리 알고리즘 |
+--------------------+----------------------------------------------+
| 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 명세 부록 C [JWK]를 참조하세요.
4.8.1. PBES2 키 암호화에 사용되는 헤더 파라미터
다음 헤더 파라미터들은 PBES2를 이용한 키 암호화에 사용됩니다.
Jones Standards Track [Page 20]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8.1.1. "p2s"(PBES2 솔트 입력) 헤더 파라미터
"p2s"(PBES2 솔트 입력) 헤더 파라미터는
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 카운트) 헤더 파라미터는 PBKDF2 반복 횟수를
양수의 JSON 정수로 나타냅니다. 이 헤더 파라미터는 반드시 존재해야 하며,
해당 알고리즘을 사용할 때 반드시 구현체가 이해하고 처리해야 합니다.
반복 횟수는 계산비용을 늘려주며, 솔트가 가져오는 키의 범위와
결합하여 안전성을 높여줍니다. 반복 횟수는 최소 1000회를 권장합니다.
5. 콘텐츠 암호화를 위한 암호화 알고리즘
JWE는 본문을 암호화하고 무결성을 보호하며,
추가 인증 데이터의 무결성도 보호하기 위해
암호화 알고리즘을 사용합니다。
Jones Standards Track [Page 21]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.1. JWE의 "enc"(암호화 알고리즘) 헤더 파라미터 값
아래 표는 JWE에 사용하기 위해 이 명세서가 정의한
"enc"(암호화 알고리즘) 헤더 파라미터 값의 집합입니다.
+---------------+----------------------------------+----------------+
| "enc" Param | 콘텐츠 암호화 알고리즘 | 구현 요구사항 |
| Value | | |
+---------------+----------------------------------+----------------+
| 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 초기화 벡터 값을 사용하며,
JWE 암호문 및 JWE 인증 태그 값을 생성합니다.
이 명세서에서 정의한 JWE "enc"(암호화 알고리즘) 값과
타 규격/소프트웨어의 동등 식별자 매핑 표는 부록 A.3을 참고하세요.
5.2. AES_CBC_HMAC_SHA2 알고리즘
이 절에서는 AES [AES]를
Cipher Block Chaining(CBC) 모드 [NIST.800-38A]로,
패딩 작업에 [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 Standards Track [Page 22]
RFC 7518 JSON Web Algorithms (JWA) May 2015
이 알고리즘들은 "Authenticated Encryption with AES-
CBC and HMAC-SHA" [AEAD-CBC-SHA]를 기반으로 하며,
기본 암호연산은 동일하지만,
여기서는 초기화 벡터(IV)와 인증 태그 값을 암호문과 별개로 보관합니다.
(AEAD-CBC-SHA 규정의 부록 B 참조)
이 알고리즘 계열은 [AEAD-CBC-SHA] 알고리즘 계열의 일반화로,
해당 알고리즘 구현에도 사용할 수 있습니다.
5.2.1. AES_CBC_HMAC_SHA2 정의 방식 관례
다음 표기 관례를 사용합니다.
CBC-PKCS7-ENC(X, P)는 키 X로 PKCS #7 패딩을 적용해
AES-CBC로 P를 암호화한 것을 나타냅니다.
MAC(Y, M)은 키 Y로 메시지 M(MAC) 연산을 적용한 것입니다.
5.2.2. 일반화된 AES_CBC_HMAC_SHA2 알고리즘
이 절에서는 AES_CBC_HMAC_SHA2를
AES-CBC 키 길이와 해시 함수에 무관하게 정의합니다.
5.2.2.1, 5.2.2.2은 각각 일반화된 암호화/복호화 알고리즘을,
5.2.3~5.2.5는 그 세부 변형을 정의합니다.
5.2.2.1. AES_CBC_HMAC_SHA2 암호화
인증 암호화 알고리즘은 입력으로 네 옥텟 문자열, 즉 비밀키 K,
평문 P, 추가 인증 데이터 A, 초기화 벡터 IV를 받습니다.
출력으로 인증 암호문 E와 인증 태그 T를 산출합니다.
평문 데이터는 암호화와 인증이 되며,
추가 인증 데이터는 인증만 되고 암호화되지는 않습니다.
암호화 절차는 다음과 같거나, 이에 준하는 단계로 진행됩니다:
1. 보조 키 MAC_KEY, ENC_KEY는 K로부터 다음과 같이 만듭니다.
둘 다 옥텟 문자열입니다.
MAC_KEY는 K의 처음 MAC_KEY_LEN 바이트를 차례로 취합니다.
ENC_KEY는 K의 마지막 ENC_KEY_LEN 바이트를 차례로 취합니다.
Jones Standards Track [Page 23]
RFC 7518 JSON Web Algorithms (JWA) May 2015
입력 키 K의 옥텟 수는 반드시 MAC_KEY_LEN과 ENC_KEY_LEN의 합이어야 합니다.
이 파라미터 값은 5.2.3~5.2.5절에서 각 인증 암호화 알고리즘마다 달리 명시합니다.
입력 키 K 안에서는 MAC 키가 암호화 키보다 앞에 위치한다는 점에 유의해야 하며,
이는 식별자 "AES_CBC_HMAC_SHA2"의 알고리즘명 순서와는 반대입니다.
2. IV는 암호화에 사용할 128비트 값을 난수 또는 의사난수로 생성합니다.
3. 평문은 ENC_KEY를 키, IV를 초기화 벡터로 해서
PKCS #7 패딩을 적용한 뒤 CBC로 암호화됩니다.
이 단계에서 나온 암호문을 E라고 합니다.
4. 옥텟 문자열 AL은 추가 인증 데이터 A의 비트수를
64비트 부호 없는 빅엔디안 정수로 표현한 것입니다.
5. 다음 데이터를 차례로 HMAC([RFC2104])에 적용해
인증 태그 T를 계산합니다:
- 추가 인증 데이터 A,
- 초기화 벡터 IV,
- 이전 단계의 암호문 E,
- 위 정의된 AL 옥텟 문자열.
MAC_KEY 문자열은 MAC 키로 사용됩니다.
이 단계에서 계산된 MAC 값 M의 처음 T_LEN 바이트를 T로 삼습니다.
6. 암호문 E와 인증 태그 T를
인증 암호화의 출력값으로 반환합니다.
K(키), P(평문), A(추가 인증 데이터), IV, E(암호문) 변수가 있을 때
암호화 프로세스 예시는 아래와 같습니다.
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 Standards Track [Page 24]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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. 무결성과 진위 검증을 위해 5.2.2.1절 5단계와
동일한 입력을 사용해 HMAC 연산을 수행합니다.
이전 단계의 T 값은, HMAC 출력의 처음 MAC_KEY 길이 비트와 비교됩니다.
두 값이 동일하면 A와 E가 유효하다고 간주해 진행합니다.
일치하지 않으면 MAC 검증에 쓴 모든 데이터를 즉시 폐기하고,
인증 복호화 연산은 실패 신호와 함께 즉시 종료합니다.
(타이밍 공격 방지 관련 보안 주의는 [JWE] 11.5절 참조)
3. E 값을 복호화하고, PKCS #7 패딩 검증 및 제거를 합니다.
IV는 복호화용 초기화 벡터로, ENC_KEY는 복호화 키로 사용합니다.
4. 평문 값을 반환합니다.
5.2.3. AES_128_CBC_HMAC_SHA_256
이 알고리즘은 위의 일반화된 AES_CBC_HMAC_SHA2 알고리즘의
구체적 인스턴스 중 하나입니다.
메시지 인증에는 SHA-256 해시 함수를 사용하는 HMAC([RFC2104]),
결과값은 128비트로 잘린 HMAC-SHA-256-128([RFC4868])을 사용합니다.
암호화에는 [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 출력은 T_LEN=16바이트로 잘립니다(마지막 16바이트를 잘라냄).
Jones Standards Track [Page 25]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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 암호문 및 JWE 인증 태그 값을
계산했음을 나타냅니다:
+---------------+---------------------------------------------------+
| "enc" Param | 콘텐츠 암호화 알고리즘 |
| Value | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | 5.2.3절에 정의된 AES_128_CBC_HMAC_SHA_256 |
| | 인증 암호화 알고리즘 |
| A192CBC-HS384 | 5.2.4절에 정의된 AES_192_CBC_HMAC_SHA_384 |
| | 인증 암호화 알고리즘 |
| A256CBC-HS512 | 5.2.5절에 정의된 AES_256_CBC_HMAC_SHA_512 |
| | 인증 암호화 알고리즘 |
+---------------+---------------------------------------------------+
Jones Standards Track [Page 26]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.3. AES GCM을 사용한 콘텐츠 암호화
이 절에서는 Galois/Counter Mode(GCM) ([AES] 및
[NIST.800-38D])를 사용한 AES 인증 암호화의 세부사항을 정의합니다.
CEK는 암호화 키로 사용됩니다.
이 알고리즘에 96비트 크기의 IV 사용은 필수입니다.
인증 태그 출력값의 요청 크기는 키 길이와 상관없이 반드시
128비트여야 합니다.
다음 "enc"(암호화 알고리즘) 헤더 파라미터 값들은
해당 알고리즘과 키 길이를 사용해 JWE 암호문 및 JWE 인증 태그가
계산되었음을 나타냅니다:
+-------------------+------------------------------+
| "enc" Param Value | 콘텐츠 암호화 알고리즘 |
+-------------------+------------------------------+
| A128GCM | 128비트 키를 사용하는 AES GCM |
| A192GCM | 192비트 키를 사용하는 AES GCM |
| A256GCM | 256비트 키를 사용하는 AES GCM |
+-------------------+------------------------------+
이 알고리즘의 예시는 [JWE] 부록 A.1에 나와 있습니다.
6. 키를 위한 암호화 알고리즘
JSON Web Key (JWK) [JWK]는 암호화 키를 나타내는
JSON 데이터 구조입니다. 이 키는 비대칭 또는 대칭일 수 있습니다.
공개 및 개인 정보를 모두 포함할 수 있습니다.
이 절에서는 이 문서에서 명시한 알고리즘을 사용하는
키의 파라미터를 정의합니다.
Jones Standards Track [Page 27]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.1. "kty"(키 유형) 파라미터 값
아래 표는 JWK에서 사용하기 위해
이 명세서가 정의한 "kty"(키 유형) 파라미터 값의 집합입니다.
+-------------+--------------------------------+--------------------+
| "kty" Param | 키 유형 | 구현 요구사항 |
| Value | | |
+-------------+--------------------------------+--------------------+
| 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 Standards Track [Page 28]
RFC 7518 JSON Web Algorithms (JWA) May 2015
이 값들은 7.6절에 정의된 IANA "JSON Web Key Elliptic Curve"
레지스트리에 등록되어 있습니다. 추가 "crv" 값은
다른 명세서에 의해 등록될 수 있습니다. 추가 곡선을 등록하는
명세서는, 등록된 곡선에서 키를 표현하기 위해 사용하는
파라미터를 정의해야 합니다. "crv" 값은 대소문자 구분 문자열입니다.
SEC1 [SEC1] 포인트 압축은
이 세 곡선 모두에서 지원되지 않습니다.
6.2.1.2. "x"(X 좌표) 파라미터
"x"(x 좌표) 파라미터는 타원 곡선 점의 x좌표입니다.
이는 SEC1 2.3.5절에 정의된 좌표의 옥텟 문자열 표현을
base64url로 인코딩한 것입니다. 이 옥텟 문자열의 길이는
"crv" 파라미터에 지정된 곡선의 좌표 크기와 동일해야 합니다.
예를 들어 "crv" 값이 "P-521"이면, 옥텟 문자열 길이는 66바이트여야 합니다.
6.2.1.3. "y"(Y 좌표) 파라미터
"y"(y 좌표) 파라미터는 타원 곡선 점의 y좌표입니다.
이는 SEC1 2.3.5절에 정의된 좌표의 옥텟 문자열 표현을
base64url로 인코딩한 것입니다. 이 옥텟 문자열의 길이는
"crv" 파라미터에 지정된 곡선의 좌표 크기와 동일해야 합니다.
예를 들어 "crv" 값이 "P-521"이면, 옥텟 문자열 길이는 66바이트여야 합니다.
6.2.2. 타원 곡선 개인키를 위한 파라미터
타원 곡선 공개키 표현에 사용되는 멤버에 더해,
다음 멤버가 반드시 있어야 타원 곡선 개인키를 표현할 수 있습니다.
6.2.2.1. "d"(ECC 개인키) 파라미터
"d"(ECC 개인키) 파라미터는
타원 곡선 개인키 값을 포함합니다. 이는
SEC1 2.3.7절에 정의된 개인키 값의 옥텟 문자열 표현을
base64url로 인코딩한 것입니다. 이 옥텟 문자열의 길이는
반드시 ceiling(log-base-2(n)/8) 바이트여야 합니다(n은 곡선의 차수).
Jones Standards Track [Page 29]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3. RSA 키용 파라미터
JWK는 RSA [RFC3447] 키를 표현할 수 있습니다. 이 경우
"kty" 멤버 값은 "RSA"가 됩니다. 아래에 정의된 파라미터의 의미는
3.1절 및 3.2절, RFC 3447에서 정의된 것과 동일합니다.
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 Standards Track [Page 30]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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"(기타 소인수 정보) 파라미터는
세 번째 및 그 이후의 소인수에 대한 정보를 담은 배열입니다.
두 개의 소인수만 사용한 경우(일반적) 이 파라미터는 생략해야 하며,
세 개 이상을 사용한 경우 배열 요소 개수는 사용된 소인수의 수에서
둘을 뺀 값이어야 합니다. 이 경우의 자세한 내용은
RFC 3447 부록 A.1.2 [RFC3447]의 OtherPrimeInfo 파라미터 설명을 참고하세요.
JWK 소비자가 두 개 초과 소인수 개인키를 지원하지 않으면서
"oth" 파라미터가 있는 개인키를 발견하면,
반드시 해당 키를 사용해서는 안 됩니다. 각 배열 요소는
다음 멤버들을 가진 객체여야 합니다.
6.3.2.7.1. "r"(소인수)
"oth" 배열 멤버 내 "r"(소인수) 파라미터는
이후 소인수의 값을 나타내며,
Base64urlUInt 방식으로 인코딩됩니다.
Jones Standards Track [Page 31]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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]를 따릅니다. 단, 명세가 발행되기 전에 값 할당이
필요한 경우 지정 전문가가 해당 명세가 발행될 것이라고
확신할 때 등록 승인 가능함을 허용합니다.
리뷰를 위해 메일링 리스트에 전송한 등록 요청은
적절한 제목(e.g., "Request to register algorithm: example")을 써야 합니다.
검토 기간 중 지정 전문가는 등록 요청을 승인하거나 거부하며,
이 결정을 리뷰 리스트와 IANA에 통보합니다. 거부 시에는
설명과, 해당 요청을 성공시키기 위한 제안(가능하다면)도 포함합니다.
Jones Standards Track [Page 32]
RFC 7518 JSON Web Algorithms (JWA) May 2015
21일보다 긴 기간 동안 미정 상태인 등록 요청은
IESG(iesg@ietf.org)에게 알릴 수 있습니다.
지정 전문가는 제안된 등록이 기존 기능과 중복되는지,
일반적 적용 가능성 또는 단일 애플리케이션에만 유용한지,
등록 설명이 명확한지 등을 판단하는 기준을 적용해야 합니다.
IANA는 지정 전문가로부터의 레지스트리 갱신만을 받아야 하며,
모든 등록 요청을 리뷰 메일 리스트로 전달해야 합니다.
여러 애플리케이션 관점을 대표할 수 있는 복수 지정 전문가를
임명해서, 다양한 정보 기반 검토가 이루어지도록 하는 것이 권장됩니다.
만약 등록 결정이 특정 전문가에게 이해 상충으로 여겨질 수 있다면,
해당 전문가는 다른 전문가의 판단을 존중해야 합니다.
7.1. JSON Web Signature 및 암호화 알고리즘 레지스트리
이 명세서는 JWS와 JWE의 "alg"(알고리즘), "enc"(암호화 알고리즘)
헤더 파라미터 값의 IANA "JSON Web Signature and Encryption Algorithms"
레지스트리를 설정합니다. 이 레지스트리는 알고리즘 이름, 설명,
사용 위치, 구현 요구사항, 변경 관리자를 기록하고,
정의 명세 문서의 참조를 남깁니다. 같은 알고리즘 이름이 여럿 등록될 수는 있지만,
사용 위치 집합이 서로 겹치지 않아야 합니다.
여러 키 길이 변형 알고리즘을 등록할 때,
각 키 길이가 고정되어야 하거나(예: 키 유도 함수로 생성),
알고리즘 이름에 반드시 길이를 포함하는 것을 추천합니다.
이를 통해 JSON 문서를 보는 사람이 쉽게 보안 결정을 내릴 수 있습니다.
지정 전문가는 등록되는 알고리즘이
현재 암호학적으로 신뢰할만하거나, Deprecated/Prohibited 상태인지
적정 수준으로 검토해야 합니다.
Jones Standards Track [Page 33]
RFC 7518 JSON Web Algorithms (JWA) May 2015
알고리즘의 구현 요구사항은 시간이 지남에 따라 암호 환경 변화에 맞춰
변경될 수 있습니다. 예를 들어, 알고리즘 상태를 Deprecated로 바꾸거나,
Optional에서 Recommended+ 또는 Required로 변경할 수 있습니다.
구현 요구사항 변경은 지정 전문가의 리뷰 및 새로운 명세 정의에서만
"명세 필요(Specification Required)" 방식으로 허용됩니다.
7.1.1. 등록 양식(템플릿)
알고리즘 이름:
요청한 이름(e.g., "HS256"). 대소문자 구분 ASCII 문자열입니다.
Designated Experts가 예외 사유가 있다고 판단하지 않는 한,
이름은 대소문자 구분 없이 다른 등록 이름과 겹칠 수 없습니다.
알고리즘 설명:
알고리즘에 대한 간단 설명(e.g., "HMAC using SHA-256").
알고리즘 사용 위치:
알고리즘 사용 위치. JWS 또는 JWE에서 사용할 경우 "alg" 또는 "enc" 중
하나 이상이어야 합니다. JWK에서만 알고리즘 식별자에 쓸 경우(예: 비인증 암호화
알고리즘), "JWK" 값을 사용합니다. 다른 값은 지정 전문가 승인 하에 사용 가능.
JOSE 구현 요구사항:
JWS/JWE 적용시 구현 요구 수준으로 필수(Required), 권장(Recommended),
선택(Optional), 폐지(Deprecated), 금지(Prohibited)의 단어 중 하나로 기재합니다.
옵션으로 "+" 또는 "-"를 뒤에 붙일 수 있습니다.
"+"는 요구 강도가 앞으로 더 높아질 수 있음을,
"-"는 줄어들 수 있음을 나타냅니다.
비인증 암호화 알고리즘 등 JWS/JWE에 부적합한 알고리즘은
반드시 "Prohibited"로 등록해야 합니다.
변경 관리자:
Standards Track RFC의 경우 "IESG"를 기재합니다.
기타의 경우 책임자 이름을 씁니다.
(우편 주소, 이메일, 홈페이지 URI 등 추가 세부 정보도 포함 가능)
Jones Standards Track [Page 34]
RFC 7518 JSON Web Algorithms (JWA) May 2015
명세 문서:
파라미터를 명시한 문서의 참조.
가능한 한 사본을 얻을 수 있는 URI도 포함할 것.
해당 절 정보도 포함될 수 있으나 필수는 아님.
알고리즘 분석 문서:
등록 알고리즘의 암호적 안전성을 분석한
권위있는 학회, 국가 표준기관, 기타 권위기관의 출판물 참조.
지정 전문가는, Deprecated 또는 Prohibited로 등록되는 것이 아니라면
신규 알고리즘 등록 요청 시 암호적 안전성의 신뢰할만한 근거 제시를
요구할 수 있습니다. 이 문서에서 최초로 등록되는 항목들은
작업그룹과 IETF 리뷰를 거쳤으므로 해당 정보 제출 의무가 면제됩니다.
7.1.2. 초기 레지스트리 내용
o 알고리즘 이름: "HS256"
o 알고리즘 설명: HMAC(SHA-256 사용)
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구사항: 필수
o 변경 관리자: IESG
o 명세 문서: RFC 7518 3.2절
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "HS384"
o 알고리즘 설명: HMAC(SHA-384 사용)
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구사항: 선택
o 변경 관리자: IESG
o 명세 문서: RFC 7518 3.2절
o 알고리즘 분석 문서: 해당 없음
o 알고리즘 이름: "HS512"
o 알고리즘 설명: HMAC(SHA-512 사용)
o 알고리즘 사용 위치: "alg"
o JOSE 구현 요구사항: 선택
o 변경 관리자: IESG
o 명세 문서: RFC 7518 3.2절
o 알고리즘 분석 문서: 해당 없음
Jones Standards Track [Page 35]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "RS256"
o 알고리즘 설명: SHA-256을 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 3.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "RS384"
o 알고리즘 설명: SHA-384을 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "RS512"
o 알고리즘 설명: SHA-512을 사용하는 RSASSA-PKCS1-v1_5
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ES256"
o 알고리즘 설명: P-256 및 SHA-256을 사용하는 ECDSA
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장+
o 변경 제어자: IESG
o 명세 문서(들): Section 3.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ES384"
o 알고리즘 설명: P-384 및 SHA-384을 사용하는 ECDSA
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ES512"
o 알고리즘 설명: P-521 및 SHA-512을 사용하는 ECDSA
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 36]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "PS256"
o 알고리즘 설명: SHA-256 및 SHA-256을 사용하는 MGF1과 함께 RSASSA-PSS
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.5 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "PS384"
o 알고리즘 설명: SHA-384 및 SHA-384을 사용하는 MGF1과 함께 RSASSA-PSS
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.5 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "PS512"
o 알고리즘 설명: SHA-512 및 SHA-512을 사용하는 MGF1과 함께 RSASSA-PSS
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.5 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "none"
o 알고리즘 설명: 디지털 서명 또는 MAC 미실시
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 3.6 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "RSA1_5"
o 알고리즘 설명: RSAES-PKCS1-v1_5
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장-
o 변경 제어자: IESG
o 명세 문서(들): Section 4.2 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 37]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "RSA-OAEP"
o 알고리즘 설명: 기본 매개변수를 사용하는 RSAES OAEP
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장+
o 변경 제어자: IESG
o 명세 문서(들): Section 4.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "RSA-OAEP-256"
o 알고리즘 설명: SHA-256 및 SHA-256을 사용하는 MGF1과 함께 RSAES OAEP
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A128KW"
o 알고리즘 설명: 128비트 키를 사용하는 AES 키 랩
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 4.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A192KW"
o 알고리즘 설명: 192비트 키를 사용하는 AES 키 랩
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A256KW"
o 알고리즘 설명: 256비트 키를 사용하는 AES 키 랩
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 4.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "dir"
o 알고리즘 설명: 공유 대칭 키의 직접 사용
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 4.5 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 38]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "ECDH-ES"
o 알고리즘 설명: Concat KDF를 사용하는 ECDH-ES
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장+
o 변경 제어자: IESG
o 명세 문서(들): Section 4.6 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ECDH-ES+A128KW"
o 알고리즘 설명: Concat KDF와 "A128KW" 래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 4.6 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ECDH-ES+A192KW"
o 알고리즘 설명: Concat KDF와 "A192KW" 래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.6 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "ECDH-ES+A256KW"
o 알고리즘 설명: Concat KDF와 "A256KW" 래핑을 사용하는 ECDH-ES
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 4.6 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A128GCMKW"
o 알고리즘 설명: 128비트 키를 사용하는 AES GCM을 이용한 키 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.7 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 39]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "A192GCMKW"
o 알고리즘 설명: 192비트 키를 사용하는 AES GCM을 이용한 키 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.7 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A256GCMKW"
o 알고리즘 설명: 256비트 키를 사용하는 AES GCM을 이용한 키 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.7 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "PBES2-HS256+A128KW"
o 알고리즘 설명: HMAC SHA-256을 사용하는 PBES2와 "A128KW" 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.8 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "PBES2-HS384+A192KW"
o 알고리즘 설명: HMAC SHA-384을 사용하는 PBES2와 "A192KW" 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.8 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "PBES2-HS512+A256KW"
o 알고리즘 설명: HMAC SHA-512를 사용하는 PBES2와 "A256KW" 래핑
o 알고리즘 사용 위치(들): "alg"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 4.8 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 40]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "A128CBC-HS256"
o 알고리즘 설명: AES_128_CBC_HMAC_SHA_256 인증된 암호화 알고리즘
o 알고리즘 사용 위치(들): "enc"
o JOSE 구현 요구사항: 필수
o 변경 제어자: IESG
o 명세 문서(들): Section 5.2.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A192CBC-HS384"
o 알고리즘 설명: AES_192_CBC_HMAC_SHA_384 인증된 암호화 알고리즘
o 알고리즘 사용 위치(들): "enc"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 5.2.4 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A256CBC-HS512"
o 알고리즘 설명: AES_256_CBC_HMAC_SHA_512 인증된 암호화 알고리즘
o 알고리즘 사용 위치(들): "enc"
o JOSE 구현 요구사항: 필수
o 변경 제어자: IESG
o 명세 문서(들): Section 5.2.5 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A128GCM"
o 알고리즘 설명: 128비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치(들): "enc"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서(들): Section 5.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
o 알고리즘 이름: "A192GCM"
o 알고리즘 설명: 192비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치(들): "enc"
o JOSE 구현 요구사항: 선택 사항
o 변경 제어자: IESG
o 명세 문서(들): Section 5.3 of RFC 7518
o 알고리즘 분석 문서(들): 해당 없음
Jones Standards Track [Page 41]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 알고리즘 이름: "A256GCM"
o 알고리즘 설명: 256비트 키를 사용하는 AES GCM
o 알고리즘 사용 위치: "enc"
o JOSE 구현 요구사항: 권장
o 변경 제어자: IESG
o 명세 문서: Section 5.3 of RFC 7518
o 알고리즘 분석 문서: 해당 없음
7.2. 헤더 매개변수 이름 등록
이 섹션은 이 명세서의 Sections
4.6.1, 4.7.1, 및 4.8.1에 정의된 헤더 매개변수 이름을 IANA "JSON Web
Signature and Encryption Header Parameters" 레지스트리에 등록합니다.
[JWS].
7.2.1. 레지스트리 내용
o 헤더 매개변수 이름: "epk"
o 헤더 매개변수 설명: 임시 공개 키
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.6.1.1 of RFC 7518
o 헤더 매개변수 이름: "apu"
o 헤더 매개변수 설명: 합의 당사자 U 정보
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.6.1.2 of RFC 7518
o 헤더 매개변수 이름: "apv"
o 헤더 매개변수 설명: 합의 당사자 V 정보
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.6.1.3 of RFC 7518
o 헤더 매개변수 이름: "iv"
o 헤더 매개변수 설명: 초기화 벡터
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.7.1.1 of RFC 7518
o 헤더 매개변수 이름: "tag"
o 헤더 매개변수 설명: 인증 태그
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.7.1.2 of RFC 7518
Jones Standards Track [Page 42]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 헤더 매개변수 이름: "p2s"
o 헤더 매개변수 설명: PBES2 솔트 입력
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.8.1.1 of RFC 7518
o 헤더 매개변수 이름: "p2c"
o 헤더 매개변수 설명: PBES2 카운트
o 헤더 매개변수 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: Section 4.8.1.2 of RFC 7518
7.3. JSON Web Encryption 압축 알고리즘 레지스트리
이 명세서는 JWE "zip" 멤버 값에 대한 IANA "JSON Web Encryption
Compression Algorithms" 레지스트리를 설정합니다. 레지스트리는
압축 알고리즘 값과 그것을 정의하는 명세에 대한 참조를 기록합니다.
7.3.1. 등록 템플릿
압축 알고리즘 값:
요청된 이름(예: "DEF"). 이 명세의 핵심 목표 중 하나는
결과 표현을 간결하게 하는 것이므로, 특별한 이유가 없는 한
이름은 8자를 초과하지 않는 것이 권장됩니다. 이 이름은
대/소문자를 구분합니다. 이름은 지정된 전문가가 예외 사유가
있다고 판단하지 않는 한 대소문자를 구분하지 않는 방식으로
다른 등록된 이름과 일치할 수 없습니다.
압축 알고리즘 설명:
압축 알고리즘에 대한 간단한 설명(예: "DEFLATE").
변경 제어자:
스탠다드 트랙 RFC의 경우 "IESG"를 기재합니다. 기타의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부사항(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함될 수 있습니다.
명세 문서:
매개변수를 지정하는 문서에 대한 참조로, 가능한 경우 문서 사본을
가져오는 데 사용될 수 있는 URI를 포함하는 것이 좋습니다.
관련 섹션을 표시할 수도 있지만 필수는 아닙니다.
Jones Standards Track [Page 43]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.3.2. 초기 레지스트리 내용
o 압축 알고리즘 값: "DEF"
o 압축 알고리즘 설명: DEFLATE
o 변경 제어자: IESG
o 명세 문서: JSON Web Encryption (JWE) [JWE]
7.4. JSON Web Key 유형 레지스트리
이 명세서는 JWK "kty" 매개변수 값에 대한 IANA "JSON Web Key Types" 레지스트리를
설정합니다. 레지스트리는 "kty" 값, 구현 요구사항 및 해당 값을
정의하는 명세에 대한 참조를 기록합니다.
키 유형의 구현 요구사항은 암호학 환경의 변화에 따라 시간이 지남에
따라 변경될 수 있습니다. 예를 들어, 키 유형의 상태를 사용중단으로
변경하거나 구현 요구사항의 상태를 Optional에서 Recommended+ 또는
Required로 변경할 수 있습니다. 구현 요구사항의 변경은 지정된
전문가의 검토 후 새 명세가 개정된 구현 요구사항 수준을 정의하는
경우에만 Specification Required 방식으로 허용됩니다.
7.4.1. 등록 템플릿
"kty" 매개변수 값:
요청된 이름(예: "EC"). 이 명세의 핵심 목표 중 하나는
결과 표현을 간결하게 하는 것이므로, 특별한 이유가 없는 한
이름은 8자를 초과하지 않는 것이 권장됩니다. 이 이름은
대/소문자를 구분합니다. 이름은 지정된 전문가가 예외 사유가
있다고 판단하지 않는 한 대소문자를 구분하지 않는 방식으로
다른 등록된 이름과 일치할 수 없습니다.
키 유형 설명:
키 유형에 대한 간단한 설명(예: "Elliptic Curve").
변경 제어자:
스탠다드 트랙 RFC의 경우 "IESG"를 기재합니다. 기타의 경우에는
책임 당사자의 이름을 기재합니다. 기타 세부사항(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함될 수 있습니다.
Jones Standards Track [Page 44]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JOSE 구현 요구사항:
JWS 및 JWE에 대한 키 유형 구현 요구사항으로, 반드시 Required(필수),
Recommended(권장), Optional(선택), Deprecated(사용중단) 또는
Prohibited(금지) 중 하나여야 합니다. 선택적으로 단어 뒤에 "+" 또는
"-"가 올 수 있습니다. "+"는 향후 명세 버전에서 요구 강도가
증가할 가능성이 있음을 나타내고, "-"는 요구 강도가 향후 버전에서
감소할 가능성이 있음을 나타냅니다.
명세 문서:
매개변수를 지정하는 문서에 대한 참조로, 가능한 경우 문서 사본을
가져오는 데 사용될 수 있는 URI를 포함하는 것이 좋습니다.
관련 섹션을 표시할 수도 있지만 필수는 아닙니다.
7.4.2. 초기 레지스트리 내용
이 섹션은 Section 6.1에 정의된 값을 등록합니다.
o "kty" 매개변수 값: "EC"
o 키 유형 설명: 타원 곡선
o JOSE 구현 요구사항: 권장+
o 변경 제어자: IESG
o 명세 문서: Section 6.2 of RFC 7518
o "kty" 매개변수 값: "RSA"
o 키 유형 설명: RSA
o JOSE 구현 요구사항: 필수
o 변경 제어자: IESG
o 명세 문서: Section 6.3 of RFC 7518
o "kty" 매개변수 값: "oct"
o 키 유형 설명: 옥텟 시퀀스
o JOSE 구현 요구사항: 필수
o 변경 제어자: IESG
o 명세 문서: Section 6.4 of RFC 7518
7.5. JSON Web Key 매개변수 등록
이 섹션은 이 명세서의 6.2,
6.3, 및 6.4에 정의된 매개변수 이름을 IANA "JSON Web Key
Parameters" 레지스트리에 등록합니다. [JWK]
Jones Standards Track [Page 45]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.5.1. 레지스트리 내용
o 매개변수 이름: "crv"
o 매개변수 설명: 곡선
o 사용되는 "kty" 값: "EC"
o 매개변수 정보 분류: 공개
o 변경 제어자: IESG
o 명세 문서: Section 6.2.1.1 of RFC 7518
o 매개변수 이름: "x"
o 매개변수 설명: X 좌표
o 사용되는 "kty" 값: "EC"
o 매개변수 정보 분류: 공개
o 변경 제어자: IESG
o 명세 문서: Section 6.2.1.2 of RFC 7518
o 매개변수 이름: "y"
o 매개변수 설명: Y 좌표
o 사용되는 "kty" 값: "EC"
o 매개변수 정보 분류: 공개
o 변경 제어자: IESG
o 명세 문서: Section 6.2.1.3 of RFC 7518
o 매개변수 이름: "d"
o 매개변수 설명: ECC 개인 키
o 사용되는 "kty" 값: "EC"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.2.2.1 of RFC 7518
o 매개변수 이름: "n"
o 매개변수 설명: 모듈러스
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.1.1 of RFC 7518
o 매개변수 이름: "e"
o 매개변수 설명: 지수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.1.2 of RFC 7518
Jones Standards Track [Page 46]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 매개변수 이름: "d"
o 매개변수 설명: 개인 지수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.1 of RFC 7518
o 매개변수 이름: "p"
o 매개변수 설명: 첫 번째 소수 인수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.2 of RFC 7518
o 매개변수 이름: "q"
o 매개변수 설명: 두 번째 소수 인수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.3 of RFC 7518
o 매개변수 이름: "dp"
o 매개변수 설명: 첫 번째 인수 CRT 지수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.4 of RFC 7518
o 매개변수 이름: "dq"
o 매개변수 설명: 두 번째 인수 CRT 지수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.5 of RFC 7518
o 매개변수 이름: "qi"
o 매개변수 설명: 첫 번째 CRT 계수
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.6 of RFC 7518
Jones Standards Track [Page 47]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 매개변수 이름: "oth"
o 매개변수 설명: 기타 소수 정보
o 사용되는 "kty" 값: "RSA"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.3.2.7 of RFC 7518
o 매개변수 이름: "k"
o 매개변수 설명: 키 값
o 사용되는 "kty" 값: "oct"
o 매개변수 정보 분류: 비공개
o 변경 제어자: IESG
o 명세 문서: Section 6.4.1 of RFC 7518
7.6. JSON Web Key 타원 곡선 레지스트리
이 섹션은 JWK "crv" 멤버 값에 대한 IANA "JSON Web Key Elliptic Curve"
레지스트리를 설정합니다. 레지스트리는 곡선 이름, 구현 요구사항,
및 해당 곡선을 정의하는 명세에 대한 참조를 기록합니다. 이 명세서는
Section 6.2.1.1에 정의된 매개변수 이름을 등록합니다.
곡선의 구현 요구사항은 암호학 환경의 변화에 따라 시간이 지남에
따라 변경될 수 있습니다. 예를 들어, 곡선의 상태를 사용중단으로
변경하거나 구현 요구사항의 상태를 Optional에서 Recommended+ 또는
Required로 변경할 수 있습니다. 구현 요구사항의 변경은 지정된
전문가의 검토 후 새 명세가 개정된 구현 요구사항 수준을 정의하는
경우에만 Specification Required 방식으로 허용됩니다.
7.6.1. 등록 템플릿
곡선 이름:
요청된 이름(예: "P-256"). 이 명세의 핵심 목표 중 하나는
결과 표현을 간결하게 하는 것이므로, 특별한 이유가 없는 한
이름은 8자를 초과하지 않는 것이 권장됩니다. 이 이름은
대/소문자를 구분합니다. 이름은 지정된 전문가가 예외 사유가
있다고 판단하지 않는 한 대소문자를 구분하지 않는 방식으로
다른 등록된 이름과 일치할 수 없습니다.
곡선 설명:
곡선에 대한 간단한 설명(예: "P-256 곡선").
JOSE 구현 요구사항:
JWS 및 JWE에 대한 곡선 구현 요구사항으로, 반드시 Required(필수),
Recommended(권장), Optional(선택), Deprecated(사용중단) 또는
Prohibited(금지) 중 하나여야 합니다. 선택적으로 단어 뒤에 "+" 또는
"-"가 올 수 있습니다.
Jones Standards Track [Page 48]
RFC 7518 JSON Web Algorithms (JWA) May 2015
"+"의 사용은 요구사항의 강도가 향후 명세 버전에서
증가될 가능성이 있음을 나타냅니다. "-"의 사용은 요구사항의
강도가 향후 명세 버전에서 감소될 가능성이 있음을 나타냅니다.
변경 관리자:
Standards Track RFC의 경우 "IESG"를 기재하십시오. 다른 경우에는
책임자의 이름을 기재하십시오. 추가 세부사항(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함될 수 있습니다.
명세 문서:
매개변수를 명시하는 문서 또는 문서들에 대한 참조로서,
문서 사본을 가져오기 위해 사용할 수 있는 URI를 포함하는 것이
바람직합니다. 관련 섹션의 표시를 포함할 수도 있으나 필수는
아닙니다.
7.6.2. Initial Registry Contents
o Curve Name: "P-256"
o Curve Description: P-256 Curve
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-384"
o Curve Description: P-384 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-521"
o Curve Description: P-521 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
8. 보안 고려사항
모든 암호화 응용프로그램과 관련된 보안 문제는 JWS/JWE/JWK 에이전트에
의해 다루어져야 합니다. 이러한 문제에는 사용자의 비대칭 개인 키와
대칭 비밀 키를 보호하고 다양한 공격에 대한 대응책을 적용하는 것이
포함됩니다.
[AES], [DSS], [JWE], [JWK], [JWS],
[NIST.800-38D], [NIST.800-56A], [NIST.800-107], [RFC2104], [RFC3394],
[RFC3447], [RFC5116], [RFC6090], and [SHS]의 보안 고려사항이
이 명세에 적용됩니다.
Jones Standards Track [Page 49]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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에 있는 제약을 따라야 합니다. 또한 "Twenty Years of Attacks on the
RSA Cryptosystem"의 섹션 3에 설명된 바와 같이
낮은 공개 지수 값을 가진 키는 사용해서는 안 됩니다 [Boneh99].
8.4. AES GCM 보안 고려사항
AES GCM과 함께 사용되는 키는 [NIST.800-38D]의 섹션 8.3에 있는 제약을 따라야 합니다. 해당 문서는 다음과 같이 명시합니다: "주어진 키로 인증된 암호화 함수를 호출한 총 횟수는 모든 IV 길이와 해당 키로 수행된 모든 인스턴스를 포함하여 2^32를 초과해서는 안 된다". 이 규칙에 따라 AES GCM은 동일한 키 값으로 2^32번을 초과하여 사용해서는 안 됩니다.
IV 값은 동일한 AES GCM 키와 함께 여러 번 사용되어서는 안 됩니다. 이를 방지하는 한 가지 방법은 키와 함께 카운터를 저장하고 사용 시마다 증가시키는 것입니다. 이 카운터는 위의 2^32 제한을 초과하지 않도록 하는 데에도 사용할 수 있습니다.
이 보안 고려사항은 복합 AES-CBC HMAC SHA-2 또는 AES Key Wrap 알고리듬에는 적용되지 않습니다.
Jones Standards Track [Page 50]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.5. 보안되지 않은 JWS에 대한 보안 고려사항
보안되지 않은 JWS들( "alg" 값으로 "none"을 사용하는 JWS)은 무결성
보호를 제공하지 않습니다. 따라서 페이로드가 디지털 서명이나 MAC 값
이외의 수단으로 보호되는 문맥에서만 사용되어야 하거나 보호가 필요하지
않은 경우에만 사용되어야 합니다.
보안되지 않은 JWS의 수락을 기본적으로 방지하는 한 가지 예는 가상의
JWS 소프트웨어 라이브러리의 "verify" 메서드가 "none"이 허용 가능한
"alg" 값임을 나타내는 불리언 "acceptUnsecured" 매개변수를 갖도록
하는 것입니다. 또 다른 예로, "verify" 메서드는 애플리케이션에서
허용되는 알고리즘 목록을 매개변수로 받아 "none"이 그 목록에 없다면
보안되지 않은 JWS 값을 거부할 수 있습니다.
다음 예시는 전역 수준에서 보안되지 않은 JWS를 수락하지 않아야 하는
이유를 설명합니다. 애플리케이션이 두 개의 채널, (1) HTTP 및 (2) 클라이언트
인증이 있는 HTTPS를 통해 JWS를 수락한다고 가정해 보십시오. 애플리케이션은
HTTP로 수신된 객체에 대해 JWS 서명을 요구하지만 HTTPS를 통해서는
보안되지 않은 JWS를 허용합니다. 만약 애플리케이션이 전역적으로 "none"을
허용한다고 표시한다면 공격자는 HTTP를 통해 보안되지 않은 JWS를 제공하여도
해당 객체가 성공적으로 검증될 수 있습니다. 대신 애플리케이션은 HTTPS로
수신된 각 객체에 대해 "none"의 수락을 명시해야 합니다(예: 위의 가상 JWS
소프트웨어 라이브러리에 대해 "acceptUnsecured"를 "true"로 설정), 그러나
HTTP로 수신된 각 객체에 대해서는 그러할 필요가 없습니다.
8.6. 서비스 거부(DoS) 공격
서명을 검증하는 수신 에이전트와 메시지를 암호화하는 송신 에이전트는
서명 검증 및 암호화 시 명세에서 요구하는 것보다 더 큰 키를 사용하여
수행되는 암호화 처리의 사용량에 주의해야 합니다. 공격자는 과도한
암호화 처리를 야기할 수 있는 큰 키를 사용하여 콘텐츠를 제공할 수
있습니다(예: 본 명세에서 요구하는 것보다 큰 키). 구현체는 허용하는
키 크기에 대한 상한을 설정하고 적용해야 합니다. NIST SP 800-57의
섹션 5.6.1 (Comparable Algorithm Strengths)에는
적용될 수 있는 최대 승인 키 크기에 관한 진술이 포함되어 있습니다.
8.7. 키를 암호화할 때 키 재사용
여러 JWK 또는 JWK Set 객체를 암호화하거나 동일한 JWK 또는 JWK Set
객체를 여러 번 암호화하기 위해 동일한 전체 키 재료 집합(키 암호화 키,
콘텐츠 암호화 키, 초기화 벡터 등)을 재사용하는 것은 권장되지 않습니다.
한 가지 제안은
Jones Standards Track [Page 51]
RFC 7518 JSON Web Algorithms (JWA) May 2015
재사용을 방지하기 위해 각 암호화 연산마다 적어도 하나의 새로운 키
재료(예: 새로운 콘텐츠 암호화 키, 새로운 IV 및/또는 새로운 PBES2 Salt)를
항상 생성할 것을 권장합니다. 이는 본 문서에 기재된 고려사항들과
RFC 4086 [RFC4086]의 권고 사항을 기반으로 합니다.
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 Standards Track [Page 52]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[Boneh99] "Twenty Years of Attacks on the RSA Cryptosystem", Notices
of the American Mathematical Society (AMS), Vol. 46,
No. 2, pp. 203-213, 1999, <http://crypto.stanford.edu/
~dabo/pubs/papers/RSA-survey.pdf>.
Jones Standards Track [Page 53]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[DSS] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4, July
2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[NIST.800-38A]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", NIST
Special Publication 800-38A, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[NIST.800-56A]
National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[NIST.800-57]
National Institute of Standards and Technology (NIST),
"Recommendation for Key Management - Part 1: General
(Revision 3)", NIST Special Publication 800-57, Part 1,
Revision 3, July 2012, <http://csrc.nist.gov/publications/
nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
Jones Standards Track [Page 54]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
Jones Standards Track [Page 55]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009,
<http://www.secg.org/sec1-v2.pdf>.
[SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
10.2. Informative References
[AEAD-CBC-SHA]
McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", Work in Progress,
draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[CanvasApp]
Facebook, "Canvas Applications", 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JCA] Oracle, "Java Cryptography Architecture (JCA) Reference
Guide", 2014, <http://docs.oracle.com/javase/8/docs/techno
tes/guides/security/crypto/CryptoSpec.html>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", Work in Progress,
draft-rescorla-jsms-00, March 2011.
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign 1.0",
Draft 01, September 2010, <http://jsonenc.info/jss/1.0/>.
Jones Standards Track [Page 56]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[JWE-JWK] Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK)
Objects", Work in Progress,
draft-miller-jose-jwe-protected-jwk-02, June 2013.
[MagicSignatures]
Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[NIST.800-107]
National Institute of Standards and Technology (NIST),
"Recommendation for Applications Using Approved Hash
Algorithms", NIST Special Publication 800-107, Revision 1,
August 2012, <http://csrc.nist.gov/publications/
nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-63-2]
National Institute of Standards and Technology (NIST),
"Electronic Authentication Guideline", NIST Special
Publication 800-63-2, August 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-2.pdf>.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Work in Progress,
draft-ietf-precis-saslprepbis-16, April 2015.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
Jones Standards Track [Page 57]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<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., and S. Cantor, "XML Signature
Syntax and Processing Version 2.0", World Wide Web
Consortium Note NOTE-xmldsig-core2-20130411, April 2013,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium Recommendation REC-xmlenc-
core1-20130411, April 2013,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones Standards Track [Page 58]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix A. Algorithm Identifier Cross-Reference
This appendix contains tables cross-referencing the cryptographic
algorithm identifier values defined in this specification with the
equivalent identifiers used by other standards and software packages.
See 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], and Java Cryptography Architecture
[JCA] for more information about the names defined by those
documents.
Jones Standards Track [Page 59]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.1. Digital Signature/MAC Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.
+-------------------------------------------------------------------+
| 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 Standards Track [Page 60]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.2. Key Management Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
identifiers used by other standards and software packages.
+-------------------------------------------------------------------+
| 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 Standards Track [Page 61]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.3. Content Encryption Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "enc"
(encryption algorithm) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and
"A256CBC-HS512", the corresponding AES-CBC algorithm identifiers are
listed.
+-------------------------------------------------------------------+
| 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 |
+-------------------------------------------------------------------+
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 5.2. They are
also intended to correspond to test cases that may appear in a future
version of [AEAD-CBC-SHA], demonstrating that the cryptographic
computations performed are the same.
The variable names are those defined in Section 5.2. All values are
hexadecimal.
Jones Standards Track [Page 62]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.1. Test Cases for 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 Standards Track [Page 63]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.2. Test Cases for 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 Standards Track [Page 64]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.3. Test Cases for 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 Standards Track [Page 65]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix C. Example ECDH-ES Key Agreement Computation
This example uses ECDH-ES Key Agreement and the Concat KDF to derive
the CEK in the manner described in Section 4.6. In this example, the
ECDH-ES Direct Key Agreement mode ("alg" value "ECDH-ES") is used to
produce an agreed-upon key for AES GCM with a 128-bit key ("enc"
value "A128GCM").
In this example, a producer Alice is encrypting content to a consumer
Bob. The producer (Alice) generates an ephemeral key for the key
agreement computation. Alice's ephemeral key (in JWK format) used
for the key agreement computation in this example (including the
private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
}
The consumer's (Bob's) key (in JWK format) used for the key agreement
computation in this example (including the private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
Header Parameter values used in this example are as follows. The
"apu" (agreement PartyUInfo) Header Parameter value is the base64url
encoding of the UTF-8 string "Alice" and the "apv" (agreement
PartyVInfo) Header Parameter value is the base64url encoding of the
UTF-8 string "Bob". The "epk" (ephemeral public key) Header
Parameter is used to communicate the producer's (Alice's) ephemeral
public key value to the consumer (Bob).
Jones Standards Track [Page 66]
RFC 7518 JSON Web Algorithms (JWA) May 2015
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
The resulting Concat KDF [NIST.800-56A] parameter values are:
Z
This is set to the ECDH-ES key agreement output. (This value is
often not directly exposed by libraries, due to NIST security
requirements, and only serves as an input to a KDF.) In this
example, Z is following the octet sequence (using JSON array
notation):
[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
This value is 128 - the number of bits in the desired output key
(because "A128GCM" uses a 128-bit key).
AlgorithmID
This is set to the octets representing the 32-bit big-endian value
7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content
"A128GCM", followed, by the octets representing the ASCII string
"A128GCM" - [65, 49, 50, 56, 71, 67, 77].
PartyUInfo
This is set to the octets representing the 32-bit big-endian value
5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content
"Alice", followed, by the octets representing the UTF-8 string
"Alice" - [65, 108, 105, 99, 101].
PartyVInfo
This is set to the octets representing the 32-bit big-endian value
3 - [0, 0, 0, 3] - the number of octets in the PartyUInfo content
"Bob", followed, by the octets representing the UTF-8 string "Bob"
- [66, 111, 98].
Jones Standards Track [Page 67]
RFC 7518 JSON Web Algorithms (JWA) May 2015
SuppPubInfo
This is set to the octets representing the 32-bit big-endian value
128 - [0, 0, 0, 128] - the keydatalen value.
SuppPrivInfo
This is set to the empty octet sequence.
Concatenating the parameters AlgorithmID through SuppPubInfo results
in an OtherInfo value of:
[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]
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo
value results in the Concat KDF round 1 hash input of:
[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]
The resulting derived key, which is the first 128 bits of the round 1
hash output is:
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26]
The base64url-encoded representation of this derived key is:
VqqN6vgjbSBcIijNcacQGg
Jones Standards Track [Page 68]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Acknowledgements
Solutions for signing and encrypting JSON content were previously
explored by "Magic Signatures" [MagicSignatures], "JSON Simple Sign
1.0" [JSS], "Canvas Applications" [CanvasApp], "JSON Simple
Encryption" [JSE], and "JavaScript Message Security Format" [JSMS],
all of which influenced this document.
The "Authenticated Encryption with AES-CBC and HMAC-SHA"
[AEAD-CBC-SHA] specification, upon which the AES_CBC_HMAC_SHA2
algorithms are based, was written by David A. McGrew and Kenny
Paterson. The test cases for AES_CBC_HMAC_SHA2 are based upon those
for [AEAD-CBC-SHA] by John Foley.
Matt Miller wrote "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects"
[JWE-JWK], upon which the password-based encryption content of this
document is based.
This specification is the work of the JOSE working group, which
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
that influenced this specification:
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 and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security Area Directors during the creation of this specification.
Author's Address
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Jones Standards Track [Page 69]