요약

  • RFC 1439는 이름에서 파생된 계정 문자열이 예측 가능성을 충돌 위험과 맞바꾼다는 것을 보여주었다. 고유성은 이름과의 유사성이 아니라 네임스페이스, 비교 규칙, 할당 시점이 만든다.
  • 가장 영향력 있는 조언은 운영적이었다. 구별 접미사를 항상 노출하고, 접미사 없는 모호한 주소는 거부하며, 오래된 메일이 여전히 작용할 수 있는 동안에는 식별자를 재사용하지 않는다.
  • 이후 RFC들은 계층을 더 명확히 분리한다. 표시 이름, 사용자명, 공급자가 발급한 안정적 ID, 클라이언트 범위의 외부 ID, 메일박스, SMTP 인계, 자격 증명, 권한 부여 결정은 서로 다른 근거이다.

두 번째 크레이그가 시스템을 바꾼다

초기 캠퍼스 네트워크가 단순한 관례 하나를 공표한다고 상상해 보자. 이름, 미들네임 이니셜, 성을 가져와 그 사이에 구두점을 넣으면 그 결과가 계정이 된다. 이 관례는 상대가 디렉터리를 찾아보지 않고도 주소를 추론할 수 있다는 점에서 유용하다. 그런데 정규화된 이름이 동일한 후보를 만드는 또 다른 사람이 나타난다.

이 충돌은 외부에서 추가된 드문 결함이 아니다. 형식 자체의 속성이다. 이 규칙은 다양한 사회적 대상, 즉 인간의 이름을 더 작은 기술적 네임스페이스로 압축했다. 이제 누군가 두 번째 계정에 번호를 붙일지, 첫 번째 계정에도 번호를 표시할지, 대소문자와 구두점이 항목을 구별하는지, 어느 한 사람이 떠나면 어떻게 되는지를 결정해야 한다. 그 답이 바뀔 때마다 발신자가 보이는 문자열에서 안전하게 추론할 수 있는 것이 달라진다.

그것이 1993년 3월 크레이그 핀세스가 발표한 RFC 1439의 실질적 주제였다. 이 메모는 인터넷 표준이 아니라 정보성(Informational) 문서였다. 제목인 “고유 식별자의 고유성(The Uniqueness of Unique Identifiers)”은 장난스럽게 들린다. 그러나 핵심 주장은 엄격했다. 시스템은 짧은 계정 식별자가 고유하기를 필요로 했지만, 이름에서 추측 가능하게 만드는 형식에는 충돌을 드문 사건으로 만들 정보가 충분하지 않았다.

메모는 세 가지 할당 전략을 구분했다. 시스템은 사람과 무관한 불투명한 고유 문자열을 발급할 수 있다. 이는 고유성 관리가 쉬워지지만 추측이 불가능해진다. 또는 문자열 대부분을 이름에서 파생하고 고유해질 때까지, 보통 숫자 접미사를 붙여, 결과를 변형할 수 있다. 또는 문자열을 이름에서 파생하고 중복이 발생하도록 허용한 뒤 그것을 임기응변식으로 처리할 수도 있다. 전자 메일은 발신자가 관례를 알면 주소를 예측할 수 있기 때문에 두 번째와 세 번째 모델의 가치를 높였다.

그 편의는 거짓된 시각적 등가성을 만들어냈다.Craig.A.Finseth는 크레이그 A. 핀세스에 대한 어떤 명제처럼 보인다. 운영적으로는 단지 한 발급자의 규칙 아래에서의 후보 키일 뿐이다. 이름은 입력을 제공한다. 정규화 규칙은 비교 형태를 제공한다. 가용성 확인은 어떤 시점의 네임스페이스를 관찰한다. 할당 기록은 슬롯을 묶는다. 그 어느 행위도 그 사람과 동일하지 않다.

직원 디렉터리 속 생일 문제

RFC 1439는 이 압축을 정량화하려 했다. 이니셜, 이름, 성, 그 조합이 운반하는 정보의 전형적 값과 최대값을 추정했다. 대부분의 형식은 전형적으로 8~20비트 범위에 들었다. 그 표에서 가장 정보가 풍부한 전형적 조합은 26비트에 도달했고, 최대 추정치 중 40비트를 넘는 것은 없었다. 그러한 가정 하에서 중복은 단지 가능한 수준이 아니라, 인구가 늘어날수록 일어날 가능성이 높아졌다.

메모는 생일 문제 계산을 사용했다. 충돌 위험은 네임스페이스가 겉보기에 차지한 비율이 아니라 쌍의 수와 함께 커진다. 그 실제 예제는 이름에 성을 붙인 형식에 전형적인 17비트를 할당했다. 100명 중에는 중복 확률을 2~5퍼센트, 아마 4퍼센트 근처로 추정했다. 1,000명 중에는 20퍼센트보다 훨씬 크다고 보았다.

