요약

  • RFC 7515는 보호된crit목록이 검증자가 이해하고 지원하지 않는 확장을 가리키는 경우, 서명 계산이 성공하더라도 검증자가 해당 JWS를 거부하도록 요구합니다.
  • crit는 의미적 상호운용성을 보호합니다. 오래되었거나 불완전한 구현이 규칙이 변경된 메시지를 평범한 JWS로 조용히 처리하는 일을 막습니다.
  • 암호학적 유효성, 확장 처리, 애플리케이션 승인은 각각 다른 소유자와 근거 경로를 지닌 세 개의 별개 결정입니다.

서명만으로는 충분하지 않았던 사례

검증자가 올바르게 인코딩된 컴팩트한 JWS를 받는 상황을 상상해 보십시오. 검증자는 서명 입력을 재구성하고, 표시된 알고리즘을 선택하고, 올바른 키를 확보합니다. 서명 바이트가 일치합니다. 많은 대시보드는 이 시점에서 해당 이벤트를 녹색으로 표시할 것입니다. 그런데 보호된 헤더에는 메시지 해석 방식을 바꾸는 파라미터가 포함되어 있고, 그 파라미터의 이름이crit에 등재되어 있습니다. 검증자는 이를 구현한 적이 없습니다.

RFC 7515는 이를 무시하는 태도를 허용하지 않습니다. 그 구현에게 JWS는 무효입니다. 검증자는 해당 확장을 무시하거나, 녹색 서명 결과를 유지하거나, 익숙한 의미론으로 계속 진행할 수 없습니다. 수학적 결과는 바이트와 키에 관한 사실로 남습니다. 그것은 검증자가 서명된 진술을 이해했다고 가장할 허가가 아닙니다.

이것이 바로 Critical Header Parameter(필수 헤더 파라미터)의 존재 이유입니다. 그 값은 헤더 파라미터 이름의 배열입니다. 각 이름은 JOSE 헤더에 존재하며 그 처리가 필수인 확장을 식별합니다. 이 중 하나라도 이해하고 지원하지 않는 수신자는 JWS를 거부해야 합니다. 이 목록 자체가 보호된 헤더에 위치해야 하는데, 무엇이 필수인지에 대한 보호되지 않은 선언은 서명을 무효화하지 않고 변경될 수 있기 때문입니다.

규칙은 의도적으로 좁습니다. 목록은 비어 있을 수 없고, 이름을 반복하거나 JOSE 헤더에 존재하지 않는 파라미터를 인용할 수 없습니다. 이 목록은 확장을 위한 것이며, JWS나 JWA가 이미 정의한 파라미터를 다시 나열하기 위한 것이 아닙니다. critical로 표시되지 않은 알 수 없는 헤더 파라미터는 일반적으로 무시할 수 있습니다.crit목록은 낯선 메타데이터를 필수 의미적 의존성으로 바꾸는 장치입니다.

헌법적 규칙을 담은 작은 필드

Nat Sakimura는 RFC 7515에 명시된 세 저자 중 한 명으로, Michael B. Jones와 John Bradley와 함께 이름을 올렸습니다. 이 문서는 웹 시스템에 클레임과 기타 콘텐츠를 보호하는 컴팩트한 방법을 제공한 JOSE 계열의 중심에 위치합니다. Sakimura의 폭넓은 표준 활동과 OpenID Foundation에서의 역할은 그를 반복되는 제도적 문제 안에 놓입니다. 프로토콜이 진화하면서도, 두 명의 준수하는 참여자가 동일한 서명된 객체에 서로 양립할 수 없는 의미를 부여하는 일을 어떻게 막을 것인가.

crit의 우아한 해답은 미래의 의미를 등록하는 레지스트리가 아닙니다. 의미가 바뀔 때 누가 진행할 수 있는지에 관한 규칙입니다. 생산자는 이 특정 JWS에 어떤 확장이 필수적인지 선언합니다. 수신자는 실제로 그것들을 이해하고 처리함으로써 능력을 증명합니다. 어느 쪽도 그 핸드셰이크를 서명 일치라는 관찰로 대체할 수 없습니다.

