Skip to content

Commit

Permalink
Manually creating draft-mahy-kp-context-00.xml
Browse files Browse the repository at this point in the history
  • Loading branch information
rohan-wire committed Oct 22, 2023
1 parent 29b6ced commit d2b32e3
Showing 1 changed file with 289 additions and 0 deletions.
289 changes: 289 additions & 0 deletions versioned/draft-mahy-mls-kp-context-00.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,289 @@
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.35 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mls-kp-context-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front>
<title abbrev="MLS KeyPackage Context">KeyPackage Context Extension for Message Layer Security (MLS)</title>
<seriesInfo name="Internet-Draft" value="draft-mahy-mls-kp-context-00"/>
<author initials="R." surname="Mahy" fullname="Rohan Mahy">
<organization>Wire</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2023" month="October" day="22"/>
<area>sec</area>
<workgroup>MLS</workgroup>
<keyword>mls extension</keyword>
<keyword>keypackage context</keyword>
<keyword>keypackage extension</keyword>
<abstract>
<?line 37?>

<t>This document describes a Message Layer Security (MLS) KeyPackage extension
to convey a specific context or anticipated use for the KeyPackage. It is useful
when a client provides the KeyPackage out-of-band to another client, and wants
the specific KeyPackage used only in the anticipated context, for example a
specific MLS group.</t>
</abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-mls-kp-context/"/>.
</t>
<t>
Discussion of this document takes place on the
MLS Working Group mailing list (<eref target="mailto:[email protected]"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mls/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mls/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/rohan-wire/mls-kp-context/"/>.</t>
</note>
</front>
<middle>
<?line 45?>

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

<t>The terms MLS client, MLS group, LeafNode, GroupContext, KeyPackage,
GroupContextExtensions Proposal, Credential, CredentialType, and
RequiredCapabilities have the same meanings as in the MLS
protocol <xref target="I-D.ietf-mls-protocol"/>.</t>
</section>
<section anchor="introduction">
<name>Introduction</name>
<t>In some use cases of MLS, a client might wish to provide a KeyPackage to
another client, but communicate that the specific KeyPackage is only to be
used in a specific context, for example to join a specific MLS group. This
document describes a KeyPackage extension that can convey that context.</t>
</section>
<section anchor="extension-description">
<name>Extension Description</name>
<t>This document specifies a KeyPackage MLS extension <tt>kp_context</tt>
of type ContextPair. The syntax is described using
the TLS Presentation Language <xref target="RFC8446"/></t>
<t>Each PerDomainTrustAnchor represents a specific identity domain which is
expected and authorized to participate in the MLS group. It contains the
domain name and the specific trust anchor used to validate identities for
members in that domain.</t>
<sourcecode type="tls-presentation"><![CDATA[
enum {
reserved(0),
groupid(1),
uri(2),
domain(3),
jwk_thumbprint(4)
(255)
} ContextType;
struct {
ContextType context_type;
opaque context_value<V>;
} ContextPair;
ContextPair kp_context;
]]></sourcecode>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document proposes registration of a new MLS Extension Type.</t>
<t>RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document</t>
<section anchor="kpcontext-mls-extension-type">
<name>kp_context MLS Extension Type</name>
<t>The <tt>kp_context</tt> MLS Extension Type is used inside KeyPackage objects. It
contains a URN Anchors object representing the trust anchors which are expected
for identity validation inside the MLS group.</t>
<artwork><![CDATA[
Template:
Value: 0x000B
Name: kp_context
Message(s): This extension may appear in KeyPackage objects
Recommended: Y
Reference: RFC XXXX
]]></artwork>
</section>
<section anchor="urnietfmlskpcontextgroupid-urn-registration">
<name>urn:ietf:mls:kp_context:group_id URN registration</name>
<artwork><![CDATA[
Namespace Identifier: Requested of IANA (formal) or assigned by IANA
(informal).
Version: 1
Date: 2023-08-01
Registrant:
Rohan Mahy
[email protected]
Purpose: Described in Section 3 of RFCXXXX.
Syntax: Described in Section 3 of RFCXXXX.
Assignment: Described in Section 4.1 of RFCXXXX.
Security and Privacy: Described in Section 5 of RFCXXXX.
Interoperability: Described in Section 3 of this document.
Resolution: Described in Section 3 of this document.
Documentation: RFCXXXX
Additional Information: none
Revision Information: n/a
]]></artwork>
</section>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>The Security Considerations of MLS apply.</t>
<t>The use of this extension may reveal the client's intentions or wishes
in an out-of-band protocol, which may have weaker privacy protections than
MLS handshake messages.</t>
</section>
</middle>
<back>
<references>
<name>Normative References</name>
<reference anchor="RFC2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<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 protocol 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="I-D.ietf-mls-protocol">
<front>
<title>The Messaging Layer Security (MLS) Protocol</title>
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>Cisco</organization>
</author>
<author fullname="Benjamin Beurdouche" initials="B." surname="Beurdouche">
<organization>Inria &amp; Mozilla</organization>
</author>
<author fullname="Raphael Robert" initials="R." surname="Robert">
<organization>Phoenix R&amp;D</organization>
</author>
<author fullname="Jon Millican" initials="J." surname="Millican">
<organization>Meta Platforms</organization>
</author>
<author fullname="Emad Omara" initials="E." surname="Omara">
<organization>Google</organization>
</author>
<author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-Gordon">
<organization>University of Oxford</organization>
</author>
<date day="27" month="March" year="2023"/>
<abstract>
<t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing 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 the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-protocol-20"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
</references>
<?line 176?>



</back>
<!-- ##markdown-source:
H4sIAGKTNWUAA5VXbXPbuBH+jl+xVT7U7kiy7Dhtjsnk4lhOT1O/qLKSNnNz
44NISEJMgjwAlKzLOL+lv6W/rLsLUqT80mn9wSIXwGLx7LMPlr1eT3jtUxXB
39RmLONbuVBwmhuv7jyc3XllnM4NzHMLF8o5Gj2XG2XhWsWl1X4Dexfn1/tC
zmZWrSLAlyc8iSSPjcxwl8TKue9lcrnpZanr3Ra9OEzppdIr54UubATels4f
DQY/DI6EK2eZdhSF3xToYXQ2/QjwAmTq8gg62iSqUPjP+E4XOqOTD/iD0XZG
k+nHjpBWyQik9WKd29uFzcuCg6wGnIpFjBsvcruJQJt5Lm7VBqcmkYAeYIig
ahDIgINFdbQq7gfWZrZwXprkRqa5wag3yolCR/Czz+MuuNx6q+YOnzYZPfwi
xEqZUuGu0AoSIJz5Hxi7Ngv4Kw2hNZM6jSi691r5eT+3CzRKGy8jWHpfuOjg
gKaQRa9Uv550QIaDmc3XTh3g6gPaTftlOYvA5ktpemtteaSVmAPxAiAkp/Ee
VvXjPDt4fmGVUSFLv8wtA4oQuwgmfbhABuDuAIEWE3LSGDFWafTv0iOQeHr0
zWYVzs079olD72lbikIIk9sM568QQkF5bN56vR7ImfNWxhjMdKkdIB3LDBkD
iXKx1TPlQP5Xfrc53aTY58SCldrgaleoWM91XPOCOCiN17EuEIYESqe4ivxS
tZz1YeQBA8LReZmK9VIZ9BWnmoIrbL7SGOGDNZCXvpfPezOkF2AI0uQ4wVar
ukDmNW7tBK3bxtVygLslkJt0g+lg5+1Aq/i7HK26k1mR4gSx9UMVzhTtB2gz
nSSpEsiSqbKZNnmaLzaEs6K6AKolB52LT9dTqk/6hcsrfp6c/f3TaHI2pOfr
n07Oz7cPoppx/dPVp/Nh89SsPL26uDi7HIbFaIUdk+hcnHzpBCg6V+Pp6Ory
5LwTTttOP4oAIThTOOSVLawiBKQTNS8SWvPhdPzvfx0ew7dvf5h8PD06PPzh
/r56eX34l2N8obyF3RjV8IrAboQsCiUteZFpCrEstEfhwrkO3DJfG8DMKUTy
Tz8TMr9E8HYWF4fH7yoDHXjHWGO2Y2TMHlseLQ4gPmF6Ypstmjv2B0jvxnvy
Zee9xr1lfPtjqo2C3uHrH9+JwBGEPXNMqpq/W4J14VzJ+WWeqG5QvtOamg2X
u6I9sr2wHIxtXuROpl04tYpuB737PEVh5ZSJifqtRBlJTmUhZzrVXmPJLeVK
cWk41CfIFMqRWThKW1UyJM9YoCjneUpkGPWGrLN8rdUD9/d9KoyR8TZPytjz
vTAyqP8ZVyESwuFm+ZzcdZvKz/Ri6WGt3ZLoWekADrdq2OfiYeHPSo/Vm2Wl
0XSnYZjSw3MagGXAXGX6C1YEIukjHdvVAZz9Nd+d1+gBkLaKJ7X1KfkM8cWo
+5WIhvewLePW9B9D9lUEAHclvArk4TYUVrPVr7fFTeX5V4Fw07VaNydjqS3F
jjhtjJd3BE1T/6XDxLOSTtHj2CqHm/LFhBeFWZS0V6UFx8d/vr8X4kzGSxgr
O8zxujJTamVOTIw3IFhVhPWuDaBmRuJNk/ACVA+NDhBJdYdTWJBQWMIlqn9X
rPkFdjSVYrcIWedhFGBEZ3x3iMoxXbXsa4cT3GuhmSNkHqD/lUx1ws5DcAQv
8kBkKpspWxUBZit4xmR9//4dPDO/AUhgR5PBN7y6yWhXKtkb7HfrDkcne4f8
htfs3hE/BW97L/nl6/r2BpuMbFZYFOe943207R29erUv7uvMUQ2/oUbLYm3x
RtAeqrl043keNxaF/K1sBvCYpXr7+d2bxiexAX223qDhzhs6p+CSPrk8oSUO
AbJ8WveQmAUrEAJn1UJT+8GkQfJJMGrN+WoITvEijEgjOBuOpleTCMapQnUg
0qQyVvBP/EPQEbrFEjsAVAe/5EzSGgQa84Ly5PTChBTu3HQY8ovWOZ7YPKhx
u06emFS1KiQVdPCdpmT2FcnqiHxiSz4JnyaXENjvqilNFVBHSwdoM9BV9Keb
uea/IAXaVklFTQqpimKX/cxF/sOMTxXKFvKY+urPlOwIBneDweADvl9y59kc
GE1VC7jn9iMWs5aCZBK7vO1l/vjguHqiSH3pWySJ4Asb5ni7m5gaXEwSZbAJ
jjJSWhPRpRHhpRE1kUR8khudMHxt+vDhiMkUvCuIFyMGBgUQv5uA7jLsuam9
mweO7nErnO5zP1rTY7bhQS4JrKqqX073ETx8/4wVzo03HPL7kAAEOBocvewN
XvcGwTqpwjI+Cn4e9PBVm07He7+gxj306TgwLi0VBrocttss7Lg5qy8pdsSL
4AoBXbMu/+/zT/icxPvn1hz3Dx/vUnf8JJFjq1cy3jy3/tWj1SNqIPMCxYB7
iGdXcrQ7tdmv4HR5WoYPnv9v5bB6q76W6rACEkmiySxTDLD6KOJJBr9Kq31X
mgn+YPxAikA2FLstMo8FTz03WDU1VDPpph+mUsdTn2G3sqxaKYyRKjl0M390
3JKbypflZgi/oan3MDtfQHWv1a2Ug9xx97ZW8hY1sQiZ5HkBSboUpREUHf4m
bonzsMXj0ncYKn/WzLC88fE/efZeNSERAAA=
-->

</rfc>

0 comments on commit d2b32e3

Please sign in to comment.