요약

  • 개인 Internet-Draft는 RATS 호환 Identity Document Service가 어테스테이션 결과를 RATS를 이해하지 못하는 서비스가 받아들일 수 있는 공통 키, 토큰 또는 자격 증명으로 변환할 것을 제안한다.
  • 발급 이후 공백이 남는다: Evidence, 평가 정책, 워크로드 위치 또는 핵심 클레임이 바뀐 뒤에도 자격 증명이 자체 네이티브 규칙에 따라 계속 수용될 수 있다.
  • Daniel Kade는 어테스테이션과 자격 증명 사이에 임대(lease)를 제안하며, 기간·상태·폐기를 Evidence 시점, 정책 버전, 클레임 클래스, 워크로드 키, 변경 이벤트에 연결한다. 이는 편집상의 제안이지 IETF 규칙이 아니다.

신뢰는 경계에서 갈라진다

마이그레이션 예는 공격에 의존하지 않는다. 워크로드가 Evidence를 제시하면, 한 Verifier가 그것을 평가하고, Identity Document Service(IDS)가 결과를 수용한다. 개인 키는 워크로드에 남아 있고, 채널은 제대로 보호될 수 있으며, 발급된 자격 증명은 완전히 정당한 것일 수 있다. 그 다음 오케스트레이터가 일상적인 위치 변경을 수행한다.

draft-bdnr-rats-trustworthy-credentials-02는 독일에서 프랑스로의 라이브 마이그레이션이Country=Germany를 무효화할 수 있지만Region=Europe은 여전히 옳음을 지적한다. 이는 단일 응답을 만들어내지 않는다. 유럽 역량은 유지될 수 있고, 독일에 묶인 권한은 다시 평가되어야 한다. 결과는 각 클레임과 각 권한 조각 사이의 관계에 달려 있다.

구 서비스는 이 관계를 보지 못한다. 그것은 이미 적용하던 모델 기준으로 유효한 인증서나 토큰을 받는다. 드래프트는 의도적으로 그 서비스를 RATS 밖에 두었다. 신뢰 변경을 그 서비스가 이해하는 행동으로 변환해야 할 주체까지 보이지 않게 두면 거버넌스가 실패한다.

호환성은 배포 제약이다

모든 소비자를 바꾸지 않을 타당한 이유가 있다. 서드파티 애플리케이션, 불변 바이너리, 미지원 언어, 규제 절차, 팀 간 분업은 Evidence와 어테스테이션 결과의 도입을 느리게 하거나 불가능하게 만들 수 있다. 모든 클라이언트와 서버가 RATS를 다뤄야 한다면, 가장 경직된 부분이 일정을 지배하게 된다.

드래프트 작성자는 RATS Relying Party와 IDS의 역할을 모아가지는 Credential Broker, Key Broker 또는 Credential Authority를 제안한다. 워크로드는 중개자에게 자신의 상태를 증명하고, 결과가 정책을 통과하면 기존 협력자들이 인식하는 Identity Document를 받는다. 이 문서는 키, 토큰 또는 자격 증명이며, 수명은 짧거나 길 수 있다. 변형으로는 키 중개, 사전 프로비저닝된 소유 증명 자격 증명, 새 소유 자격 증명 또는 짧은 베어러 토큰 발급이 있다.

이득은 영향 반경을 줄이는 것이다. 이미 존재하는 TLS, PKI, 토큰, 인가는 계속 작동하고, 개인 키는 워크로드 안에 머무를 수 있다. 민감한 Evidence의 보호도 모든 소비자에 복제할 필요가 없다.

이 장점은 보존되어야 한다. 그러나 중개자는 상응하는 의무를 짊어진다: 입력에서 어테스테이션을 감추었다면, 이후의 변경을 네이티브 만료, 범위 축소, 상태 또는 폐기로 번역해야 한다. 복잡성은 사라지는 것이 아니라 자리를 옮긴다.

세 개의 시계가 하나의 접근을 다스린다

RFC 9334는 Verifier가 적용하는 Appraisal Policy for Evidence와 Relying Party가 적용하는 Appraisal Policy for Attestation Results를 구분한다. 전자는 해석을 만들고, 후자는 그 해석이 특정 용도에 충분한지를 결정한다. 정당성과 인가는 동의어가 아니다.

Evidence는 적절한 신선도를 요구하고 어테스테이션 결과에는 유효 기한이 있다. RFC는 필연적인 경합을 인정한다: 상태나 정책은 결과가 발급된 직후에 바뀔 수 있다. 유효 기한을 넘겨 결과를 쓰지 않는 것은 필수이지만, 그 간격 동안 모든 것이 안정적으로 유지됨을 보장하지는 않는다.

