요약

  • DNSKEY SEP 비트는 의도된 운영 용도를 표시합니다. 상위 측 DS 워크플로나 서명 및 디버깅 소프트웨어에 도움이 될 수 있지만, 자격 증명이 아니며 신뢰 사슬을 수립하지 않습니다.
  • RFC 4034와 RFC 4035는 엄격한 경계를 유지합니다. 검증기는 비트 15가 설정되었다는 이유로 서명 검증 동작을 바꿔서는 안 됩니다. SEP 표시된 키도 RRset 서명 검증에는 Zone Key 플래그가 필요합니다.
  • Edward Lewis는 Olaf Kolkman, Jakob Schlyter와 함께 RFC 3757을 공동 저술했습니다. 기록은 그 표준 기여에 대한 귀속을 뒷받침할 뿐, 단독 저술, 구현 공로 또는 현재 재직 주장을 뒷받침하지 않습니다.

DNSSEC은 서로 다른 두 종류의 진술을 연결해야 합니다. 하나는 운영적 진술입니다. 관리자는 특정 키가 특정 역할을 수행하도록 의도하거나, 도구가 특정 작업을 위해 그 키를 제시하기를 원할 수 있습니다. 다른 하나는 암호학적 진술입니다. 검증기는 서명과 키 관계가 프로토콜을 충족함을 확립해야 합니다. Secure Entry Point 비트, 즉 SEP은 첫 번째 범주에 속합니다. 그 좁은 목적이 이 비트를 유용하게 만듭니다. 두 번째 범주에 속하는 것처럼 다루면, 하나의 비트에 실제로 없는 권한을 부여하게 됩니다.

원래 사양인 RFC 3757은 2004년 4월 Olaf Kolkman, Jakob Schlyter, Edward Lewis에 의해 발표되었습니다. 이 문서는 secure entry point로 동작하도록 의도된 키를 식별하기 위해 DNSKEY 플래그 필드에 SEP 플래그를 도입했습니다. 문서는 두 가지 운영 용도를 기술합니다. Delegation Signer(DS) 레코드 생성 절차를 돕는 것과, 운영자가 정적으로 구성하려는 키를 식별하는 것입니다. 또한 DNS 검증 프로토콜은 SEP을 사용하지 않는다고 명시합니다. 이 문장은 메커니즘의 한계를, 이름이 의도된 역할을 표시하는 만큼 명확하게 표시합니다.

인계는 자식 존에서 시작됩니다. 존은 DNSKEY 레코드를 게시하고, SEP 비트는 그중 하나 이상에 대한 운영자의 의도된 처리를 표현할 수 있습니다. 흔한 구성에서 Key Signing Key 역할에 쓰이는 키는 SEP이 표시되고 Zone Signing Key는 그렇지 않습니다. 운영자나 서명 도구는 이 구분을 사용해 상위 측 정보를 준비할 때 고려해야 할 키를 식별할 수 있습니다. 그러나 게시된 비트는 의도된 용도에 대한 단정일 뿐입니다. 상위는 여전히 올바른 DS 자료를 획득하고, 그것이 자식의 키와 대응함을 검증하고, 자체 절차를 통해 필요한 상위 측 레코드를 게시해야 합니다. SEP은 그 비교를 수행하거나 상위가 의도된 키를 수용했음을 증명할 수 없습니다.

다음 인계는 키 관리에서 서명 검증으로 이어집니다. 2005년 3월에 발표된 RFC 4034와 RFC 4035는 RFC 3757을 대체하고 DNSKEY 모델에 SEP을 유지합니다. RFC 4034는 비트 15를 SEP 플래그이자 존 서명 또는 디버깅 소프트웨어를 위한 힌트로 기술합니다. RFC 4035는 결정적인 검증기 규칙을 제공합니다. SEP 비트가 설정되었다는 이유로 검증 동작이 바뀌어서는 안 됩니다(MUST NOT). 같은 레코드 모델은 SEP을 Zone Key 플래그와도 구별합니다. SEP이 표시된 DNSKEY도 자원 레코드 집합에 대한 서명을 검증할 자격을 갖추려면 Zone Key 플래그가 필요합니다. 두 플래그는 서로 다른 질문에 답합니다. SEP은 의도된 운영 처리를 나타내고, Zone Key는 서명 검증에서 프로토콜 역할의 자격을 나타냅니다.

이 구분은 유혹적이지만 무효한 추론을 차단합니다. DNSKEY에 SEP이 보인다고 해서 그 키가 존에 속함이나, 상위가 DS 관계를 수립했음이나, 특정 서명이 유효함이 증명되지 않습니다. 반대로 검증기는 SEP 비트가 지워졌다는 것을, 그 외에는 유효한 서명을 기각하는 근거로 삼을 수 없습니다. 이 비트는 어느 방향으로도 지름길이 아닙니다. 암호학적 사슬, 알고리즘 및 프로토콜 검사가 관련 DNSSEC 규칙 아래 여전히 결정적입니다.

