RFC 3548: Base64에는 프로필이 필요했다

요약

RFC 3548는 겉보기에는 사소하지만 실제로는 중요한 상호 운용성 문제를 다루었습니다. 규격 문서들이 자신이 의도한 알파벳, 줄바꿈, 패딩, 거부 규칙을 명시하지 않은 채 그저 "base64"라고만 쓰는 경우가 흔했습니다.
이 문서의 핵심 교훈은 MIME의 메일 전송 동작이 하나의 프로필이지 보편적인 디코더 계약이 아니라는 점이며, 프로토콜은 자신이 어느 프로필을 사용하는지 명시해야 한다는 것입니다.

텍스트 편집기로 Base64 문자열을 열어볼 수 있습니다. 이 편리함 때문에 변환이 저절로 이해될 수 있다는 인상을 받기 쉽습니다. 바이트가 들어가고 출력 가능한 문자가 나오며, 어떤 디코더든 그 과정을 되돌릴 수 있다는 식으로요. 그러나 RFC 3548에 기록된 역사는 다른 이야기를 합니다. 구현체들은 작은 차이들을 쌓아 왔고, 프로토콜들은 그 이름 하나로 모든 차이가 해결된 것처럼 "base64"를 불러 왔습니다.

불일치의 문제는 여섯 비트 산술이 아니었습니다. 그 바깥의 봉투에 관한 것이었습니다. 인코더는 줄바꿈을 삽입해야 하는가? 마지막=패딩이 반드시 있어야 하는가? 디코더는 벗어난 문자를 거부하는가, 아니면 무시하는가? 64개의 기호 중 어떤 것이 알파벳을 차지하는가? 이런 질문들을 근처의 다른 포맷을 빌려 답하는 시스템은 그 포맷에서는 동작하더라도 다른 것을 기대하는 상대편과는 여전히 어긋날 수 있습니다.

2003년 7월에 Informational RFC로 발표된 RFC 3548은 이 모호성을 줄이려 했습니다. 문서의 서론은 되풀이되는 지름길을 지목합니다. 프로토콜 문서들이 정확한 설명이나 참조 없이 "base64"를 사용했고, 줄 넘김이나 알파벳 밖 문자를 고려하지 않은 채 MIME을 기본값처럼 다루는 경우가 많았다는 것입니다. 그래서 이 문서는 널리 쓰이는 Base16, Base32, Base64 방식을 모아 그 주변의 선택 사항들을 드러냈습니다.

MIME은 구체적이었기 때문에 오히려 혼란의 주요 원천이었습니다. RFC 2045는 Base64를 메시지 본문의 Content-Transfer-Encoding으로 정의합니다. 76자 줄 길이 제한은 그 메일 맥락에 속합니다. PEM도 메일 시대의 설정 안에서 64자 줄을 사용했습니다. RFC 3548이 일반적인 참조 규격에 내린 규칙은, 참조하는 규격이 요청하지 않는 한 줄바꿈을 추가하지 말라는 것이었습니다. 다른 파서가 줄바꿈을 데이터로 세거나 거부할 수 있다면 그것은 장식이 아니기 때문입니다.

패딩과 관용성도 프로필의 결정이었습니다. RFC 3548에 따르면 인코더는 참조 규격이 달리 정하지 않는 한 적절한 패딩을 포함합니다. 디코더는 참조 규격이 명시적으로 다른 정책을 선택하지 않는 한 알파벳 밖의 문자를 거부합니다. MIME은 CRLF를 포함한 그런 문자를 무시할 수 있지만, 그 예외는 MIME이 정의한 동작에 속합니다. 이를 다른 프로토콜에 복사하면 수용되는 입력이 달라집니다. 이 RFC는 은닉 채널과 구현 오류를 신중해야 할 이유로 언급하지만, 특정 구현이 초래했다고 알려진 공격 사례를 보고하지는 않습니다.

알파벳 자체에도 이름이 필요했습니다. 통상적인 Base64 알파벳은 값 62와 63에+와/를 씁니다. RFC 3548은와_를 쓰는 URL·파일명 안전한 대안을 문서화했습니다. 이것은 같은 인코딩이 아니며 "base64"라고만 불러서는 안 된다고 명시합니다. 이 구분은 문자열이 경로, 파일명 또는 식별자 필드로 이동할 때 메일 본문과는 다른 규칙을 만나기 때문에 중요합니다.

2006년 10월, RFC 4648이 Standards Track 문서로서 RFC 3548을 폐기(obsolete)했습니다. 이 후속 문서는 프로필 중심 접근을 유지하면서 정규 인코딩(canonical encoding) 절을 추가했습니다. Base64와 Base32 출력의 패딩 비트는 0이어야 하며, 그렇지 않으면 여러 문자열이 같은 바이트로 디코딩될 수 있다는 것입니다. 이 후속 문서의 논점은 MIME의 줄 넘김 문제와 별개입니다. 두 RFC를 함께 보면, "디코딩에 성공한다"는 것이 완전한 프로토콜 명세가 아니라는 이유가 드러납니다. 송신자와 수신자는 여전히 표기법, 패딩, 관용성, 그리고 값이 어느 계층에서 해석되는지에 대한 합의가 필요합니다.

Base 인코딩은 암호화가 아니며 메시지를 인증하지도 않습니다. 그 가치는 옥텟을 전송 친화적으로 표현하는 데 있습니다. RFC 3548의 역사적 작업은 더 소박하고 더 내구성 있는 것이었습니다. 익숙한 라벨을 완전한 규칙 집합처럼 다루는 관행을 끝낸 것입니다.