요약

  • RFC 3982는 빈 레지스트리 값에 두 가지 서로 다른 설명을 부여했습니다.private은 해당 내용이 영원히 공개되지 않을 수 있음을,denied는 정책이 요청자의 현재 접근 수준에서 공개를 보류했음을 의미했습니다.
  • 또한 공개된 값에는specialAccess와doNotRedistribute자격을 부여하여 데이터를 볼 수 있는 권한과 그 데이터를 유통할 수 있는 권한을 분리했습니다. 이 라벨들은 정책을 전달했을 뿐, 암호적으로나 법적으로 그것을 강제하지는 않았습니다.

빈 연락처 필드가 있는 도메인 등록 기록을 생각해 보십시오. 어뷰즈 대응 담당자는 이를 "연락처가 존재하지 않는다"고 읽을 수 있습니다. 개인정보 보호 담당자는 "연락처가 존재하지만 보호되고 있다"고 읽을 수 있습니다. 인증된 조사자는 "내 현재 계정에는 접근 권한이 없다"고 읽을 수 있습니다. 이는 사소한 차이가 아닙니다. 서로 다른 에스컬레이션 경로, 서로 다른 증거 진술, 그리고 다른 요청이 성공할 수 있는지에 대한 서로 다른 판단으로 이어집니다.

RFC 3982는 바로 이 모호성을 프로토콜 데이터로 만들었습니다. 이상태 기록,정정 기록,Datatracker 기록은 2005년 1월의 Standards Track 사양을 IRIS 계열에 위치시킵니다. 이 사양은 도메인 레지스트리 유형, 즉 도메인, 호스트, 연락처, 등록 대행자, 등록 기관을 위한 구조화된 질의와 결과를 정의했습니다. 그러나 그 가장 오래 살아남은 아이디어는 전체 시스템보다 작은 것이었습니다. 부재에 유형이 생긴 것입니다.

그 요구 사항은 이미 문서화되어 있었습니다.RFC 3707은 자신의상태,정정 기록,Datatracker 기록과 함께, Cross Registry Internet Service Protocol이 표현해야 할 내용을 기술했습니다. 운영자는 설명 없이 값을 생략하거나, 권한이 부족하다고 명시하거나, 권한과 무관하게 개인정보가 공개를 막는다고 명시할 수 있었습니다. 값이 반환될 경우 프로토콜은 재배포 금지 및 특수 접근 부여라는 두 라벨을 지원해야 했으며, 둘은 동시에 적용될 수 있었습니다.

이 어휘는 기본 프로토콜의 실제 한계에 대한 답이었습니다.RFC 3912는 WHOIS를 TCP 포트 43 위의 텍스트 요청·응답으로 문서화했습니다. 그상태 페이지,정정 페이지,Datatracker 기록은 구조화된 필드 모델을 기술하지 않습니다. 사양 자체가 WHOIS에는 강한 보안, 접근 제어, 무결성, 기밀성이 없다고 밝힙니다. 운영자는 사람이 읽는 응답에 정책 문구를 넣을 수 있었지만, 전송 프로토콜은 누락된 필드의 사유를 파서, 캐시, 내보내기를 거치며 보존할 공통의 기계 판독 가능한 방법을 제공하지 않았습니다.

RFC 3982의 개인정보 라벨은 유형화된 결과 값에 적용되었습니다. 관련 요소는 내용과 함께 존재하거나 nil 내용으로 존재할 수 있었습니다. 내용 없이 나타나는 경우, 두 부울 속성 중 하나 이상을 반드시 가져야 했습니다.private은 내용이 영원히 공개되지 않을 수 있기 때문에 없다고 말했고,denied는 정책이 현재 접근 수준에서 공개를 허용하지 않는다고 말했습니다.

시간적 차이가 중요합니다.private은 지속적인 공개 경계를 기술했습니다. 더 높은 권한의 자격 증명으로 다시 요청한다고 바뀌리라는 보장은 없었습니다.denied는 정책과 현재 접근 맥락 사이의 관계를 기술했습니다. 다른 인증된 계급은 그 값을 받을 수 있도록 허용될 수 있었습니다. 어느 라벨도 데이터가 레지스트리에서 누락되었다는 의미가 아니었으며, 생략된 요소는 여전히 표준화된 설명이 없었습니다.

