요약

  • RFC 3741은 추출된 조각에 대한 XML 서명이 무관한 상위 네임스페이스 컨텍스트에 덜 민감하도록, 네임스페이스 선언을 요소 또는 속성 이름에 그 접두사가 눈에 보이게 사용되는 곳에서 주로 렌더링하도록 만들었다.
  • 그렇다고 조각이 애플리케이션이 사용할 수 있는 모든 컨텍스트로부터 독립해진 것은 아니다. 상속된xml:속성과 값 안에만 내장된 접두사는 재봉입(enveloping) 후에도 해석을 바꿀 수 있다.

메시지 래퍼는 페이로드의 서명을 다시 쓰면 안 된다

어떤 프로토콜이 큰 메시지 안의 작은 XML 요소에 서명한다고 가정하자. 게이트웨이가 바깥 래퍼를 제거하고, 다른 서비스가 그 동일한 요소를 새 봉투 안에 넣는다. 포괄적(inclusive) 정준 XML에서는 상위 네임스페이스 선언과 선택된xml:속성이 서명된 요소가 사용하지 않더라도 정준 바이트 스트림에 들어올 수 있다. 따라서 래퍼의 변경만으로도 다이제스트 입력이 달라져, 그 외에는 전혀 바뀌지 않은 조각에 대한 서명이 깨질 수 있다.

2004년 3월에 발행된 RFC 3741은 바로 그 마찰을 다루었다. 이 RFC는 XPath 노드 집합에 대한 직렬화 방법으로 배타적(exclusive) XML 정준화를 정의했다. 상속된 대부분의 네임스페이스 컨텍스트를 가져오는 대신, 하위 집합이 어떤 바인딩의 접두사를 요소 또는 속성 이름에 눈에 보이게 사용할 때에만 그 네임스페이스 바인딩을 렌더링한다. 선택 사항인InclusiveNamespaces PrefixList는 그 규칙에도 불구하고 포괄적으로 처리해야 하는 접두사를 지정할 수 있다. 목표는 무관한 래퍼를 각각의 정준 형식에 포함시키지 않으면서, 서명된 하위 문서가 추출과 다른 봉투에의 삽입을 견디게 하는 것이었다.

이는 경계 결정이지 컨텍스트에 무관한 의미에 대한 보장이 아니다. RFC 3741 자신의 한계와 보안 논의에서 그렇게 말한다. 이는 XML 서명이 실제로 무엇을 다루는지 묻는 RFC 3075의 문제, 파싱 후 노드 집합을 정준화하는 방법을 기술하는 RFC 3076과도 구별된다. RFC 3741이 묻는 것은 선택된 하위 집합이 이동할 때 어떤 컨텍스트를 유지할 것인가이다.

“보이는(Visible)”은 유용한 기준이면서도 좁은 기준이다

이 알고리즘의 가시적 사용 규칙은 XML 이름을 따른다. 어떤 요소가 접두사n1을 사용하거나 속성 이름이n1을 사용하면,n1에 대한 바인딩은 그 요소를 렌더링하는 데 관련이 있다. 이런 이름에 사용되지 않는 상속된 접두사는 생략할 수 있다. 이는 종종 잡음을 제거한다. SOAP 또는 프로토콜 래퍼는 래퍼에는 필요하지만 추출된 페이로드에는 무관한 네임스페이스를 선언할 수 있기 때문이다. 배타적 정준화는 그러면 두 봉투 모두에서 페이로드에 대해 동일한 정준 바이트를 만들어 낼 수 있다.

그러나 애플리케이션 의미가 선택된 노드 집합에서 QName으로는 보이지 않는 정보에 의존할 수 있다. 속성 값이 접두사 바인딩이 중요한 XPath 식을 담고 있을 수 있다. 애플리케이션은 XPath가 문자열 값으로만 보더라도xsi:type="xsd:decimal"같은 문자열을 QName으로 다룰 수 있다. 배타적 XML 정준화에서는 어떤 요소 또는 속성 이름도xsd를 눈에 보이게 사용하지 않고 포괄적 접두사 목록에 없다면xsd바인딩은 생략될 수 있다. 그러면 수신 애플리케이션은 새 봉투에서 그 값을 다르게 해석할 수 있다.

