[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON 웹 서명 (JWS)
요약
JSON 웹 서명(JWS)은 JSON 기반 데이터 구조를 사용하여 디지털
서명 또는 메시지 인증 코드(MAC)로 보호된 콘텐츠를 나타낸다.
이 명세와 함께 사용하기 위한 암호 알고리즘과 식별자는 별도의
JSON 웹 알고리즘(JWA) 명세와 해당 명세에서 정의된 IANA 레지스트리에
기술되어 있다. 관련된 암호화 기능은 별도의 JSON 웹 암호화(JWE)
명세에 기술되어 있다.
이 메모의 상태
본 문서는 인터넷 표준 트랙 문서이다.
본 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며
인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 출판 승인을
받았다. 인터넷 표준에 대한 추가 정보는
RFC 5741의 섹션 2에서 확인할 수 있다.
본 문서의 현재 상태, 정오표, 그리고 이에 대한 피드백 제공 방법에
대한 정보는 다음에서 확인할 수 있다.
http://www.rfc-editor.org/info/rfc7515.
Jones, et al. Standards Track [Page 1]
RFC 7515 JSON Web Signature (JWS) May 2015
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.
목차
1. 서론 ....................................................4
1.1. 표기 규약 .....................................4
2. 용어 .....................................................5
3. JSON 웹 서명(JWS) 개요 ...............................7
3.1. JWS Compact 직렬화 개요 .........................7
3.2. JWS JSON 직렬화 개요 ............................8
3.3. JWS 예제 ................................................8
4. JOSE 헤더 .....................................................9
4.1. 등록된 헤더 매개변수 이름 .........................10
4.1.1. "alg"(알고리즘) 헤더 매개변수 .................10
4.1.2. "jku"(JWK 세트 URL) 헤더 매개변수 ...............10
4.1.3. "jwk"(JSON 웹 키) 헤더 매개변수 ..............11
4.1.4. "kid"(키 ID) 헤더 매개변수 ....................11
4.1.5. "x5u"(X.509 URL) 헤더 매개변수 .................11
4.1.6. "x5c"(X.509 인증서 체인) 헤더 매개변수 ...11
4.1.7. "x5t"(X.509 인증서 SHA-1 지문)
헤더 매개변수 ...................................12
4.1.8. "x5t#S256"(X.509 인증서 SHA-256
지문) 헤더 매개변수 .......................12
4.1.9. "typ"(타입) 헤더 매개변수 ......................12
4.1.10. "cty"(콘텐츠 타입) 헤더 매개변수 .............13
4.1.11. "crit"(중요) 헤더 매개변수 ................14
4.2. 공개 헤더 매개변수 이름 .............................14
4.3. 개인 헤더 매개변수 이름 ............................14
5. JWS 생성 및 소비 ...................................15
5.1. 메시지 서명 또는 MAC 계산 ......................15
5.2. 메시지 서명 또는 MAC 검증 .......................16
5.3. 문자열 비교 규칙 ...................................17
6. 키 식별 .............................................18
Jones, et al. Standards Track [Page 2]
RFC 7515 JSON Web Signature (JWS) May 2015
7. 직렬화 .................................................19
7.1. JWS Compact 직렬화 .................................19
7.2. JWS JSON 직렬화 ....................................19
7.2.1. 일반 JWS JSON 직렬화 구문 ..............20
7.2.2. 평탄화된 JWS JSON 직렬화 구문 ............21
8. TLS 요구사항 ...............................................22
9. IANA 고려사항 ............................................22
9.1. JSON 웹 서명 및 암호화 헤더
매개변수 레지스트리 .......................................23
9.1.1. 등록 템플릿 ..............................23
9.1.2. 초기 레지스트리 내용 ..........................24
9.2. 미디어 타입 등록 ...................................26
9.2.1. 레지스트리 내용 ..................................26
10. 보안 고려사항 .......................................27
10.1. 키 엔트로피 및 난수 값 ............................27
10.2. 키 보호 ...........................................28
10.3. 키 출처 인증 ................................28
10.4. 암호 민첩성 ....................................28
10.5. 디지털 서명과 MAC 간의 차이 ..........28
10.6. 알고리즘 검증 .....................................29
10.7. 알고리즘 보호 .....................................29
10.8. 선택 평문 공격 .................................30
10.9. 타이밍 공격 ...........................................30
10.10. 재생 공격 방지 .......................................30
10.11. SHA-1 인증서 지문 ...........................30
10.12. JSON 보안 고려사항 ............................31
10.13. 유니코드 비교 보안 고려사항 ..............31
11. 참고문헌 ....................................................32
11.1. 규범적 참고문헌 .....................................32
11.2. 정보 제공 참고문헌 ...................................34
부록 A. JWS 예제 .........................................36
A.1. HMAC SHA-256을 사용하는 JWS 예제 ............................36
A.1.1. 인코딩 ..............................................36
A.1.2. 검증 ............................................38
A.2. RSASSA-PKCS1-v1_5 SHA-256을 사용하는 JWS 예제 ...............38
A.2.1. 인코딩 ..............................................38
A.2.2. 검증 ............................................42
A.3. ECDSA P-256 SHA-256을 사용하는 JWS 예제 .....................42
A.3.1. 인코딩 ..............................................42
A.3.2. 검증 ............................................44
A.4. ECDSA P-521 SHA-512를 사용하는 JWS 예제 .....................45
A.4.1. 인코딩 ..............................................45
A.4.2. 검증 ............................................47
A.5. 서명되지 않은 JWS 예제 .....................................47
A.6. 일반 JWS JSON 직렬화를 사용하는 JWS 예제 ..........48
A.6.1. 서명별 보호된 JWS 헤더 ...................48
A.6.2. 서명별 비보호 JWS 헤더 .................49
A.6.3. 완전한 JOSE 헤더 값 ...........................49
Jones, et al. Standards Track [Page 3]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 완전한 JWS JSON 직렬화 표현 ........50
A.7. 평탄화된 JWS JSON 직렬화를 사용하는 JWS 예제 ........51
부록 B. "x5c"(X.509 인증서 체인) 예제 ..............52
부록 C. 패딩 없는 base64url 인코딩 구현에 대한 참고 사항
..............................................54
부록 D. 키 선택에 대한 참고 사항 ...............................55
부록 E. "crit" 헤더 매개변수에 대한 부정 테스트 케이스 .......57
부록 F. 분리된 콘텐츠 .....................................57
감사의 글 ..................................................58
저자 주소 ................................................58
1. 서론
JSON 웹 서명(JWS)은 JSON 기반
[RFC7159] 데이터 구조를 사용하여 디지털
서명 또는 메시지 인증 코드(MAC)로 보호된 콘텐츠를 나타낸다.
JWS 암호 메커니즘은 임의의 옥텟 시퀀스에 대해 무결성 보호를 제공한다.
디지털 서명과 MAC 간의 차이에 대한 논의는
섹션 10.5를 참조하라.
JWS에 대해 두 가지의 밀접하게 관련된 직렬화 형식이 정의되어 있다.
JWS Compact 직렬화는 HTTP Authorization 헤더나
URI 쿼리 매개변수와 같은 공간 제약 환경을 위한
간결하고 URL 안전한 표현이다.
JWS JSON 직렬화는 JWS를 JSON 객체로 표현하며,
동일한 콘텐츠에 대해 여러 서명 및/또는 MAC을 적용할 수 있게 한다.
두 형식은 동일한 암호학적 기반을 공유한다.
본 명세와 함께 사용하기 위한 암호 알고리즘과 식별자는
별도의 JSON 웹 알고리즘(JWA)
[JWA] 명세와
해당 명세에서 정의된 IANA 레지스트리에 기술되어 있다.
관련된 암호화 기능은 별도의 JSON 웹 암호화(JWE)
[JWE] 명세에 기술되어 있다.
본 명세에서 정의된 이름들이 짧은 이유는,
결과 표현이 간결해지는 것을 핵심 목표로 하기 때문이다.
1.1. 표기 규약
본 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
"OPTIONAL"이라는 핵심 단어는
RFC에서 요구 수준을 나타내기 위해 사용하는 키워드에 관한 문서
[RFC2119]에
기술된 대로 해석되어야 한다.
이러한 해석은 해당 용어가 모두 대문자로 표시된 경우에만 적용된다.
BASE64URL(OCTETS)는
섹션 2에 따라 OCTETS의 base64url 인코딩을 의미한다.
Jones, et al. Standards Track [Page 4]
RFC 7515 JSON Web Signature (JWS) May 2015
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)
디지털 서명되었거나 MAC 처리된 메시지를 나타내는 데이터 구조.
JOSE Header
사용된 암호 연산 및 매개변수를 설명하는 매개변수를 포함하는
JSON 객체.
JOSE(JSON Object Signing and Encryption) 헤더는
헤더 매개변수들의 집합으로 구성된다.
JWS Payload
보호되어야 할 옥텟 시퀀스 — 즉 메시지.
페이로드는 임의의 옥텟 시퀀스를 포함할 수 있다.
JWS Signature
JWS 보호된 헤더와 JWS 페이로드에 대한
디지털 서명 또는 MAC.
Header Parameter
JOSE 헤더의 구성원인 이름/값 쌍.
JWS Protected Header
JWS 서명 디지털 서명 또는 MAC 연산에 의해
무결성 보호되는 헤더 매개변수를 포함하는 JSON 객체.
JWS Compact 직렬화의 경우,
이는 전체 JOSE 헤더를 구성한다.
JWS JSON 직렬화의 경우,
이는 JOSE 헤더의 한 구성 요소이다.
JWS Unprotected Header
무결성 보호되지 않는 헤더 매개변수를 포함하는 JSON 객체.
이는 JWS JSON 직렬화를 사용하는 경우에만 존재할 수 있다.
Jones, et al. Standards Track [Page 5]
RFC 7515 JSON Web Signature (JWS) May 2015
Base64url 인코딩
RFC 4648의 섹션 5 [RFC4648]에 정의된
URL 및 파일명에 안전한 문자 집합을 사용하는 Base64 인코딩으로,
( 섹션 3.2에서 허용된 대로) 모든 뒤따르는 '=' 문자를
생략하고, 줄 바꿈, 공백 또는 기타 추가 문자를 포함하지 않는다.
빈 옥텟 시퀀스의 base64url 인코딩은 빈 문자열임에 유의하라.
(패딩 없이 base64url 인코딩을 구현하는 데 대한 참고 사항은
부록 C를 참조하라.)
JWS 서명 입력(JWS Signing Input)
디지털 서명 또는 MAC 계산에 대한 입력.
그 값은
ASCII(BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드))이다.
JWS Compact 직렬화
JWS를 간결하고 URL-안전한 문자열로 표현한 것.
JWS JSON 직렬화
JWS를 JSON 객체로 표현한 것.
JWS Compact 직렬화와 달리, JWS JSON 직렬화는
동일한 콘텐츠에 대해 여러 개의 디지털 서명 및/또는 MAC을
적용할 수 있게 한다.
이 표현은 간결성에 최적화되어 있지 않으며 URL-안전하지도 않다.
보안되지 않은 JWS(Unsecured JWS)
무결성 보호를 제공하지 않는 JWS.
보안되지 않은 JWS는 "alg" 값으로 "none"을 사용한다.
충돌 방지 이름(Collision-Resistant Name)
다른 이름과 충돌할 가능성이 매우 낮도록
이름을 할당할 수 있게 하는 네임스페이스 내의 이름.
충돌 방지 네임스페이스의 예로는 도메인 이름,
ITU-T X.660 및 X.670 권고 시리즈에 정의된 객체 식별자(OID),
그리고 전역 고유 식별자(UUID)
[RFC4122]가 있다.
관리적으로 위임된 네임스페이스를 사용하는 경우,
이름을 정의하는 주체는 자신이 이름을 정의하는 데 사용하는
네임스페이스의 부분을 통제하고 있음을 보장하기 위해
합리적인 예방 조치를 취할 필요가 있다.
StringOrURI
JSON 문자열 값으로,
임의의 문자열 값을 사용할 수 있으나,
":" 문자를 포함하는 모든 값은 반드시 URI
[RFC3986]여야 한다는 추가 요구사항이 있다.
StringOrURI 값은 어떠한 변환이나 정규화도 적용하지 않고
대소문자를 구분하는 문자열로 비교된다.
Jones, et al. Standards Track [Page 6]
RFC 7515 JSON Web Signature (JWS) May 2015
"JSON Web Encryption (JWE)", "JWE Compact Serialization",
및 "JWE JSON Serialization"이라는 용어는
JWE 사양
[JWE]에 의해 정의된다.
"디지털 서명(Digital Signature)"과
"메시지 인증 코드(Message Authentication Code, MAC)"라는 용어는
“Internet Security Glossary, Version 2”
[RFC4949]에 의해 정의된다.
3. JSON Web Signature (JWS) 개요
JWS는 JSON 데이터 구조와 base64url 인코딩을 사용하여
디지털 서명되었거나 MAC이 적용된 콘텐츠를 표현한다.
이러한 JSON 데이터 구조는
RFC 7159의 섹션 2
[RFC7159]에 따라,
JSON 값이나 구조 문자 앞이나 뒤에 공백 및/또는 줄 바꿈을
포함할 수 있다.
JWS는 다음의 논리적 값들을 표현한다
(각각은 섹션 2에 정의되어 있다):
o JOSE 헤더
o JWS 페이로드
o JWS 서명
JWS의 경우, JOSE 헤더의 멤버는
다음 값들의 멤버들의 합집합이다
(각각은 섹션 2에 정의되어 있다):
o JWS 보호된 헤더
o JWS 비보호 헤더
이 문서는 JWS에 대해 두 가지 직렬화를 정의한다:
JWS Compact 직렬화라고 불리는
간결하고 URL-안전한 직렬화와,
JWS JSON 직렬화라고 불리는 JSON 직렬화이다.
두 직렬화 모두에서,
JSON은 임의의 옥텟 시퀀스를 직접 표현하는 방법이 없기 때문에,
JWS 보호된 헤더, JWS 페이로드, JWS 서명은
base64url로 인코딩된다.
3.1. JWS Compact 직렬화 개요
JWS Compact 직렬화에서는
JWS 비보호 헤더를 사용하지 않는다.
이 경우 JOSE 헤더와 JWS 보호된 헤더는 동일하다.
JWS Compact 직렬화에서,
JWS는 다음을 연결한 것으로 표현된다:
BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드) || '.' ||
BASE64URL(JWS 서명)
JWS Compact 직렬화에 대한 추가 정보는
섹션 7.1을 참조하라.
Jones, et al. Standards Track [Page 7]
RFC 7515 JSON Web Signature (JWS) May 2015
3.2. JWS JSON 직렬화 개요
JWS JSON 직렬화에서는
JWS 보호된 헤더와 JWS 비보호 헤더 중
하나 또는 둘 모두가 반드시 존재해야 한다.
이 경우 JOSE 헤더의 멤버는,
존재하는 JWS 보호된 헤더와
JWS 비보호 헤더 값의 멤버들의 합집합이다.
JWS JSON 직렬화에서,
JWS는 다음 네 가지 멤버 중
일부 또는 전부를 포함하는 JSON 객체로 표현된다:
o "protected": 값은 BASE64URL(UTF8(JWS 보호된 헤더))
o "header": 값은 JWS 비보호 헤더
o "payload": 값은 BASE64URL(JWS 페이로드)
o "signature": 값은 BASE64URL(JWS 서명)
base64url로 인코딩된 세 개의 결과 문자열과
JWS 비보호 헤더 값은
JSON 객체의 멤버로 표현된다.
이러한 값들 중 일부의 포함은 선택 사항이다.
JWS JSON 직렬화는
하나만이 아니라 여러 개의 서명 및/또는 MAC 값을
표현할 수도 있다.
JWS JSON 직렬화에 대한 추가 정보는
섹션 7.2를 참조하라.
3.3. JWS 예제
이 절에서는 JWS의 예제를 제공한다.
그 계산 과정은,
사용된 JSON 값들을 표현하는 정확한 옥텟 시퀀스와
사용된 키 값을 포함하여,
부록 A.1에 더 자세히 설명되어 있다.
다음 예제의 JWS 보호된 헤더는,
인코딩된 객체가 JSON Web Token임을 선언하며
[JWT],
JWS 보호된 헤더와 JWS 페이로드가
HMAC SHA-256
[RFC2104]
[SHS]
알고리즘을 사용하여 보호됨을 나타낸다:
{"typ":"JWT",
"alg":"HS256"}
이 JWS 보호된 헤더를
BASE64URL(UTF8(JWS 보호된 헤더))로 인코딩하면
다음 값을 얻는다:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
다음 JSON 객체의 UTF-8 표현이
JWS 페이로드로 사용된다.
(페이로드는 어떤 콘텐츠든 될 수 있으며,
반드시 JSON 객체의 표현일 필요는 없다.)
Jones, et al. Standards Track [Page 8]
RFC 7515 JSON Web Signature (JWS) May 2015
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
이 JWS 페이로드를
BASE64URL(JWS 페이로드)로 인코딩하면
다음 값을 얻는다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
부록 A.1에 지정된 키를 사용하여
HMAC SHA-256 알고리즘으로
JWS 서명 입력
ASCII(BASE64URL(UTF8(JWS 보호된 헤더)) || '.' || BASE64URL(JWS 페이로드))
에 대한 HMAC을 계산하고,
그 결과를 base64url로 인코딩하면
다음 BASE64URL(JWS 서명) 값을 얻는다:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이러한 값들을
Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 두고 연결하면,
다음과 같은
JWS Compact 직렬화를 사용하는
완전한 JWS 표현을 얻게 된다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
JWS JSON 직렬화를 사용하는 예제를 포함한
추가 예제는
부록 A를 참조하라
(섹션 A.6 및 A.7 참조).
4. JOSE 헤더
JWS의 경우,
JOSE 헤더를 표현하는 JSON 객체의 멤버들은,
JWS 보호된 헤더와 JWS 페이로드에 적용된
디지털 서명 또는 MAC과,
선택적으로 JWS의 추가 속성들을 설명한다.
JOSE 헤더 내의 헤더 파라미터 이름은 반드시 고유해야 하며,
JWS 파서는
중복된 헤더 파라미터 이름을 가진 JWS를 거부하거나,
ECMAScript 5.1
[ECMAScript]
의
섹션 15.12
(“JSON 객체”)에 명시된 대로,
사전적으로 마지막에 나타난 중복 멤버 이름만을 반환하는
JSON 파서를 사용해야 한다.
구현은,
이 사양에서
“반드시 이해되어야 함(MUST be understood)”으로
지정된 특정 헤더 파라미터를 이해하고,
이 사양에 정의된 방식으로 처리해야 한다.
이 사양에 정의된 다른 모든 헤더 파라미터 중,
그러한 지정이 없는 것들은,
이해되지 않을 경우 반드시 무시되어야 한다.
Jones, et al. Standards Track [Page 9]
RFC 7515 JSON Web Signature (JWS) May 2015
섹션 4.1.11에 따라
중요한(critical) 헤더 파라미터로 나열되지 않는 한,
이 사양에 정의되지 않은 모든 헤더 파라미터는,
이해되지 않을 경우 반드시 무시되어야 한다.
헤더 파라미터 이름에는
세 가지 분류가 있다:
등록된 헤더 파라미터 이름,
공개 헤더 파라미터 이름,
그리고 개인 헤더 파라미터 이름이다.
4.1. 등록된 헤더 파라미터 이름
JWS에서 사용하기 위한 다음 헤더 파라미터 이름들은,
섹션 9.1에 의해 설정된
IANA “JSON Web Signature and Encryption Header Parameters”
레지스트리에 등록되어 있으며,
그 의미는 아래의 하위 절들에 정의되어 있다.
공통 레지스트리에 표시된 바와 같이,
JWS와 JWE는 공통의 헤더 파라미터 공간을 공유한다.
하나의 파라미터가 두 사양 모두에서 사용되는 경우,
그 사용 방식은 두 사양 간에 호환되어야 한다.
4.1.1. "alg"(알고리즘) 헤더 파라미터
"alg"(알고리즘) 헤더 파라미터는
JWS를 보호하는 데 사용된
암호학적 알고리즘을 식별한다.
"alg" 값이 지원되는 알고리즘을 나타내지 않거나,
해당 알고리즘을 사용하기 위한 키가
콘텐츠를 디지털 서명하거나 MAC 처리한 주체와
연관되어 있지 않은 경우,
JWS 서명 값은 유효하지 않다.
"alg" 값은
[JWA]에 의해 설정된
IANA “JSON Web Signature and Encryption Algorithms”
레지스트리에 등록되거나,
충돌 방지 이름을 포함하는 값이어야 한다.
"alg" 값은
StringOrURI 값을 포함하는,
대소문자를 구분하는 ASCII 문자열이다.
이 헤더 파라미터는 반드시 존재해야 하며,
구현에 의해 반드시 이해되고 처리되어야 한다.
이 용도를 위해 정의된 "alg" 값의 목록은,
[JWA]에 의해 설정된
IANA “JSON Web Signature and Encryption Algorithms”
레지스트리에서 찾을 수 있으며,
이 레지스트리의 초기 내용은
[JWA]의
섹션 3.1에 정의된 값들이다.
4.1.2. "jku"(JWK 세트 URL) 헤더 파라미터
"jku"(JWK 세트 URL) 헤더 파라미터는,
JWS를 디지털 서명하는 데 사용된 키에 대응하는,
JSON으로 인코딩된 공개 키들의 집합을 위한 리소스를
가리키는 URI이다
[RFC3986].
키들은 반드시 JWK 세트로 인코딩되어야 한다
[JWK].
해당 리소스를 획득하는 데 사용되는 프로토콜은
무결성 보호를 제공해야 하며,
JWK 세트를 검색하기 위한 HTTP GET 요청은
전송 계층 보안(Transport Layer Security)을 사용해야 한다.
Jones, et al. Standards Track [Page 10]
RFC 7515 JSON Web Signature (JWS) May 2015
(TLS) [RFC2818] [RFC5246]; 그리고 서버의 신원은
RFC 6125의 섹션 6
[RFC6125]에 따라
반드시 검증되어야 한다. 또한 TLS 요구 사항에 대해서는
섹션 8을 참조하라. 이 헤더 파라미터의 사용은
선택 사항이다.
4.1.3. "jwk" (JSON Web Key) 헤더 파라미터
"jwk"(JSON Web Key) 헤더 파라미터는
JWS를 디지털 서명하는 데 사용된 키에 대응하는 공개 키이다.
이 키는 JSON Web Key로 표현된다
[JWK].
이 헤더 파라미터의 사용은 선택 사항이다.
4.1.4. "kid" (키 ID) 헤더 파라미터
"kid"(키 ID) 헤더 파라미터는
JWS를 보호하는 데 사용된 키가 무엇인지를 나타내는 힌트이다.
이 파라미터는 발신자가 수신자에게
키 변경을 명시적으로 알릴 수 있게 한다.
"kid" 값의 구조는 지정되어 있지 않다.
그 값은 대소문자를 구분하는 문자열이어야 한다.
이 헤더 파라미터의 사용은 선택 사항이다.
JWK와 함께 사용될 경우,
"kid" 값은 JWK의 "kid" 파라미터 값과 매칭하는 데 사용된다.
4.1.5. "x5u" (X.509 URL) 헤더 파라미터
"x5u"(X.509 URL) 헤더 파라미터는,
JWS를 디지털 서명하는 데 사용된 키에 대응하는
X.509 공개 키 인증서 또는 인증서 체인을 위한 리소스를
가리키는 URI이다
[RFC3986].
식별된 리소스는
RFC 5280
[RFC5280]을 준수하는,
PEM 인코딩 형식의 인증서 또는 인증서 체인 표현을
반드시 제공해야 하며,
각 인증서는
RFC 4945의 섹션 6.1
[RFC4945]에 명시된 대로 구분되어야 한다.
JWS를 디지털 서명하는 데 사용된 키에 대응하는 공개 키를
포함하는 인증서는 반드시 첫 번째 인증서여야 한다.
그 뒤에 추가 인증서가 올 수 있으며,
각 후속 인증서는 이전 인증서를 인증하는 데 사용된
인증서여야 한다.
해당 리소스를 획득하는 데 사용되는 프로토콜은
무결성 보호를 제공해야 하며,
인증서를 검색하기 위한 HTTP GET 요청은
TLS
[RFC2818]
[RFC5246]를
반드시 사용해야 한다.
또한 서버의 신원은
RFC 6125의 섹션 6
[RFC6125]에 따라
반드시 검증되어야 한다.
TLS 요구 사항에 대해서는
섹션 8도 참조하라.
이 헤더 파라미터의 사용은 선택 사항이다.
4.1.6. "x5c" (X.509 인증서 체인) 헤더 파라미터
"x5c"(X.509 인증서 체인) 헤더 파라미터는,
JWS를 디지털 서명하는 데 사용된 키에 대응하는
X.509 공개 키 인증서 또는 인증서 체인을 포함한다
[RFC5280].
인증서 또는 인증서 체인은
인증서 값 문자열들의 JSON 배열로 표현된다.
Jones, et al. Standards Track [Page 11]
RFC 7515 JSON Web Signature (JWS) May 2015
배열 내의 각 문자열은
base64로 인코딩된
([RFC4648]의 섹션 4 -- base64url 인코딩 아님)
DER
[ITU.X690.2008]
PKIX 인증서 값이다.
JWS를 디지털 서명하는 데 사용된 키에 대응하는 공개 키를
포함하는 인증서는 반드시 첫 번째 인증서여야 한다.
그 뒤에 추가 인증서가 올 수 있으며,
각 후속 인증서는 이전 인증서를 인증하는 데 사용된
인증서여야 한다.
수신자는
RFC 5280
[RFC5280]에 따라
인증서 체인을 검증해야 하며,
검증 실패가 발생할 경우
해당 인증서 또는 인증서 체인을
유효하지 않은 것으로 간주해야 한다.
이 헤더 파라미터의 사용은 선택 사항이다.
"x5c" 값의 예제는
부록 B를 참조하라.
4.1.7. "x5t" (X.509 인증서 SHA-1 지문) 헤더 파라미터
"x5t"(X.509 인증서 SHA-1 지문) 헤더 파라미터는,
JWS를 디지털 서명하는 데 사용된 키에 대응하는
X.509 인증서의 DER 인코딩에 대한
base64url로 인코딩된 SHA-1 지문
(일명 다이제스트)이다
[RFC5280].
인증서 지문은
인증서 핑거프린트라고도 불린다.
이 헤더 파라미터의 사용은 선택 사항이다.
4.1.8. "x5t#S256" (X.509 인증서 SHA-256 지문) 헤더
파라미터
"x5t#S256"(X.509 인증서 SHA-256 지문) 헤더 파라미터는,
JWS를 디지털 서명하는 데 사용된 키에 대응하는
X.509 인증서의 DER 인코딩에 대한
base64url로 인코딩된 SHA-256 지문
(일명 다이제스트)이다
[RFC5280].
인증서 지문은
인증서 핑거프린트라고도 불린다.
이 헤더 파라미터의 사용은 선택 사항이다.
4.1.9. "typ" (타입) 헤더 파라미터
"typ"(타입) 헤더 파라미터는,
JWS 애플리케이션이
이 완전한 JWS의 미디어 타입을 선언하는 데 사용된다
[IANA.MediaTypes].
이는 JWS를 포함할 수 있는 애플리케이션 데이터 구조 내에
하나 이상의 객체 종류가 존재할 수 있는 경우에,
애플리케이션이 서로 다른 객체 종류를
구분할 수 있도록 하기 위한 것이다.
객체의 종류가 이미 알려져 있는 경우에는,
일반적으로 애플리케이션에서 사용되지 않는다.
이 파라미터는 JWS 구현에서는 무시되며,
이 파라미터에 대한 모든 처리는
JWS 애플리케이션에 의해 수행된다.
이 헤더 파라미터의 사용은 선택 사항이다.
RFC 2045
[RFC2045]에 따라,
모든 미디어 타입 값, 서브타입 값, 그리고
파라미터 이름은 대소문자를 구분하지 않는다.
그러나 파라미터 값은,
특정 파라미터에 대해 달리 지정되지 않는 한,
대소문자를 구분한다.
Jones, et al. Standards Track [Page 12]
RFC 7515 JSON Web Signature (JWS) May 2015
일반적인 상황에서 메시지를 간결하게 유지하기 위해,
미디어 타입 값에 '/' 문자가 더 이상 나타나지 않는 경우에는,
"typ" 헤더 파라미터에서
미디어 타입 값의 "application/" 접두어를
생략하는 것이 권장된다.
미디어 타입 값을 사용하는 수신자는,
'/'를 포함하지 않는 모든 "typ" 값 앞에
"application/"이 붙어 있는 것처럼
처리해야 한다.
예를 들어,
"typ" 값 "example"은
"application/example" 미디어 타입을
표현하는 데 사용되어야 한다.
반면,
미디어 타입 "application/example;part="1/2""는
"example;part="1/2""로
축약될 수 없다.
"typ" 값 "JOSE"는,
이 객체가
JWS Compact 직렬화 또는
JWE Compact 직렬화를 사용하는
JWS 또는 JWE임을 나타내는 데
애플리케이션에서 사용할 수 있다.
"typ" 값 "JOSE+JSON"은,
이 객체가
JWS JSON 직렬화 또는
JWE JSON 직렬화를 사용하는
JWS 또는 JWE임을 나타내는 데
애플리케이션에서 사용할 수 있다.
그 밖의 타입 값들도
애플리케이션에서 사용할 수 있다.
4.1.10. "cty" (콘텐츠 타입) 헤더 파라미터
"cty"(콘텐츠 타입) 헤더 파라미터는,
JWS 애플리케이션이
보호된 콘텐츠(페이로드)의
미디어 타입을 선언하는 데 사용된다
[IANA.MediaTypes].
이는 JWS 페이로드에
하나 이상의 객체 종류가 존재할 수 있는 경우에,
애플리케이션이 서로 다른 객체 종류를
구분할 수 있도록 하기 위한 것이다.
객체의 종류가 이미 알려져 있는 경우에는,
일반적으로 애플리케이션에서 사용되지 않는다.
이 파라미터는 JWS 구현에서는 무시되며,
이 파라미터에 대한 모든 처리는
JWS 애플리케이션에 의해 수행된다.
이 헤더 파라미터의 사용은 선택 사항이다.
RFC 2045
[RFC2045]에 따라,
모든 미디어 타입 값, 서브타입 값, 그리고
파라미터 이름은 대소문자를 구분하지 않는다.
그러나 파라미터 값은,
특정 파라미터에 대해 달리 지정되지 않는 한,
대소문자를 구분한다.
일반적인 상황에서 메시지를 간결하게 유지하기 위해,
미디어 타입 값에 '/' 문자가 더 이상 나타나지 않는 경우에는,
"cty" 헤더 파라미터에서
미디어 타입 값의 "application/" 접두어를
생략하는 것이 권장된다.
미디어 타입 값을 사용하는 수신자는,
'/'를 포함하지 않는 모든 "cty" 값 앞에
"application/"이 붙어 있는 것처럼
처리해야 한다.
예를 들어,
"cty" 값 "example"은
"application/example" 미디어 타입을
표현하는 데 사용되어야 한다.
반면,
미디어 타입 "application/example;part="1/2""는
"example;part="1/2""로
축약될 수 없다.
Jones, et al. Standards Track [Page 13]
RFC 7515 JSON Web Signature (JWS) May 2015
4.1.11. "crit" (중요) 헤더 파라미터
"crit"(중요) 헤더 파라미터는,
이 사양 및/또는
[JWA]에 대한 확장이 사용되고 있으며,
반드시 이해되고 처리되어야 함을 나타낸다.
그 값은,
이러한 확장을 사용하는
JOSE 헤더 내에 존재하는
헤더 파라미터 이름들의 배열이다.
나열된 확장 헤더 파라미터 중
어느 하나라도 수신자가 이해하거나 지원하지 못할 경우,
해당 JWS는 유효하지 않다.
생성자는,
이 사양 또는
[JWA]에서
JWS와 함께 사용하도록 정의된 헤더 파라미터 이름,
중복된 이름,
또는 JOSE 헤더 내에서
헤더 파라미터 이름으로 존재하지 않는 이름을
"crit" 목록에 포함해서는 안 된다.
생성자는 "crit" 값으로
빈 목록 "[]"을 사용해서는 안 된다.
수신자는,
중요 목록에
이 사양 또는
[JWA]에서
JWS와 함께 사용하도록 정의된
헤더 파라미터 이름이 포함되어 있거나,
그 사용에 대한 다른 제약 조건이 위반된 경우,
해당 JWS를 유효하지 않은 것으로
간주할 수 있다.
이 헤더 파라미터가 사용되는 경우,
무결성 보호가 반드시 적용되어야 하므로,
반드시 JWS 보호된 헤더 내에만
존재해야 한다.
이 헤더 파라미터의 사용은 선택 사항이다.
이 헤더 파라미터는
구현에 의해 반드시 이해되고 처리되어야 한다.
가상의 "exp"(만료 시간) 필드를 포함한
사용 예시는 다음과 같다:
{"alg":"ES256",
"crit":["exp"],
"exp":1363284000
}
4.2. 공개 헤더 파라미터 이름
JWS를 사용하는 이들은
추가적인 헤더 파라미터 이름을 정의할 수 있다.
그러나 충돌을 방지하기 위해,
새로운 헤더 파라미터 이름은
섹션 9.1에 의해 설정된
IANA “JSON Web Signature and Encryption Header Parameters”
레지스트리에 등록되거나,
공개 이름
(충돌 방지 이름을 포함하는 값)이어야 한다.
각 경우에,
이름 또는 값을 정의하는 이는,
헤더 파라미터 이름을 정의하는 데 사용하는
네임스페이스의 부분을
자신이 통제하고 있음을 보장하기 위해
합리적인 예방 조치를 취해야 한다.
새로운 헤더 파라미터는,
상호 운용되지 않는 JWS를 초래할 수 있으므로,
신중하게 도입되어야 한다.
4.3. 개인 헤더 파라미터 이름
JWS의 생성자와 소비자는,
등록된 헤더 파라미터 이름이 아닌
개인 이름
(섹션 4.1에 정의된 등록된 헤더 파라미터 이름이 아닌 이름)
또는 공개 헤더 파라미터 이름
(섹션 4.2)을
사용하기로 합의할 수 있다.
Jones, et al. Standards Track [Page 14]
RFC 7515 JSON Web Signature (JWS) May 2015
공개 헤더 파라미터 이름과 달리,
개인 헤더 파라미터 이름은
충돌이 발생할 수 있으므로
주의하여 사용해야 한다.
5. JWS 생성 및 소비
5.1. 메시지 서명 또는 MAC 계산
JWS를 생성하기 위해,
다음 단계들이 수행된다.
입력과 출력 간에 의존성이 없는 경우,
단계들의 순서는 중요하지 않다.
1. JWS 페이로드로 사용할 콘텐츠를 생성한다.
2. 인코딩된 페이로드 값
BASE64URL(JWS 페이로드)를 계산한다.
3. 원하는 헤더 파라미터 집합을 포함하는
JSON 객체를 생성한다.
이 객체들은 함께
JOSE 헤더
(JWS 보호된 헤더 및/또는 JWS 비보호 헤더)를
구성한다.
4. 인코딩된 헤더 값
BASE64URL(UTF8(JWS 보호된 헤더))를 계산한다.
JWS 보호된 헤더가 존재하지 않는 경우
(이는 JWS JSON 직렬화를 사용하면서
"protected" 멤버가 존재하지 않는 경우에만 발생할 수 있다),
이 값은 빈 문자열로 한다.
5. 사용 중인 특정 알고리즘에 대해 정의된 방식으로,
JWS 서명 입력
ASCII(BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드))
에 대해
JWS 서명을 계산한다.
"alg"(알고리즘) 헤더 파라미터는
JOSE 헤더에 반드시 존재해야 하며,
그 알고리즘 값은
JWS 서명을 생성하는 데 사용된 알고리즘을
정확하게 나타내야 한다.
6. 인코딩된 서명 값
BASE64URL(JWS 서명)을 계산한다.
7. JWS JSON 직렬화를 사용하는 경우,
수행되는 각 디지털 서명 또는 MAC 연산에 대해
이 과정(단계 3-6)을 반복한다.
8. 원하는 직렬화된 출력을 생성한다.
이 결과의 JWS Compact 직렬화는
BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드) || '.' ||
BASE64URL(JWS 서명)이다.
JWS JSON 직렬화는
섹션 7.2에 설명되어 있다.
Jones, et al. Standards Track [Page 15]
RFC 7515 JSON Web Signature (JWS) May 2015
5.2. 메시지 서명 또는 MAC 검증
JWS를 검증할 때 다음 단계들이 수행된다. 단계들의 순서는
단계들의 입력과 출력 사이에 의존성이 없는 경우에는 중요하지 않다.
나열된 단계 중 하나라도 실패하면, 서명 또는 MAC은
검증될 수 없다.
여러 개의 JWS 서명 값이 있는 경우, 어떤 JWS 서명 값이
성공적으로 검증되어야 JWS를 수용할 것인지는 애플리케이션의
결정 사항이다. 어떤 경우에는 모두 성공적으로 검증되어야 하며,
그렇지 않으면 JWS는 유효하지 않은 것으로 간주된다.
다른 경우에는 특정 JWS 서명 값 하나만 성공적으로
검증되면 된다. 그러나 모든 경우에 최소한 하나의
JWS 서명 값은 반드시 성공적으로 검증되어야 하며,
그렇지 않으면 JWS는 반드시 유효하지 않은 것으로 간주되어야 한다.
1. JWS 표현을 파싱하여 JWS 구성 요소들의 직렬화된 값을
추출한다. JWS Compact 직렬화를 사용하는 경우,
이러한 구성 요소들은 JWS 보호된 헤더, JWS 페이로드,
그리고 JWS 서명의 base64url-인코딩된 표현이다.
JWS JSON 직렬화를 사용하는 경우에는,
이러한 구성 요소들에 인코딩되지 않은
JWS 비보호 헤더 값도 포함된다.
JWS Compact 직렬화를 사용하는 경우,
JWS 보호된 헤더, JWS 페이로드, 그리고 JWS 서명은
그 순서대로 base64url-인코딩된 값으로 표현되며,
각 값은 단일 마침표 문자('.')로 구분된다.
그 결과 정확히 두 개의 구분 마침표 문자가 사용된다.
JWS JSON 직렬화는 섹션 7.2에 설명되어 있다.
2. JWS 보호된 헤더의 인코딩된 표현을 base64url-디코딩한다.
이때 줄 바꿈, 공백 또는 기타 추가 문자가
사용되지 않았다는 제한을 따른다.
3. 결과로 얻은 옥텟 시퀀스가
RFC 7159 [RFC7159]에
부합하는 완전히 유효한 JSON 객체의 UTF-8 인코딩된 표현인지
검증한다. 이 JSON 객체를 JWS 보호된 헤더로 둔다.
4. JWS Compact 직렬화를 사용하는 경우,
JOSE 헤더를 JWS 보호된 헤더로 둔다.
그렇지 않고 JWS JSON 직렬화를 사용하는 경우에는,
JOSE 헤더를 해당 JWS 보호된 헤더와
JWS 비보호 헤더의 멤버들의 합집합으로 둔다.
이들 모두는 완전히 유효한 JSON 객체여야 한다.
이 단계에서 결과로 생성된 JOSE 헤더에
중복된 헤더 매개변수 이름이 포함되어 있지 않은지
검증한다. JWS JSON 직렬화를 사용하는 경우,
이 제한에는 JOSE 헤더를 구성하는 서로 다른 JSON 객체 값들에
동일한 헤더 매개변수 이름이
동시에 존재해서는 안 된다는 것도 포함된다.
5. 구현이 이 사양에 의해 요구되는 필드,
사용 중인 알고리즘에 의해 요구되는 필드,
또는 "crit" 헤더 매개변수 값에 의해 요구되는 필드
모두를 이해하고 처리할 수 있는지,
그리고 해당 매개변수들의 값 또한
이해되고 지원되는지 검증한다.
6. JWS 페이로드의 인코딩된 표현을 base64url-디코딩한다.
이때 줄 바꿈, 공백 또는 기타 추가 문자가
사용되지 않았다는 제한을 따른다.
7. JWS 서명의 인코딩된 표현을 base64url-디코딩한다.
이때 줄 바꿈, 공백 또는 기타 추가 문자가
사용되지 않았다는 제한을 따른다.
8. JWS 서명을
ASCII(BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드))
라는 JWS 서명 입력에 대해,
사용 중인 알고리즘에 대해 정의된 방식으로 검증한다.
이 알고리즘은 반드시 "alg"(알고리즘) 헤더 매개변수 값으로
정확히 표현되어야 하며, 해당 매개변수는 반드시 존재해야 한다.
알고리즘 검증에 대한 보안 고려사항은
섹션 10.6을 참조하라.
검증이 성공했는지 여부를 기록한다.
9. JWS JSON 직렬화를 사용하는 경우,
표현에 포함된 각 디지털 서명 또는 MAC 값에 대해
이 과정(단계 4-8)을 반복한다.
10. 단계 9의 검증들 중 어느 것도 성공하지 못한 경우,
JWS는 반드시 유효하지 않은 것으로 간주되어야 한다.
그렇지 않은 경우, JWS JSON 직렬화의 경우에는
어떤 검증이 성공했고 실패했는지를
애플리케이션에 반환한다.
JWS Compact 직렬화의 경우에는,
JWS가 성공적으로 검증되었는지 여부만
표시하면 된다.
마지막으로, 어떤 알고리즘을 특정 문맥에서 사용할 수 있는지는
애플리케이션의 결정 사항임에 유의하라.
JWS가 성공적으로 검증될 수 있더라도,
JWS에 사용된 알고리즘이 애플리케이션에 의해
허용되지 않는 경우에는,
JWS를 유효하지 않은 것으로 간주해야 한다(SHOULD).
5.3. 문자열 비교 규칙
JWS 처리는 필연적으로 알려진 문자열을
JSON 객체의 멤버 및 값과 비교하는 작업을 필요로 한다.
예를 들어, 사용 중인 알고리즘을 확인할 때,
유니코드 문자열 "alg"는 JOSE 헤더의 멤버 이름들과
비교되어 일치하는 헤더 매개변수 이름이 있는지
확인된다.
JSON에서 멤버 이름 비교를 수행하는 규칙은
RFC 7159의 섹션 8.3
[RFC7159]에
설명되어 있다. 수행되는 문자열 비교 연산은
동일성 및 비동일성 비교뿐이므로,
동일한 규칙을 멤버 이름과 멤버 값 모두를
알려진 문자열과 비교하는 데 사용할 수 있다.
이러한 비교 규칙은,
멤버의 정의에서 해당 멤버 값에 대해
다른 비교 규칙을 사용해야 함을
명시적으로 호출한 경우를 제외하고,
모든 JSON 문자열 비교에 반드시 사용되어야 한다.
이 사양에서 정의된 멤버 값 중
"typ"과 "cty"만이 이 비교 규칙을 사용하지 않는다.
일부 애플리케이션은 대소문자를 구분하는 값 안에
대소문자를 구분하지 않는 정보를 포함할 수 있는데,
예를 들어 "kid"(키 ID) 값의 일부로 DNS 이름을
포함하는 경우가 그러하다.
이러한 경우, 둘 이상의 당사자가
동일한 값을 생성해야 비교가 가능한 상황이라면,
대소문자를 구분하지 않는 부분을 표현하기 위한
정규화된 대소문자 규칙(예: 소문자로 변환)을
애플리케이션이 정의할 필요가 있을 수 있다.
(그러나 다른 모든 당사자가
생성자가 출력한 값을 그대로 소비하고,
독립적으로 생성한 값과 비교하려 하지 않는다면,
생성자가 사용한 대소문자는 중요하지 않다.)
또한 섹션 10.12의 JSON 보안 고려사항과
섹션 10.13의 유니코드 보안 고려사항을
참조하라.
6. 키 식별
JWS의 수신자는 디지털 서명 또는 MAC 연산에
사용된 키를 결정할 수 있어야 한다.
사용된 키는 섹션 4.1에 설명된
헤더 매개변수 방법을 사용하여 식별할 수 있으며,
또는 이 사양의 범위를 벗어나는 방법을
사용하여 식별할 수도 있다.
구체적으로, "jku", "jwk", "kid", "x5u", "x5c", "x5t",
그리고 "x5t#S256" 헤더 매개변수를 사용하여
사용된 키를 식별할 수 있다.
이러한 헤더 매개변수들이 전달하는 정보가
신뢰 결정에 사용되는 경우에는
반드시 무결성 보호가 되어야 한다.
그러나 신뢰 결정에 사용되는 유일한 정보가 키인 경우에는,
이 매개변수들이 무결성 보호될 필요는 없다.
왜냐하면 이들을 변경하여 다른 키가 사용되게 만들면,
검증이 실패하게 되기 때문이다.
애플리케이션이 사용된 키를 결정하기 위한
다른 수단이나 관례를 사용하지 않는 한,
생성자는 사용된 키를 식별하기에 충분한 정보를
헤더 매개변수에 포함해야 한다(SHOULD).
알고리즘이 키를 요구하는 경우
(이는 "none"을 제외한 모든 알고리즘에 해당한다)
사용된 키를 결정할 수 없으면,
서명 또는 MAC 검증은 실패한다.
공유 대칭 키를 교환하는 방법은
이 사양의 범위를 벗어난다.
또한 가능한 키 선택 알고리즘에 대한 참고 사항은
부록 D를 참조하라.
7. 직렬화
JWS는 두 가지 직렬화 중 하나를 사용한다.
JWS Compact 직렬화 또는 JWS JSON 직렬화이다.
이 사양을 사용하는 애플리케이션은
어떤 직렬화와 어떤 직렬화 기능을
해당 애플리케이션에서 사용하는지를
명시해야 한다.
예를 들어, 애플리케이션은
JWS JSON 직렬화만을 사용한다거나,
단일 서명 또는 MAC 값에 대한
JWS JSON 직렬화 지원만을 사용한다거나,
여러 개의 서명 및/또는 MAC 값에 대한
지원을 사용한다고 명시할 수 있다.
JWS 구현은 자신이 지원하도록 설계된
애플리케이션에 필요한 기능만
구현하면 된다.
7.1. JWS Compact 직렬화
JWS Compact 직렬화는
디지털 서명되거나 MAC이 적용된 콘텐츠를
간결하고 URL-안전한 문자열로 표현한다.
이 문자열은 다음과 같다:
BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드) || '.' ||
BASE64URL(JWS 서명)
JWS Compact 직렬화는
하나의 서명/MAC만을 지원하며,
JWS 비보호 헤더 값을
표현하기 위한 구문을 제공하지 않는다.
7.2. JWS JSON 직렬화
JWS JSON 직렬화는
디지털 서명되거나 MAC이 적용된 콘텐츠를
JSON 객체로 표현한다.
이 표현은 간결성에 최적화되어 있지 않으며
URL-안전하지도 않다.
JWS JSON 직렬화에는
두 가지 밀접하게 관련된 구문이 정의되어 있다:
하나는 하나 이상의 디지털 서명 및/또는
MAC 연산으로 콘텐츠를 보호할 수 있는
완전 일반 구문이고,
다른 하나는 단일 디지털 서명 또는 MAC의 경우에
최적화된 평탄화된 구문이다.
7.2.1. 일반 JWS JSON 직렬화 구문
다음 멤버들은
완전 일반 JWS JSON 직렬화 구문에 사용되는
최상위 JSON 객체에서 사용되도록 정의된다:
payload
"payload" 멤버는 반드시 존재해야 하며,
BASE64URL(JWS 페이로드) 값을 포함해야 한다.
signatures
"signatures" 멤버 값은 반드시
JSON 객체의 배열이어야 한다.
각 객체는 JWS 페이로드와
JWS 보호된 헤더에 대한
서명 또는 MAC을 나타낸다.
다음 멤버들은
"signatures" 배열의 요소인
JSON 객체에서 사용되도록 정의된다:
protected
JWS 보호된 헤더 값이 비어 있지 않은 경우,
"protected" 멤버는 반드시 존재해야 하며
BASE64URL(UTF8(JWS 보호된 헤더)) 값을 포함해야 한다.
그렇지 않은 경우에는 반드시 존재하지 않아야 한다.
이러한 헤더 매개변수 값들은 무결성 보호된다.
header
JWS 비보호 헤더 값이 비어 있지 않은 경우,
"header" 멤버는 반드시 존재해야 하며
JWS 비보호 헤더 값을 포함해야 한다.
그렇지 않은 경우에는 반드시 존재하지 않아야 한다.
이 값은 문자열이 아니라
인코딩되지 않은 JSON 객체로 표현된다.
이러한 헤더 매개변수 값들은 무결성 보호되지 않는다.
signature
"signature" 멤버는 반드시 존재해야 하며
BASE64URL(JWS 서명) 값을 포함해야 한다.
각 서명/MAC 계산에 대해,
"alg" 헤더 매개변수 값이 전달되도록 하기 위해,
"protected"와 "header" 멤버 중
최소 하나는 반드시 존재해야 한다.
위에서 정의된 JSON 객체들에는
추가적인 멤버들이 존재할 수 있다.
구현이 이를 이해하지 못하는 경우에는,
반드시 무시해야 한다.
개별 서명 또는 MAC 값을 생성하거나 검증할 때
사용되는 헤더 매개변수 값들은,
존재할 수 있는 두 집합의
헤더 매개변수 값들의 합집합이다:
(1) 서명/MAC의 배열 요소에 있는
"protected" 멤버로 표현된
JWS 보호된 헤더,
(2) 서명/MAC의 배열 요소에 있는
"header" 멤버의 JWS 비보호 헤더.
이 두 집합의 합집합이
JOSE 헤더를 구성한다.
두 위치에 있는 헤더 매개변수 이름들은
반드시 서로 겹치지 않아야 한다.
각 JWS 서명 값은
JWS Compact 직렬화에서와 동일한 방식으로,
해당 JOSE 헤더 값의 매개변수들을 사용하여
계산된다.
이로 인해,
"signatures" 배열에 표현된 각 JWS 서명 값은,
해당 서명/MAC 계산에 사용된
JWS 보호된 헤더 값이
JWS Compact 직렬화에서 사용된 것과
일치하는 경우,
JWS Compact 직렬화에서
동일한 매개변수에 대해
계산되었을 값과
동일하다는 바람직한 속성을 갖는다.
요약하면,
일반 JWS JSON 직렬화를 사용하는
JWS의 구문은 다음과 같다:
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
일반 JWS JSON 직렬화 구문을 사용하는
JWS의 예는 부록 A.6을 참조하라.
7.2.2. 평탄화된 JWS JSON 직렬화 구문
평탄화된 JWS JSON 직렬화 구문은
일반 구문을 기반으로 하되,
단일 디지털 서명/MAC 경우에 최적화하기 위해
이를 평탄화한 것이다.
이는 "signatures" 멤버를 제거하고,
대신 "signatures" 배열에서 사용되도록 정의된
멤버들("protected", "header", "signature")을
최상위 JSON 객체에서
"payload" 멤버와 동일한 수준에 배치함으로써
이루어진다.
이 구문을 사용할 때는
"signatures" 멤버가
반드시 존재해서는 안 된다.
이 구문 차이를 제외하면,
평탄화된 구문을 사용하는
JWS JSON 직렬화 객체는
일반 구문을 사용하는 객체와
동일하게 처리된다.
요약하면,
평탄화된 JWS JSON 직렬화를 사용하는
JWS의 구문은 다음과 같다:
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
평탄화된 JWS JSON 직렬화 구문을 사용하는
JWS의 예는 부록 A.7을 참조하라.
8. TLS 요구사항
"jku" 및/또는 "x5u" 헤더 매개변수를 지원하는
구현은 반드시 TLS를 지원해야 한다.
어떤 TLS 버전을 구현해야 하는지는
시간에 따라 달라지며,
구현 시점에서의 광범위한 배포 상태와
알려진 보안 취약성에 따라 달라진다.
이 문서를 작성하는 시점에서,
TLS 버전 1.2
[RFC5246]가
가장 최신 버전이다.
정보 공개와 변조를 방지하기 위해,
기밀성 보호는 반드시
기밀성과 무결성 보호를 제공하는
암호군을 사용하는 TLS를 통해
적용되어야 한다.
현재 적절하다고 간주되는 암호군에 대한
지침은 RFC
6176
[RFC6176]을 포함하여,
IETF TLS 작업 그룹의
최신 출판물을 참조하라.
또한 TLS를 사용하는 소프트웨어와 서비스의
보안을 향상시키기 위한 권고사항은
“Recommendations for Secure Use of
Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)”
[RFC7525]를
참조하라.
TLS가 사용될 때마다,
TLS 서버 인증서에 인코딩된
서비스 제공자의 신원은
RFC 6125의 섹션 6
[RFC6125]에
설명된 절차를 사용하여
반드시 검증되어야 한다.
9. IANA 고려사항
이 사양에 의해 설정된 모든 레지스트리에는
다음 등록 절차가 사용된다.
값은 jose-reg-review@ietf.org 메일링 리스트에서의
3주간의 검토 기간 이후,
하나 이상의 지정 전문가의 조언에 따라
사양 필요(Specification Required)
[RFC5226] 기준으로
등록된다.
그러나 출판 이전에 값 할당을 허용하기 위해,
지정 전문가들은 해당 사양이 출판될 것임을
충분히 만족하는 경우,
등록을 승인할 수 있다.
Jones, et al. Standards Track [Page 22]
RFC 7515 JSON Web Signature (JWS) May 2015
검토를 위해 메일링 리스트로 보내는 등록 요청은
적절한 제목(예: "Request to register header parameter:
example")을 사용해야 한다.
검토 기간 내에 지정 전문가(Designated Experts)는
등록 요청을 승인하거나 거부하며, 이 결정은 검토 리스트와
IANA에 전달된다. 거부 시에는 설명이 포함되어야 하며,
해당되는 경우 요청을 성공적으로 만들기 위한 제안도
포함되어야 한다. 21일을 초과하는 기간 동안 결정되지 않은
등록 요청은 해결을 위해 IESG의 주의를 끌 수 있다
(iesg@ietf.org 메일링 리스트 사용).
지정 전문가가 적용해야 할 기준에는 제안된 등록이 기존
기능을 중복하는지 여부, 일반적으로 적용 가능하거나
단일 애플리케이션에만 유용한지 여부, 그리고 등록 설명이
명확한지 여부를 판단하는 것이 포함된다.
IANA는 지정 전문가로부터의 레지스트리 업데이트만
수락해야 하며, 모든 등록 요청을 검토 메일링 리스트로
안내해야 한다.
이 사양을 사용하는 서로 다른 애플리케이션의 관점을
대표할 수 있도록 여러 명의 지정 전문가를 임명하는 것이
권장된다. 이를 통해 등록 결정에 대해 폭넓고 정보에
근거한 검토가 가능해진다. 특정 전문가에게 이해 상충을
야기한다고 인식될 수 있는 등록 결정의 경우, 해당 전문가는
다른 전문가들의 판단에 따르는 것이 바람직하다.
9.1. JSON Web Signature 및 암호화 헤더 매개변수 레지스트리
이 사양은 헤더 매개변수 이름을 위한 IANA
"JSON Web Signature 및 암호화 헤더 매개변수"
레지스트리를 설정한다. 이 레지스트리는 헤더 매개변수
이름과 이를 정의하는 사양에 대한 참조를 기록한다.
동일한 헤더 매개변수 이름은, 매개변수 사용이 사양 간에
호환되는 경우, 여러 번 등록될 수 있다. 동일한 헤더
매개변수 이름에 대한 서로 다른 등록은 일반적으로 서로
다른 헤더 매개변수 사용 위치 값(Header Parameter Usage
Locations)을 사용한다.
9.1.1. 등록 템플릿
Header Parameter Name:
요청되는 이름(예: "kid"). 이 사양의 핵심 목표 중 하나는
결과 표현을 간결하게 만드는 것이므로, 특별한 이유가
없는 한 이름은 짧게 유지하는 것이 RECOMMENDED되며,
8자를 초과하지 않는 것이 바람직하다. 이 이름은
Jones, et al. Standards Track [Page 23]
RFC 7515 JSON Web Signature (JWS) May 2015
대소문자를 구분한다. 지정 전문가가 예외를 허용해야 할
중대한 이유가 있다고 판단하지 않는 한, 이름은
대소문자를 구분하지 않는 방식으로 다른 등록된 이름과
일치해서는 안 된다.
Header Parameter Description:
헤더 매개변수에 대한 간단한 설명(예: "Key ID").
Header Parameter Usage Location(s):
헤더 매개변수 사용 위치로, "JWS" 또는 "JWE" 중 하나 이상이어야 한다.
Change Controller:
표준 트랙 RFC의 경우 "IESG"를 기재한다.
그 외의 경우에는 책임자의 이름을 제공한다.
기타 세부 정보(예: 우편 주소, 이메일 주소, 홈페이지 URI)도
포함될 수 있다.
Specification Document(s):
매개변수를 규정하는 문서에 대한 참조로,
가능하면 문서 사본을 가져올 수 있는 URI를 포함하는 것이 바람직하다.
관련 섹션에 대한 표시는 포함될 수 있으나 필수는 아니다.
9.1.2. 초기 레지스트리 내용
이 절은 이 레지스트리에
섹션 4.1에 정의된 헤더 매개변수 이름을 등록한다.
o Header Parameter Name: "alg"
o Header Parameter Description: 알고리즘
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.1
o Header Parameter Name: "jku"
o Header Parameter Description: JWK 세트 URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.2
o Header Parameter Name: "jwk"
o Header Parameter Description: JSON 웹 키
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.3
Jones, et al. Standards Track [Page 24]
RFC 7515 JSON Web Signature (JWS) May 2015
o Header Parameter Name: "kid"
o Header Parameter Description: 키 ID
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.4
o Header Parameter Name: "x5u"
o Header Parameter Description: X.509 URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.5
o Header Parameter Name: "x5c"
o Header Parameter Description: X.509 인증서 체인
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.6
o Header Parameter Name: "x5t"
o Header Parameter Description: X.509 인증서 SHA-1 지문
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.7
o Header Parameter Name: "x5t#S256"
o Header Parameter Description: X.509 인증서 SHA-256 지문
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.8
o Header Parameter Name: "typ"
o Header Parameter Description: 타입
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.9
o Header Parameter Name: "cty"
o Header Parameter Description: 콘텐츠 타입
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.10
o Header Parameter Name: "crit"
o Header Parameter Description: 중요
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515의 섹션 4.1.11
Jones, et al. Standards Track [Page 25]
RFC 7515 JSON Web Signature (JWS) May 2015
9.2. 미디어 타입 등록
9.2.1. 레지스트리 내용
이 절은 "Media Types" 레지스트리
[IANA.MediaTypes]에
"application/jose" 미디어 타입을
[RFC2046]에 따라
RFC 6838 [RFC6838]에 설명된 방식으로 등록한다.
이는 콘텐츠가 JWS Compact Serialization 또는
JWE Compact Serialization을 사용하는 JWS 또는 JWE임을
나타내는 데 사용할 수 있다. 또한 이 절은
"Media Types" 레지스트리에 "application/jose+json"
미디어 타입도 등록하는데, 이는 JWS JSON Serialization 또는
JWE JSON Serialization을 사용하는 JWS 또는 JWE임을
나타내는 데 사용할 수 있다.
o Type name: application
o Subtype name: jose
o Required parameters: 해당 없음
o Optional parameters: 해당 없음
o Encoding considerations: 8bit; application/jose 값은
base64url로 인코딩된 값들의 연속으로 인코딩되며
(그중 일부는 빈 문자열일 수 있음),
각 값은 단일 마침표('.') 문자로 구분된다.
o Security considerations: RFC 7515의
보안 고려 사항 절을 참조하라.
o Interoperability considerations: 해당 없음
o Published specification: RFC 7515
o Applications that use this media type: OpenID Connect, Mozilla
Persona, Salesforce, Google, Android, Windows Azure, Xbox One,
Amazon Web Services, 그리고 JWT를 사용하는 수많은 기타 애플리케이션
o Fragment identifier considerations: 해당 없음
o Additional information:
Magic number(s): 해당 없음
File extension(s): 해당 없음
Macintosh file type code(s): 해당 없음
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: 없음
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? 아니오
Jones, et al. Standards Track [Page 26]
RFC 7515 JSON Web Signature (JWS) May 2015
o Type name: application
o Subtype name: jose+json
o Required parameters: 해당 없음
o Optional parameters: 해당 없음
o Encoding considerations: 8bit; application/jose+json 값은
JSON 객체로 표현되며, JSON 객체에는 UTF-8 인코딩을
사용하는 것이 SHOULD 된다.
o Security considerations: RFC 7515의
보안 고려 사항 절을 참조하라.
o Interoperability considerations: 해당 없음
o Published specification: RFC 7515
o Applications that use this media type: Nimbus JOSE + JWT 라이브러리
o Fragment identifier considerations: 해당 없음
o Additional information:
Magic number(s): 해당 없음
File extension(s): 해당 없음
Macintosh file type code(s): 해당 없음
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: 없음
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? 아니오
10. 보안 고려 사항
암호 응용 전반에 관련되는 모든 보안 문제는
JWS/JWE/JWK 에이전트에 의해 다루어져야 한다.
여기에는 사용자의 비대칭 개인 키 및 대칭 비밀 키를
보호하는 것과, 다양한 공격에 대응하기 위한
대응책을 사용하는 것이 포함된다.
"XML Signature Syntax and Processing Version 2.0"
[W3C.NOTE-xmldsig-core2-20130411]에 포함된 모든 보안 고려 사항은,
XML에 특화된 내용을 제외하고는 이 사양에도 적용된다.
마찬가지로, "XML Signature Best Practices"
[W3C.NOTE-xmldsig-bestpractices-20130411]에 문서화된 많은 모범 사례 또한,
XML에 특화된 내용을 제외하고는 이 사양에 적용된다.
10.1. 키 엔트로피와 난수 값
키의 강도는 이를 생성하는 데 사용된 엔트로피의 양에
비례한다. 모든 키에 대해 최소 128비트의 엔트로피를
사용해야 하며, 애플리케이션의 맥락에 따라 더 많은
엔트로피가 필요할 수도 있다.
Jones, et al. Standards Track [Page 27]
RFC 7515 JSON Web Signature (JWS) May 2015
구현은 공개/개인 키 쌍, MAC 키, 그리고 패딩 값을
무작위로 생성해야 한다. 부적절한 의사 난수 생성기(PRNG)를
사용하여 암호 키를 생성하면 보안이 거의 없거나 전혀
없을 수 있다. 공격자는 전체 키 공간을 무차별 대입으로
탐색하는 것보다, 키를 생성한 PRNG 환경을 재현하여
결과로 나오는 작은 가능성 집합을 탐색하는 것이 훨씬
쉬울 수 있다. 고품질 난수의 생성은 어렵다.
RFC 4086 [RFC4086]는
이 분야에 대한 중요한 지침을 제공한다.
10.2. 키 보호
구현은 서명자의 개인 키를 보호해야 한다.
서명자의 개인 키가 노출되면 공격자가 서명자로
가장할 수 있다.
구현은 MAC 키를 보호해야 한다.
MAC 키가 노출되면 인증된 콘텐츠가
감지되지 않은 채로 수정될 수 있다.
10.3. 키 출처 인증
공개 키를 획득하는 데 사용되는 키 관리 기법은
키의 출처를 인증해야 하며, 그렇지 않으면
어떤 주체가 메시지를 서명했는지 알 수 없다.
마찬가지로, MAC 키를 배포하는 데 사용되는
키 관리 기법은 데이터 출처 인증을 제공해야 하며,
그렇지 않으면 콘텐츠는 출처가 알려지지 않은 상태에서
무결성만 보장된 채 전달된다.
10.4. 암호 기법 민첩성
암호 기법 민첩성에 대한 보안 고려 사항은
[JWA]의 섹션 8.1을 참조하라.
10.5. 디지털 서명과 MAC 간의 차이
MAC과 디지털 서명은 모두 무결성 검증에 사용될 수 있지만,
각각이 제공하는 보안 속성에는 중요한 차이가 있다.
이러한 차이점은 프로토콜을 설계하고 사용할 알고리즘을
선택할 때 고려되어야 한다.
서명과 MAC은 모두 무결성 검증을 제공하며,
이는 무결성 값이 계산된 이후 메시지가 수정되지 않았음을
검증한다. 그러나 MAC은 특정한 상황에서만
발신자 식별을 제공한다. 일반적으로 서명에 사용되는
개인 키는 단일 엔티티만이 보유하고 있다고 가정할 수 있다
(복제된 서버의 경우처럼 분산된 엔티티일 수도 있지만).
Jones, et al. Standards Track [Page 28]
RFC 7515 JSON Web Signature (JWS) May 2015
그러나 MAC 키는 무결성 계산과 검증에 이를 사용하는
모든 엔티티가 보유해야 한다. MAC 검증은
메시지가 대칭 MAC 키를 알고 있는 당사자 중 하나에 의해
생성되었음을 확인해 줄 뿐이다.
이는 MAC 키가 오직 두 엔티티만 알고 있고,
수신자가 자신이 메시지를 생성하지 않았음을 알고 있을 때에만
발신자를 판단할 수 있음을 의미한다.
MAC 검증은 제3자에게 발신자를 증명하는 데에는
사용할 수 없다.
10.6. 알고리즘 검증
일부 알고리즘에 대한 디지털 서명 표현에는
서명 값 내부에 사용된 알고리즘에 대한 정보가 포함되어 있다.
예를 들어, RSASSA-PKCS1-v1_5
[RFC3447]로 생성된 서명은
사용된 해시 함수를 인코딩하며,
많은 라이브러리는 실제로 서명을 검증할 때
서명 내부에 지정된 해시 알고리즘을 사용한다.
이러한 라이브러리를 사용할 경우,
알고리즘 검증의 일부로서 구현은
서명에 인코딩된 알고리즘 정보가
"alg" 헤더 매개변수에 지정된 것과
일치함을 MUST 보장해야 한다.
이를 수행하지 않으면, 공격자가
실제로는 약한 해시 알고리즘을 사용했음에도
강한 해시 알고리즘을 사용했다고 주장할 수 있다.
10.7. 알고리즘 보호
일부 JWS 사용 사례에서는 알고리즘 대체 공격의
위험이 존재한다. 이 공격에서 공격자는
기존의 디지털 서명 값을 다른 서명 알고리즘과 함께 사용하여,
서명자가 실제로는 서명하지 않은 내용을
서명한 것처럼 보이게 할 수 있다.
이러한 공격은 Cryptographic Message Syntax(CMS)
[RFC6211]의 맥락에서
자세히 논의된 바 있다.
이 위험은 다음 조건이 모두 참일 때 발생한다:
o 서명 검증자가 여러 알고리즘을 지원한다.
o 기존 서명이 주어졌을 때, 공격자가
다른 알고리즘으로 동일한 서명 값을 생성하는
또 다른 페이로드를 찾을 수 있다.
o 공격자가 조작한 페이로드가
애플리케이션 맥락에서 유효하다.
애플리케이션이 알고리즘 대체 공격을 완화하는
방법에는 여러 가지가 있다:
o 대체 공격에 취약하지 않은
디지털 서명 알고리즘만 사용한다.
대체 공격은 수신자가 허용하는 해시 함수에 대해
공격자가 역상(pre-image)을 계산할 수 있을 때만 가능하다.
JWA에 정의된 모든 서명 알고리즘은
SHA-2 해시를 사용하며,
이 문서를 작성하는 시점 기준으로
알려진 역상 공격은 존재하지 않는다.
Jones, et al. Standards Track [Page 29]
RFC 7515 JSON Web Signature (JWS) May 2015
o "alg" 헤더 매개변수가
JWS 보호된 헤더(JWS Protected Header)에
포함되도록 요구한다.
(이는 JWS Compact Serialization을 사용할 때는
항상 해당되며, CMS
[RFC6211]가 채택한 접근 방식이다.)
o 애플리케이션 페이로드에
알고리즘을 포함하는 필드를 추가하고,
검증 시 해당 필드가
"alg" 헤더 매개변수와 일치함을
요구한다.
(이는 PKIX
[RFC5280]가 채택한 접근 방식이다.)
10.8. 선택 평문 공격
JWS 생성자는 제3자가 자신이 통제하지 않는 엔트로피를
추가하지 않은 채 메시지에 임의의 콘텐츠를 삽입하도록
허용해서는 안 된다.
10.9. 타이밍 공격
암호 알고리즘이 성공한 연산과 실패한 연산에 대해
서로 다른 시간이 소요되도록 구현된 경우,
공격자는 이 시간 차이를 이용하여
사용된 키에 대한 정보를 획득할 수 있다.
따라서 이러한 시간 차이는 반드시 피해야 한다.
10.10. 재생 공격 방지
이 사양의 직접적인 범위에는 포함되지 않지만,
JWS(또는 JWE) 객체를 사용하는 애플리케이션은
JWS(또는 JWE) 메시지의 무결성 보호된 콘텐츠에
고유한 메시지 식별자를 포함시키고,
수신자가 해당 메시지가 이전에 수신되었거나
처리된 적이 없는지 검증함으로써
재생 공격을 방지할 수 있다.
10.11. SHA-1 인증서 지문
호환성 이유로 "x5t"
(X.509 인증서 SHA-1 지문) 값을 계산할 때
SHA-1 해시가 사용된다.
만약 SHA-1 해시 충돌을 생성하는 효과적인 방법이
개발되고, 공격자가 특정 시스템에서 알려진 인증서의
사용을 방해하고자 한다면,
동일한 SHA-1 해시 값을 갖는 다른 인증서를 생성하여
의도된 피해자가 사용하는 인증서 저장소에
추가함으로써 이를 달성할 수 있다.
이 공격이 성공하기 위한 전제 조건은
공격자가 의도된 피해자의 인증서 저장소에
쓰기 권한을 가지고 있어야 한다는 점이다.
Jones, et al. Standards Track [Page 30]
RFC 7515 JSON Web Signature (JWS) May 2015
대안으로, "x5t" 대신
"x5t#S256"(X.509 인증서 SHA-256 지문)
헤더 매개변수를 사용할 수도 있다.
그러나 이 문서를 작성하는 시점 기준으로,
SHA-256 인증서 지문을 지원하는 개발 플랫폼은
알려져 있지 않다.
10.12. JSON 보안 고려 사항
엄격한 JSON
[RFC7159] 검증은 보안 요구 사항이다.
잘못된 형식의 JSON이 수신되면,
생산자의 의도를 신뢰성 있게 파악하는 것이
불가능하다. JSON 파서가 잘못된 JSON 구문을
거부하지 않는 경우,
모호하고 잠재적으로 악용 가능한 상황이
발생할 수 있다. 특히,
RFC 7159에 정의된 JSON-text 구문을
준수하지 않는 모든 JSON 입력은
JSON 파서에 의해 전체가 MUST 거부되어야 한다.
"The JavaScript Object Notation (JSON) Data Interchange
Format" [RFC7159]의
섹션 4에서는
"객체 내의 이름은 SHOULD 고유해야 한다"고
명시하고 있으나, 이 사양에서는 다음과 같이 규정한다:
JOSE 헤더 내의 헤더 매개변수 이름은 MUST 고유해야 하며,
JWS 파서는 중복된 헤더 매개변수 이름을 가진 JWS를
거부하거나, ECMAScript 5.1
[ECMAScript]의
섹션 15.12
("JSON 객체")에 명시된 대로,
어휘적으로 마지막에 나타난 중복 멤버 이름만을
반환하는 JSON 파서를 사용해야 한다.
따라서 이 사양은
[RFC7159]의 섹션 4에 있는 "SHOULD"를
생산자에게는 "MUST"로 취급할 것을 요구하며,
소비자에게는 "MUST"로 취급하거나
ECMAScript 5.1에 명시된 방식으로
취급할 것을 요구한다.
JSON 파서가 멤버 이름의 고유성을 강제하지 않거나
중복 멤버 이름에 대해 예측 불가능한 값을 반환하는 경우,
모호하고 잠재적으로 악용 가능한 상황이 발생할 수 있다.
일부 JSON 파서는 유효한 입력 뒤에
추가적인 의미 있는 문자가 포함된 입력을
거부하지 않을 수도 있다.
예를 들어, 입력
"{"tag":"value"}ABCD"는
유효한 JSON-text 객체 뒤에
추가 문자 "ABCD"가 이어진 형태이다.
구현은 이러한 입력을 포함한 JWS를
MUST 유효하지 않은 것으로 간주해야 한다.
10.13. 유니코드 비교 보안 고려 사항
헤더 매개변수 이름과 알고리즘 이름은
유니코드 문자열이다.
보안상의 이유로, 이러한 이름의 표현은
RFC 7159의 섹션 8.3에 따른
이스케이프 처리를 수행한 후,
그대로(문자 단위로) 비교되어야 한다.
이는 예를 들어 다음과 같은 의미를 갖는다:
이들 JSON 문자열은
("sig", "\u0073ig")는 서로 동일하게 비교되어야 하지만,
("SIG", "Sig", "si\u0047")는
앞의 집합이나 서로 간에도
모두 동일하지 않은 것으로 비교되어야 한다.
Jones, et al. Standards Track [Page 31]
RFC 7515 JSON Web Signature (JWS) May 2015
JSON 문자열에는
유니코드 기본 다국어 평면(Basic Multilingual Plane)을
벗어나는 문자가 포함될 수 있다.
예를 들어, 높은음자리표(G clef) 문자(U+1D11E)는
JSON 문자열에서 "\uD834\uDD1E"로 표현될 수 있다.
이상적으로는 JWS 구현이
기본 다국어 평면 밖의 문자가
올바르게 보존되고 비교되도록 SHOULD 보장해야 한다.
또는, 이러한 문자가
기본 JSON 구현에 존재하는 제약을
유발하여 이것이 불가능한 경우에는,
이를 포함한 입력은 MUST 거부되어야 한다.
11. 참고 문헌
11.1. 규범적 참고 문헌
[ECMAScript] Ecma International,
"ECMAScript Language Specification,
5.1 Edition", ECMA 262, June 2011,
<http://www.ecma-international.org/ecma-262/5.1/
ECMA-262.pdf>.
[IANA.MediaTypes]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[ITU.X690.2008]
International Telecommunications Union,
"Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690,
2008.
[JWA] Jones, M., "JSON Web Algorithms (JWA)",
RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>.
[JWK] Jones, M., "JSON Web Key (JWK)",
RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>.
[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>.
[RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies",
RFC 2045,
DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
Jones, et al. Standards Track [Page 32]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types",
RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.
[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>.
[RFC2818] Rescorla, E.,
"HTTP Over TLS",
RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986,
DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S.,
"The Base16, Base32, and Base64 Data Encodings",
RFC 4648,
DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC4945] Korver, B.,
"The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX",
RFC 4945,
DOI 10.17487/RFC4945, August 2007,
<http://www.rfc-editor.org/info/rfc4945>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security (TLS)
Protocol Version 1.2",
RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile",
RFC 5280,
DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
Jones, et al. Standards Track [Page 33]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC6125] Saint-Andre, P. 및 J. Hodges, "도메인 기반 애플리케이션 서비스
아이덴티티의 표현 및 검증을 인터넷 공개 키 인프라 내에서
전송 계층 보안(TLS) 맥락에서 X.509(PKIX) 인증서를 사용하여
수행", RFC 6125, DOI 10.17487/RFC6125,
2011년 3월, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6176] Turner, S. 및 T. Polk, "보안 소켓 계층(SSL) 버전 2.0 금지",
RFC 6176,
DOI 10.17487/RFC6176, 2011년 3월,
<http://www.rfc-editor.org/info/rfc6176>.
[RFC7159] Bray, T., 편집자, "JavaScript 객체 표기법(JSON)
데이터 교환 형식", RFC 7159,
DOI 10.17487/RFC7159, 2014년 3월,
<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] 유니코드 컨소시엄, "유니코드 표준",
<http://www.unicode.org/versions/latest/>.
11.2. 정보 참고 문헌
[CanvasApp] Facebook, "Canvas 애플리케이션",
<http://developers.facebook.com/docs/authentication/
canvas>.
[JSS] Bradley, J. 및 N. Sakimura, 편집자, "JSON Simple Sign",
2010년 9월, <http://jsonenc.info/jss/1.0/>.
[JWE] Jones, M. 및 J. Hildebrand, "JSON Web Encryption
(JWE)", RFC 7516, DOI 10.17487/RFC7516, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7516>.
[JWT] Jones, M., Bradley, J. 및 N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7519>.
[MagicSignatures]
Panzer, J., 편집자, Laurie, B. 및 D. Balfanz, "Magic
Signatures", 2011년 1월,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[RFC2104] Krawczyk, H., Bellare, M. 및 R. Canetti, "HMAC:
메시지 인증을 위한 키 기반 해싱", RFC 2104,
DOI 10.17487/RFC2104, 1997년 2월,
<http://www.rfc-editor.org/info/rfc2104>.
Jones, et al. Standards Track [Page 34]
RFC 7515 JSON Web Signature (JWS) May 2015
[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>.
[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>.
[RFC4122] Leach, P., Mealling, M. 및 R. Salz, "범용 고유 식별자
(UUID) URN 네임스페이스", RFC 4122,
DOI 10.17487/RFC4122, 2005년 7월,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. 및 H. Alvestrand, "RFC에서 IANA 고려 사항
섹션을 작성하기 위한 지침", BCP 26,
RFC 5226, DOI 10.17487/RFC5226, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6211] Schaad, J., "암호화 메시지 구문(CMS)
알고리즘 식별자 보호 속성", RFC 6211,
DOI 10.17487/RFC6211, 2011년 4월,
<http://www.rfc-editor.org/info/rfc6211>.
[RFC6838] Freed, N., Klensin, J. 및 T. Hansen, "미디어 타입
사양 및 등록 절차", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, 2013년 1월,
<http://www.rfc-editor.org/info/rfc6838>.
[RFC7525] Sheffer, Y., Holz, R. 및 P. Saint-Andre,
"전송 계층 보안(TLS) 및 데이터그램 전송 계층 보안(DTLS)의
안전한 사용을 위한 권고 사항", BCP 195,
RFC 7525, DOI 10.17487/RFC7525, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7525>.
[SHS] 미국 국립표준기술연구소, "보안 해시 표준(SHS)",
FIPS PUB 180-4, 2012년 3월,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
Jones, et al. Standards Track [Page 35]
RFC 7515 JSON Web Signature (JWS) May 2015
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F.,
Roessler, T., Yiu, K., Datta, P. 및 S. Cantor,
"XML 서명 구문 및 처리 버전 2.0", 월드 와이드 웹 컨소시엄 노트
NOTE-xmldsig-core2-20130411, 2013년 4월,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
Jones, et al. Standards Track [Page 36]
RFC 7515 JSON Web Signature (JWS) May 2015
부록 A. JWS 예제
이 절에서는 여러 JWS의 예제를 제공한다. 처음 세 가지 예제는
모두 JSON Web Token(JWT) [JWT]을 나타내지만,
부록 A.4에 표시된 것처럼 페이로드는 임의의 옥텟 시퀀스일 수 있다.
A.1. HMAC SHA-256을 사용하는 JWS 예제
A.1.1. 인코딩
다음 예제의 JWS 보호된 헤더는 데이터 구조가
JWT [JWT]임을 선언하며, JWS 서명 입력이
HMAC SHA-256 알고리즘을 사용하여 보호됨을 나타낸다.
{"typ":"JWT",
"alg":"HS256"}
위 JSON 객체의 표현에서 발생할 수 있는 잠재적 모호성을 제거하기 위해,
이 예제에서 사용된 UTF8(JWS 보호된 헤더)를 실제로 나타내는 옥텟 시퀀스도
아래에 포함한다. (모호성은 플랫폼별 줄 바꿈 표현(CRLF 대 LF),
줄의 시작과 끝의 공백 차이, 마지막 줄에 종료 줄 바꿈이 있는지 여부,
기타 여러 원인으로 인해 발생할 수 있다. 이 예제에서 사용된 표현에서는
첫 번째 줄에 선행 또는 후행 공백이 없고, 첫 번째와 두 번째 줄 사이에
CRLF 줄 바꿈(13, 10)이 있으며, 두 번째 줄에는 선행 공백 하나(32)가 있고
후행 공백은 없으며, 마지막 줄에는 종료 줄 바꿈이 없다.)
이 예제에서의 UTF8(JWS 보호된 헤더)를 나타내는 옥텟은
(JSON 배열 표기법을 사용하여) 다음과 같다:
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
이 JWS 보호된 헤더를 BASE64URL(UTF8(JWS 보호된 헤더))로 인코딩하면
다음 값이 된다:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
이 예제에서 사용된 JWS 페이로드는 아래 JSON 객체의 UTF-8 표현에 해당하는
옥텟들이다. (페이로드는 어떤 base64url로 인코딩된 옥텟 시퀀스도 될 수 있으며,
반드시 base64url로 인코딩된 JSON 객체일 필요는 없다.)
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Jones, et al. Standards Track [Page 37]
RFC 7515 JSON Web Signature (JWS) May 2015
다음 옥텟 시퀀스는 위 JSON 객체에 대해 이 예제에서 사용된
UTF-8 표현이며, 이것이 JWS 페이로드이다:
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
이 JWS 페이로드를 BASE64URL(UTF8(JWS 페이로드))로 인코딩하면
다음 값이 된다(표시 목적상 줄 바꿈을 포함함):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드)를 결합하면
다음 문자열이 된다(표시 목적상 줄 바꿈을 포함함):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
결과로 생성된 JWS 서명 입력 값은 위 문자열의 ASCII 표현이며,
다음 옥텟 시퀀스이다
(JSON 배열 표기법 사용):
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81,
105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74,
73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51,
77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67,
74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84,
107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100,
72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76,
109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73,
106, 112, 48, 99, 110, 86, 108, 102, 81]
HMAC은 키를 사용하여 생성된다. 이 예제에서는
아래의 JSON Web Key [JWK] 형식으로 표현된
대칭 키를 사용한다(표시 목적상 값 내부에 줄 바꿈을 포함함):
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
Jones, et al. Standards Track [Page 38]
RFC 7515 JSON Web Signature (JWS) May 2015
이 키로 JWS 서명 입력에 대해 HMAC SHA-256 알고리즘을 실행하면
다음과 같은 JWS 서명 옥텟 시퀀스를 얻는다:
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173,
187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83,
132, 141, 121]
이 JWS 서명을 BASE64URL(JWS 서명)으로 인코딩하면
다음 값이 된다:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이 값들을 Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 넣어 연결하면,
다음과 같이 JWS Compact Serialization을 사용하는
완전한 JWS 표현이 된다(표시 목적상 줄 바꿈을 포함함):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
A.1.2. 검증
"alg" 헤더 매개변수가 "HS256"이므로,
JWS 서명에 포함된 HMAC SHA-256 값을 검증한다.
HMAC 값을 검증하기 위해, 올바른 키와 JWS 서명 입력
(JWS Compact Serialization 표현에서 두 번째 마침표 문자
직전까지의 초기 부분 문자열)을 입력으로 사용하여
이전과 동일한 HMAC SHA-256 과정을 반복한 다음,
그 출력이 JWS 서명과 일치하는지 확인한다
(JWS 표현에 인코딩된 값에서 base64url 디코딩됨).
정확히 일치하면 HMAC이 검증된 것이다.
A.2. RSASSA-PKCS1-v1_5 SHA-256을 사용하는 JWS 예제
A.2.1. 인코딩
이 예제의 JWS 보호된 헤더는 이전 예제와 두 가지 점에서 다르다.
첫째, 다른 알고리즘을 사용하므로 "alg" 값이 다르다.
둘째, 설명 목적상 선택적 "typ"(type) 헤더 매개변수를 사용하지 않는다.
(이 차이는 사용된 알고리즘과는 관련이 없다.)
사용된 JWS 보호된 헤더는 다음과 같다:
Jones, et al. Standards Track [Page 39]
RFC 7515 JSON Web Signature (JWS) May 2015
{"alg":"RS256"}
이 예제에서의 UTF8(JWS 보호된 헤더)를 나타내는 옥텟은
(JSON 배열 표기법 사용) 다음과 같다:
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
이 JWS 보호된 헤더를 BASE64URL(UTF8(JWS 보호된 헤더))로 인코딩하면
다음 값이 된다:
eyJhbGciOiJSUzI1NiJ9
이 예제에서 사용된 JWS 페이로드는 이전 예제와 동일하다.
따라서 BASE64URL(JWS 페이로드) 값도 동일하므로,
여기서는 그 계산을 반복하지 않는다.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
BASE64URL(UTF8(JWS 보호된 헤더)) || '.' ||
BASE64URL(JWS 페이로드)를 결합하면
다음 문자열이 된다(표시 목적상 줄 바꿈을 포함함):
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
결과로 생성된 JWS 서명 입력 값은 위 문자열의 ASCII 표현이며,
다음 옥텟 시퀀스이다:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
Jones, et al. Standards Track [Page 40]
RFC 7515 JSON Web Signature (JWS) May 2015
이 예제에서는 아래에 제시된 JSON Web Key [JWK]
형식으로 표현된 RSA 키를 사용한다
(표시 목적상 값 내부에 줄 바꿈을 포함함):
{"kty":"RSA",
"n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
}
Jones, et al. Standards Track [Page 41]
RFC 7515 JSON Web Signature (JWS) May 2015
그런 다음 RSA 개인 키가 RSA 서명 함수로 전달되며,
이 함수는 해시 유형인 SHA-256과 JWS 서명 입력도
함께 입력으로 받는다. 디지털 서명의 결과는
빅엔디언 정수를 나타내는 옥텟 시퀀스이다.
이 예제에서는 다음과 같다:
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69,
243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125,
131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81,
102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69,
229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219,
61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7,
16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31,
190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244,
74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1,
48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129,
253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239,
177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202,
173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157,
105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69,
34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202,
234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90,
193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238,
251, 71]
이 서명을 BASE64URL(JWS 서명)으로 인코딩하면
다음 값이 생성된다(표시 목적상 줄 바꿈을 포함함):
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Jones, et al. Standards Track [Page 42]
RFC 7515 JSON Web Signature (JWS) May 2015
이 값들을 Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 넣어 연결하면,
다음과 같이 JWS Compact Serialization을 사용하는
완전한 JWS 표현이 된다(표시 목적상 줄 바꿈을 포함함):
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
A.2.2. 검증
"alg" 헤더 매개변수가 "RS256"이므로,
JWS 서명에 포함된 RSASSA-
PKCS1-v1_5 SHA-256 디지털 서명을 검증한다.
JWS 서명 검증은 이전 예제와 약간 다르다.
공개 키(n, e), JWS 서명
(JWS 표현에 인코딩된 값에서 base64url 디코딩됨),
그리고 JWS 서명 입력
(JWS Compact Serialization 표현에서 두 번째 마침표 문자
직전까지의 초기 부분 문자열)을
SHA-256 해시 함수를 사용하도록 구성된
RSASSA-PKCS1-v1_5 서명 검증기에 전달한다.
A.3. ECDSA P-256 SHA-256을 사용하는 JWS 예제
A.3.1. 인코딩
이 예제의 JWS 보호된 헤더는 다른 알고리즘을 사용하므로
이전 예제와 다르다. 사용된 JWS 보호된 헤더는 다음과 같다:
{"alg":"ES256"}
이 예제에서의 UTF8(JWS 보호된 헤더)를 나타내는 옥텟은
(JSON 배열 표기법 사용) 다음과 같다:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Jones, et al. Standards Track [Page 43]
RFC 7515 JSON Web Signature (JWS) May 2015
이 JWS 보호 헤더를 BASE64URL(UTF8(JWS Protected
Header))로 인코딩하면 다음 값이 된다:
eyJhbGciOiJFUzI1NiJ9
이 예제에서 사용된 JWS 페이로드는 다음에 나오는 것으로,
이전 예제에서 사용된 것과 동일하다. 따라서
BASE64URL(JWS Payload) 값도 동일하므로,
여기서는 그 계산을 반복하지 않는다.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
이들을 BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)로 결합하면 다음 문자열이 된다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
결과로 생성된 JWS 서명 입력 값은,
위 문자열의 ASCII 표현이며,
다음과 같은 옥텟 시퀀스이다:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
이 예제에서는 아래에 나타낸 JSON Web Key
[JWK] 형식으로 표현된 타원 곡선 키를 사용한다:
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
그런 다음 ECDSA 개인 부분 d는 ECDSA 서명 함수에 전달되며,
이 함수는 곡선 유형 P-256, 해시 유형 SHA-256,
그리고 JWS 서명 입력을 입력으로 함께 사용한다.
디지털 서명의 결과는 타원 곡선
Jones, et al. Standards Track [Page 44]
RFC 7515 JSON Web Signature (JWS) May 2015
(EC) 점 (R, S)이며, 여기서 R과 S는 부호 없는 정수이다.
이 예제에서 R과 S 값은,
빅엔디언 정수를 나타내는 옥텟 시퀀스로서 다음과 같다:
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
JWS 서명은 값 R || S이다. 서명을
BASE64URL(JWS Signature)로 인코딩하면
다음 값이 생성된다
(표시 목적상 줄 바꿈이 포함되어 있다):
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
이러한 값들을 Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 넣어 연결하면,
JWS Compact Serialization을 사용한
완전한 JWS 표현이 된다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
A.3.2. 검증
"alg" 헤더 매개변수가 "ES256"이므로,
JWS 서명에 포함된 ECDSA
P-256 SHA-256 디지털 서명을 검증한다.
JWS 서명 검증은 이전 예제들과는 약간 다르다.
JWS 서명의 64개 멤버 옥텟 시퀀스
(JWS 표현에 인코딩된 값에서 base64url 디코딩된 것)를
두 개의 32옥텟 시퀀스로 분할해야 하며,
첫 번째는 R을, 두 번째는 S를 나타낸다.
그런 다음 공개 키 (x, y), 서명 (R, S),
그리고 JWS 서명 입력
(JWS Compact Serialization 표현에서
Jones, et al. Standards Track [Page 45]
RFC 7515 JSON Web Signature (JWS) May 2015
두 번째 마침표 문자 앞까지의 초기 부분이지만,
두 번째 마침표 문자는 포함하지 않음)을
SHA-256 해시 함수를 사용하는
P-256 곡선으로 구성된
ECDSA 서명 검증기에 전달한다.
A.4. ECDSA P-521 SHA-512를 사용하는 JWS 예제
A.4.1. 인코딩
이 예제의 JWS 보호 헤더는
이전 예제와 다른데,
이는 서로 다른 ECDSA 곡선과
해시 함수가 사용되기 때문이다.
사용된 JWS 보호 헤더는 다음과 같다:
{"alg":"ES512"}
이 예제에서 UTF8(JWS Protected Header)를 나타내는
옥텟들은 (JSON 배열 표기법을 사용하여)
다음과 같다:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
이 JWS 보호 헤더를
BASE64URL(UTF8(JWS Protected Header))로 인코딩하면
다음 값이 된다:
eyJhbGciOiJFUzUxMiJ9
이 예제에서 사용된 JWS 페이로드는
ASCII 문자열 "Payload"이다.
이 문자열의 표현은
다음과 같은 옥텟 시퀀스이다:
[80, 97, 121, 108, 111, 97, 100]
이 JWS 페이로드를
BASE64URL(JWS Payload)로 인코딩하면
다음 값이 된다:
UGF5bG9hZA
이들을 BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)로 결합하면
다음 문자열이 된다:
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
결과로 생성된 JWS 서명 입력 값은,
위 문자열의 ASCII 표현이며,
다음과 같은 옥텟 시퀀스이다:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85,
120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
Jones, et al. Standards Track [Page 46]
RFC 7515 JSON Web Signature (JWS) May 2015
이 예제에서는 JSON Web Key
[JWK] 형식으로 표현된
타원 곡선 키를 사용한다
(표시 목적상 값 내부에 줄 바꿈이 포함되어 있다):
{"kty":"EC",
"crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C"
}
그런 다음 ECDSA 개인 부분 d는
ECDSA 서명 함수에 전달되며,
이 함수는 곡선 유형 P-521,
해시 유형 SHA-512,
그리고 JWS 서명 입력을
입력으로 함께 사용한다.
디지털 서명의 결과는
EC 점 (R, S)이며,
여기서 R과 S는 부호 없는 정수이다.
이 예제에서 R과 S 값은,
빅엔디언 정수를 나타내는
옥텟 시퀀스로서 다음과 같다:
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+
JWS 서명은 값 R || S이다.
서명을 BASE64URL(JWS Signature)로 인코딩하면
다음 값이 생성된다
(표시 목적상 줄 바꿈이 포함되어 있다):
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Jones, et al. Standards Track [Page 47]
RFC 7515 JSON Web Signature (JWS) May 2015
이러한 값들을 Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 넣어 연결하면,
JWS Compact Serialization을 사용한
완전한 JWS 표현이 된다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJhbGciOiJFUzUxMiJ9
.
UGF5bG9hZA
.
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
A.4.2. 검증
"alg" 헤더 매개변수가 "ES512"이므로,
JWS 서명에 포함된
ECDSA P-521 SHA-512
디지털 서명을 검증한다.
이 JWS 서명 검증은
이전 예제와 매우 유사하다.
JWS 서명의 132개 멤버
옥텟 시퀀스를
두 개의 66옥텟 시퀀스로 분할해야 하며,
첫 번째는 R을,
두 번째는 S를 나타낸다.
그런 다음 공개 키 (x, y),
서명 (R, S),
그리고 JWS 서명 입력을
SHA-512 해시 함수를 사용하는
P-521 곡선으로 구성된
ECDSA 서명 검증기에 전달한다.
A.5. 무보안 JWS 예제
다음 JWS 보호 헤더 예제는
인코딩된 객체가
무보안 JWS임을 선언한다:
{"alg":"none"}
이 JWS 보호 헤더를
BASE64URL(UTF8(JWS Protected Header))로 인코딩하면
다음 값이 된다:
eyJhbGciOiJub25lIn0
이 예제에서 사용된 JWS 페이로드는
이전 예제에서 사용된 것과 동일하다.
따라서 BASE64URL(JWS Payload) 값도 동일하므로,
여기서는 그 계산을 반복하지 않는다.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWS 서명은 빈 옥텟 문자열이며,
BASE64URL(JWS Signature)는 빈 문자열이다.
Jones, et al. Standards Track [Page 48]
RFC 7515 JSON Web Signature (JWS) May 2015
이러한 값들을 Header.Payload.Signature 순서로,
각 부분 사이에 마침표('.') 문자를 넣어 연결하면,
JWS Compact Serialization을 사용한
완전한 JWS 표현이 된다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
A.6. 일반 JWS JSON 직렬화를 사용하는 JWS 예제
이 절에는
일반 JWS JSON 직렬화 구문을 사용하는
예제가 포함되어 있다.
이 예제는
동일한 페이로드에 대해
여러 디지털 서명 및/또는 MAC을
전달할 수 있는 기능을 보여준다.
이 예제에서 사용된 JWS 페이로드는
부록 A.2 및 부록 A.3의 예제에서
사용된 것과 동일하다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
이 예제에서는 두 개의 디지털 서명이 사용된다.
첫 번째는 RSASSA-PKCS1-v1_5 SHA-256을 사용하고,
두 번째는 ECDSA P-256 SHA-256을 사용한다.
첫 번째의 경우,
JWS 보호 헤더와 키는
부록 A.2와 동일하므로,
동일한 JWS 서명 값이 생성된다.
따라서 여기서는 그 계산을 반복하지 않는다.
두 번째의 경우에도,
JWS 보호 헤더와 키는
부록 A.3과 동일하므로,
동일한 JWS 서명 값이 생성되며,
따라서 여기서는 그 계산을 반복하지 않는다.
A.6.1. 서명별 JWS 보호 헤더
첫 번째 서명에 사용된
JWS 보호 헤더 값은 다음과 같다:
{"alg":"RS256"}
이 JWS 보호 헤더를
BASE64URL(UTF8(JWS Protected Header))로 인코딩하면
다음 값이 된다:
eyJhbGciOiJSUzI1NiJ9
두 번째 서명에 사용된
JWS 보호 헤더 값은 다음과 같다:
{"alg":"ES256"}
Jones, et al. Standards Track [Page 49]
RFC 7515 JSON Web Signature (JWS) May 2015
이 JWS 보호 헤더를
BASE64URL(UTF8(JWS Protected Header))로 인코딩하면
다음 값이 된다:
eyJhbGciOiJFUzI1NiJ9
A.6.2. 서명별 JWS 비보호 헤더
키 ID 값은
서명별 헤더 매개변수를 사용하여
두 키 모두에 대해 제공된다.
이 키 ID를 나타내는
두 개의 JWS 비보호 헤더 값은 다음과 같다:
{"kid":"2010-12-29"}
그리고
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. 전체 JOSE 헤더 값
제공된 JWS 보호 헤더와
JWS 비보호 헤더 값을 결합하면,
첫 번째 및 두 번째 서명에 사용된
JOSE 헤더 값은 각각 다음과 같다:
{"alg":"RS256",
"kid":"2010-12-29"}
그리고
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
Jones, et al. Standards Track [Page 50]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 완전한 JWS JSON 직렬화 표현
이러한 값들에 대한 완전한 JWS JSON 직렬화는 다음과 같다
(표시 목적상 값 내부에 줄 바꿈이 포함되어 있다):
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
Jones, et al. Standards Track [Page 51]
RFC 7515 JSON Web Signature (JWS) May 2015
A.7. 평탄화된 JWS JSON 직렬화를 사용하는 JWS 예제
이 절에는 평탄화된 JWS JSON 직렬화 구문을 사용하는 예제가 포함되어 있다.
이 예제는 단일 디지털 서명 또는 MAC을 평탄화된 JSON 구조로
전달할 수 있는 기능을 보여준다.
이 예제의 값들은 부록 A.6에 있는 이전 예제의
두 번째 서명에 있는 값들과 동일하다.
이러한 값들에 대한 완전한 JWS JSON 직렬화는 다음과 같다
(표시 목적상 값 내부에 줄 바꿈이 포함되어 있다):
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
Jones, et al. Standards Track [Page 52]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix B. "x5c"(X.509 인증서 체인) 예제
아래의 JSON 배열은 섹션 4.1.6에 따라
"x5c"(X.509 인증서 체인) 헤더 매개변수의 값으로 사용될 수 있는
인증서 체인의 예제이다
(표시 목적상 값 내부에 줄 바꿈이 포함되어 있다):
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
...
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
Jones, et al. Standards Track [Page 54]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix C. 패딩 없는 base64url 인코딩 구현에 대한 참고 사항
이 부록은 패딩을 사용하는 표준 base64 인코딩 및 디코딩 함수를
기반으로, 패딩 없이 base64url 인코딩 및 디코딩 함수를 구현하는
방법을 설명한다.
구체적으로, 이러한 함수를 구현한 C# 코드 예제가
아래에 제시되어 있다. 유사한 코드는 다른 언어에서도 사용할 수 있다.
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // 일반 base64 인코더
s = s.Split('=')[0]; // 끝의 '=' 제거
s = s.Replace('+', '-'); // 인코딩의 62번째 문자
s = s.Replace('/', '_'); // 인코딩의 63번째 문자
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 인코딩의 62번째 문자
s = s.Replace('_', '/'); // 인코딩의 63번째 문자
switch (s.Length % 4) // 끝에 '='로 패딩
{
case 0: break; // 이 경우 패딩 없음
case 2: s += "=="; break; // 두 개의 패딩 문자
case 3: s += "="; break; // 하나의 패딩 문자
default: throw new System.Exception(
"잘못된 base64url 문자열!");
}
return Convert.FromBase64String(s); // 표준 base64 디코더
}
위의 예제 코드에서 보듯이, 패딩이 없는 base64url 인코딩 문자열의
끝에 추가되어야 하는 '=' 패딩 문자의 개수는 인코딩된 문자열의
길이에 의해 결정되는 함수이다. 구체적으로,
길이를 4로 나눈 나머지가 0이면 패딩을 추가하지 않고,
나머지가 2이면 '=' 패딩 문자 두 개를 추가하며,
나머지가 3이면 '=' 패딩 문자 하나를 추가한다.
나머지가 1이면 입력은 잘못된 것이다.
Jones, et al. Standards Track [Page 55]
RFC 7515 JSON Web Signature (JWS) May 2015
인코딩되지 않은 값과 인코딩된 값 간의 대응 예제는 다음과 같다.
아래의 옥텟 시퀀스는 아래의 문자열로 인코딩되며,
이를 디코딩하면 옥텟 시퀀스가 다시 재현된다.
3 236 255 224 193
A-z_4ME
Appendix D. 키 선택에 대한 참고 사항
이 부록은 JWS의 디지털 서명 또는 MAC을 검증하는 데 사용될 키,
또는 JWE를 복호화하는 데 사용될 키를 선택하기 위한
가능한 알고리즘들의 집합을 설명한다.
이 지침은 단일 알고리즘이 아니라 가능한 알고리즘 계열을 설명하는데,
이는 서로 다른 맥락에서 모든 키 소스가 사용되지는 않으며,
서로 다른 순서로 시도될 수 있고,
때로는 수집된 모든 키가 시도되지 않기 때문이다.
따라서 서로 다른 애플리케이션 맥락에서는
서로 다른 알고리즘이 사용된다.
아래의 단계들은 설명을 위한 예시일 뿐이며,
특정 애플리케이션은 다른 알고리즘을 사용하거나
단계의 순서를 다르게 수행할 수 있다.
많은 애플리케이션에서는 사용할 키를 결정하는 훨씬 단순한 방법을
갖게 되는데, 이는 애플리케이션 사용에 맞게 프로파일링된
하나 또는 두 개의 키 선택 방법이 존재할 수 있기 때문이다.
이 부록은 섹션 6의 키 위치에 대한
규범적 정보를 보완한다.
이러한 알고리즘에는 다음과 같은 단계들이 포함된다.
단계들은 어떤 순서로든 수행될 수 있으며,
반드시 구분된 단계로 취급될 필요는 없다.
예를 들어, 모든 키를 수집한 후에 시도하는 대신,
키를 발견하는 즉시 시도할 수도 있다.
1. 잠재적으로 적용 가능한 키 집합을 수집한다.
키의 소스에는 다음이 포함될 수 있다:
* 사용 중인 애플리케이션 프로토콜에서 제공되는 키.
* "jku"(JWK Set URL) 헤더 매개변수가 참조하는 키.
* "jwk"(JSON Web Key) 헤더 매개변수가 제공하는 키.
* "x5u"(X.509 URL) 헤더 매개변수가 참조하는 키.
* "x5c"(X.509 인증서 체인) 헤더 매개변수가 제공하는 키.
* 애플리케이션에서 사용 가능한 기타 키.
Jones, et al. Standards Track [Page 56]
RFC 7515 JSON Web Signature (JWS) May 2015
서로 다른 키 소스로부터 키를 수집하고 시도하는 순서는
일반적으로 애플리케이션에 따라 달라진다.
예를 들어, 종종 로컬 캐시와 같은 한 위치 집합의 모든 키를
먼저 시도한 후, 다른 위치에서 키를 수집하고 시도한다.
2. 수집된 키 집합을 필터링한다.
예를 들어, 일부 애플리케이션은 "kid"(키 ID) 또는
"x5t"(X.509 인증서 SHA-1 지문) 매개변수가 참조하는 키만
사용할 수 있다.
애플리케이션이 JWK의 "alg"(알고리즘),
"use"(공개 키 사용),
또는 "key_ops"(키 작업) 매개변수를 사용하는 경우,
해당 매개변수 값이 부적절한 키는 제외된다.
또한 애플리케이션별 방식으로 특정 다른 멤버 값을
포함하거나 제외하도록 키를 필터링할 수도 있다.
일부 애플리케이션에서는 필터링이 적용되지 않는다.
3. 수집된 키 집합을 정렬한다.
예를 들어, "kid"(키 ID) 또는
"x5t"(X.509 인증서 SHA-1 지문) 매개변수가 참조하는 키는
이러한 값이 없는 키보다 먼저 시도될 수 있다.
마찬가지로, 특정 멤버 값을 가진 키가
다른 멤버 값을 가진 키보다 먼저 정렬될 수 있다.
일부 애플리케이션에서는 정렬이 적용되지 않는다.
4. 키에 대한 신뢰 결정을 내린다.
애플리케이션의 신뢰 기준을 충족하지 않는 키로 생성된 서명은
허용되지 않는다.
이러한 기준에는 키의 출처, URL에서 검색된 키에 대해
TLS 인증서가 유효한지 여부,
X.509 인증서의 키가 유효한 인증서 체인에 의해
뒷받침되는지 여부,
그리고 애플리케이션이 알고 있는 기타 정보가 포함될 수 있으나,
이에 국한되지는 않는다.
5. 수집되고, 필터링되었으며,
그리고/또는 정렬된 키 중 일부 또는 전부를 사용하여
JWS의 서명 또는 MAC 검증을 시도하거나
JWE의 복호화를 시도한다.
시도할 키의 개수에 제한이 적용될 수 있다.
이 과정은 일반적으로 검증 또는 복호화가
성공적으로 완료되면 종료된다.
일부 애플리케이션에서는 키에 대한 신뢰 결정을 내리기 전에
서명 또는 MAC 검증을 수행하는 것이 합리적일 수 있는데,
이는 검증에 실패한 키에 대해서는
신뢰 결정을 내릴 필요가 없기 때문이다.
Jones, et al. Standards Track [Page 57]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix E. "crit" 헤더 매개변수에 대한 부정 테스트 케이스
적합한 구현은 이해할 수 없거나 처리할 수 없는
중요 확장을 포함하는 입력을 반드시 거부해야 한다.
다음 JWS는 이해할 수 없는
"http://example.invalid/
UNDEFINED"라는
확장 헤더 매개변수 이름을 사용하므로,
모든 구현에서 반드시 거부되어야 한다.
구현에서 이해할 수 없는 다른 어떤 헤더 매개변수 이름 대신
"http://example.invalid/UNDEFINED" 값을
사용하는 유사한 입력 또한 반드시 거부되어야 한다.
이 JWS의 보호된 헤더 값은 다음과 같다:
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
반드시 거부되어야 하는 완전한 JWS는 다음과 같다
(표시 목적상 줄 바꿈이 포함되어 있다):
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU
ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
RkFJTA.
Appendix F. 분리된 콘텐츠
일부 맥락에서는 JWS 자체에 포함되지 않은 콘텐츠의 무결성을
보호하는 것이 유용하다.
이를 위한 한 가지 방법은,
콘텐츠의 표현을 페이로드로 사용하여
일반적인 방식으로 JWS를 생성한 다음,
JWS에서 페이로드 표현을 삭제하고
수정된 객체를 JWS 대신 수신자에게 보내는 것이다.
JWS Compact 직렬화를 사용하는 경우,
두 번째 필드(즉, BASE64URL(JWS Payload)를 포함하는 필드)의 값을
빈 문자열로 대체함으로써 삭제가 이루어진다.
JWS JSON 직렬화를 사용하는 경우,
"payload" 멤버를 삭제함으로써 삭제가 이루어진다.
이 방법은 수신자가 JWS에 사용된 정확한 페이로드를
재구성할 수 있다고 가정한다.
수정된 객체를 사용하기 위해,
수신자는 페이로드 표현을 수정된 객체에 다시 삽입하여
JWS를 재구성하고,
결과로 생성된 JWS를 일반적인 방식으로 사용한다.
이 방법은 JWS 라이브러리의 지원이 필요 없으며,
애플리케이션은 표준 JWS 라이브러리의
입력과 출력을 수정함으로써
이 방법을 사용할 수 있다.
Jones, et al. Standards Track [Page 58]
RFC 7515 JSON Web Signature (JWS) May 2015
감사의 말
JSON 콘텐츠에 서명하기 위한 솔루션은 이전에
Magic Signatures [MagicSignatures],
JSON Simple Sign [JSS],
그리고 Canvas Applications [CanvasApp]에서
탐구되었으며, 이들 모두가 본 문서에 영향을 미쳤다.
JWS 및 JWE 사양에 대한 초기 구현과 피드백을 제공해 준
Axel Nennker에게 감사를 표한다.
이 사양은 JOSE 작업 그룹의 산물이며,
수십 명의 활발하고 헌신적인 참가자들이 포함되어 있다.
특히 다음 인물들이 본 사양에 영향을 준
아이디어, 피드백, 그리고 문구에 기여하였다:
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben
Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony
Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel
Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes
Tschofenig, 그리고 Sean Turner.
Jim Schaad와 Karen O'Donoghue는 JOSE 작업 그룹의 의장을 맡았으며,
Sean Turner, Stephen Farrell, 그리고 Kathleen Moriarty는
이 사양이 작성되는 동안 보안 영역 디렉터로 활동하였다.
저자 주소
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Jones, et al. Standards Track [Page 59]