요약

  • RFC 1485는 이미 ASN.1 구조로 알려진 식별명(Distinguished Name)에 대해 사람이 읽기 좋은 문자열 표기를 정의했으며, 불완전한 이름으로부터 엔트리를 찾아내지는 않았다.
  • 쉼표와 세미콜론, 개행 접기, 따옴표 처리, 속성 키워드, OID, 16진수 값, AVA 순서는 왜 표시상의 동등성이 DN 동등성이 아닌지를 보여준다.
  • 이후 LDAP 규칙은 단일 표준 DN 문자열을 명시적으로 배제하고 스키마를 인식하는 매칭을 요구한다. 파싱된 DN조차 인증, 권한 부여, 외부 결과의 증명이 되지 않는다.

두 장의 카드, 하나의 구조화된 이름

1993년 회의 테이블 위에 놓인 두 장의 카드를 상상해 보라. 한 장은 식별명을 쉼표로 구분해 한 줄에 인쇄했다. 다른 장은 같은 구성 요소를 좁은 단으로 접어 세미콜론으로 구분했다. 잉크도, 줄바꿈도 다르다. 합의된 표기를 따르는 파서는 여전히 동일한 구조화된 이름을 복원할 수 있다.

그것이 바로RFC 1485뒤에 있던 소박하지만 중요한 문제였다. X.500은 식별명을 엔트리의 기본 키로 사용하고 ASN.1로 인코딩했다. 사람들은 종이나 일반 메일로 ASN.1을 주고받지 않았다. 흔한 이름은 읽기 쉬우면서도 어떤 DN이든 표현할 수 있는 문자열이 필요했다.RFC Editor 기록은 그 표준화 시도를 1993년 7월로 기록하고 있으며, 현재는 Historic으로 분류한다.

『표현(representation)』이라는 단어가 경계를 담고 있다. RFC 1485는 이미 알려진 DN에서 출발했다. 그 자매 문서인 RFC 1484는 더 앞서서, 디렉터리를 통해 여전히 해석되어야 하는 가칭(friendly name)에서 시작했다. 공개된 RFC 1484 Article은 그 맥락적 조회를 다룬다. 이 Article은 그 다음 단계에서 시작한다: 구조화된 이름이 텍스트가 될 때 정확히 무엇이 살아남는가?

가독성은 대안을 요구했다

이 형식은 가장 구체적인 상대 식별명(RDN)을 먼저 두었다. 구성 요소는 쉼표 또는 세미콜론으로 구분될 수 있고, 선택적 공백으로 둘러싸일 수 있었다. 긴 이름은 여러 줄에 걸쳐 접힐 수 있었다. 본문 흐름 속에서는 꺾쇠 괄호로 감쌀 수 있었다. 문장부호, 반복 공백, 앞뒤 공백을 포함하는 값은 따옴표 처리나 이스케이프가 필요했다.

다중 값을 갖는 RDN은 Attribute Value Assertion을+로 결합했다. 흔한 속성 유형에는 짧은 키워드가 붙었다: CN, L, ST, O, OU, C. 덜 익숙한 유형은OID.2.6.53같은 점 구분 객체 식별자로 나타날 수 있었고, 편한 경로 밖의 값은 16진수로 출력될 수 있었다. RFC 1485는 이 탈출구를 '보기 흉한' 것으로 부르며 주로 병리적인 경우에 쓰일 것으로 기대했다. 일반성에는 눈에 보이는 비용이 있었다.

이 선택들은 단순한 겉모습의 잡음이 아니었다. 깨끗한 일반 사례와 그 아래의 구조화된 객체 사이의 경계를 보존했다. 렌더러는 줄바꿈을 선택할 수 있었다. 발신자는 대체 구분자를 사용할 수 있었다. 유형 레지스트리는 익숙한 키워드를 식별자로 매핑할 수 있었다. 그래도 파서는 RDN 경계, AVA 소속, 유형과 값을 복원해야 했다.

RFC 4512의 이후 디렉터리 모델은 한 세부 사항을 특히 중요하게 만든다: RDN은 순서 없는 AVA 집합이다. 플러스 기호 주변의 두 AVA 위치는 새로운 식별 정보가 아니다. DN은 RDN의 수열이며, 표시는 그 구조의 하나의 인코딩이다.

표준은 과거를 다시 쓰지 않고도 진화할 수 있다

RFC 1779는 그기록에 따르면 RFC 1485를 폐기(obsolete)했으며, 이스케이프 처리를 다듬고 쉼표와 세미콜론의 혼용을 권하지 않았다. 이어서RFC 2253이 DN 문자열을 LDAPv3와 UTF-8로 가져갔고, 그기록은 대체 연쇄를 보여준다. 현재RFC Editor 기록을 지니는RFC 4514가 이제 LDAP 문자열 표현을 정의한다.

