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


	</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[	<sourcecode type="asn.1"><![CDATA[
	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 40 }]]></sourcecode>
	]]></artwork>
	</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	<t>The security considerations of <xref target="RFC5280"/> are applicable
	document. This extended key purpose does not introduce new security	to this
		document. The <tt>id-kp-imUri</tt> 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	<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). These	for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). This
	OIDs are defined in Section 4.</t>	OID is defined in <xref target="the-im-uri-extended-key-usage"/>.</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"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	<author fullname="J. Millican" initials="J." surname="Millican"/>	barnes-mimi-identity-arch.xml"/>
	<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>
	</front>
	<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:
	H4sIAAAAAAAAA8VYbXPbuBH+jl+xp3yROiZj2U7iaHK5ky0lYWPZriX3ctPp
	TCASklDzRQVIO6rj/Jb+lv6yPgtQb7GS6bVz0yQTESCw2H1299kFgyAQpS5T
	1aHGh/DZ/ks6VabUEx3LUlH/U6nyRCX0Xi3o2sqpomb//XWLJoWhKLelzEsa
	KIs3Op/S9VVkG0KOx0bdQp6qd2Oz3+t2DeplfMC0MIsO2TIRIiniXGZQIzFy
	UgZalZMgldncBjoLbtSiYgnB/pGw1TjT1uoiLxdzrI/6ozdET0imtsChGifO
	+di8bOxBh0SXhdEy5UHUPcEPlGhEV6M3DZFX2ViZjkigSkfERW5VbivbodJU
	SsCEQyGNkh0a9k/FXWFupqao5h066w4uh/TLWwG9MJ10BAX0idHjh3gNIA+X
	KBAWk7PCzd5U/KNrDLMlhm4yY4j4KdOZxvOZuFV5BRWJvtaAyKPwC7RjF7zl
	95jNpE475AD8mbEMCzPl7bqcVeMOmWIm80zOFk/5v8dAY2kK/W3ZoVlZzm3n
	6dPVltALCXXxjc1Pv+fCcFZmqRCyKmeFYeBwFNGkSlPv/is+hgYQ7F5AbZnr
	f8gS/t58SafwVpWWbPNQmVsdK+s2KG+50zZkFX6e8kwYF5kQeWEyiLp1UEaj
	6/DD85f74cH+QbvjNteZ8NoNsCKf+A1FTiMVz/IiLaYL+KU7PA/bpPK4SFgB
	U6XKdupNw7mKvft5WzGhE2l1TP3l4iteTM2T/lVrr95yKvMix4700apTrKoX
	yTyhnrZscaXtDAH19eLecvEKXKohRJbkpTK50wnHjFSqAEhW5bWelq5z/Lgd
	LhuIQXFDq4xWVgOKpUAAF4zgDCcCse0t/RACS7HC9fi/wnVsSyPjkoaLvJSf
	6Lwo/aqLHMzjUG99E+exwzmvt/xfgTgGEHppJEebEEEQkKzNE+LqzSk9Ozje
	J+utgPusulUGKm3xxbwy88Iq0sxnvM5Y0QSfXvr5KLGeiz11bzCPDYlGM20J
	vFpBt5ISNdE5kuQxbTejQas+oVzQpnQnW+dxWjHf4kmUs+9UBae6rd3hVbo9
	hA3jFI6BOWJTwRqTTCdJqoR4wp4xRVLFznvfUtMubKkyCyLlKdZmveBMLpQB
	G8SVYUOag7NhS9zf/wSwXx4d7D880NwUZREXKcWSrYkL2Gm40M2VCeJUM04r
	IDZ5PDbKTaPIhNQl1KC/qbjspuU5SAuSWBO4adM+d8ZYIW/rmlercnj8nFVh
	pw0uL/kF+RfP2wfth4c9h7n6BN5MVSjExQYBWtD6gmVW+Z1OU4dAQSiG1VdH
	Py7PMMGb54GTNFW5C7ctd9sqnpG09FEnwc08QMQjJrtIoo/QV9SzXpCb3YMy
	saxgORzOzjDa3uBBll7UNh5FlSbYgAYBOxJGTVJsCmuDlV9kWcr4BmZ3c2Aw
	T2W+Sm94kzbcwGrixAXJ+TxdMA6PI0ZbkSgbGz32xwHnKOiFY2mQCAEX12Dp
	7UCaePbwECJpnCM3DzJKQBf4G1JwDvCfKXmrUy7nXrCLw8KoHTo4vikQX3Ks
	UxwkmoNoELW2CzYMRgKgpN3yoexox/acsdqNhYBejhG437DUGFwPR9zS8C+d
	X7jnq/6frqOrfo+fh++6Z2erB1GvGL67uD7rrZ/WO08vBoP+ec9vxixtTYnG
	oPsr3rBWjYvLUXRx3j1reMs3OQZQ1QhpNntuFGMmv3LDyenlv/7ZPoI7fkDY
	H7TbL5EPfnDcfnGEwd1M5f60IgfMfsjeFvC2ksbFTsppPNclfLTH0WBnxV0O
	1xhOmz/8hZH5a4dejeN5++h1PcEGb00uMduadJg9nnm02YO4Y2rHMSs0t+a/
	Qnpb3+6vW+Ml7huTr34CCSgK2sc/vXYhxFHi2WYHS3MQwVt2q3DWZcGF8BYX
	+GTX2bXRe/CAjmeiZh9XEBLvy60Md+kA/yOdb5WTuCJTJDAToU8PsU4PTyah
	1wxFZKOGwH74tXRyivmSBni0cahnP8NERAp9qTLgauQMN1MgQfRVwXKMqPjy
	5YtwdhFdnPyxfzqiqNc/H0Vvov4VUafzI92jtGtbNNutdc1Ngs0utHnYQsAn
	zectH+S5KrFacH/gC0/zWQv9fIz+U9vM8mh+oz81X7ToZs6bH4TYwHaHIk4P
	jz+NTnpt7GDF2b+r4sbtLxQ0coMevvGSUfPZxR0HsouzlFkToIxTl7CcxWKZ
	xcvOYWcjkhTwM3ostt1Va0W5ulvZLrgAWBpXpbvaKJkQmBSrWJxvXldrqV67
	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. 46 change blocks.
	319 lines changed or deleted	97 lines changed or added
This html diff was produced by rfcdiff 1.48.