이 수치를 보편적 인구 통계 법칙으로 착각해서는 안 된다. 출처가 된 책들, 문화적 가정, 음역 관행, 조직 인구는 모두 역사적으로 특정한 시점에 놓여 있었다. 다른 문자 체계, 이름 관습, 정규화 규칙은 다른 분포를 만든다. 지속되는 통찰은 구조적이다. 읽을 수 있는 형식의 충돌률은 실제 입력 분포, 비교 함수, 할당 횟수에 의존한다. 보이는 문자 수를 세는 것만으로는 부족하다.

같은 구조적 교훈은 시스템이 악센트를 제거하거나, 대소문자를 통합하거나, 구두점을 없애거나, 긴 이름을 줄이거나, 문자 체계를 음역하거나, 공백을 삭제할 때마다 적용된다. 각 변환은 한 맥락에서 상호운용성을 개선하면서 다른 맥락에서 서로 다른 후보를 하나로 합칠 수 있다. 네임스페이스는 “고유”하다고 선언하면서 그 범위와 동등성 규칙까지 함께 명명하지 않으면 안 된다.

접미사는 예외 각주가 아니라 주소의 일부다

부록이 결정적인 예를 제시했다. 형식이First.M.Last-#이라고 하자. 첫 번째 보유자만 예쁜 접미사 없는 형태를 쓰고 두 번째 사람만-2를 받아도 될까? RFC 1439의 답은 아니오였다. 외부인이 접미사 없는 형태로 보내면, 그 메시지가 잘못된 사람에게 갈 수 있다는 신뢰할 수 있는 신호가 없다. 모든 계정이 접미사를 달고 접미사 없는 형태가 거부된다면, 실패한 시도 자체가 발신자에게 구별자가 필요하다고 알려준다.

이는 오류의 목적을 바꾼다. 거부는 편리한 별칭을 제공하지 못한 실패 그 이상이다. 시스템이 안전하게 해소할 수 없는 불확실성을 보존한다. 첫 청구자를 조용히 선택하면 이름 충돌이 자신만만한 오배달로 변한다.

메모는 그 논리를 전자 메일에 지워야 하는 주의와 연결하며 1987년 미국 전자통신 사생활 보호법을 인용했다. 이 인용은 1993년 당시의 논거에 속하며 현행법에 대한 진술이 아니다. 법적 외삽 없이도 기술적 요점은 유지된다. 이름에서 파생된 후보를 공유하는 그럴듯한 두 사람이 있을 때, 한 메일박스로의 성공적인 전송은 추측을 명시적으로 거부하는 것보다 약한 근거이다.

RFC 1439는 이어서 그러한 식별자는 메일 시스템의 수명 동안 재사용되어서는 안 된다고 조언했다. 재사용은 동시 재직자 간의 충돌이 아니라 시간을 가로지르는 충돌을 만든다. 오래된 주소록, 보관된 메시지, 접근 제어 항목, 구독, 복구 연락처, 인간의 기억은 계속 전 보유자를 가리킬 수 있다. 같은 보이는 슬롯을 재할당하는 네임스페이스는 문자열 뒤의 사람을 바꾸면서, 문자열을 믿게 만드는 모든 낡은 참조를 그대로 유지한다.

따라서 관련 수명은 반드시 고용이나 계정 활동이 아니다. 의존적 참조의 수명이다. 오래된 메시지, ACL, 감사 기록, 복구 채널이 여전히 어떤 작용을 일으킬 수 있다면, 식별자는 운영적으로 살아 있다.

SMTP는 책임을 인수할 수 있지만 그 사람을 증명하지는 않는다

이후의 SMTP 언어는 이 근거 경계를 정밀하게 만든다. RFC 5321에 따르면 주소는 메일이 보내질 사용자 또는 메일이 예치될 위치를 식별하는 문자열이며, 메일박스는 그 예치 장소이다. 현대의 주소는 단순 사용자명 이상의 용도를 가지므로, 도메인이 지명하는 호스트만이 로컬파트에 의미를 부여한다.

이것은 철저히 경계가 정해진 권한이다. 원격 발신자는 문자열을 보존하고 도메인을 향해 전송할 수 있다. 수신 도메인이 자신의 로컬파트가 무엇을 지칭하는지 결정한다. 구문은 그 대상이 사람인지, 공유 큐인지, 전달 별칭인지, 프로그램인지, 연속성을 위해 살아 있는 폐기 계정인지 드러내지 않는다.

SMTP 자체에도 또 하나의 깔끔한 경계가 있다. 서버가 메시지 데이터의 끝에서 성공 응답을 보내면 책임이 공식적으로 넘어간다. 그 서버는 메시지를 전달하거나 실패를 적절히 보고해야 한다. 그 성공은 프로토콜 인계를 증명한다. 의도된 사람이 메일박스를 소유한다는 것, 인간이 메시지를 읽었다는 것, 어떤 후속 작용이 일어났다는 것은 증명하지 않는다.

RFC 2142는 비(非)인간 사례를 의도적인 것으로 만든다.postmaster,abuse,noc,security같은 주소는 서비스, 역할, 기능을 위한 잘 알려진 이름이다. 그 기능을 지원하는 도메인은 그 이름을 해당 역할에 맞는 수신자로 전송하는 것이 기대된다. 목표는 기능의 연속성이며 특정 개인의 신원이 아니다.

