Internationalized Electronic Mail Addresses in RFC5280 / X.509 Certificates
draft-lbaudoin-iemax-01

Abstract

Specifies support for email address internationalization in RFC5280 / X.509 certificates. This defines an encoding for UTF-8 characters in certificate Subject Alternative Names and Issuer Alternative Names using base64url which is backwards compatible with the IA5String encoding used to encode email addresses.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 14, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.

Table of Contents

• 1. Background
• 2. Proposal
• 3. References
• Authors' Addresses

1. Background

Internationalization of email addresses has significant precedence. Internationalization of domain names was specified in RFC3490 [RFC3490] and more recently in RFC5890 [RFC5890] via puny-coding of the unicode domain name labels. Email address in RFC5280 [RFC5280] certificate Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) support this internationalization of domain names as described in section 7.5. In RFC6532 [RFC6532], email headers as specified in RFCRFC5321 [RFC5321] and RFCRFC5322 [RFC5322] was refined to support UTF-8 unicode representation which implies support for unicode email addresses but RFC5280 was not updated to take this into account.

2. Proposal

This draft proposes an encoding for internationalized email addresses. To support the unicode local name part, this draft proposes a base64url encoding for the local part of the email address in the RFC5280 certificate SAN and IAN. That is the encoded string starts with an escape character ':' to identify that the RFC5280 email address is internationalized and encoded. The local part of the email address then consists of unicode UTF-8 name that must be websafe base64url encoded as specifed in RFC4648 [RFC4648]. The escape colon character is a character intentionally choosen such that it is supported by IA5String but not possible in a compliant ASCII RFC5322 email addresses. Support for internationalized domain names in the certificates is already specified in RFC5280 [RFC5280], and this draft does not change that interpretation.

One potential issue for an encoded internationalized SAN or IAN email address is its impact on RFC5280 naming constraints particularly between a draft compliant certificate and a non compliant implementation. This encoding will not impact name matching in this scenario as mismatching local part names and constraints will always match test negatively. The local part should only match if the implementation is compliant with this draft. Because the draft does not change internationalized domain name behavior, both the compliant and non-compliant implementation can test domain name constraints in the expected way.

3. References

Authors' Addresses