이 설계는 확장 저자에게도 규율을 부과합니다. 단순히 선택적 조언을 제공하는 새 파라미터는 무시 가능한 상태로 남을 수 있습니다. 메시지의 구성, 해석 또는 보안 속성을 변경하는 파라미터는 그 정의 명세 또는 애플리케이션 프로파일에 따라 반드시 critical로 지정되어야 합니다. 생산자가 그 선언을 생략하면, 인지하지 못한 검증자가 오래된 규칙 아래에서 객체를 수용할 수 있습니다. 생산자가 모든 것을 critical로 표시하면 우아한 상호운용성이 파괴됩니다. 따라서 이 목록은 심각도 표시가 아니라 정밀한 호환성 경계입니다.

RFC 7515의 검증 절차는 이 점을 강화합니다. 수신자는 보호된 헤더의 인코딩을 검증하고, 필수 필드와 값이 이해되는지 확인하고, 서명 입력을 구성하고, 암호 연산을 검증합니다. 이것들은 서로 연관된 테스트이지만 동의어가 아닙니다.valid라는 단일 불리언만 반환하는 라이브러리 API는 어떤 테스트가 실패했는지 지울 수 있고, 호출자에게 성공한 암호학을 성공한 처리로 취급하도록 유혹할 수 있습니다.

b64:false는 왜 무지가 실패로 닫혀야 하는지 보여 줍니다

RFC 7797이 가장 명확한 구체적 사례를 제공합니다. 평범한 JWS 처리는 페이로드를 서명 입력에 포함하기 전에 base64url로 인코딩합니다. 그보다 나중의b64확장은 보호된 값이false일 때 인코딩되지 않은 페이로드를 허용합니다. 이는 서명이 계산되는 바이트를 바꾸고, 직렬화된 형태에서 페이로드가 이동하는 방식을 바꿉니다.

그런 이유로b64:false를 사용하는 JWS는 반드시crit에b64를 등재해야 합니다. RFC 7515는 알지만 RFC 7797은 모르는 검증자는 그 필수 이름을 보고 객체를 거부합니다. 평범한 페이로드 인코딩이 적용되는 것처럼 객체를 처리하지 않습니다. 이 거부는 생산적입니다. 겉보기에 유효한 서명이 두 개의 양립 불가능한 해석 사이를 다리하는 일을 막습니다.

이 확장은 원시 연산 너머의 경계도 드러냅니다. 애플리케이션 프로파일은 주변 시스템이 안정적으로 구분할 수 없는 곳에서 인코딩된 페이로드와 인코딩되지 않은 페이로드를 혼용하지 않도록 설정을 일관되게 사용하라는 권고를 받습니다. 일부 페이로드 옥텟은 컴팩트 직렬화에서 주의를 요합니다. 그리고 JSON Web Token은 인코딩되지 않은 페이로드 옵션을 사용하는 것이 금지되어 있습니다. 범용 JWS 라이브러리는b64:false를 올바르게 구현할 수 있지만, JWT 애플리케이션은 여전히 그 사용을 거부해야 합니다.

따라서 최소한 세 가지 질문이 있습니다. 서명 연산은 성공했는가? JOSE 프로세서는 모든 필수 확장을 이해하고 올바르게 적용했는가? 애플리케이션 프로파일은 이 메시지 유형에 대해 이 조합을 허용하는가? 하나의 녹색 답을 다른 두 칸에 복사할 수는 없습니다.

알고리즘도 또 하나의 수용 경계입니다

RFC 7518은 JOSE가 사용하는 알고리즘과 식별자를 정의하지만, 인식은 수용 가능성과 동일하지 않습니다. RFC 7515는 어떤 알고리즘이 그 맥락에서 수용 가능한지를 애플리케이션의 판단에 맡깁니다. 검증자는 알고리즘 검증을 기술적으로 수행하고 올바른 서명을 얻으면서도, 정책이 그 알고리즘, 키, 파라미터 집합 또는 배포를 거부할 수 있습니다.

RFC 8725는 이 운영상의 교훈을 JWT 배포에 대해 명시합니다. 구현은 수용 가능한 알고리즘의 허용 목록을 갖추어야 하며, 공격자가 통제하는 입력만으로 검증 방법을 선택해서는 안 됩니다. 발급자, 주제, 청중 및 기타 애플리케이션 규칙을 검증해야 합니다. 서로 다른 종류의 JWT는 상호 배타적인 검증 규칙을 요구할 수 있어, 한 목적을 위해 생성된 토큰이 다른 목적의 토큰과 혼동되지 않도록 합니다.