이 표준은 그 의존성을 관리하는 세 가지 방법을 기술한다. 접두사 사용을 XML 구조에서 보이게 만들거나, 모든 해석 컨텍스트에서 동일한 바인딩이 나타나도록 보장하거나, 접두사를InclusiveNamespaces PrefixList에 포함하는 것이다. 각각은 계약상의 선택이다. 이 목록은 숨겨진 QName 의미를 위한 마법의 탐지기가 아니며, 어떤 값이 네임스페이스에 민감한 의미를 담는지는 애플리케이션 설계자가 이미 알아야 한다.

바이트에서 생략된 컨텍스트도 여전히 읽는 이를 지배할 수 있다

배타적 정준화는 또한 조상의xml:lang,xml:space,xml:base값을 고아가 된 하위 집합에 복사하지 않기로 의도적으로 결정했다. 이 속성들은 언어 선택, 공백 처리, 상대 참조의 해석에 영향을 줄 수 있다. RFC 3741은 애플리케이션이 필요한 값을 하위 집합 내의 노드에 두거나, 그 하위 집합이 해석될 모든 컨텍스트에서 동등한 값이 존재하도록 보장할 것을 요구한다.

표준의 대상 컨텍스트 예제는 더 날카로운 경고다. 조각의 정준 옥텟은 새 기본 네임스페이스 선언 아래로 옮겨져도 바뀌지 않을 수 있다. 그러나 대상 애플리케이션은 접두사 없는 요소를 다른 네임스페이스에 연결해 다른 종류의 객체로 다룰 수 있다. 선택된 옥텟이 바뀌지 않았기 때문에 서명은 여전히 검증된다. 해석이 바뀌는 것은 목적지 컨텍스트가 바뀌었기 때문이다.

RFC 3741은 네임스페이스 선언을 추출하거나 삽입하거나 복구하는 규칙을 지정하지 않으며, 수신 애플리케이션이 그 작업을 승인하는지 여부도 결정하지 않는다. 프로토콜이 관련 컨텍스트를 어떻게 운반하고, 소비자가 그 결과 노드로 무엇을 해야 하는지를 정의해야 한다. 암호학적 무결성은 그 경로의 한 부분일 뿐이다.

더 작은 서명 경계는 더 큰 통합 책무를 만든다

배타적 정준화는 래퍼 컨텍스트에 대한 우발적 의존을, 의미 의존성을 명시적으로 목록화할 의무로 교환했다. 서명된 조각을 전달하는 프로토콜에서 검토자는 서명이 검증되는지만이 아니라, 조각의 네임스페이스 바인딩,xml:속성, QName 값 필드, 상대 참조가 목적지에서 동일한 의미를 갖는지도 확인해야 한다. 이 사실들이 암묵적으로 남아 있으면, 서명 안정성이 의미적 안정성처럼 보일 수 있으나 두 속성은 별개다.

이는 특정 익스플로잇이나 구현 실패의 증거가 아니라 사양 수준의 위험 모델이다. RFC 3741은 Informational이며, 이 RFC는 알고리즘의 목적과 한계를 확립하지만 특정 구현이 얼마나 널리 배포되었는지나 특정 서비스가 그것을 잘못 다루었는지는 확립하지 않는다. 남는 교훈은 더 좁다. 서명된 바이트에서 컨텍스트를 제거하는 것은 이동성을 높일 수 있지만, 생략된 컨텍스트 중 어느 것이 여전히 해석을 지배하는지는 오직 애플리케이션만이 판별할 수 있다.

출처