IDS가 자격 증명을 발급하면 세 번째 시계가 태어난다. 인증서에는 시작과 끝이 있고, 토큰은 만료되며, 상태 목록과 서비스는 다른 리듬으로 갱신된다. 레거시 시스템은 이 시계를 읽지, Evidence의 시점도 두 정책의 버전도 읽지 않는다. 자격 증명이 8시간 유효하고 어떤 중요 클레임이 5분의 신뢰만을 받아야 한다면, 변환은 그 차이를 가릴 뿐이다.

짧은 자격 증명은 노출을 줄일 뿐, 연결 자체를 정의하지 않는다. 10분 토큰도 5분만 신뢰할 수 있는 사실보다 오래 살아 있다. 지속 어테스테이션은 변화를 감지하지만, 유통 중인 자격 증명의 운명을 정하지 않는다. 폐기는 IDS가 의존성을 알고 각 소비자가 상태 채널을 적용할 때만 작동한다.

올바른 서명이 낡은 의미를 실을 수 있다

RFC 7515의 JWS는 객체의 무결성과 암호학적 작성자를 보호한다. RFC 5280의 인증서 검증은 설정에 따라 체인, 이름, 제약, 기간, 폐기를 고려한다. 소유 증명은 개인 키의 통제를 입증한다. 이 어느 검사도 발급의 근거가 된 Evidence 평가를 반복하지 않는다.

그래서 레거시 서비스는 올바르게 행동하면서 만료된 권한을 유지할 수 있다. 자격 증명이 만료되지도 폐기되지도 않았다면 수용하는 것은 그 시야와 부합한다. RATS에서 그 서비스를 떼어놓아 놓고 마이그레이션이나 정책 변경을 알아차리지 않았다고 책임지우는 것은 모순이다.

IDS는 발급 후에도 신뢰 사슬 안에 있다. 그것은 동적 측—Evidence, 기준값, Endorsements, Verifiers, 정책—을 만료, 로테이션, 인트로스펙션, 폐기로 이루어진 측과 결합했다. 이 결합은 행동을 유발할 수 있는 운영 상태로 존속해야 한다. 사고 후에만 참조되는 역사적 기록은 권한을 끝내지 못한다.

클레임은 서로 다른 리듬으로 늙는다

국가와 리전은 같은 신호등의 두 이름이 아니다. 측정되는 구성 요소가 유지되는 동안 실행 공급자가 바뀔 수 있다. 구성은 보안 부팅을 깨지 않고 열화될 수 있다. 정책 개정은 한 알고리즘을 제외하면서 다른 속성을 유지할 수 있다. 각 변경은 그에 의존하는 역량에만 도달해야 한다.

유럽 권한은 국가에 의존하지 않을 수 있다. 독일에서만 데이터를 처리할 권리는 의존한다. 둘을 하나의 분할 불가능한 자격 증명에 넣으면 교정이 거칠어진다: 유지는 과잉 권한을 보존하고, 폐기는 여전히 정당한 것까지 끊는다. 따라서 범위 분리는 거버넌스 도구다.

의존성 지도는 두 극단을 피한다. 변화마다 전부 폐기하면 어테스테이션이 가용성 장애의 원인이 되고 팀들이 신호를 무시하도록 유도한다. 항상 만료를 기다리면 서명이 죽은 전제를 계속 실어 나른다. 기록은 어떤 클레임이 어떤 권한을 지배했고, 그 이벤트가 왜 교체·제한·중단 또는 불행동으로 이어졌는지 설명해야 한다.

워크로드의 신원은 운반자에게서 나오지 않는다

드래프트는 EST 클라이언트가 워크로드 신뢰 기반 밖의 하이퍼바이저나 오케스트레이터에 있을 수 있음을 인정한다. 그 클라이언트는 채널을 형성하기 위해 자신을 인증할 수 있다. 이 선택적 신원이 어떤 워크로드에 자격 증명을 돌려줄지 결정해서는 안 된다; Evidence와 어테스테이션이 결합을 세우고, 개인 키는 워크로드에 남아 있어야 한다.

발급 후에도 이벤트는 요청을 운반한 오케스트레이터 세션이 아니라 어테스테이션된 신원과 키로 자격 증명에 연결되어야 한다. 그렇지 않으면 모든 채널이 인증된 채로도 업데이트나 폐기가 잘못된 대상에 이르러 충돌한다.

