요약

  • 10월 28일 초안은 측정값이 워크로드의 종류를 나타낼 뿐, 같은 이미지에서 실행된 개별 인스턴스를 구별하지 못한다고 설명한다.
  • 한 방안은 증명 자료에 담긴 키를 신뢰한다. 다른 방안은 그 키에 WIMSE 인증서의 이름을 붙여 키 교체 뒤에도 신원을 이어 간다.

출입문 앞에 같은 제복을 입은 직원 두 명이 섰다. 제복만 검사하면 둘 중 누구에게 일을 맡겼는지 알 수 없다. 같은 이미지를 실행하는 기밀 워크로드의 두 인스턴스도 그렇다. 측정값이 모두 합격이어도, 어느 인스턴스와 거래하기로 했는지는 별도 질문이다.

Tirumaleswar Reddy 등의 문서는 SEAT 논의를 위한 개인 Internet-Draft다. 작업반이 어느 설계를 채택했다는 기록은 없다. 문서는 먼저 요구를 가른다. 승인된 이미지의 아무 인스턴스에나 비밀을 주면 되는 경우와 특정 인스턴스를 다시 알아봐야 하는 경우는 신원 요구가 다르다.

첫 방안에서 워크로드 인스턴스는 증명된 실행 환경 안에서 키 쌍을 만든다. 공개키는 증명 자료와 TLS 연결에 함께 나타난다. 상대방은 두 키가 같은지 확인하고, 증명 자료의 측정값을 평가한다. 공개키 자체를 제시하거나 자체 서명 인증서에 담을 수 있다. 인증기관이 별도의 오래가는 이름을 붙이지 않으므로, 키를 바꾸면 이전 키와 새 키의 연속성을 따로 설명해야 한다.

둘째 방안은 이름을 발급하는 기관을 들인다. WIMSE 자격 증명은 워크로드 식별자와 키를 연결하고, 증명 자료는 같은 키를 측정된 환경에 연결한다. 이름은 키 교체를 넘어 유지될 수 있다. 다만 WIMSE 식별자는 한 인스턴스를 가리킬 수도, 여러 복제본이 공유하는 논리적 워크로드를 가리킬 수도 있다. 발급 신뢰 도메인이 이름의 범위를 정한다. 발급, 갱신, 폐지를 관리하는 주체도 함께 생긴다.

증명 자료가 진짜이고 인증서가 유효하다는 두 판정만으로 입장이 끝나지 않는다. 그 이름의 워크로드가 해당 이미지에서 돌아가도록 허가받았는지 확인해야 한다. 초안은 이 보증이 필요한 경우 접속을 받는 쪽이 이름과 측정값을 함께 평가하도록 한다. 키의 출처도 별도다. 키를 소유한다는 증명은 개인키가 보호 환경에서 만들어졌고 밖으로 나가지 않았다는 사실까지 입증하지 않는다.

RFC 9334는 증거 생산자, 검증자, 최종 결정을 내리는 신뢰 당사자의 역할을 나눈다. 이번 초안의 핵심은 그 마지막 결정이다. 이 이름을 단 워크로드 인스턴스가 지금 제시한 환경에서 일하도록 누가 허락했는가.