요약

  • RFC 1485는 ASN.1 구조를 잃지 않고 이미 알려진 X.500 Distinguished Name을 명함, 문서, 메시지 같은 사용자 지향 텍스트로 옮겼다.
  • "모호성 없이 파싱"은 정규 텍스트를 뜻하지 않았다. 구분자, 레이아웃, 디스크립터나 OID, 따옴표, 이스케이프, 우회 인코딩 때문에 같은 DN에 대해 유효한 문자열이 여러 개 존재할 수 있었다.
  • 재구성된 DN은 디렉터리 모델 안의 항목을 가리켰지만, 현재 존재, 동일성, 인간 신원, 인증, 권한 부여, 외부 효과를 입증하지 않았다.

짧은 이름이 더 이상 알려지지 않게 된 순간

발행 측은 어떤 속성 유형의 사용자 친화적 디스크립터를 알고 그대로 출력할 수 있었다. 다른 등록부를 가진 수신 측은 그것을 인식하지 못할 수도 있었다. RFC 1485는 이 사실이 사라지도록 강제하지 않았다. 유형은 점 구분 표기법의 숫자 객체 식별자로도 전송될 수 있었다.

이 작은 메커니즘이 문제의 본질을 드러낸다.RFC 1485는 전역 별명을 만들지 않았다. ASN.1로 구조화된 이미 알려진 Distinguished Name을 명함이나 전자 우편 메시지 같은 인간 지향 매체에 적합한 형태로 변환했을 뿐이다.

이웃한 작업은 더 앞서 시작되었다.RFC 1484는 사용자가 주장하는 친화적 이름을 받아 디렉터리에서 후보를 검색했다. RFC 1485에서는 DN의 선택이 이미 이루어진 뒤였다. 이름을 직렬화하는 것과, 항목을 찾는 것과, 누가 그 항목을 통제하는지 증명하는 것은 서로 다른 작업으로 남았다.

구두점 속에 숨은 나무

DN은 Directory Information Tree의 한 경로를 따라 Relative Distinguished Name들을 모은다. RFC 1485의 표현은 가장 구체적인 부분을 먼저 두고 더 넓은 맥락을 뒤에 놓았다.=기호가 유형과 값을 연결했다. 쉼표나 세미콜론이 RDN들을 구분했다.+기호는 동일한 다중값 RDN 안의 여러 AttributeTypeAndValue 주장을 묶었다.

+를 쉼표로 바꾸면 스타일이 아니라 객체가 바뀐다. 하나의 명명 단계에 있던 두 주장이 연이은 두 단계로 변한다. 이 표현에서 속성 유형은 필수였으며, 비록 문법이 친화적 이름 작업과 연관이 있더라도 그러했다.

따라서 그 한 줄은 유형, 값, 묶음, 순서를 보존했다. 사람 독자는 세미콜론이 들어간 여러 줄 배치를 선호할 수 있고, 응용 프로그램은 압축된 한 줄을 선호할 수 있다. 둘이 같은 구조화된 시퀀스로 되돌아온다면, 시각적 차이는 허용되었다.

불쾌한 이스케이프가 전체 약속을 떠받쳤다

실제 값에는 쉼표, 따옴표, 앞뒤 공백, 연속 공백이 들어갈 수 있었다. 따옴표와 이스케이프는 이런 데이터가 문법으로 읽히는 것을 막았다. 값이 표시에 적합한 형태를 갖지 않을 때, RFC는 그 BER 인코딩을 16진수로 기록하는 것을 허용했다.

문서는 이 형태를 보기 흉하다고 불렀고, 주로 병리적 사례에서 나타날 것이라 기대했다. 그러나 바로 이 형태 덕분에 어떤 DN이라도 표현될 수 있다고 말할 수 있었다. 인터페이스가 보여줄 수 있는 것만 받아들이는 문법은 예제에서는 쾌적했겠지만, 미래의, 사적이거나 드문 속성 앞에서는 파괴적이었을 것이다.

보존은 이해가 아니다. 파서는 OID와 바이트를 회수할 수 있지만, 응용 프로그램에는 구문, 표시, 동일성 규칙을 정의하는 스키마가 없을 수 있다. 정직한 설계는 의미를 발명하지 않은 채 알려지지 않은 사실을 알려지지 않은 채로 유지한다.

결정된 도착이 유일한 출발을 요구하지 않았다

"모호성 없이"는 파싱을 묘사했다. 규격에 맞는 문자열은 결정된 하나의 DN을 재구성해야 했다. 모든 직렬화기가 그 DN에 대해 같은 문자를 낼 것이라는 말이 아니었다.

쉼표와 세미콜론, 다른 줄 구성, 디스크립터와 OID, 이스케이프 선택지가 이미 서로 다른 표면을 제공했다. 프로그램이 아는 등록부와 그 인코딩 정책도 출력에 영향을 주었다. 따라서 문자열을 바이트 단위로 비교하는 것은 DN 동일성의 일반 규칙이 아니었다.

