draft-ietf-lamps-eai-addresses-10.txt   draft-ietf-lamps-eai-addresses-11.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: November 19, 2017 Google, Inc. Expires: December 20, 2017 Google, Inc.
May 18, 2017 June 18, 2017
Internationalized Email Addresses in X.509 certificates Internationalized Email Addresses in X.509 certificates
draft-ietf-lamps-eai-addresses-10 draft-ietf-lamps-eai-addresses-11
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 and Issuer Alternate Name field of an X.509 Subject Alternative Name and Issuer Alternative
extension that allows a certificate subject to be associated with an Name extension that allows a certificate subject to be associated
Internationalized Email Address. with an Internationalized Email Address.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 19, 2017. This Internet-Draft will expire on December 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 26 skipping to change at page 2, line 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Example of SmtpUTF8Name . . . . . . . . . . . . . . 10 Appendix B. Example of SmtpUTF8Name . . . . . . . . . . . . . . 10
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC5280] defines rfc822Name subjectAltName choice for representing [RFC5280] defines the rfc822Name subjectAltName name type for
[RFC5321] email addresses. This form is restricted to a subset of representing [RFC5321] email addresses. The syntax of rfc822Name is
US-ASCII characters and thus can't be used to represent restricted to a subset of US-ASCII characters and thus can't be used
Internationalized Email addresses [RFC6531]. To facilitate use of to represent Internationalized Email addresses [RFC6531]. This
these Internationalized Email addresses with X.509 certificates, this document calls for a new otherName variant to represent
document specifies a new name form in otherName so that Internationalized Email addresses. In addition this document calls
subjectAltName and issuerAltName can carry them. In addition this for all email address domains in X.509 certificates to conform to
document calls for all email address domain in X.509 certificates to IDNA2008 [RFC5890].
conform to IDNA2008 [RFC5890].
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
The GeneralName structure is defined in [RFC5280], and supports many The GeneralName structure is defined in [RFC5280], and supports many
different names forms including otherName for extensibility. This different name forms including otherName for extensibility. This
section specifies the SmtpUTF8Name name form of otherName, so that section specifies the SmtpUTF8Name name form of otherName, so that
Internationalized Email addresses can appear in the subjectAltName of Internationalized Email addresses can appear in the subjectAltName of
a certificate, the issuerAltName of a certificate, or anywhere else a certificate, the issuerAltName of a certificate, or anywhere else
that GeneralName is used. that GeneralName is used.
id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 } id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 }
SmtpUTF8Name ::= UTF8String (SIZE (1..MAX)) SmtpUTF8Name ::= UTF8String (SIZE (1..MAX))
When the subjectAltName (or issuerAltName) extension contains an When the subjectAltName (or issuerAltName) extension contains an
Internationalized Email address, the address MUST be stored in the Internationalized Email address with a non-ASCII local-part, the
SmtpUTF8Name name form of otherName. The format of SmtpUTF8Name is address MUST be stored in the SmtpUTF8Name name form of otherName.
defined as the ABNF rule SmtpUTF8Mailbox. SmtpUTF8Mailbox is a The format of SmtpUTF8Name is defined as the ABNF rule
modified version of the Internationalized Mailbox which was defined SmtpUTF8Mailbox. SmtpUTF8Mailbox is a modified version of the
in Section 3.3 of [RFC6531] which was itself derived from SMTP Internationalized Mailbox which was defined in Section 3.3 of
Mailbox from Section 4.1.2 of [RFC5321]. [RFC6531] defines the [RFC6531] which was itself derived from SMTP Mailbox from
following ABNF rules for Mailbox whose parts are modified for Section 4.1.2 of [RFC5321]. [RFC6531] defines the following ABNF
internationalization: <Local-part>, <Dot-string>, <Quoted-string>, rules for Mailbox whose parts are modified for internationalization:
<QcontentSMTP>, <Domain>, and <Atom>. In particular, <Local-part> <Local-part>, <Dot-string>, <Quoted- string>, <QcontentSMTP>,
was updated to also support UTF8-non-ascii. UTF8-non-ascii was <Domain>, and <Atom>. In particular, <Local- part> was updated to
described by Section 3.1 of [RFC6532]. Also, sub-domain was extended also support UTF8-non-ascii. UTF8-non-ascii was described by
to support U-label, as defined in [RFC5890]. Section 3.1 of [RFC6532]. Also, domain was 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,
domain that encode non-ASCII characters SHALL use U-label Unicode labels that include non-ASCII characters MUST be stored in U-label
native character labels and MUST NOT use A-label [RFC5890]. This (rather than A-label) [RFC5890] form. This restriction removes the
restriction prevents having to determine which label encoding A- or need to determine which label encoding A- or U-label is present in
U-label is present in the Domain. As per Section 2.3.2.1 of the Domain. As per Section 2.3.2.1 of [RFC5890], U-label are encoded
[RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and as UTF-8 [RFC3629] in Normalization Form C and other properties
other properties specified there. In SmtpUTF8Mailbox, sub-domain specified there. In SmtpUTF8Mailbox, domain labels that solely use
that encode ASCII character labels SHALL use NR-LDH restrictions as ASCII characters (meaning not A- nor U-labels) SHALL use NR-LDH
specified by section 2.3.1 of [RFC5890] and SHALL be restricted to restrictions as specified by section 2.3.1 of [RFC5890] and SHALL be
lower case letters. One suggested approach to apply these sub- restricted to lower case letters. NR-LDH stands for "Non-Reserved
domains restriction is to restrict sub-domain so that labels not Letters Digits Hyphen" and is the set LDH labels that do not have
start with two letters followed by two hyphen-minus characters. "--" characters in the third and forth character position, which
Consistent with the treatment of rfc822Name in [RFC5280], excludes "tagged domain names" such as A-labels. Consistent with the
SmtpUTF8Name is an envelope <Mailbox> and has no phrase (such as a treatment of rfc822Name in [RFC5280], SmtpUTF8Name is an envelope
common name) before it, has no comment (text surrounded in <Mailbox> and has no phrase (such as a common name) before it, has no
parentheses) after it, and is not surrounded by "<" and ">". comment (text surrounded in parentheses) after it, and is not
surrounded by "<" and ">".
Due to operational reasons described shortly and name constraint Due to operational reasons to be described shortly and name
compatibility reasons described in its section, SmtpUTF8Name constraint compatibility reasons described in Section 6, SmtpUTF8Name
subjectAltName MUST only be used when the local part of the email subjectAltName MUST only be used when the local part of the email
address contains UTF-8. When the local-part is ASCII, rfc822Name address contains contains non-ASCII characters. When the local-part
subjectAltName MUST be used instead of SmtpUTF8Name. The use of is ASCII, rfc822Name subjectAltName MUST be used instead of
rfc822Name rather than SmtpUTF8Name is currently more likely to be SmtpUTF8Name. This is compatible with legacy software that supports
supported. Also use of SmtpUTF8Name incurs higher byte only rfc822Name (and not SmtpUTF8Name).
representation overhead due to encoding with otherName and the
additional OID needed. This may be offset if domain requires non-
ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name
supports A-label.
SmtpUTF8Name is encoded as UTF8String. The UTF8String encoding MUST SmtpUTF8Name is encoded as UTF8String. The UTF8String encoding MUST
NOT contain a Byte-Order- Mark (BOM) [RFC3629] to aid consistency NOT contain a Byte-Order- Mark (BOM) [RFC3629] to aid consistency
across implementations particularly for comparison. across implementations particularly for comparison.
4. IDNA2008 4. IDNA2008
To facilitate comparison between email addresses, all email address To facilitate comparison between email addresses, all email address
domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and domains in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and
excludes any "mappings" mentioned in that document). Otherwise non- avoids any "mappings" mentioned in that document). Use of non-
conforming email address domains introduces the possibility of conforming email address domains introduces the possibility of
conversion errors between alternate forms. This applies to conversion errors between alternate forms. This applies to
SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and SmtpUTF8Name and rfc822Name in subjectAltName, issuerAltName and
anywhere else that GeneralName is used. anywhere else that these are used.
5. Matching of Internationalized Email Addresses in X.509 certificates 5. 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 on one or both inputs depending of whether the input is already
content or the email address that is being compared against. The in comparison form. Comparing SmtpUTF8Names consists of a domain
process for setup for comparing with SmtpUTF8Name is split into part step and a local-part step. The comparison form for local-parts
domain steps and local- part steps. The comparison form for local- always is UTF-8. The comparison form for domain parts 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 domain to A-label, this document [RFC5280] specify transforming domain to A-label (section 7.5 and 7.2
RECOMMENDS transforming to UTF-8 U-label instead. This reduces the in [RFC5280]), this document RECOMMENDS transforming to UTF-8 U-label
likelihood of errors by reducing conversions as more implementations instead. This reduces the likelihood of errors by reducing
natively support U-label domains. conversions as more implementations natively support U- label
domains.
Comparison of two SmtpUTF8Name is straightforward with no setup work Comparison of two SmtpUTF8Name is straightforward with no setup work
needed. They are considered equivalent if there is an exact octet- needed. They are considered equivalent if there is an exact octet-
for-octet match. Comparison with other email address forms such as for-octet match. Comparison with email addresses such as
Internationalized email address or rfc822Name requires additional Internationalized email address or rfc822Name requires additional
setup steps. Domain setup is particularly important for forms that setup steps for domain part and local-part. The initial preparation
may contain A- or U-label such as International email address, or for the email addresses is to remove any phrases or comments, as well
A-label only forms such as rfc822Name. This document specifies the as "<" and ">" present. This document calls for comparison of domain
process to transform the domain to U-label. (To convert the domain labels that include non-ASCII characters be tranformed to U-label if
to A-label, follow the process specified in section 7.5 and 7.2 in not already in that form. The first step is to detect use of the
[RFC5280]) The first step is to detect A-label by using section 5.1 A-label by using section 5.1 of [RFC5891]. Next if necessary,
of [RFC5891]. Next if necessary, transform the A-label to U-label transform any A-labels to U-labels Unicode as specified in section
Unicode as specified in section 5.2 of [RFC5891]. Finally if 5.2 of [RFC5891]. Finally if necessary convert the Unicode to UTF-8
necessary convert the Unicode to UTF-8 as specified in section 3 of as specified in section 3 of [RFC3629]. For ASCII NR-LDH labels,
[RFC3629]. For ASCII NR-LDH labels, upper case letters are converted upper case letters are converted to lower case letters. In setup for
to lower case letters. In setup for SmtpUTF8Mailbox, the email SmtpUTF8Mailbox, the email address local-part MUST conform to the
address local-part MUST conform to the requirements of [RFC6530] and requirements of [RFC6530] and [RFC6531], including being a string in
[RFC6531], including being a string in UTF-8 form. In particular, UTF-8 form. In particular, the local-part MUST NOT be transformed in
the local-part MUST NOT be transformed in any way, such as by doing any way, such as by doing case folding or normalization of any kind.
case folding or normalization of any kind. The <Local-part> part of The <Local-part> part of an Internationalized email address is
an Internationalized email address is already in UTF-8. For already in UTF-8. For rfc822Name the local-part, which is IA5String
rfc822Name the local-part, which is IA5String (ASCII), trivially maps (ASCII), trivially maps to UTF-8 without change. Once setup is
to UTF-8 without change. Once setup is complete, they are again complete, they are again compared octet-for-octet.
compared octet-for-octet.
To summarize non-normatively, the comparison steps including setup To summarize non-normatively, the comparison steps including setup
are: are:
1. If the domain contains A-labels, transform them to U-label. 1. If the domain contains A-labels, transform them to U-labels.
2. If the domain contains ASCII NR-LDH labels, lowercase them. 2. If the domain contains ASCII NR-LDH labels, lowercase them.
3. Ensure local-part is UTF-8. 3. Compare strings octet-for-octet for equivalence.
4. Compare strings octet-for-octet for equivalence.
This specification expressly does not define any wildcards characters This specification expressly does not define any wildcard characters
and SmtpUTF8Name comparison implementations MUST NOT interpret any and SmtpUTF8Name comparison implementations MUST NOT interpret any
character as wildcards. Instead, to specify multiple email addresses character as wildcards. Instead, to specify multiple email addresses
through SmtpUTF8Name, the certificate SHOULD use multiple through SmtpUTF8Name, the certificate MUST use multiple
subjectAltNames or issuerAltNames to explicitly carry those email subjectAltNames or issuerAltNames to explicitly carry any additional
addresses. email addresses.
6. Name constraints in path validation 6. Name constraints in path validation
This section updates [RFC5280] name constraints defined in section This section updates section 4.2.1.10 of [RFC5280] to extend
4.2.1.10 to work with SmtpUTF8Name subjectAltName. The following rfc822Name name constraints to SmtpUTF8Name subjectAltNames. A
specifies that a SmtpUTF8Name aware CA use a compatible name SmtpUTF8Name aware path validators will apply name constraint
constraint representation. Similarly a SmtpUTF8Name aware path comparison to the subject distinguished name and both forms of
validators MUST be able to apply name constraint comparison to the subject alternative name rfc822Name and SmtpUTF8Name.
subject distinguished name and both forms of subject alternative name
rfc822Name and SmtpUTF8Name.
The SmtpUTF8Name aware email address name constraint form is Both rfc822Name and SmtpUTF8Name subject alternative names represent
specified to be rfc822Name motivated by compatibility considerations the same underlying email address namespace. Since legacy CAs
with legacy systems that already understand that form. This constrained to issue certificates for a specific set of domains would
specification modifies [RFC5280] name constraint to only require with lack corresponding UTF-8 constraints, this specification modifies and
MAY that it represents all addresses at a host or all mailboxes in a extends rfc822Name name SmtpUTF8Name does not violate existing name
domain, and require with MAY NOT that it represent a particular constraints. Since it is not valid to include non-ASCII UTF-8
mailbox. For context, [RFC5280] Section 4.2.1.10 specifies with MAY characters in the local-part of rfc822Name name constraints, and
that name constraint represent a particular mailbox, all addresses at since name constraints that include a local-part are rarely, if at
a host, or all mailboxes in a domain by specifying the complete email all, used in practice, this specification modifies [RFC5280] name
address, a host name, or a domain. The change is due to rfc822Name constraints to only admit the forms represent all addresses at a host
name constraints inability to represent a specific mailbox with a or all mailboxes in a domain, and deprecates rfc822Name name
UTF-8 email local part email address. CA certificate issuers should constraints that represent a particular mailbox. That is, rfc822Name
be aware of this lessened support. constraints with a local-part SHOULD NOT be used.
Constraint comparison with SmtpUTF8Name subjectAltName starts with Constraint comparison with SmtpUTF8Name subjectAltName starts with
the setup steps defined by Section 5. The setup applies to the the setup steps defined by Section 5. Setup converts the inputs of
inputs of the comparison which is one of a subject distinguished name the comparison which is one of a subject distinguished name or a
or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a rfc822Name or SmtpUTF8Name subjectAltName, and one of a rfc822Name
rfc822Name name constraint. Non-normatively the setup will convert name constraint, to constraint comparison form. For rfc822Name name
any domain A-label to U-label in the rfc822Name name constraint, and constraint, this will convert any domain A-labels to U-labels. For
to lower case any doman NR-LDH label in both the name constraint and both the name constraint and the subject, this will lower case any
the subject. After setup, this follows the comparison steps defined domain NR-LDH labels. Strip the local-part and "@" separator from
in 4.2.1.10 of [RFC5280] with some modifications as follows. The each rfc822Name and SmtpUTF8Name, leaving just the domain-part.
comparison process starts by determining the name constraint After setup, this follows the comparison steps defined in 4.2.1.10 of
representation i.e. email host name or domain part, then comparing [RFC5280] as follows. If the resulting name constraint domain starts
the name constraint against the corresponding part in the email with a "." character, then for the name constraint to match, a suffix
address using a byte for byte comparison. This document suggests of the resulting subject alternative name domain MUST match the name
that name constraint comparison with subject distinguished name or constraint (including the leading ".") octet for octet. If the
rfc822Name subjectAltName also follow these setup and comparisons resulting name constraint domain does not start with a "." character,
steps as well. then for the name constraint to match, the entire resulting subject
alternative name domain MUST match the name constraint octet for
octet.
Certificate Authorities that wish to issue CA certificates with email
address name constraint MUST use rfc822Name subject alternative names
only. These MUST be IDNA2008 conformant names with no mappings, and
with non-ASCII domains encoded in A-labels only.
The name constraint requirement with SmtpUTF8Name subject alternative The name constraint requirement with SmtpUTF8Name subject alternative
name is illustrated in the non-normative diagram Figure 1. The first name is illustrated in the non-normative diagram Figure 1. The first
example (1) illustrates a permitted rfc822Name ASCII only hostname example (1) illustrates a permitted rfc822Name ASCII only hostname
name constraint, and the corresponding valid rfc822Name name constraint, and the corresponding valid rfc822Name
subjectAltName and SmtpUTF8Name subjectAltName email addresses. The subjectAltName and SmtpUTF8Name subjectAltName email addresses. The
second example (2) illustrates a permitted rfc822Name hostname name second example (2) illustrates a permitted rfc822Name hostname name
constraint with A-label, and the corresponding valid rfc822Name constraint with A-label, and the corresponding valid rfc822Name
subjectAltName and SmtpUTF8Name subjectAltName email addresses. subjectAltName and SmtpUTF8Name subjectAltName email addresses. Note
that an email address with ASCII only local-part is encoded as
rfc822Name despite also having unicode present in the domain.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Root CA Cert | | Root CA Cert |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| |
v v
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Intermediate CA Cert | | Intermediate CA Cert |
| Permitted | | Permitted |
| rfc822Name: elementary.school.example.com (1) | | rfc822Name: elementary.school.example.com (1) |
skipping to change at page 7, line 37 skipping to change at page 7, line 37
| SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) | | SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Name constraints with SmtpUTF8Name and rfc822Name Name constraints with SmtpUTF8Name and rfc822Name
Figure 1 Figure 1
7. Security Considerations 7. Security Considerations
Use for SmtpUTF8Name for certificate subjectAltName (and Use of SmtpUTF8Name for certificate subjectAltName (and
issuerAltName) will incur many of the same security considerations of issuerAltName) will incur many of the same security considerations as
Section 8 in [RFC5280] but is further complicated by permitting non- in Section 8 in [RFC5280] , but introduces a new issue by permitting
ASCII characters in the email address local-part. This complication, non-ASCII characters in the email address local-part. This issue, as
as mentioned in Section 4.4 of [RFC5890] and in Section 4 of mentioned in Section 4.4 of [RFC5890] and in Section 4 of [RFC6532],
[RFC6532], is that use of Unicode introduces the risk of visually is that use of Unicode introduces the risk of visually similar and
similar and identical characters which can be exploited to deceive identical characters which can be exploited to deceive the recipient.
the recipient. The former document references some means to mitigate The former document references some means to mitigate against these
against these attacks. attacks.
8. IANA Considerations 8. IANA Considerations
in Section Section 3 and the ASN.1 module identifier defined in in Section Section 3 and the ASN.1 module identifier defined in
Section Appendix A. IANA is kindly requested to make the following Section Appendix A. IANA is kindly requested to make the following
assignments for: assignments for:
The LAMPS-EaiAddresses-2016 ASN.1 module in the "SMI Security for The LAMPS-EaiAddresses-2016 ASN.1 module in the "SMI Security for
PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
 End of changes. 25 change blocks. 
141 lines changed or deleted 142 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/