요약

  • RFC 3058은 IDEA 콘텐츠 암호화와 IDEA 키 래핑에 각각 별도의 식별자와 파라미터 규칙을 부여했다. 이로써 전송 표현은 정확해졌지만, 지원은 여전히 선택 사항이었고, 파라미터가 없는지,NULL인지, 8옥텟 IV를 담는지는 여전히 맥락이 결정했다.
  • 서명된 S/MIME capability는 클라이언트에 대한 순서 있는 주장이지 실행 영수증이 아니었다. 실제 사용 여부는 여전히 양쪽 엔드포인트, 로컬 선호 설정, 사적 합의, 법적 제약, 키 접근, 언랩 성공 여부, 콘텐츠 처리 성공 여부에 달려 있었다.

서로 다른 두 가지 작업을 위한 이름

암호 소프트웨어는 "IDEA를 사용하라"는 문구만으로는 상호 운용할 수 없다. CMS 메시지는 알고리즘 식별자와 파라미터, 모든 값이 놓일 자리를 필요로 한다. 또한 메시지 콘텐츠를 보호하는 알고리즘과 콘텐츠 암호화 키를 보호하는 알고리즘을 구분해야 한다. 2001년 2월 Informational 문서로 공개된 RFC 3058이 바로 그 정밀성을 제공했다.

하나의 객체 식별자가 콘텐츠 암호화를 위한 CBC 모드의 IDEA를 지칭했다. 두 번째는 IDEA 키 래핑 알고리즘을 지칭했다. 이 구분은 장식이 아니었다. 첫 번째는 128비트 비밀 키와 64비트 블록으로 메시지 콘텐츠에 작용했다. 두 번째는 16옥텟 콘텐츠 암호화 키를 받아 8옥텟 체크섬과 결합해 32옥텟의 래핑된 값을 산출했다. 클라이언트는 어느 쪽 식별자도 이 암호에 대한 일반적인 선호 선언으로 대체할 수 없었다.

이 OID들은 Ascom과 연관된 private-enterprise 가지 아래에 놓였다. 그 가치는 조율에 있었다. 독립적으로 구현된 소프트웨어가 같은 기능에 대해 같은 식별자를 내보낼 수 있었다. 등록은 모든 S/MIME 클라이언트가 그 코드를 담고 있거나, 모든 사용자가 활성화할 수 있거나, 암호화된 메시지가 누군가에게 도달했다는 뜻이 아니었다. 선택을 가능하게 하기 전에, 그 선택을 판독 가능하게 만든 것이다.

부재, NULL, IV는 동의어가 아니다

RFC 3058은 콘텐츠 암호화 식별자에 정확히 8옥텟인 선택적 IV를 담는IDEA-CBCPar구조를 부여했다. 파라미터에 IV가 나타나면 구현은 그것을 사용하고 암호문 앞에 배치하지 않는다. 파라미터가 생략되면 암호문의 처음 64비트가 IV가 된다. RFC는 이 두 번째 형태를 기술하면서도 CMS나 S/MIME에서 사용해서는 안 된다고 밝혔다.

키 래핑 식별자는 다른 규칙을 따랐다. 그 파라미터 필드는NULL이어야 했다. 두 개의 S/MIME capability 광고는 세 번째 규칙을 따랐다. 그 파라미터는 없어야 했다. 대충 쓴 문서에서는 이 세 가지 상태가 "아무것도 없음"의 변형처럼 보일 수 있다. ASN.1에서는 서로 다른 바이트이자 서로 다른 지시다.

이 차이가 문서의 조용한 핵심이다. 맥락과 파라미터 규칙이 알려지기 전까지 식별자는 완전한 지시가 아니다. 부재와NULL을 호환되는 것으로 취급하는 파서는 유효한 구조를 거부하거나, 합의된 적 없는 의미론을 가진 구조를 받아들일 수 있다. "IDEA"만 기록하는 대시보드는 메시지를 재현하는 데 필요한 증거를 잃는다.

이 RFC 자체의 후속 정오표가 이 점을 보강한다. 문서 갱신을 위해 보류된 정오표 ID 5913은 ASN.1 심볼IDEA-CBC가 소문자 호환 형태인id-IDEA-CBC로 시작해야 한다고 말한다. 숫자 OID는 바뀌지 않았다. 사람이 읽는 라벨, ASN.1 소스 식별자, 등록된 번호는 서로 연관되어 있지만 하나의 객체가 아니다.

래핑의 내부는 무작위, 외부는 고정

래핑 절차는 의도적으로 정확했다. 16옥텟 콘텐츠 키에 8옥텟 무결성 검사 값을 덧붙였다. 8옥텟 무작위 IV를 생성해 그 24옥텟 값을 IDEA-CBC로 암호화했다. 그다음 무작위 IV를 앞에 붙이고 32옥텟 전체를 역순으로 뒤집은 뒤, 고정된 외부 IV4adda22c79e82105로 다시 암호화했다. 언랩은 이 작업들을 역순으로 수행하고 체크섬 불일치를 거부했다.

