Diff: rfc9734.original.xml

	rfc9734.original.xml	rfc9734.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.	-ietf-lamps-im-keyusage-04" number="9734" category="std" updates="" obsoletes=""
	4) -->	consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRef
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft	s="true" version="3" xml:lang="en">
	-ietf-lamps-im-keyusage-04" category="std" consensus="true" submissionType="IETF
	" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.23.2 -->
	<front>	<front>
	<title abbrev="extendedKeyUsage for IM URIs">X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs</title>	<title abbrev="extendedKeyUsage for IM URIs">X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-im-keyusage-04"/>	<seriesInfo name="RFC" value="9734"/>
	<author fullname="Rohan Mahy">	<author fullname="Rohan Mahy">
	<organization>Rohan Mahy Consulting Services</organization>	<organization>Rohan Mahy Consulting Services</organization>
	<address>	<address>
	<email>rohan.ietf@gmail.com</email>	<email>rohan.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>

	<date year="2024" month="December" day="09"/>	<date year="2025" month="February"/>

	<area>SEC</area>	<area>SEC</area>

	<workgroup>LAMPS WG</workgroup>	<workgroup>lamps</workgroup>

	<keyword>x.509</keyword>	<keyword>x.509</keyword>
	<keyword>certificate</keyword>	<keyword>certificate</keyword>
	<keyword>extended key usage</keyword>	<keyword>extended key usage</keyword>
	<keyword>eku</keyword>	<keyword>eku</keyword>
	<keyword>instant messaging</keyword>	<keyword>instant messaging</keyword>
	<keyword>im URI</keyword>	<keyword>im URI</keyword>
	<keyword>mimi URL</keyword>	<keyword>mimi URL</keyword>
	<abstract>	<abstract>

	<?line 61?>

	<t>RFC 5280 specifies several extended key purpose identifiers	<t>RFC 5280 specifies several extended key purpose identifiers
	(KeyPurposeIds) for X.509 certificates. This document defines	(KeyPurposeIds) for X.509 certificates. This document defines
	Instant Messaging (IM) identity KeyPurposeId for inclusion in	Instant Messaging (IM) identity KeyPurposeId for inclusion in
	the Extended Key Usage (EKU) extension of X.509 v3 public key	the Extended Key Usage (EKU) extension of X.509 v3 public key
	certificates</t>	certificates</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	rohanmahy.github.io/mahy-lamps-im-keyusage/draft-ietf-lamps-im-keyusage.html"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-lamps-im-keyusage/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	LAMPS WG Working Group mailing list (<eref target="mailto:lamps@ietf.org
	"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/lamps/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/lamps/"
	/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/rohanmahy/mahy-lamps-im-keyusage"/>.</t
	>
	</note>
	</front>	</front>
	<middle>	<middle>

	<?line 70?>

	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>
	<t>Instant Messaging (IM) systems using the Messaging Layer Security (MLS)	<t>Instant Messaging (IM) systems using the Messaging Layer Security (MLS)
	<xref target="RFC9420"/> protocol can incorporate per-client identity certificat e	<xref target="RFC9420"/> protocol can incorporate per-client identity certificat e
	credentials. A subjectAltName in these certificates can be an IM URI	credentials. A subjectAltName in these certificates can be an IM URI

	<xref target="RFC3860"/> or XMPP URI <xref target="RFC6121"/>, for example.</t>	<xref target="RFC3860"/> or Extensible Messaging and Presence Protocol (XMPP) UR
	<t>Organizations may be unwilling to issue certificates for Instant Messag	I <xref target="RFC6121"/>, for example.</t>
	e	<t>Organizations may be unwilling to issue certificates for an IM
	client using a general KeyPurposeId such as <tt>id-kp-serverAuth</tt> or	client using a general KeyPurposeId, such as <tt>id-kp-serverAuth</tt> or
	<tt>id-kp-clientAuth</tt>, because of the risk that such certificates could be	<tt>id-kp-clientAuth</tt>, because of the risk that such certificates could be
	abused in a cross-protocol attack.</t>	abused in a cross-protocol attack.</t>

	<t>An explanation of MLS credentials as they apply to Instant Messaging is	<t>An explanation of MLS credentials as they apply to IM is
	described in <xref target="I-D.barnes-mimi-identity-arch"/>. These credentials a re	described in <xref target="I-D.barnes-mimi-identity-arch"/>. These credentials a re
	expected to be heavily used in the More Instant Messaging Interoperability	expected to be heavily used in the More Instant Messaging Interoperability
	(MIMI) Working Group.</t>	(MIMI) Working Group.</t>
	</section>	</section>
	<section anchor="conventions-and-definitions">	<section anchor="conventions-and-definitions">
	<name>Conventions and Definitions</name>	<name>Conventions and Definitions</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14	<t>
	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	nterpreted as	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	only when, they	be
	appear in all capitals, as shown here.</t>	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	<?line -18?>	target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
	</section>	</t>
		</section>
	<section anchor="the-im-uri-extended-key-usage">	<section anchor="the-im-uri-extended-key-usage">

	<name>The IM URI Extended Key Usage</name>	<name>The IM URI EKU</name>
	<t>This specification defines the KeyPurposeId id-kp-imUri, which	<t>This specification defines the KeyPurposeId <tt>id-kp-imUri</tt>, which
	may be included in certificates used to prove the identity of an Instant	may be
	Messaging client.	included in certificates used to prove the identity of an IM client. This
	This EKU extension <bcp14>MAY</bcp14>, at the option of the certificate issuer,	EKU extension <bcp14>MAY</bcp14>, at the option
	be either	of the certificate issuer, be either critical or non-critical.</t>
	critical or non-critical.</t>
	<artwork><![CDATA[	<!--[rfced] We note a small discrepancy between the ASN.1 snippet in
		Section 3 and the ASN.1 in Appendix A: the { character at the end
		of the "id-kp" line in Section 3 is on the following line in the
		Appendix. Please review and let us know if/how to make these
		consistent. Might it be possible to simply point the reader to
		Appendix A instead of repeating the code?

		Original (Section 3):
	id-kp OBJECT IDENTIFIER ::= {	id-kp OBJECT IDENTIFIER ::= {
	iso(1) identified-organization(3) dod(6) internet(1)	iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) kp(3) }	security(5) mechanisms(5) pkix(7) kp(3) }

	id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }	id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }

	]]></artwork>
		Original (Appendix A):
		id-kp OBJECT IDENTIFIER ::=
		{ iso(1) identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) kp(3) }

		id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }

		-->
		<sourcecode type="asn.1"><![CDATA[
		id-kp OBJECT IDENTIFIER ::= {
		iso(1) identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) kp(3) }

		id-kp-imUri OBJECT IDENTIFIER ::= { id-kp 40 }]]></sourcecode>

	</section>	</section>
	<section anchor="security-considerations">	<section anchor="security-considerations">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>The Security Considerations of <xref target="RFC5280"/> are applicable
	to this	<!--[rfced] Might it be beneficial to the reader to replace "This"
		with the antecedent? If so, we will also use the necessary <tt>
		marking in the xml.

		Original:
		This extended key purpose does not introduce new security risks but
		instead reduces existing security risks by providing means to identify
		if the certificate is generated to sign IM identity credentials.

		Perhaps:
		The KeyPurposeId id-kp-imUri does not introduce new security risks;
		instead, it reduces existing security risks by providing means to
		identify if the certificate is generated to sign IM identity
		credentials.

		-->

		<t>The security considerations of <xref target="RFC5280"/> are applicable
		to this
	document. This extended key purpose does not introduce new security	document. This extended key purpose does not introduce new security
	risks but instead reduces existing security risks by providing means	risks but instead reduces existing security risks by providing means
	to identify if the certificate is generated to sign IM identity credentials.	to identify if the certificate is generated to sign IM identity credentials.
	Issuers <bcp14>SHOULD NOT</bcp14> set the <tt>id-kp-imUri</tt> extended key purp ose and an	Issuers <bcp14>SHOULD NOT</bcp14> set the <tt>id-kp-imUri</tt> extended key purp ose and an

	<tt>id-kp-clientAuth</tt> or <tt>id-kp-serverAuth</tt> extended key purpose, as that would	<tt>id-kp-clientAuth</tt> or <tt>id-kp-serverAuth</tt> extended key purpose: tha t would
	defeat the improved specificity offered by having an <tt>id-kp-imUri</tt> extend ed key	defeat the improved specificity offered by having an <tt>id-kp-imUri</tt> extend ed key
	purpose.</t>	purpose.</t>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>IANA is requested to register the following OIDs in the "SMI Security
	for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). These	<!-- [rfced] We had the following questions regarding the IANA
	OIDs are defined in Section 4.</t>	Considerations section:

		a) Please review the citation to the Security Considerations section
		in the following text:

		Original:
		IANA is requested to register the following OIDs in the "SMI Security
		for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). These OIDs
		are defined in Section 4.

		Section 3 defines the "KeyPurposeId id-kp-imUri". We will update
		unless we hear objection.

		b) We note that the first paragraph of the IANA Considerations spoke
		of OIDs (plural), but we see only one registration in the IANA
		registry mentioned. We have updated to use the singular. Please
		review that this is as intended.
		-->
		<t>IANA has registered the following OID in the "SMI Security
		for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). This
		OID is defined in <xref target="security-considerations"/>.</t>
	<table>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Decimal</th>	<th align="left">Decimal</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	<th align="left">References</th>	<th align="left">References</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>

	<td align="left">TBD1</td>	<td align="left">40</td>
	<td align="left">id-kp-imUri</td>	<td align="left">id-kp-imUri</td>

	<td align="left">This-RFC</td>	<td align="left">RFC 9734</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<t>IANA is also requested to register the following ASN.1 <xref target="IT U.X690.2021"/>	<t>IANA has also registered the following ASN.1 <xref target="ITU.X690.202 1"/>
	module OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5. 5.7.0). This OID is defined in <xref target="asn1-module"/>.</t>	module OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5. 5.7.0). This OID is defined in <xref target="asn1-module"/>.</t>
	<table>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Decimal</th>	<th align="left">Decimal</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	<th align="left">References</th>	<th align="left">References</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>

	<td align="left">TBD2</td>	<td align="left">113</td>
	<td align="left">id-mod-im-eku</td>	<td align="left">id-mod-im-eku</td>

	<td align="left">This-RFC</td>	<td align="left">RFC 9734</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>

		<displayreference target="I-D.barnes-mimi-identity-arch" to="E2E-IDENTITY"/>
	<references anchor="sec-combined-references">	<references anchor="sec-combined-references">
	<name>References</name>	<name>References</name>
	<references anchor="sec-normative-references">	<references anchor="sec-normative-references">
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="ITU.X690.2021">
		<reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-
		X.690">
	<front>	<front>
	<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>	<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
	<author>	<author>

	<organization>International Telecommunications Union</organization >	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2021"/>	<date month="February" year="2021"/>
	</front>	</front>
	<seriesInfo name="ITU-T" value="Recommendation X.690"/>	<seriesInfo name="ITU-T" value="Recommendation X.690"/>

		<seriesInfo name="ISO/IEC" value="8825-1-2021"/>
	</reference>	</reference>

	<reference anchor="ITU.X680.2021">
		<reference anchor="ITU.X680.2021" target="https://www.itu.int/rec/T-REC-
		X.680">
	<front>	<front>
	<title>Information Technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>	<title>Information Technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>
	<author>	<author>

	<organization>International Telecommunications Union</organization >	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2021"/>	<date month="February" year="2021"/>
	</front>
	<seriesInfo name="ITU-T" value="Recommendation X.680"/>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC5280">
	<front>
	<title>Internet X.509 Public Key Infrastructure Certificate and Cert
	ificate Revocation List (CRL) Profile</title>
	<author fullname="D. Cooper" initials="D." surname="Cooper"/>
	<author fullname="S. Santesson" initials="S." surname="Santesson"/>
	<author fullname="S. Farrell" initials="S." surname="Farrell"/>
	<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
	<author fullname="R. Housley" initials="R." surname="Housley"/>
	<author fullname="W. Polk" initials="W." surname="Polk"/>
	<date month="May" year="2008"/>
	<abstract>
	<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
	icate revocation list (CRL) for use in the Internet. An overview of this approac
	h and model is provided as an introduction. The X.509 v3 certificate format is d
	escribed in detail, with additional information regarding the format and semanti
	cs of Internet name forms. Standard certificate extensions are described and two
	Internet-specific extensions are defined. A set of required certificate extensi
	ons is specified. The X.509 v2 CRL format is described in detail along with stan
	dard and Internet-specific extensions. An algorithm for X.509 certification path
	validation is described. An ASN.1 module and examples are provided in the appen
	dices. [STANDARDS-TRACK]</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="RFC" value="5280"/>	<seriesInfo name="ITU-T Recommendation" value="X.680"/>
	<seriesInfo name="DOI" value="10.17487/RFC5280"/>	<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
	</reference>	</reference>

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		280.xml"/>
	</references>	</references>
	<references anchor="sec-informative-references">	<references anchor="sec-informative-references">
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC9420">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<front>	420.xml"/>
	<title>The Messaging Layer Security (MLS) Protocol</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<author fullname="R. Barnes" initials="R." surname="Barnes"/>	860.xml"/>
	<author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	>	121.xml"/>
	<author fullname="R. Robert" initials="R." surname="Robert"/>	<!-- [I-D.barnes-mimi-identity-arch] IESG State: Expired as of 12/13/24.
	<author fullname="J. Millican" initials="J." surname="Millican"/>
	<author fullname="E. Omara" initials="E." surname="Omara"/>
	<author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon
	"/>
	<date month="July" year="2023"/>
	<abstract>
	<t>Messaging applications are increasingly making use of end-to-en
	d security mechanisms to ensure that messages are only accessible to the communi
	cating endpoints, and not to any servers involved in delivering messages. Establ
	ishing keys to provide such protections is challenging for group chat settings,
	in which more than two clients need to agree on a key but may not be online at t
	he same time. In this document, we specify a key establishment protocol that pro
	vides efficient asynchronous group key establishment with forward secrecy (FS) a
	nd post-compromise security (PCS) for groups in size ranging from two to thousan
	ds.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9420"/>
	<seriesInfo name="DOI" value="10.17487/RFC9420"/>
	</reference>
	<reference anchor="RFC3860">
	<front>
	<title>Common Profile for Instant Messaging (CPIM)</title>
	<author fullname="J. Peterson" initials="J." surname="Peterson"/>
	<date month="August" year="2004"/>
	<abstract>
	<t>At the time this document was written, numerous instant messagi
	ng protocols were in use, and little interoperability between services based on
	these protocols has been achieved. This specification defines common semantics a
	nd data formats for instant messaging to facilitate the creation of gateways bet
	ween instant messaging services. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3860"/>
	<seriesInfo name="DOI" value="10.17487/RFC3860"/>
	</reference>
	<reference anchor="RFC6121">
	<front>
	<title>Extensible Messaging and Presence Protocol (XMPP): Instant Me
	ssaging and Presence</title>
	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
	"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document defines extensions to core features of the Extens
	ible Messaging and Presence Protocol (XMPP) that provide basic instant messaging
	(IM) and presence functionality in conformance with the requirements in RFC 277
	9. This document obsoletes RFC 3921. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6121"/>
	<seriesInfo name="DOI" value="10.17487/RFC6121"/>
	</reference>
	<reference anchor="I-D.barnes-mimi-identity-arch">
	<front>
	<title>Identity for E2E-Secure Communications</title>
	<author fullname="Richard Barnes" initials="R." surname="Barnes">
	<organization>Cisco</organization>
	</author>
	<author fullname="Rohan Mahy" initials="R." surname="Mahy">
	<organization>Wire</organization>
	</author>
	<date day="23" month="October" year="2023"/>
	<abstract>
	<t> End-to-end (E2E) security is a critical property for modern
	user
	communications systems. E2E security protects users' communications
	from tampering or inspection by intermediaries that are involved in
	delivering those communcations from one logical endpoint to another.
	In addition to the much-discussed E2E encryption systems, true E2E
	security requires an identity mechanism that prevents the
	communications provider from impersonating participants in a session,
	as a way to gain access to the session. This document describes a
	high-level architecture for E2E identity, identifying the critical
	mechanisms that need to be specified.


	</t>	-->
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	</front>	barnes-mimi-identity-arch.xml"/>
	<seriesInfo name="Internet-Draft" value="draft-barnes-mimi-identity-ar
	ch-01"/>
	</reference>
	</references>	</references>
	</references>	</references>

	<?line 157?>

	<section anchor="asn1-module">	<section anchor="asn1-module">
	<name>ASN.1 Module</name>	<name>ASN.1 Module</name>
	<t>The following module adheres to ASN.1 specifications <xref target="ITU. X680.2021"/> and	<t>The following module adheres to ASN.1 specifications <xref target="ITU. X680.2021"/> and
	<xref target="ITU.X690.2021"/>.</t>	<xref target="ITU.X690.2021"/>.</t>

	<sourcecode type="asn1"><![CDATA[
		<sourcecode type="asn.1"><![CDATA[
	<CODE BEGINS>	<CODE BEGINS>

	IM-EKU	IM-EKU
	{ iso(1) identified-organization(3) dod(6) internet(1)	{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)

	id-mod-im-eku (TBD2) }	id-mod-im-eku (113) }

	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=
	BEGIN	BEGIN

	-- OID Arc	-- OID Arc

	id-kp OBJECT IDENTIFIER ::=	id-kp OBJECT IDENTIFIER ::=
	{ iso(1) identified-organization(3) dod(6) internet(1)	{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) kp(3) }	security(5) mechanisms(5) pkix(7) kp(3) }

	-- Extended Key Usage Values	-- Extended Key Usage Values


	id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }	id-kp-imUri OBJECT IDENTIFIER ::= { id-kp 40 }

	END	END


	<CODE ENDS>	<CODE ENDS>]]></sourcecode>
	]]></sourcecode>
	</section>
	<section anchor="change-log">
	<name>Change log</name>
	<t>RFC Editor, please remove this section on publication.</t>
	<ul spacing="normal">
	<li>
	<t>made Proposed Standard</t>
	</li>
	<li>
	<t>added a <bcp14>MAY</bcp14> statement in Section 3</t>
	</li>
	<li>
	<t>corrected typo in registration of the ASN.1 module (Thanks Sean!)</
	t>
	</li>
	<li>
	<t>updated author affiliation</t>
	</li>
	<li>
	<t>added ASN.1 module</t>
	</li>
	<li>
	<t>specified that eku is optionally critical</t>
	</li>
	</ul>
	</section>	</section>


	<section numbered="false" anchor="acknowledgments">	<section numbered="false" anchor="acknowledgments">
	<name>Acknowledgments</name>	<name>Acknowledgments</name>

	<t>Thanks to Sean Turner and Russ Housley for reviews, suggestions,	<t>Thanks to <contact fullname="Sean Turner"/> and <contact
	corrections, and encouragement.</t>	fullname="Russ Housley"/> for reviews, suggestions, corrections, and
		encouragement.</t>
	</section>	</section>

	</back>
	<!-- ##markdown-source:	<!--[rfced] We had the following comments regarding abbreviation use
	H4sIAAAAAAAAA8VYbXPbuBH+jl+xp3yROiZj2U7iaHK5ky0lYWPZriX3ctPp	in this document:
	TCASklDzRQVIO6rj/Jb+lv6yPgtQb7GS6bVz0yQTESCw2H1299kFgyAQpS5T
	1aHGh/DZ/ks6VabUEx3LUlH/U6nyRCX0Xi3o2sqpomb//XWLJoWhKLelzEsa	a) Please note that we have expanded the following abbreviations.
	KIs3Op/S9VVkG0KOx0bdQp6qd2Oz3+t2DeplfMC0MIsO2TIRIiniXGZQIzFy	Please review and let us know any objections.
	UgZalZMgldncBjoLbtSiYgnB/pGw1TjT1uoiLxdzrI/6ozdET0imtsChGifO
	+di8bOxBh0SXhdEy5UHUPcEPlGhEV6M3DZFX2ViZjkigSkfERW5VbivbodJU	XMPP - Extensible Messaging and Presence Protocol
	SsCEQyGNkh0a9k/FXWFupqao5h066w4uh/TLWwG9MJ10BAX0idHjh3gNIA+X
	KBAWk7PCzd5U/KNrDLMlhm4yY4j4KdOZxvOZuFV5BRWJvtaAyKPwC7RjF7zl	b) Please note that we have updated frequently used expanded
	95jNpE475AD8mbEMCzPl7bqcVeMOmWIm80zOFk/5v8dAY2kK/W3ZoVlZzm3n	abbreviations to remove their expansions after first use in accordance
	6dPVltALCXXxjc1Pv+fCcFZmqRCyKmeFYeBwFNGkSlPv/is+hgYQ7F5AbZnr	with the guidance at
	f8gS/t58SafwVpWWbPNQmVsdK+s2KG+50zZkFX6e8kwYF5kQeWEyiLp1UEaj	https://www.rfc-editor.org/styleguide/part2/#exp_abbrev.-->
	6/DD85f74cH+QbvjNteZ8NoNsCKf+A1FTiMVz/IiLaYL+KU7PA/bpPK4SFgB
	U6XKdupNw7mKvft5WzGhE2l1TP3l4iteTM2T/lVrr95yKvMix4700apTrKoX	<!-- [rfced] Please review the "type" attribute of each sourcecode
	yTyhnrZscaXtDAH19eLecvEKXKohRJbkpTK50wnHjFSqAEhW5bWelq5z/Lgd	element in the XML file to ensure correctness. If the current
	LhuIQXFDq4xWVgOKpUAAF4zgDCcCse0t/RACS7HC9fi/wnVsSyPjkoaLvJSf	list of preferred values for "type"
	6Lwo/aqLHMzjUG99E+exwzmvt/xfgTgGEHppJEebEEEQkKzNE+LqzSk9Ozje	(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
	J+utgPusulUGKm3xxbwy88Iq0sxnvM5Y0QSfXvr5KLGeiz11bzCPDYlGM20J	does not contain an applicable type, then feel free to let us
	vFpBt5ISNdE5kuQxbTejQas+oVzQpnQnW+dxWjHf4kmUs+9UBae6rd3hVbo9	know. Also, it is acceptable to leave the "type" attribute not
	hA3jFI6BOWJTwRqTTCdJqoR4wp4xRVLFznvfUtMubKkyCyLlKdZmveBMLpQB	set.
	G8SVYUOag7NhS9zf/wSwXx4d7D880NwUZREXKcWSrYkL2Gm40M2VCeJUM04r
	IDZ5PDbKTaPIhNQl1KC/qbjspuU5SAuSWBO4adM+d8ZYIW/rmlercnj8nFVh	Particularly, note that we have updated an <artwork> tag in Section 3
	pw0uL/kF+RfP2wfth4c9h7n6BN5MVSjExQYBWtD6gmVW+Z1OU4dAQSiG1VdH	to instead appear as <sourcecode>. Please review and let us know any
	Py7PMMGb54GTNFW5C7ctd9sqnpG09FEnwc08QMQjJrtIoo/QV9SzXpCb3YMy	objections.
	saxgORzOzjDa3uBBll7UNh5FlSbYgAYBOxJGTVJsCmuDlV9kWcr4BmZ3c2Aw	-->
	T2W+Sm94kzbcwGrixAXJ+TxdMA6PI0ZbkSgbGz32xwHnKOiFY2mQCAEX12Dp
	7UCaePbwECJpnCM3DzJKQBf4G1JwDvCfKXmrUy7nXrCLw8KoHTo4vikQX3Ks	<!--[rfced] Please note that we have added a single pair of <tt> tags
	UxwkmoNoELW2CzYMRgKgpN3yoexox/acsdqNhYBejhG437DUGFwPR9zS8C+d	around a use of id-kp-imUri for consistency. Please let us know
	X7jnq/6frqOrfo+fh++6Z2erB1GvGL67uD7rrZ/WO08vBoP+ec9vxixtTYnG	any objections.-->
	oPsr3rBWjYvLUXRx3j1reMs3OQZQ1QhpNntuFGMmv3LDyenlv/7ZPoI7fkDY
	H7TbL5EPfnDcfnGEwd1M5f60IgfMfsjeFvC2ksbFTsppPNclfLTH0WBnxV0O	<!--[rfced] Please review the "Inclusive Language" portion of the
	1xhOmz/8hZH5a4dejeN5++h1PcEGb00uMduadJg9nnm02YO4Y2rHMSs0t+a/	online Style Guide
	Qnpb3+6vW+Ml7huTr34CCSgK2sc/vXYhxFHi2WYHS3MQwVt2q3DWZcGF8BYX	<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	+GTX2bXRe/CAjmeiZh9XEBLvy60Md+kA/yOdb5WTuCJTJDAToU8PsU4PTyah	and let us know if any changes are needed. Updates of this
	1wxFZKOGwH74tXRyivmSBni0cahnP8NERAp9qTLgauQMN1MgQfRVwXKMqPjy	nature typically result in more precise language, which is
	5YtwdhFdnPyxfzqiqNc/H0Vvov4VUafzI92jtGtbNNutdc1Ngs0utHnYQsAn	helpful for readers.
	zectH+S5KrFacH/gC0/zWQv9fIz+U9vM8mh+oz81X7ToZs6bH4TYwHaHIk4P
	jz+NTnpt7GDF2b+r4sbtLxQ0coMevvGSUfPZxR0HsouzlFkToIxTl7CcxWKZ	Note that our script did not flag any words in particular, but this
	xcvOYWcjkhTwM3ostt1Va0W5ulvZLrgAWBpXpbvaKJkQmBSrWJxvXldrqV67	should still be reviewed as a best practice.
	cPGiXSebKQlruKh58Bekd7m8rl41IVs9dTV2Xbk3qrWIXIBYWmcmNPBR9XHD
	Dx9328scJPMdpY+ja0eZ3CVkz9cqhPIdl0CQ4UTVca0zlyvJKil9rkxAYgkj
	M0Od4XKdf0dXUR8Tuiaqe959FBxuEqgZ9fcKdzqPmlFTOAQNE+sxKdK0uOOj
	LqKeXZa0xnAQraJKcFNx+T76sM0sNWE0ankGfVc7PAyfh+3wGf6+CA9bLqBQ
	VYWTzdHnSccRCMS71D6C+p9R8mKdIXX5iSuGT3vC+EoxKDlH0mfxuRPUf9ZP
	O8ZY6BPISdhMOh5zkAfciGOwxog/I/xHQPk74P391jXy4UFkyApkFWzdCSOt
	YBz4hdGqtf82hvut0Oekk2o38bu/lzZvB/5UNDC/G4oHKxRxFt/o1U31GEZu
	6cdo4TgWPUK1mfdPNvX0hLUGswZNJly+LaPuN2/VKrtC+3iJNueneOQDz/TE
	B4pXpxe9Pp3030bnQ9TIaBCgyoCt738/mvcQNfd59TZcTcbRVYBe/010HnFB
	H4K6Ls+i02hEo+7bIbO/cOoymM7hXRPXJWN3sfhfrPlNZQv67Lj7/VmmFV/n
	fnNRE+h5UNW8h/AM/7g6h04YWkByWkz9VbnvvuLtEa5EEqRsVOYbDO5mav7A
	P3/RdPZyB4jLUqLoEs13wX3JEJ1HIk2CFzJhCyR3GISGBBdKd/Fbk9EhFuFy
	aOqefzEv+G2dnXKzFfFhWodvcwS9UdKGqGI/tCCjmieuSPnvECQnE9wB/OeJ
	pRabAjC5/B6Q+ILBQQMjffuDjpdrm+9mXILFN3lxl6pkygZYcd/xXzRV8mNj
	AiJTDZdoTiekFKtFowrON66uXVXW0ruisqnytGTUrVZ36KZtNZ2C/zjn9kQN
	hBu4ffzdqzJwvesWxL8B7cjL5UMWAAA=

	-->	-->


		</back>

	</rfc>	</rfc>

End of changes. 42 change blocks.
	316 lines changed or deleted	192 lines changed or added
This html diff was produced by rfcdiff 1.48.