대소문자조차 네임스페이스에서 떼어놓으면 보편적 의미가 없다. RFC 5321은 메일박스 로컬파트의 대소문자 보존을 요구하고 로컬파트를 형식상 대소문자 구별로 다루면서도, 그 민감성이 상호운용성을 저해하기 때문에 배포에서 이를 활용하는 것은 권하지 않는다. 도메인 이름은 대소문자를 구별하지 않는다. 중간 시스템이 수행하는 문자열 비교가 목적지 호스트의 계정 의미론을 안전하게 발명할 수는 없다.

이후의 신원 스키마는 계층을 보이게 만들었다

RFC 7643, 즉 SCIM 코어 스키마는 역사적 메일 문제를 해결하지 않는다. 여기서 유용한 이유는 그 어휘가 하나의 매력적인 필드가 모든 신원 기능을 수행할 수 있다는 가장을 거부하기 때문이다.

SCIM의id는 서비스 공급자가 발급하며, 그 공급자의 자원 전반에서 고유하고, 안정적이며, 재할당되지 않는다.externalId는 프로비저닝 클라이언트가 발급하며 해당 클라이언트의 프로비저닝 도메인으로 범위가 한정되고, 서비스 공급자는 그 고유성을 강제하지 않는다.userName은 사용자 대면 식별자로, 필수이며 공급자의 사용자 전반에서 고유하다. 인간 이름 구성요소는 별도 속성이다.

이 차이들은 네 개의 권한을 식별한다. 공급자는 자신의 자원 키를 통제한다. 클라이언트는 자신의 외부 참조를 통제한다. 공급자는 로그인 네임스페이스를 통제한다. 사람이나 조직은 표시 데이터를 제공한다. 두 문자열이 서로 다른 범위에서 주장을 하며 동일하게 보일 수 있고, 서로 다른 두 문자열이 서로 다른 시스템을 통해 정당하게 같은 자원을 가리킬 수 있다.

RFC 8265는 국제화된 비교 계층을 추가한다. 사용자명을 계정을 지정하는 문자열로 정의하며, 대개이지만 반드시 그렇지는 않게 사람이 사용한다. 사용자명이 반드시 특정 응용 프로그램 식별자에 대응하지는 않는다고 명시하고, 제한적인 계정 식별자와 표현적인 표시 이름 또는 닉네임의 분리를 장려한다.

또한 두 프로필을 정의한다. 하나는 대소문자를 매핑하고 하나는 보존한다. 선택은 응용 프로토콜, 구현 또는 배포에 속한다. 매핑 실패가 오탈 승인이나 사용자 혼란을 일으킬 수 있는 곳에서는 대소문자 매핑이 일반적으로 선호되지만, 호환성을 위해 보존이 요구될 수 있다. 매핑은 정보를 잃으므로 RFC는 그 시점을 가능한 한 마지막까지 미루라고 조언한다. 교훈은 “항상 소문자로”가 아니라 “검증자가 실제로 어떤 비교를 수행하는지 선언하라”이다.

사람 같은 문자열을 위한 근거 사다리

인터넷 역사의 실수는 이 모든 작업을 “신원”이라고 서술하는 것이다. 더 유용한 사다리는 각 단계가 무엇을 증명하는지 보존한다.

표시된 인간 이름은 표시 근거이다. 정규화 또는 음역 출력은 후보 비교 문자열이다. 가용성 응답은 그 후보가 하나의 네임스페이스의 현재 규칙 아래 미사용이라고 말한다. 할당은 어떤 발급자가 어떤 시점에 슬롯을 자원에 묶었다고 말한다. 메일박스 주소는 수신 도메인의 의미론 아래에서 예치 장소 또는 사용자를 식별한다. SMTP 성공은 이후 전달 또는 실패 보고에 대한 책임을 증명한다. 인증은 검증자의 규칙 아래에서 자격 증명의 통제를 증명한다. 권한 부여는 하나의 정책 아래에서 하나의 작용에 대한 허가를 증명한다. 회신이나 독립적 채널은 인간 참여의 주장을 뒷받침할 수 있지만, 그 증명조차 시간과 맥락의 경계를 가진다.

모든 단계는 유용하다. 어느 단계도 자동으로 그 위 단계의 의미를 상속하지 않는다.

이 분리는 더 넓은 인터넷 규율을 따른다. 공통 계층은 최소적이고 결정론적으로 유지하라. 고유성에는 명시된 네임스페이스, 비교 규칙, 충돌 규칙, 할당 전환이 필요하다. 상호운용성에는 중간자가 의미론을 발명하지 않고 보이는 식별자가 전송되는 것이 필요하다. 나머지, 즉 표시 선호, 조직의 이름 관습, 별칭 미학은 로컬에 머물 수 있다. 디렉터리 항목은 조정 기록이다. 비교와 라우팅 코드를 실행하는 것만이 실행 가능한 결과를 만든다.

출처