고정된 외부 IV는 전체 구성에서 분리해 보면 오해하기 쉽다. 그것은 새로운 내부 IV를 제거한 것이 아니다. 반대로 무작위성과 일치하는 체크섬이 있다는 것만으로는 누가 메시지를 승인했는지, 수신자가 이 알고리즘을 원했는지, 복호화된 콘텐츠가 의미 있는 것인지 증명하지 않는다. 체크섬은 언랩된 키에 대한 좁은 처리 질문에 답했을 뿐이다.

CMS는 이 계층들을 분리했다. 각각의 목적이 달랐기 때문이다. 콘텐츠 암호화 키는 본문을 보호했고, 키 암호화 키는 그 콘텐츠 키를 보호했으며, 래핑 형식은 그것을 운반했고, 봉투는 알고리즘과 수신자를 식별했다. 한 계층에서의 성공이 다른 모든 계층의 영수증이 아니었다.

Capability는 서명되고, 순서가 있으며, 불완전했다

S/MIME 클라이언트는 서명된 속성 안에SMIMECapabilities를 게시할 수 있었다. RFC 3058은 IDEA-CBC와 IDEA 키 래핑에 대해 정확한 DER 바이트열을 제공하고 그것들을 서로 다른 논리적 범주에 배치했다. 순서는 선호를 표현할 수 있었다. 후속 S/MIME 규격들도 이 목록을 부분적이라고 계속 기술했다. 클라이언트는 자신이 지원하는 모든 것을 나열할 의무가 없었다.

따라서 검증된 서명은 그 서명된 메시지에서 누가 capability 주장을 했는지, 인증서와 서명 시각 검사를 전제로 확립했을 뿐이다. 수신자의 현재 프로세스를 점검하지는 않았다. 소프트웨어는 업그레이드되거나 재구성될 수 있다. 공급자 모듈이 없을 수 있다. 키에 접근할 수 없을 수 있다. 정책이 구현된 알고리즘을 비활성화할 수 있다. 지원이 존재하더라도 목록이 완전할 필요가 없기 때문에 capability가 생략되었을 수 있다.

RFC 3058 자체도 선택을 레지스트리 밖에 두었다. 송신자의 결정에는 수신한 capability, 사적 합의, 사용자 선호, 법적 제한이 개입할 수 있다고 밝혔다. 사용자가 IDEA를 요구한다면, 양쪽 클라이언트가 이를 지원하고 선호 설정이 지정되어야 했다. OID 레지스트리는 바이트에 대한 모호성을 없앨 수 있었지만, 그 어떤 권한도 행사할 수 없었다.

라이선스는 전송 형식 옆에 놓여 있었다

역사적인 IPR 고지는 Ascom이 IDEA에 대한 특허를 보유하고, 합리적이고 차별 없는 조건으로 비독점 라이선스를 제공하며, 비상업적 사용은 무료로 허용했다고 말한다. 이 고지는 2001년에 그 문서가 제시한 경계에 대한 증거이지, 오늘에 대한 법률 자문이 아니다. 프로토콜적 가용성과 법적 가용성이 같은 RFC 안에서도 별개의 문제로 이해되었음을 보여준다.

구현은 OID를 인식하면서도 알고리즘을 생략할 수 있었다. 개발자가 코드를 보유하는 동안 조직이 라이선싱이나 정책 조건을 거부할 수 있었다. 수신자가 지원을 광고하는 동안 송신자의 로컬 규칙이 다른 것을 선택할 수 있었다. 이 규격은 그 결정들을 기술적 등록으로 하나로 묶지 않았다.

이후의 표준들이 주변 기준선을 바꿨다. RFC 3370은 공통 CMS 알고리즘 규약을 핵심 구문에서 분리했다. RFC 5652는 이후 CMS 버전을 표준화했다. RFC 8551의 S/MIME 4.0 스위트는 정의된 요구 수준에서 AES 기반 모드와 ChaCha20-Poly1305를 지목하면서 capability와 대역 외 선택 논리를 유지한다. 이 역사는 IDEA가 배포되었다는 증거가 아니며, 후속 필수 목록에서 빠져 있다고 그 OID들이 삭제된 것도 아니다.

RFC 3058의 지속적인 교훈은 IDEA가 승리했거나 실패했다는 것이 아니다. 표준화는 선택을 보편화하지 않고도 재현 가능하게 만들 수 있다는 점이다. 번호가 선택을 식별하고, 파라미터가 파서에게 읽는 방법을 알려주며, 서명된 capability가 주장을 귀속시킨다. 정책과 법이 선택될 수 있는지를 결정하고, 오직 실제 교환만이 양쪽 엔드포인트가 그 일을 완수했는지 보여줄 수 있다.

출처

Lu Heng은 RFC 3058을 작성하거나 승인하지 않았다. 그의 에세이는 상징적 등록과 실행 가능한 동작을 분리하기 위한 공개된 분석 렌즈로만 사용되었다.