이 계보가 중요한 이유는, 버전 없는 문자열은 불완전한 증거이기 때문이다. 한 프로파일에서 수용되는 세미콜론이 다른 프로파일에서는 거부되거나 단지 허용될 수 있다. 어떤 레지스트리에서 알려진 서술자(descriptor)가 다른 레지스트리에서는 알려지지 않을 수 있다. 유니코드 문자는 리터럴일 수도, 옥텟으로 이스케이프될 수도, 매칭 전에 정규화될 수도 있다. “DN처럼 보인다”는 것은 문법, 스키마, 디코딩 결과를 식별해 주지 않는다.

RFC 4514는 또 하나의 흔한 직관을 뒤집는다. 그 일차 목표는 인코딩과 디코딩의 용이성이며, 사람의 가독성은 차순위다. 사용자 인터페이스는 프로토콜 문자열을 그대로 보여주는 대신 속성 레이블을 현지 언어로 번역할 수 있다. 상호운용 가능한 계층은 화면의 타이포그래피가 아니다.

표준 문자열이 없다는 것은 어휘적 지름길이 없다는 뜻이다

RFC 4514는 결정적인 규칙을 명시한다: 식별명에 대한 표준(canonical) 문자열 표현을 정의하지 않는다. 다른 인코더는 서로 다른 적합 문자열을 만들어낼 수 있다. 동등성은RFC 4517에 규정된distinguishedNameMatch로 검사해야 한다.

그 매칭 규칙은 RDN의 개수와 위치를 비교한다. RDN 내부에서는 AVA의 순서가 무의미하다. 각 값은 자신의 속성 유형의 동등 규칙으로 비교된다.RFC 4518은 국제화된 문자열 준비를 제공한다: 매핑, 정규화, 금지 코드 포인트, 그리고 무의미한 공백에 대한 규칙별 처리.

따라서 바이트 비교는 양쪽 종류의 오류를 모두 만들어낼 수 있다. 다른 문자열들이 파싱과 스키마 인식 비교 후 동등한 DN을 나타낼 수 있다. 비슷해 보이는 문자열들은 속성 유형, 이스케이프된 값, RDN 경계 또는 준비 결과가 달라 실패할 수 있다. 비교자는 요구되는 AVA 비교가 정의되지 않을 때Undefined결과를 낼 수도 있다. 동등성은 입력을 갖는 실행된 판정이지, 잉크의 시각적 속성이 아니다.

문자열은 자신의 혈통을 보존하지 않을 수 있다

RFC 4514의CN=Sam예제는 두 번째 경계를 드러낸다. 하나의 X.501 값은 TeletexString을, 다른 하나는 PrintableString을 사용할 수 있다. 둘 다 같은 LDAP 문자열이 될 수 있다. 그 표시를 다시 변환하는 것이 반드시 동일한 BER 또는 DER을 재구성하지는 않는다. 정확한 DER이 필요한 응용(예를 들어 인증서 검증 중)은 16진수 형태를 사용해야 한다.

그렇다고 모든 텍스트 DN이 안전하지 않다는 것은 아니다. 의존하는 시스템에게 필요한 속성을 명명하라고 알려줄 뿐이다. 읽기 쉬운 전달, DN 동등성, 바이트 단위 재구성은 세 가지 서로 다른 목표다. 하나의 매력적인 문자열이 세 가지를 조용히 모두 충족할 수는 없다.

공개 위험도 있다. RFC 4514는 DN이 흔히 이름, 이메일 또는 네트워크 주소, 물리적 위치, 소속을 담는다고 지적한다. 이름 속성은 개인 데이터일 수 있다. RFC 1485의 보안 절은 보안 문제가 논의되지 않았다고 밝혔다. 표현 계약은 접근 제어 또는 프라이버시 계약이 아니다.

엔트리는 여전히 세계 전부가 아니다

RFC 4512는 DN이 디렉터리 트리의 한 엔트리를 명확하게 참조한다고 말한다. 엔트리는 스키마와 행정 규칙 아래에서 자신이 나타내는 객체에 대한 속성을 담는다. 그것은 정밀한 디렉터리 주장이지, 보편적인 신원 영수증이 아니다.

파싱된 DN은 그 문자열을 보낸 사람이 누구인지 증명하지 않는다. 매칭되는 엔트리가 키보드 앞의 사람이 그것을 통제한다고 증명하지 않는다. 그 속성은 낡았거나, 숨겨졌거나, 틀렸을 수 있다. 이름을 담은 인증서조차 유효한 서명과 경로가 필요하다. 응용은 여전히 인증과 권한 부여를 필요로 한다. 성공한 연산은 자신만의 영수증을 필요로 한다.

이 구분은 Lu Heng의실행 코드 우선성,최소 공통 명세와 현지 결정, 그리고현실 계층의 분리논지를 따른다. 공유된 문법이 구조를 전달한다. 스키마가 의미를 다스린다. 디렉터리가 엔트리를 보관한다. 의존하는 응용이 자신의 행동에 충분한 증거가 무엇인지 결정한다.

RFC 1485는 한 이름이 이동하도록 도왔다. 그 규율은 이동하는 문자열이 자신이 가리키는 모든 것에 대한 주권자가 되는 것을 거절할 때 살아남는다.

출처