IETF가 2023년 10월 RFC 9495 「Certification Authority Authorization (CAA) Processing for Email Addresses」를 표준 트랙(Proposed Standard) 문서로 발행했습니다. 기존 인증기관 권한 부여(CAA, Certification Authority Authorization) 레코드는 도메인 이름 인증서를 발급할 수 있는 인증기관만 제한할 수 있었습니다. RFC 9495는 여기에 이메일 주소 인증서를 발급할 수 있는 인증기관을 지정하는 새 속성 태그(Property Tag) issuemail을 추가합니다.
무엇이 발표되었나
CAA 레코드의 핵심 규격인 RFC 8659는 도메인 이름 인증서 발급을 제한하는 issue, issuewild 속성 태그를 정의하지만, 이메일 주소 인증서의 발급을 제한하는 방법은 정의하지 않습니다. RFC 9495는 이 빈자리를 채웁니다.
이 문서에서 말하는 '이메일 주소를 인증하는 인증서'는 다음 두 조건을 모두 갖춘 인증서입니다.
- 확장 키 용도(extendedKeyUsage) 확장에
id-kp-emailProtection키 용도가 들어 있음 - 주체 대체 이름(subjectAltName) 확장에 해당 도메인 이름을 포함하는
rfc822Name값이나id-on-SmtpUTF8Mailbox유형의otherName값이 하나 이상 들어 있음
issuemail 값의 문법은 issue, issuewild와 같습니다. 인증기관의 도메인 이름 뒤에 세미콜론(;)으로 구분한 매개변수를 붙일 수 있습니다. 관련 리소스 레코드 집합(Relevant RRSet)에 issuemail 속성이 하나 이상 있으면, 그 도메인은 인증기관에 이메일 주소 인증서 발급을 제한해 달라고 요청하는 것으로 해석합니다.
인증기관의 처리 방식
- 인증기관은 이메일 주소 인증서를 발급하기 전에 관련 RRSet이 게시되어 있는지 반드시(MUST) 확인해야 합니다. 이때 RFC 8659 3절의 탐색 알고리즘을 사용합니다.
- 탐색의 입력 도메인은 인증할 이메일 주소의 도메인 부분(@ 뒤)입니다.
- 도메인 부분이 U-레이블을 포함한 국제화 도메인 이름(IDN)이면, 모든 U-레이블을 A-레이블 형태로 바꾼 뒤 탐색해야 합니다.
- 관련 RRSet이 비어 있거나
issuemail속성이 없으면, 그 도메인은 이메일 주소 인증서 발급에 아무런 제한도 요청하지 않은 것으로 봅니다.
영향 범위
DNS 쪽에서 보면 새 리소스 레코드 유형이 생긴 것이 아니라 기존 CAA 레코드에 쓸 수 있는 태그가 하나 늘어난 것입니다. 마지막 처리 규칙에 따라, issue 레코드만 게시해 둔 도메인도 이메일 주소 인증서 발급은 제한되지 않습니다. 메일 서명·암호화(S/MIME 등)용 인증서를 발급할 인증기관까지 통제하려면 issuemail 레코드를 따로 게시해야 합니다.
운영자가 할 일
- 이메일 주소 인증서를 발급받는 도메인이라면, 발급을 허용할 인증기관을 정한 뒤
issuemail레코드 게시를 검토하세요. 아래는 형식 예시이며, 인증기관 도메인 이름은 해당 인증기관이 안내하는 값을 쓰세요.
example.com. IN CAA 0 issuemail "ca.example.net"- 쓰고 있는 DNS 서버나 관리 도구에서
issuemail태그가 담긴 CAA 레코드를 등록하고 응답할 수 있는지 미리 확인하세요. - 국제화 도메인을 메일 도메인으로 쓴다면, 인증기관이 A-레이블 형태의 이름으로 조회한다는 점을 고려해 해당 이름에 레코드를 게시하세요.
- 기존
issue레코드는 이메일 주소 인증서에 적용되지 않으므로, 현재 CAA 설정이 원하는 정책을 실제로 반영하는지 함께 점검하세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.