RFC 6781은 SEP이 검증 역할이 없음에도 이 구분이 운영자에게 여전히 중요한 이유를 설명합니다. 이 문서는 상위 교환 또는 가능한 trust anchor 구성에 쓰이는 키, 보통 KSK에는 설정하고 ZSK에는 설정하지 않는 널리 쓰이는 관례를 기술합니다. 또한 단일 유형 서명 방식, 즉 분리된 KSK/ZSK 모델이 따로 할당할 기능을 같은 유형의 키가 처리하는 방식을 논의합니다. 그런 방식에서는 모든 키에 SEP을 일관되게 설정하는 것이 적절할 수 있습니다. 운영상 위험은 리졸버가 수학을 바꾸는 것이 아니라, 분리를 가정하고 만들어진 소프트웨어가 배치와 맞지 않게 키를 분류·표시·처리할 수 있다는 점입니다. RFC 6781은 일부 서명 도구가 단일 유형 방식에 혼란을 겪을 수 있다고 경고합니다.

여기서 경계는 플래그의 문제가 아니라 설계의 문제가 됩니다. 프로토콜은 모든 도구가 그것을 잘 해석하리라고 보장하지 않고서 힌트를 정의할 수 있습니다. 표준은 검증기가 할 수 있는 일을 제한하지만, 서명자나 운영자 인터페이스는 어떤 키를 제출·내보내기·검사해야 하는지에 대한 관례를 여전히 내포할 수 있습니다. 따라서 배치 검토는 실제 도구가 SEP으로 무엇을 하는지, 어떤 레코드를 선택하는지, 그 출력이 의도된 DNSKEY 및 DS 값과 독립적으로 대조되는지를 물어야 합니다. 이는 신중한 운영 통제이지 RFC가 명시한 추가 요구 사항이 아닙니다.

이 비트는 RFC 5011과도 구별되어야 합니다. 그 RFC는 자체 상태를 갖는 자동 trust anchor 갱신 메커니즘을 정의하며, 그 메커니즘에서 별개의 DNSKEY 플래그인 REVOKE를 사용합니다. SEP은 키 역할과 관련된 맥락에서 운영적으로 사용될 수 있고, RFC 6781은 RFC 5011 롤오버 관행과의 관계를 언급합니다. 그러나 그렇다고 SEP이 폐지 신호나 trust anchor 갱신 규칙이 되는 것은 아닙니다. 하나의 플래그는 의도된 키 처리를 전달하고, 다른 하나는 별도로 규정된 상태 기계에 참여합니다. 둘을 혼동하면 서로 다른 목적이 뭉개지고 레코드에 대한 안전하지 않은 독해가 생깁니다.

Edward Lewis의 이 역사에서의 위치는 1차 기록이 정하는 범위 내에 있습니다. RFC 3757은 그를 세 명의 공동 저자 중 한 명으로 나열합니다. 그의 IETF Datatracker 프로필은 그의 표준 활동 목록에 이 RFC를 기록하고, Internet Society Pulse 바이라인 페이지는 제한적인 공개 경력 맥락을 제공합니다. 이 출처들은 Lewis가 사양 작성에 기여했다는 진술을 뒷받침합니다. 그러나 그가 단독으로 이 비트를 설계했거나, 이후 모든 표준이 그것을 사용하는 방식을 결정했거나, 특정 DNSSEC 배치를 구현했다는 것은 보여주지 않습니다. RFC에 나열된 ARIN은 역사적 소속이지 현재 재직의 증거가 아닙니다.

기록에는 또한 명확한 경험적 경계가 있습니다. RFC들은 의도된 의미, 규범적 동작, 도구 혼란의 가능한 원인을 기술합니다. 운영자가 SEP에 의존하는 빈도, 몇몇 도구가 분리를 가정하는지, 리졸버가 이 비트 때문에 검증을 바꾼 적이 있는지, DS 워크플로가 실패한 빈도는 측정하지 않습니다. 사양의 존재에서 사고율이나 배치 결과를 추론할 수 없습니다. 신중한 서술은 실패가 발생했다고 주장하지 않고도 경계가 왜 중요한지 설명할 수 있습니다.

따라서 SEP을 읽는 가장 유용한 방식은 소박하고 정확한 것입니다. 키를 관리하려는 사람이나 도구를 돕는 운영 의도의 표지일 뿐입니다. 그 존재는 권한을 부여하지 않습니다. 기록은 운영자가 키를 어떻게 다루길 원하는지 말할 수 있습니다. 네트워크가 무엇을 신뢰할 수 있는지는 암호학적 검사와 상위 측 절차가 확립해야 합니다.

출처