LAMPS의 CSR 어테스테이션 드래프트는 가까운 의무를 명시한다. CA 또는 RA가 어테스테이션을 사용하면, 요청 내 선언들 서로 사이와 요청의 공개 키에 대한 결합에 대해 책임지고, 그 Certification Practice Statement에 요구사항을 문서화한다. 이는 결합 책임을 특정 지을 뿐; 발급 이후 체계가 이미 정의되어 있음을 증명하지 않는다.

WIMSE도 워크로드 신원을 대표하는 자격 증명과 소유 증명 메커니즘을 분리한다. 키를 통제하는 것은 제시자가 누구인지 답한다. 위치, 구성, 측정이 여전히 참인지는 답하지 않는다.

어테스테이션에서 자격 증명으로의 임대

Daniel Kade의 제안은 IDS가 유지하는 임대다. 새 공개 형식을 만들지도, 구 서비스에 RATS를 요구하지도 않는다. 어테스테이션의 동적 유효성과 자격 증명의 네이티브 유효성을 연결하는 최소 상태다.

먼저, 자격 증명의 식별자와 유형, 워크로드 신원, 워크로드가 보유한 공개 키, 소유 증명 결합을 기록한다. 다음으로, Evidence의 시점과 신선도 한계, Verifier의 신원, 그 Verifier의 Appraisal Policy for Evidence 버전, IDS가 결과를 수용하는 데 쓴 정책의 버전을 기입한다. 이렇게 하면 변경이 검토가 필요한 대상을 찾아낸다.

이어서 각 범위를 최소 클레임 클래스에 연결한다: 국가, 리전, 측정된 소프트웨어, 키 보호 또는 운영 환경. 의존성은 필수, 정보성, 또는 기간 축소일 수 있다. Evidence 전체를 복사할 필요는 없다. 보호된 참조, 시점, 결과 요약이 프라이버시와 보존 한계 안에서 결합을 유지한다.

임대는 수평선을 정한다. 자격 증명은 설명 없이는 가장 짧은 중요 의존성을 넘어서지 않아야 하며, 지속 관측과 입증된 상태 경로가 상당한 통제를 제공하는 경우는 예외다. 항상 최단 기간을 요구하는 것이 아니라, 그 차이를 어떻게 좁힐지 말하라고 요구한다.

마지막으로 이벤트에 번역이 붙는다. 마이그레이션, 키 로테이션, 새 정책, 기준값 철회, 소프트웨어 변경, 패치 실패 또는 Endorsement 변경은 새 어테스테이션을 시작할 수 있다. 응답은 재발급, 축소, 중단, 폐기 또는 근거 있는 불행동 결정일 수 있다. IDS는 네이티브 시그널링이 발급되고 소비자에게 도달 가능했음을 보여야 한다.

폐기는 사용 지점까지 도달해야 한다

데이터베이스의 "폐기됨" 열은 접근이 멈췄음을 증명하지 않는다. 상태를 캐시하거나, 연결 시작에서만 확인하거나, 토큰 만료를 기다리는 서비스가 있다. 기존 세션은 살아남을 수 있다. 임대는 실제 적용 경로와 최대 지연을 선언해야 한다.

감사는 이벤트를 출발점부터 따른다: 누가 마이그레이션을 통보했는지, 재평가가 얼마나 걸렸는지, 어떤 인증서 또는 토큰 메커니즘이 쓰였는지, 세션과 오프라인 부분에 무슨 일이 있었는지, 구 대상이 언제 효력을 잃고 대체물이 언제 시작했는지. 폐기 호출의 성공은 결론이 아니라 시작이다.

예외에도 수명 주기가 있다. Verifier 장애는 제한된 범위의 30분 연속성을 정당화할 수 있다. 권한, 이유, 만료, 보상 관측, 최종 처분을 기록해야 한다. 종결 없이 예외를 반복하면 두 번째 신뢰 사슬이 생긴다.

문서화된 것의 한계

trustworthy credentials 드래프트는 미해결 사항을 인정한다: 베어러 토큰은 별도의 프로토콜이나 확장이 필요하고,/serverkeygen은 더 많은 상세화가 필요하다. 보호된 채널과 키 보관을 다루지만, 발급 이후 기간의 완전한 거버넌스를 제시하지는 않는다.

기준 시점에서 이는 IETF의 공식 입장이 없는 개인 Internet-Draft다. LAMPS와 WIMSE 드래프트도 진행 중이다. 자료는 특정 배포, 통상 기간, 마이그레이션 사고, 규제 실패, 성능 또는 채택을 보여주지 않는다. 초기 시나리오는 드래프트 자체의 경고를 적용할 뿐, 운영자에게 행동을 돌리지 않는다. 임대는 편집 분석이지 표준 요구가 아니다.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html