One document matched: draft-lbaudoin-iemax-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3490 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
<!ENTITY rfc4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY rfc5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY rfc5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY rfc5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY rfc6532 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6532.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?>
<rfc ipr="noDerivativesTrust200902" docName="draft-lbaudoin-iemax-02">
    <front>
        <title abbrev="Internationalized-Email-X509">Internationalized Electronic Mail Addresses in RFC5280 / X.509 Certificates</title>


        <author initials="L." surname="Baudoin"
                fullname="Laetitia Baudoin">
            <organization>Google, Inc.</organization>
            <address>
                <postal>
                    <street>1600 Amphitheatre Parkway</street>
                    <city>Mountain View</city> <region>CA</region>
                    <code>94043</code>
                    <country>US</country>
                </postal>
                <email>lbaudoin@google.com</email>
            </address>
        </author>

        <author initials="W." surname="Chuang"
                fullname="Weihaw Chuang">
            <organization>Google, Inc.</organization>
            <address>
                <postal>
                    <street>1600 Amphitheatre Parkway</street>
                    <city>Mountain View</city> <region>CA</region>
                    <code>94043</code>
                    <country>US</country>
                </postal>
                <email>weihaw@google.com</email>
            </address>
        </author>

        <author initials="N." surname="Lidzborski"
                fullname="Nicolas Lidzborski">
            <organization>Google, Inc.</organization>
            <address>
                <postal>
                    <street>1600 Amphitheatre Parkway</street>
                    <city>Mountain View</city> <region>CA</region>
                    <code>94043</code>
                    <country>US</country>
                </postal>
                <email>nlidz@google.com</email>
            </address>
        </author>

        <date day="4" month="February" year="2016" />

        <area>General</area>
        <workgroup>Security Working Group</workgroup>
        <keyword>RFC</keyword>
        <keyword>Request for Comments</keyword>
        <keyword>I-D</keyword>

        <keyword>Internet-Draft</keyword> <keyword>SMIME</keyword>
        <keyword>X.509</keyword> <keyword>Email</keyword>  <keyword>RFC5280</keyword>
        <keyword>Security</keyword> <keyword>Privacy</keyword>

      <abstract> <t>Specifies support for email address internationalization
        in RFC5280 / X.509 certificates.  This defines an encoding for Unicode
        email local-part characters in certificate Subject Alternative Names
        and Issuer Alternative rfc822Names.  The encoding is backwards
        compatible with existing practices with rfc822Name.</t>
        </abstract> </front>

  <middle>

    <section anchor="background" title="Background">

      <t>Internationalization of email addresses has significant precedence.
        Email addresses and their parts are specified in <xref target="RFC5322" />.
        Internationalization of domain names was specified in <xref target="RFC3490" />
        and more recently in <xref target="RFC5890" /> via puny-coding
        of the unicode domain name labels.  Email address as certificate
        Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) rfc822Name
        support this internationalization of domain names as described
        in section 7.5 of <xref target="RFC5280" />.  In <xref target="RFC6532" />,
        email headers as specified in <xref target="RFC5321" />
        and <xref target="RFC5322" /> was refined
        to support UTF-8 unicode representation which implies support for Unicode
        email addresses but RFC5280 was not updated to take Unicode email local-part
        into account.</t>

    </section>
    <section anchor="proposal" title="Proposal">

      <t>This draft proposes an encoding for internationalized email addresses
        with Unicode local-part.  This encoding is a further
        refinement of email addresses in RFC5280 SAN and IAN rfc822Name thus
        allowing existing PKI practices using email addresses to continue.
        To support the Unicode local-part, this draft proposes a base64 encoding for
        the local-part string with an identifier character to distinguish this
        encoding.
        That is the encoded string starts with an escape character ':'
        to identify that the local-part is Unicode and that the successive characters
        contain the base64 encoded local-part until the '@' at character is seen.
        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.
        The local-part of the email address then consists of Unicode UTF-8 name
        that must be websafe base64url encoded as specifed in <xref target="RFC4648" />.
        Support for internationalized domain names in the certificates
        is already specified in RFC5280, and this
        draft does not change that interpretation for the email domain.  Similarly the email address
        must follow existing Mailbox name practices specified in RFC5280 section 4.2.1.6
        that there must be no common name, no comment, nor "<" or ">" present.
        A compliant reader of the encoded email address would strip the escape ':' and
        decode the base64 local-part to UTF-8.</t>

      <t>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-parts 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.</t>
    </section>

    </middle>
    <back>
        <references>
            &rfc3490;
            &rfc4648;
            &rfc5280;
            &rfc5321;
            &rfc5322;
            &rfc5890;
            &rfc6532;
        </references>
    </back>
</rfc>