이후의 계보가 이 구분을 명시했다.RFC 1779가 RFC 1485를 대체했다.RFC 2253은 LDAPv3를 위한 UTF-8 표현을 정의했고,RFC 4514가 그것을 대체했다. 후자는 정규 DN 문자열을 정의하지 않으며, 결과가 파싱될 수 있다면 다른 변환 알고리즘도 허용한다. 동일성은 원시 텍스트의 동일성이 아니라distinguishedNameMatch로 결정해야 한다.

이 현대적 정식화를 1993년 텍스트에 문자 그대로 귀속시켜서는 안 된다. 이는 역사적 범위를 명확히 한다. RFC 1485는 유일한 신성한 표기법이 아니라 가역적 인코딩을 만들었다.

글리프, 바이트, 구조, 동일성

스크린샷은 글리프를 증언한다. 보존된 메시지는 바이트와 문자셋 처리를 증언할 수 있다. 파서는 구조화된 RDN 시퀀스를 증언한다. 디렉터리 메커니즘은 스키마에 따라 값을 비교한다. 하나의 증거가 다른 증거를 대신하지 않는다.

RFC 4512는 속성 유형, 구문, 매칭 규칙, DN을 LDAP 정보 모델 속에 자리매김시킨다.RFC 4517은 구문과 매칭 규칙을 규정한다.RFC 4518은 매핑, 정규화, 금지 문자, 쓰기 방향을 포함한 국제화 문자열 준비를 다룬다.

그리하여 비슷해 보이는 두 화면이 서로 다른 코드 포인트나 구조를 숨길 수 있고, 서로 다른 두 문자열이 동일한 DN을 나타낼 수 있다. 출처를 보존하지 않은 채 마이그레이션 중에 전부 소문자로 바꾸고, 공백을 자르고, OID 이름을 바꾸는 일은 의미적 결정을 청소 루틴에 넘기는 것이다.

디렉터리는 문자열이 끝나는 곳에서 시작했다

RFC 1309는 X.500의 분산 아키텍처를 기술했다. 사용자 에이전트와 시스템 에이전트, 명명 맥락, chaining, referral, 복제본이 그것이다. RFC 1485는 이 상태를 고정하지 않았다. 그 결과는 디렉터리 작업에 입력이 될 수 있었지만, 그 작업의 답은 아니었다.

올바른 파싱은 항목이 여전히 존재하는지, 복제본이 최신인지, 접근 제어가 속성을 숨겼는지 말해주지 않았다. 발견된 항목조차 디렉터리 모델 안의 객체였다. 문자열은 사람을 인증하지 않았고, 서비스 통제를 증명하지 않았으며, 직위를 부여하지 않았고, 행위를 승인하지 않았다.

RFC 1485의 보안 절은 보안 문제가 논의되지 않았다고 밝혔다. 이름의 구조를 보존하려고 만든 규칙에서 기밀성, 무결성, 사칭 저항성을 끌어내는 것은 정당하지 않다.

Historic 지위가 오래된 시스템을 지우지 않는다

RFC Editor 등록 기록은 오늘날 RFC 1485를 Historic으로 표시한다.RFC 3494는 LDAPv2 기술 명세가 이 지위에 이른 과정에 관여했다. 후속 문서들은 UTF-8, 이스케이프, 디스크립터, 동일성 설명을 바꾸었다.

이 규범적 계승이 메시지, 설정, 로그, 백업을 자동으로 다시 쓰지는 않는다. 구현은 서로 다른 속도로 마이그레이션했을 수 있고, 디스크립터 등록부가 사라졌을 수 있으며, 현재의 파서는 오래된 자료를 거부하거나 다르게 해석할 수 있다. Historic은 명세의 현재 권위를 묘사하는 것이지, 작동 중인 코드 안에 그 산물이 없다는 뜻이 아니다.

가치는 책임의 분할에 있었다

Lu Heng의실행 코드 우선,지역화된 미래 결정,현실의 층위에 관한 사상은 RFC의 약속을 확대하지 않고 읽는 데 도움이 된다. 공유된 문법이 교환을 가능하게 했다. 지역 직렬화기가 표현을 선택했다. 파서가 구조를 회수했다. 운영자가 디렉터리를 유지했다. 신원과 응용 프로그램이 인증, 권한 부여, 결과를 결정했다.

완전한 증거 연쇄는 원래의 구조화된 DN, 직렬화된 바이트, 전송 처리, 파서 버전, 얻어진 구조, 스키마와 동일성 규칙, 디렉터리 관찰, 항목 버전, 인증, 권한 부여, 최종 효과를 보관한다. 신뢰는 이 연쇄에서 나온다. 하나의 문자열을 판결문으로 격상시키는 데서 나오지 않는다.

RFC 1485는 이름을 휴대 가능하게 만들었다. 남는 교훈은 휴대 가능성과 권위는 서로 다른 경계에 속한다는 것이다.

출처