crit는 이러한 검사를 대체하지 않습니다. 그것은 수신자에게 특정 확장 의미론이 필수임을 알립니다. 발급자가 신뢰되는지, 청중이 이 서비스를 지명하는지, 클레임이 신선한지, 요청된 거래가 허용되는지를 보증하지 않습니다. 또한 양쪽 종단점이 확장의 이름을 인식한다는 이유만으로 그 확장을 안전하게 만들지 않습니다. 이해는 판단의 전제이지 판단의 대체물이 아닙니다.

다중 서명은 결정을 붕괴시키지 않습니다

JWS의 JSON 직렬화는 두 개 이상의 서명을 운반할 수 있습니다. RFC 7515는 애플리케이션이 다중 서명을 가진 JWS가 수용 가능한지, 그리고 어떤 서명이 검증되어야 하는지를 판단해야 한다고 말합니다. 일반 검증 설명에서는 객체가 유효하다고 간주되려면 최소한 하나의 서명이 검증되어야 합니다. 더 엄격한 프로파일은 더 많은 것을 요구할 수 있습니다.

각 서명은 자신의 보호된 헤더, 따라서 자신의 필수 확장을 가질 수 있습니다. 이는 시스템이 하나의 전역적 "암호 통과" 비트를 계산하고 그것을 낳은 경로를 버리는 것이 안전하지 않음을 의미합니다. 한 서명은 이해되고 수용 가능할 수 있고, 다른 서명은 암호학적으로 올바르지만 의미적으로 지원되지 않을 수 있으며, 세 번째는 키 또는 알고리즘 정책에 의해 거부될 수 있습니다. 애플리케이션의 임계 규칙이 그 집합의 의미를 결정합니다.

이것이 마이그레이션에서 중요합니다. 팀은 호환성을 위해 오래된 서명을 유지하면서 새 알고리즘이나 보호된 헤더 확장을 도입할 수 있습니다. 수용 로직이 어떤 서명이 통과했는지 기록하지 않고 통과 여부만 말한다면, 호환성 다리가 영구적인 다운그레이드 경로가 될 수 있습니다. 모든 소비자가 확장을 이해함을 보장하지 않고 둘 다를 요구하면 배포는 장애가 됩니다. 프로토콜이 표현력을 제공합니다. 배포가 명시적인 전환 규칙을 제공해야 합니다.

감사 기록에는 세 개의 판정이 필요합니다

유용한 검증자 기록은 프로토콜이 만든 구분을 보존해야 합니다. 첫째는 암호학적 근거입니다. 직렬화, 서명 입력 구성, 알고리즘, 키 참조, 서명 결과. 둘째는 JOSE 처리입니다. 보호된 헤더 파싱, 중복 이름 처리, 인식된 필수 파라미터, 각각을 처리한 코드 경로. 셋째는 애플리케이션 수용입니다. 발급자와 청중 정책, 메시지 프로파일, 클레임 제약, 승인 결정, 그 결과로 나타난 행동.

이러한 기록은 키, 토큰 또는 민감한 클레임을 노출할 필요가 없습니다. 안정적인 식별자와 사유 코드가 필요할 뿐입니다. 서명이 일치했지만 필수 확장이 지원되지 않았을 때 "유효하지 않은 서명"은 잘못된 설명입니다. JOSE 처리는 통과했지만 청중 또는 거래 정책이 실패했을 때 "유효한 토큰"은 위험하게 불완전합니다. 정밀성은 인시던트 검토 중에 단지 도움이 되는 것이 아니라, 운영자가 키 문제, 확장 배포, 승인 규칙 중 무엇을 고칠지 결정합니다.

crit라는 이름은 그것이 위험한 필드를 표시하는 것처럼 피상적으로 읽히도록 부추길 수 있습니다. 그 더 깊은 기능은 인식론적입니다. 그것은 서명자가 이렇게 말할 수 있게 합니다. 이 의미론을 이해하지 못하면, 나는 무엇을 서명했는지 이해하지 못한 것입니다. Sakimura와 그의 공동 저자들은 그 주장을 서명된 봉투 안에서 강제 가능하게 만들었습니다. 시스템은 올바른 암호학적 결과가 결여된 의미적 능력을 압도하지 못하도록 막을 때만 그것을 존중합니다.

출처