반환된 내용에는 자체적인 라벨 쌍이 있었습니다.specialAccess는 수신자가 특수 접근 권한을 보유하고 있기 때문에 값이 제공되었다고 말했고,doNotRedistribute는 내용을 다른 곳으로 전달해서는 안 된다고 말했습니다. 하나는 수신자가 데이터를 볼 수 있는 이유에 관한 것이고, 다른 하나는 수신자가 다음에 해야 할 일에 관한 것이었습니다. 사양은 특권 접근과 하류 처리가 서로 다른 판단이므로 두 라벨을 함께 허용했습니다.

바로 이 지점에서 많은 현대 데이터 파이프라인이 조용히 프로토콜의 의미를 반전시킵니다. XML이 관계형 행으로 변환되고, 빈 값이 빈 문자열이 되며, 속성이 사라집니다. 또는 특권 값을 스프레드시트에 복사하면서 재배포 금지 지시를 뒤에 두고 갑니다. 눈에 보이는 셀은 살아남지만 정책 상태는 그렇지 않습니다. 따라서 시스템은 문법적으로 충실하면서 운영적으로 거짓이 될 수 있습니다.

라벨은 마법의 강제 수단이 아니었습니다. RFC 3982는 IRIS 이상의 새로운 보안 조치를 추가하지 않았습니다.RFC 3981과 그상태 기록은 질의 권한을 코어에 두고 인증과 개인정보 보호를 애플리케이션 전송 계층에 맡겼습니다.RFC 3983과 그상태 페이지는 BEEP 전송 매핑을 제공했습니다. 부울 속성은 규격 준수 클라이언트에게 이후 재배포가 금지되었음을 알릴 수는 있었지만, 복제를 막거나, 계정을 인증하거나, 세션을 암호화하거나, 법적 의무를 만들거나, 강제가 이루어질 것임을 증명할 수는 없었습니다.

그럼에도 도메인 스키마는 필드 수준의 상태를 유용하게 만들었습니다. RFC 3982는 도메인 상태, 수명 주기 날짜, 연락처 정보, 호스트, 권한 참조를 구조화된 요소로 표현했습니다. 정책 라벨은 자신이 한정하는 값과 함께 이동했습니다. 이 배치는 모든 필드를 하나의 공개 범주에 밀어 넣는 페이지 수준의 개인정보 플래그를 피했습니다. 또한 하나의 결과가 평범한 공개 사실, 영구 비공개 필드, 현재 보류된 필드, 특권 공개를 섞을 수 있게 했습니다.

이후 표준화 노력은 이 구분이 사라지지 않았음을 보여줍니다.RFC 9083은 자신의상태,정정 기록,Datatracker 기록과 함께 RDAP의 JSON 응답 모델을 정의했습니다.RFC 9537은 자신의상태,정정 기록,Datatracker 기록과 함께, 이후 명시적 레닥션(redaction) 신호를 표준화했습니다.

RFC 9537은 이 모호성을 직접 밝힙니다. RDAP 필드는 데이터가 존재하지 않거나 클라이언트에 권한이 없기 때문에 부재할 수 있습니다. 그 확장은 제거, 빈 값, 부분 값, 대체 값 레닥션을 식별하고, 영향을 받는 필드를 지명하며, 사유를 진술할 수 있습니다.XXXX같은 일반적인 자리표시자는 일관성 없고 신뢰할 수 없는 신호이므로 이를 배제합니다. 또한 레닥션 표식이 데이터의 존재 자체를 드러낼 수 있음을 경고하며, 따라서 존재 자체가 민감하면 서버는 표식을 생략할 수 있습니다.

이후의 이 연구는 IRIS에서 이어진 입증된 계보로 제시되어서는 안 됩니다. 여기의 공식 기록은 그 계보를 확립하지 않습니다. 이들이 보여주는 것은 되풀이되는 시스템 문제입니다. 공백은 충분한 증거 모델이 아니라는 것입니다. RFC 3982의 답은 정책적 의미를 필드에 부착하는 것이었고, RFC 9537의 답은 레닥션 연산과 사유를 기술하는 것이었습니다. 둘 다 같은 파괴적 압축에 저항합니다.

운영자에게 실용적인 규칙은 단순하면서도 요구가 많습니다. 값, 부재 사유, 접근 맥락, 이후 사용 제한을 별개의 데이터로 보존하십시오. 캐시가denied를 "기록 없음"으로 변환해서는 안 됩니다. 인증된 내보내기가specialAccess를 "공개"로 바꿔서는 안 됩니다. 화면이 값을 표시할 수 있다는 이유만으로doNotRedistribute를 숨겨서도 안 됩니다. 이 프로토콜의 역사는 증거 손실에 대한 경고입니다. 빈 셀은 흔히 파이프라인의 끝이지, 설명의 시작이 아닙니다.

출처