draft-ietf-lamps-eai-addresses-00.txt   draft-ietf-lamps-eai-addresses-01.txt 
lamps A. Melnikov, Ed. LAMPS A. Melnikov, Ed.
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track W. Chuang, Ed. Intended status: Standards Track W. Chuang, Ed.
Expires: January 25, 2017 Google, Inc. Expires: May 3, 2017 Google, Inc.
July 24, 2016 October 30, 2016
Internationalized Email Addresses in X.509 certificates Internationalized Email Addresses in X.509 certificates
draft-ietf-lamps-eai-addresses-00 draft-ietf-lamps-eai-addresses-01
Abstract Abstract
This document defines a new name form for inclusion in the otherName This document defines a new name form for inclusion in the otherName
field of an X.509 Subject Alternative Name extension that allows a field of an X.509 Subject Alternative Name extension that allows a
certificate subject to be associated with an Internationalized Email certificate subject to be associated with an Internationalized Email
Address. Address.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 25, 2017. This Internet-Draft will expire on May 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 2 3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 2
4. Matching of Internationalized Email Addresses in X.509 4. Matching of Internationalized Email Addresses in X.509
certificates . . . . . . . . . . . . . . . . . . . . . . . . 3 certificates . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Name constraints in path validation . . . . . . . . . . . . . 4 5. Name constraints in path validation . . . . . . . . . . . . . 4
6. Resource Considerations . . . . . . . . . . . . . . . . . . . 5 6. Resource Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[RFC5280] defines rfc822Name subjectAltName choice for representing [RFC5280] defines rfc822Name subjectAltName choice for representing
[RFC5322] email addresses. This form is restricted to a subset of [RFC5322] email addresses. This form is restricted to a subset of
US-ASCII characters and thus can't be used to represent US-ASCII characters and thus can't be used to represent
Internationalized Email addresses [RFC6531]. Internationalized Email addresses [RFC6531]. To fascilitate use of
these Internationalized Email addresses with X.509 certificates, this
document specifies a new name form in otherName so that
subjectAltName and issuerAltName can carry them.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
notation. notation.
3. Name Definitions 3. Name Definitions
This section defines the smtputf8Name name as a form of otherName The GeneralName structure is defined in [RFC5280], and supports many
from the GeneralName structure in SubjectAltName defined in different names forms including otherName for extensibility. This
[RFC5280]. section specifies the smtputf8Name name form of otherName, so that
Internationalized Email addresses can appear in the subjectAltName of
id-on-smtputf8Name OBJECT IDENTIFIER ::= { id-on XXX } a certificate, the issuerAltName of a certificate, or anywhere else
that GeneralName is used.
smtputf8Name ::= UTF8String (SIZE (1..MAX))
When the subjectAltName extension contains an Internationalized Email id-on-smtputf8Name OBJECT IDENTIFIER ::= { id-on 9 }
address, the address MUST be stored in the smtputf8Name name form of Smtputf8Name ::= UTF8String (SIZE (1..MAX))
otherName. The format of smtputf8Name is defined as the ABNF rule
smtputf8Mailbox. smtputf8Mailbox is a modified version of the
Internationalized Mailbox which is defined in Section 3.3 of
[RFC6531] which is itself derived from SMTP Mailbox from When the subjectAltName (or issuerAltName) extension contains an
Section 4.1.2 of [RFC5321]. [RFC6531] defines the following ABNF Internationalized Email address, the address MUST be stored in the
rules for Mailbox whose parts are modified for internationalization: smtputf8Name name form of otherName. The format of smtputf8Name is
<Local-part>, <Dot-string>, <Quoted-string>, <QcontentSMTP>, defined as the ABNF rule smtputf8Mailbox. smtputf8Mailbox is a
<Domain>, and <Atom>. In particular <Local-part> was updated to also modified version of the Internationalized Mailbox which is defined in
support UTF8-non-ascii. UTF8-non-ascii is described by Section 3.1 Section 3.3 of [RFC6531] which is itself derived from SMTP Mailbox
of [RFC6532]. Also sub-domain is extended to support U-label, as from Section 4.1.2 of [RFC5321]. [RFC6531] defines the following
defined in [RFC5890] ABNF rules for Mailbox whose parts are modified for
internationalization: <Local-part>, <Dot-string>, <Quoted-string>,
<QcontentSMTP>, <Domain>, and <Atom>. In particular <Local-part> was
updated to also support UTF8-non-ascii. UTF8-non-ascii is described
by Section 3.1 of [RFC6532]. Also sub-domain is extended to support
U-label, as defined in [RFC5890]
This document further refines Internationalized [RFC6531] Mailbox This document further refines Internationalized [RFC6531] Mailbox
ABNF rules and calls this smtputf8Mailbox. In smtputf8Mailbox, sub- ABNF rules and calls this smtputf8Mailbox. In smtputf8Mailbox, sub-
domain that encode non-ascii characters SHALL use U-label Unicode domain that encode non-ascii characters SHALL use U-label Unicode
native character labels and MUST NOT use A-label [RFC5890]. This native character labels and MUST NOT use A-label [RFC5890]. This
restriction prevents having to determine which label encoding A- or restriction prevents having to determine which label encoding A- or
U-label is present in the Domain. As per Section 2.3.2.1 of U-label is present in the Domain. As per Section 2.3.2.1 of
[RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and
other properties specified there. In smtputf8Mailbox, sub-domain other properties specified there. In smtputf8Mailbox, sub-domain
that encode solely ASCII character labels SHALL use NR-LDH that encode solely ASCII character labels SHALL use NR-LDH
skipping to change at page 3, line 35 skipping to change at page 3, line 41
no comment (text surrounded in parentheses) after it, and is not no comment (text surrounded in parentheses) after it, and is not
surrounded by "<" and ">". surrounded by "<" and ">".
In the context of building name constraint as needed by [RFC5280], In the context of building name constraint as needed by [RFC5280],
the smtputf8Mailbox rules are modified to allow partial productions the smtputf8Mailbox rules are modified to allow partial productions
to allow for additional forms required by Section 5. Name to allow for additional forms required by Section 5. Name
constraints may specify a complete email address, host name, or constraints may specify a complete email address, host name, or
domain. This means that the local-part may be missing, and domain domain. This means that the local-part may be missing, and domain
partially specified. partially specified.
smtputf8Name is encoded as UTF8String. The UTF8String encoding MUST
NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid consistency
across implementations particularly for comparison.
4. Matching of Internationalized Email Addresses in X.509 certificates 4. Matching of Internationalized Email Addresses in X.509 certificates
In equivalence comparison with smtputf8Name, there may be some setup In equivalence comparison with smtputf8Name, there may be some setup
work to enable the comparison i.e. processing of the smtputf8Name work to enable the comparison i.e. processing of the smtputf8Name
content or the email address that is being compared against. The content or the email address that is being compared against. The
process for setup for comparing with smtputf8Name is split into process for setup for comparing with smtputf8Name is split into
domain steps and local-part steps. The comparison form for local- domain steps and local-part steps. The comparison form for local-
part always is UTF-8. The comparison form for domain depends on part always is UTF-8. The comparison form for domain depends on
context. While some contexts such as certificate path validation in context. While some contexts such as certificate path validation in
[RFC5280] specify transforming to A-label, this document RECOMMENDS [RFC5280] specify transforming to A-label, this document RECOMMENDS
skipping to change at page 4, line 22 skipping to change at page 4, line 33
transform the A-label to U-label Unicode as specified in section 5.2 transform the A-label to U-label Unicode as specified in section 5.2
of [RFC5891]. Finally if necessary convert the Unicode to UTF-8 as of [RFC5891]. Finally if necessary convert the Unicode to UTF-8 as
specified in section 3 of [RFC3629]. In setup for smtputf8Mailbox, specified in section 3 of [RFC3629]. In setup for smtputf8Mailbox,
the email address local-part MUST be converted to UTF-8 if it is not the email address local-part MUST be converted to UTF-8 if it is not
already. The <Local-part> part of an Internationalized email address already. The <Local-part> part of an Internationalized email address
is already in UTF-8. For the rfc822Name local-part is IA5String is already in UTF-8. For the rfc822Name local-part is IA5String
(ASCII), and conversion to UTF-8 is trivial since ASCII octets maps (ASCII), and conversion to UTF-8 is trivial since ASCII octets maps
to UTF-8 without change. Once the setup is completed, comparison is to UTF-8 without change. Once the setup is completed, comparison is
an octet for octet comparison. an octet for octet comparison.
This specification expressly does not define any wildcards characters
and smtputf8Name comparison implementations MUST NOT interpret any
character as wildcards. Instead, to specify multiple specifying
multiple email addresses through smtputf8Name, the certificate should
use multiple subjectAltNames or issuerAltNames to explicitly carry
those email addresses.
5. Name constraints in path validation 5. Name constraints in path validation
This section defines use of smtputf8Name name for name constraints. This section defines use of smtputf8Name name for name constraints.
The format for smtputf8Name in name constraints is identical to the The format for smtputf8Name in name constraints is identical to the
use in subjectAltName as specified in Section 3 with the extension as use in subjectAltName as specified in Section 3 with the extension as
noted there for partial productions. noted there for partial productions.
Constraint comparison on complete email address with smtputf8Name Constraint comparison on complete email address with smtputf8Name
name uses the matching procedure defined by Section 4. As with name uses the matching procedure defined by Section 4. As with
rfc822Name name constraints as specified in Section 4.2.1.10 of rfc822Name name constraints as specified in Section 4.2.1.10 of
[RFC5280], smtputf8Name name can specify a particular mailbox, all [RFC5280], smtputf8Name name can specify a particular mailbox, all
addresses at a host, or all mailboxes in a domain by specifying the addresses at a host, or all mailboxes in a domain by specifying the
complete email address, a host name, or a domain. complete email address, a host name, or a domain.
Name constraint comparisons in the context [RFC5280] is specified Name constraint comparisons in the context [RFC5280] is specified
with smtputf8Name name are only done on the subjectAltName with smtputf8Name name are only done on the subjectAltName (and
smtputf8Name name, and says nothing more about constaints on other issuerAltName) smtputf8Name name, and says nothing more about
email address forms such as rfc822Name. Consequently it may be constaints on other email address forms such as rfc822Name.
necessary to include other name constraints such as rfc822Name in Consequently it may be necessary to include other name constraints
addition to smtputf8Name to constrain all potential email addresses. such as rfc822Name in addition to smtputf8Name to constrain all
For example a domain with both ascii and non-ascii local-part email potential email addresses. For example a domain with both ascii and
addresses may require both rfc822Name and smtputf8Name name non-ascii local-part email addresses may require both rfc822Name and
constraints. This can be illustrated in the following Figure 1 which smtputf8Name name constraints. This can be illustrated in the
shows a name constraint set in the intermediate CA certificate, which following non-normative diagram Figure 1 which shows a name
then applies to the children entity certificates. Note that a constraint set in the intermediate CA certificate, which then applies
constraint on rfc822Name does not apply to smtputf8Name and vice to the children entity certificates. Note that a constraint on
versa. rfc822Name does not apply to smtputf8Name and vice versa.
+-------------------------------------------------+ +------------------------------------------------------+
| Root CA Cert | | Root CA Cert |
+-------------------------------------------------+ +------------------------------------------------------+
| |
v v
+-------------------------------------------------+ +------------------------------------------------------+
| Intermediate CA Cert | | Intermediate CA Cert |
| Name Constraint Extension | | Name Constraint Extension |
| Permitted | | Permitted |
| rfc822Name: allowed.com | | rfc822Name: allowed.example.com |
| smtputf8Name: allowed.com | | smtputf8Name: allowed.example.com |
| Excluded | | Excluded |
| rfc822Name: ignored.com | | rfc822Name: ignored.example.com |
+-------------------------------------------------+ +------------------------------------------------------+
| | | |
v | v |
+-------------------------------------------------+ +------------------------------------------------------+
| Entity Cert (w/explicitly permitted subjects) | | Entity Cert (w/explicitly permitted subjects) |
| SubjectAltName Extension | | SubjectAltName Extension |
| rfc822Name: student@allowed.com | | rfc822Name: student@allowed.example.com |
| smtputf8Name: \u8001\u5E2B@allowed.com | | smtputf8Name: \u8001\u5E2B@allowed.example.com |
+-------------------------------------------------+ +------------------------------------------------------+
| |
v v
+-------------------------------------------------+ +------------------------------------------------------+
| Entity Cert (w/permitted subject- excluded | | Entity Cert (w/permitted subject- excluded |
| rfc822Name does not exclude smtputf8Name) | | rfc822Name does not exclude smtputf8Name) |
| SubjectAltName Extension | | SubjectAltName Extension |
| smtputf8Name: \u4E0D\u5C0D@ignored.com | | smtputf8Name: \u4E0D\u5C0D@ignored.example.com |
+-------------------------------------------------+ +------------------------------------------------------+
Figure 1 Figure 1
6. Resource Considerations 6. Resource Considerations
For email addresses whose local-part is ASCII it may be more For email addresses whose local-part is ASCII it may be more
reasonable to continue using rfc822Name instead of smtputf8Name. Use reasonable to continue using rfc822Name instead of smtputf8Name. Use
of smtputf8Name incurs higher byte representation overhead due to of smtputf8Name incurs higher byte representation overhead due to
encoding with otherName and the additional OID needed. This document encoding with otherName and the additional OID needed. This document
RECOMMENDS using smtputf8Name when local-part contains non-ASCII RECOMMENDS using smtputf8Name when local-part contains non-ASCII
characters, and otherwise rfc822Name. characters, and otherwise rfc822Name.
7. IANA Considerations 7. Security Considerations
[[CREF1: Just need a new OID.]] Use for smtputf8Name for certificate subjectAltName (and
issuerAltName) will incur many of the same security considerations of
Section 8 in [RFC5280] but further complicated by permitting non-
ASCII characters in the email address local-part. As mentioned in
Section 4.4 of [RFC5890] and in Section 4 of [RFC6532] Unicode
introduces the risk for visually similar characters which can be
exploited to deceive the recipient. The former document references
some means to mitigate against these attacks.
8. Security Considerations 8. IANA Considerations
Use for smtputf8Name for certificate subjectAltName will incur many This document makes use of object identifiers for the smtputf8Name
of the same security considerations of Section 8 in [RFC5280] but defined in Section Section 3 and the ASN.1 module identifier defined
further complicated by permitting non-ASCII characters in the email in Section Appendix A. IANA is kindly requested to make the
address local-part. As mentioned in Section 4.4 of [RFC5890] and in following assignments for:
Section 4 of [RFC6532] Unicode introduces the risk for visually
similar characters which can be exploited to deceive the recipient. The LAMPS-EaiAddresses-2016 ASN.1 module in the "SMI Security for
The former document references some means to mitigate against these PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
attacks.
The smtputf8Name otherName in the "PKIX Other Name Forms" registry
(1.3.6.1.5.5.7.8).
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 7, line 5 skipping to change at page 8, line 15
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>. <http://www.rfc-editor.org/info/rfc5891>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<http://www.rfc-editor.org/info/rfc5912>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
<http://www.rfc-editor.org/info/rfc6531>. <http://www.rfc-editor.org/info/rfc6531>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <http://www.rfc-editor.org/info/rfc6532>. 2012, <http://www.rfc-editor.org/info/rfc6532>.
9.2. Informative References 9.2. Informative References
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
Appendix A. Acknowledgements Appendix A. ASN.1 Module
The following ASN.1 module normatively specifies the Smtputf8Name
structure. This specification uses the ASN.1 definitions from
[RFC5912] with the 2002 ASN.1 notation used in that document.
LAMPS-EaiAddresses-2016
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-lamps-eai-addresses-2016(88) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
id-pkix OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7)}
--
-- otherName carries additional name types for subjectAltName, issuerAltName,
-- and other uses of GeneralNames.
--
-- Note that the LAMPS-EaiAddresses-2016 module and id-on-smtputf8Name OID
-- uses example IANA numbers i.e. are non-normative.
--
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
SmtpUtf8OtherNames OTHER-NAME ::= { on-smtputf8Name, ... }
on-smtputf8Name OTHER-NAME ::= {
SmtpUtf8Name IDENTIFIED BY id-on-smtputf8Name
}
id-on-smtputf8Name OBJECT IDENTIFIER ::= { id-on 9 }
SmtpUtf8Name ::= UTF8String (SIZE (1..MAX))
END
Figure 2
Appendix B. Acknowledgements
Thank you to Magnus Nystrom for motivating this document. Thanks to Thank you to Magnus Nystrom for motivating this document. Thanks to
Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi and Sean Leonard Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean
for their early feedback. Also thanks to John Klensin for his Leonard, Sean Turner, and Jim Schaad for their feedback. Also thanks
valuable input on internationalization, Unicode and ABNF formatting. to John Klensin for his valuable input on internationalization,
Unicode and ABNF formatting.
Authors' Addresses Authors' Addresses
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 20 change blocks. 
91 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/