요약

  • RFC 3657은 Camellia에 대해 콘텐츠 암호화와 키 래핑을 위한 별개의 CMS 식별자를 할당했습니다. CBC 콘텐츠 암호화에서는 16옥텟 IV가 반드시 존재해야 하며, 키 래핑 알고리즘 식별자에서는 파라미터가 반드시 없어야 합니다.
  • 서명된 S/MIME capability 항목은 세 번째 형태인NULL을 사용합니다. 키 래핑 OID는 래핑되는 콘텐츠 키가 아니라 키 암호화 키의 크기를 나타냅니다.

같은 이름이 곧 같은 연산은 아니다

CMS 봉투(envelope)에서 “Camellia”라는 이름만으로는 발신자가 무엇을 했는지 해독할 수 없습니다. 수신자는 해당 암호가 메시지 콘텐츠를 보호했는지 아니면 콘텐츠 암호화 키(CEK)를 래핑했는지 알아야 하며, 그 역할에 맞춰 알고리즘 식별자를 해석해야 합니다. 2004년 1월에 Standards Track 문서로 발표된 RFC 3657은 Camellia를 위한 이러한 규약을 제공했습니다. CBC 콘텐츠 암호화용 식별자 계열 하나와 키 래핑용 계열 하나를 추가했습니다.RFC 3657

이 구분은 파라미터에서 드러납니다.id-camellia128-cbc,id-camellia192-cbc,id-camellia256-cbc의 경우AlgorithmIdentifier파라미터는 MUST(필수)로 존재해야 하며 초기화 벡터를 16옥텟 값으로 담아야 합니다. IV는 콘텐츠 암호화 기술의 일부이며, 암호 이름에서 추론할 값이 아닙니다. 이 RFC는 또한 평문 패딩이 CMS 규칙을 따르도록 지시합니다.RFC 3657RFC 5652

키 래핑은 파라미터 기대치를 뒤집습니다. 세 개의 Camellia 래핑 식별자에는 키 크기 아크가 포함되지만, 그AlgorithmIdentifier파라미터는 MUST로 없어야 합니다. 여기에 담을 IV 필드는 없습니다. 래핑 구조가 자체 내부 초기값 사용 방식을 규정하기 때문입니다. 식별자의 크기는 키 암호화 키(KEK)를 나타낼 뿐, 래핑된 CEK가 같은 크기라는 보장이 아닙니다. 구현은 반드시 CEK와 KEK 크기가 같은 경우를 지원해야 하며, 서로 다른 크기를 지원한다면 KEK는 최소한 CEK 이상으로 길어야 합니다. 따라서 RFC 3657은 모든 봉투가 하나의 키 크기를 사용한다는 규칙이 아니라, 인코딩과 호환성의 경계를 정의한 것입니다.RFC 3657RFC 3394

capability는 세 번째 인코딩 맥락이다

RFC 3657은 S/MIME 클라이언트가SMIMECapabilities에서 Camellia 지원을 어떻게 알리는지도 규정합니다. capability OID에는NULL파라미터가 함께 옵니다. 이는 키 래핑 식별자의 파라미터 부재와 모순되지 않습니다. 서로 다른 의미를 가진 서로 다른 ASN.1 구조이기 때문입니다. 또한NULL이 “파라미터 없음”과 동일한 와이어 표현이라는 뜻도 아닙니다. 이 RFC는 구현이 광고된 형태를 정밀하게 비교할 수 있도록 세 가지 키 크기의 DER 인코딩까지 제시합니다.RFC 3657RFC 2633

capability 목록은 서명되어 있고, 선호도 순으로 정렬되어 있으며, 발신자가 지원하는 기능의 일부만을 담습니다. 이는 사적인 합의, 사용자 선호, 법적 제약과 함께 이후 발신자 결정에 들어가는 입력입니다. 실시간 핸드셰이크도, 수신자 현재 구성에 대한 시험도, 메시지가 Camellia로 암호화되었다는 증거도 아닙니다. 연산을 기술하려면 독자는 과거의 capability 광고가 아니라 봉투에서 선택된 콘텐츠 알고리즘과 키 관리 필드를 확인해야 합니다.RFC 3657

적합성은 경계에서 존재한다

이 세 방향의 구분은 상호운용성 검토가 비교해야 할 항목을 바꿉니다. CBC 콘텐츠 암호화에서는 식별자가 의도한 키 크기를 선택했는지, 16옥텟 IV가 존재하는지 확인합니다. 키 래핑에서는 파라미터가 없는지, 실제 KEK와 CEK 길이가 구현이 지원하는 관계를 충족하는지 확인합니다. capability 처리에서는NULL파라미터를 포함한 서명된 DER 값과 선호도가 전달된 순서를 비교합니다. 이 맥락들을 혼동하면 모든 시스템이 같은 암호를 지원한다고 말하더라도 파싱 또는 협상 불일치가 생길 수 있습니다.

RFC 3657에 따르면 Camellia 래핑은 RFC 3394 구조를 따르되 AES를 Camellia로 대체하며, 양쪽이 공유하는 128비트 블록 크기에 의존합니다. 기본 래핑 무결성 값은 고정된A6A6A6A6A6A6A6A6이며, 언래핑에서 이 값이 복원되지 않으면 수신자는 오류를 반환하고 키 데이터를 반환하지 않습니다. 이 RFC는 애플리케이션별 무결성 범위를 위한 대체 초기값도 허용합니다. 이 검사는 지정된 구조 하에서 래핑된 키 데이터를 대상으로 하며, 발신자나 CMS 콘텐츠, 복호화된 콘텐츠에 대한 사용자 권한을 인증하지 않습니다.RFC 3657RFC 3394

이 글은 인코딩 계약에 대한 역사적 재구성이며, 보안 보증이나 배포 현황 조사가 아닙니다. 더 넓은 CMS 알고리즘 레지스트리와 이후 프로필은 배경을 제공하지만, 어떤 제품이 RFC 3657을 구현했는지 또는 얼마나 자주 사용되는지는 확정하지 않습니다. 이 문서의 지속적인 교훈은 더 좁습니다. 알고리즘 식별자는 형식화된 프로토콜 필드이며, OID와 파라미터 존재 여부, 주변 구조는 함께 읽어야 합니다.RFC 3370RFC 8419

출처