generated from martinthomson/internet-draft-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
First version of draft-mahy-lamps-im-keyusage
- Loading branch information
1 parent
1c523e1
commit 58b6d13
Showing
2 changed files
with
267 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,261 @@ | ||
| <?xml version='1.0' encoding='utf-8'?> | ||
| <!DOCTYPE rfc [ | ||
| <!ENTITY nbsp " "> | ||
| <!ENTITY zwsp "​"> | ||
| <!ENTITY nbhy "‑"> | ||
| <!ENTITY wj "⁠"> | ||
| ]> | ||
| <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||
| <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6.10) --> | ||
| <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-lamps-im-keyusage-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> | ||
| <!-- xml2rfc v2v3 conversion 3.18.2 --> | ||
| <front> | ||
| <title abbrev="extendedKeyUsage for IM URIs">X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs</title> | ||
| <seriesInfo name="Internet-Draft" value="draft-mahy-lamps-im-keyusage-00"/> | ||
| <author fullname="Rohan Mahy"> | ||
| <organization>Wire</organization> | ||
| <address> | ||
| <email>[email protected]</email> | ||
| </address> | ||
| </author> | ||
| <date year="2023" month="October" day="23"/> | ||
| <area>SEC</area> | ||
| <workgroup>LAMPS WG</workgroup> | ||
| <keyword>x.509</keyword> | ||
| <keyword>certificate</keyword> | ||
| <keyword>extended key usage</keyword> | ||
| <keyword>eku</keyword> | ||
| <keyword>instant messaging</keyword> | ||
| <keyword>im URI</keyword> | ||
| <abstract> | ||
| <?line 39?> | ||
|
|
||
| <t>RFC 5280 specifies several extended key purpose identifiers | ||
| (KeyPurposeIds) for X.509 certificates. This document defines | ||
| Instant Messaging (IM) identity KeyPurposeIds for inclusion in | ||
| the Extended Key Usage (EKU) extension of X.509 v3 public key | ||
| certificates</t> | ||
| </abstract> | ||
| <note removeInRFC="true"> | ||
| <name>About This Document</name> | ||
| <t> | ||
| The latest revision of this draft can be found at <eref target="https://example.com/LATEST"/>. | ||
| Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-lamps-im-keyusage/"/>. | ||
| </t> | ||
| <t> | ||
| Discussion of this document takes place on the | ||
| LAMPS WG Working Group mailing list (<eref target="mailto:[email protected]"/>), | ||
| which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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/rohan-wire/mahy-lamps-im-keyusage"/>.</t> | ||
| </note> | ||
| </front> | ||
| <middle> | ||
| <?line 48?> | ||
|
|
||
| <section anchor="introduction"> | ||
| <name>Introduction</name> | ||
| <t>Instant Messaging (IM) systems using the Messaging Layer Security (MLS) | ||
| <xref target="RFC9420"/> protocol can incorporate per-client identity certificate | ||
| credentials. The subjectAltName of these certificates can be an IM URI, for | ||
| example. Since IM clients could be very numerous, operators are | ||
| reticent to issue certificates for these users that might accidentally be used | ||
| to validate a TLS connection because it has the KeyPurposeId <tt>id-kp-serverAuth</tt> or | ||
| <tt>id-kp-clientAuth</tt>.</t> | ||
| <t>An explanation of MLS credentials as they apply to Instant Messaging is described | ||
| in <xref target="I-D.barnes-mimi-identity-arch"/>. These credentials are expected to be | ||
| heavily used in the More Instant Messaging Interoperability (MIMI) Working Group.</t> | ||
| </section> | ||
| <section anchor="conventions-and-definitions"> | ||
| <name>Conventions and Definitions</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?> | ||
|
|
||
| </section> | ||
| <section anchor="the-im-uri-extended-key-usage"> | ||
| <name>The IM URI Extended Key Usage</name> | ||
| <t>This specification defines the KeyPurposeId id-kp-imUri, which is used | ||
| for signing messages to prove the identity of an Instant Messaging client.</t> | ||
| <artwork><![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 TBD } | ||
| ]]></artwork> | ||
| </section> | ||
| <section anchor="security-considerations"> | ||
| <name>Security Considerations</name> | ||
| <t>The Security Considerations of <xref target="RFC5280"/> are applicable to this | ||
| document. 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 credentials.</t> | ||
| </section> | ||
| <section anchor="iana-considerations"> | ||
| <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 | ||
| OIDs are defined in Section 4.</t> | ||
| <table> | ||
| <thead> | ||
| <tr> | ||
| <th align="left">Decimal</th> | ||
| <th align="left">Description</th> | ||
| <th align="left">References</th> | ||
| </tr> | ||
| </thead> | ||
| <tbody> | ||
| <tr> | ||
| <td align="left">TBD</td> | ||
| <td align="left">id-kp-imUri</td> | ||
| <td align="left">This-RFC</td> | ||
| </tr> | ||
| </tbody> | ||
| </table> | ||
| </section> | ||
| </middle> | ||
| <back> | ||
| <references> | ||
| <name>References</name> | ||
| <references anchor="sec-normative-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="RFC5280"> | ||
| <front> | ||
| <title>Internet X.509 Public Key Infrastructure Certificate and Certificate 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 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> | ||
| </abstract> | ||
| </front> | ||
| <seriesInfo name="RFC" value="5280"/> | ||
| <seriesInfo name="DOI" value="10.17487/RFC5280"/> | ||
| </reference> | ||
| </references> | ||
| <references anchor="sec-informative-references"> | ||
| <name>Informative References</name> | ||
| <reference anchor="RFC9420"> | ||
| <front> | ||
| <title>The Messaging Layer Security (MLS) Protocol</title> | ||
| <author fullname="R. Barnes" initials="R." surname="Barnes"/> | ||
| <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/> | ||
| <author fullname="R. Robert" initials="R." surname="Robert"/> | ||
| <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-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="RFC" value="9420"/> | ||
| <seriesInfo name="DOI" value="10.17487/RFC9420"/> | ||
| </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="24" month="October" year="2022"/> | ||
| <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-arch-00"/> | ||
| </reference> | ||
| </references> | ||
| </references> | ||
| </back> | ||
| <!-- ##markdown-source: | ||
| H4sIANniNmUAA31W4XIbNRD+r6dYzB+b6blxk9LWUyhu4sJROwmxM4VhmEG+ | ||
| k22RO90h6ZyaNn0WnoUn41vJTuwm0MzUpz1J++233+5ekiTCa1+oPrV+7j49 | ||
| eEHHyno915n0iobvvTK5yumtWtOlkwtF7eHbyw7NK0upcV4aT2Pl8EabBV1e | ||
| pK4l5Gxm1Qr3qc1pHI5nw6nxZhs7WFR23Sdt5pUQeZUZWQJHbuXcJ6VcrpNC | ||
| lrVLdJlcqXXDVyQHB8I1s1I7pyvj1zX2p8PpG6IvSRauglcNlzX7Nb71CCBy | ||
| 7SurZcGLdPAaP0DRSi+mb1rCNOVM2b7IgaUvsso4ZVzj+uRtowRiOBTSKtmn | ||
| yfBYXFf2amGrpu7TaDA+n9C77wVwwZz3BSX0nunjh+yOQV5uaSBsphBFsF41 | ||
| /KM3JJZbEoOxZI7ESpkGsIg+90oUI38HRMz79/we1lLqok+BtO+08vNuZRd8 | ||
| XPtlM+uTrZbSJNfaqscPs4u9BUA736el97XrP36s3mNTobpZVT4eDabDyVQI | ||
| 2fhlZTlmHCCaN0URM3fBDmiMu8MLeJdG/yU9UgWw8BvMKsIMaLoM5DuGxB6E | ||
| MJUtsX+FsAXL4m4lkiQhOXPeyswLcfHmmJ4+eX5ArlYZyFaOnFopK4t9vuvG | ||
| 1pVTpFkPvM860YYgz6M9zV0Uc9T+TuZcl2i61I6gy6bEYcrVXBvlxH3dt9Nx | ||
| Z+PBr2nv9nC5NlnRsGDxJPzyf+oqYA87q/kG0+oQQcwKnXE8YhfhhpRS53mh | ||
| hPgSFeltlTcZEy7+C6dbO69KByWyidHcbRjJtbI0UVljOZL2eDTpiA8fXoHt | ||
| F0dPDm5uqLaVr7KqoExyNFmFQC23ilrZJCs0E3XLxG4hZFYFM6q0C2IVoYz/ | ||
| UJkfFP4U4uF4gQWZ2o0weJkpwv+xbzxiPsVWlDQBAsWvomfsr5oi5xOQwppQ | ||
| 3gql4VDygCfRBxyhnoVVXmeM1FeETtJ85pRTFrE0DnrBs0SB6sXSk8yyEJ0s | ||
| ijW7wYZc4JaVLDQ3EZI0HU0AwxgV0oBNmWxYgJ6W0gW+dwVCv+s8uaoTOALk | ||
| ASrrd9SN2FhjWMHaFWJgoI+6kCZUFDM2Zl93xFJ0sCZZ18AHXPc1wIpWLrN6 | ||
| BuTaELKbJifdmbTQdlLqUifb/CXSZsubm5AuTsyuI6sYC2KEiOFnpsRSyZUu | ||
| 1oESKCMqq8K++xigU+SFUzLTRRRaOk47+/0MAUPSx5VZsVO0ZqggpxMuQh3W | ||
| QrCMuMi5BTtqjS8nU+7y/EunZ+H5YvjTZXoxPOHnyQ+D0ej2QWx2TH44uxyd | ||
| 3D3dnTw+G4+HpyfxMKy0ZxKt8eAXvGFUrbPzaXp2Ohi1YuS7bYOpCgzhFcKu | ||
| IT4QJJ24TQOfeX18/s/fvSOk4wsU25Ne7wWKLS6e954dYXG9VCZ6qwxojkvO | ||
| tkC2leQugxHIhVlr6BOihxrcsro2tFTor0J89Ssz81ufXs6yunf07cbAAe8Z | ||
| t5ztGQNn9y33DkcSHzA94OaWzT37Z0zv4x38srfe8r5jfPmqQJumpPf81bdB | ||
| QqyS2D0e6LssImRrM0WyWFmbTn+/WGNV6vLS6kfIgM6WXE+hCXDTcHphWL9x | ||
| mPMFFTfMlQo33bZFFC43tHtlEasdifr06ZMIrojOXv84PJ5SejI8naZv0uEF | ||
| Ub//DX3AJNWuavc6d5MtT3YHbvuwAw3m7a87UXdGeezGMbfp7u2nHQDNMIS1 | ||
| Kx2v6iv9vv2sQ1c1H74RYifcB4AEHJESmr4+wQHGDcJv5weK1wGelTv1+h8v | ||
| mZQod57qkDuXDbcx5GRWhArisuIPiG1lbQf0g/M+r0C/qTwHH2aiIqOub4Pn | ||
| e6x2V45mjQ8fYUrmhAaHjXyjdp4zst2+3bsO6dR5TLI0AQ8PkZiDNekwxXbH | ||
| CQtkoQzHGVsliySMrJ2BGIb34HRwj7FgxA1W/dnguyzeYNUC+FQYUhhWRVFd | ||
| M6Cz9MRtG29rMk5vqQ7aPH+b/ryv/42sW5v7MC/bve5h9+tur/sUf8+6h51A | ||
| MXq/CHdzSmJphJY12Uy4I8D/iMac6RJfX/zEfa0O7wjrCzVH/zFM7EfxsZ9s | ||
| /t09PbDGxqApCjfs6pDXnPaEvwCxiN9AM5ldiX8BlhlxB8wMAAA= | ||
| --> | ||
|
|
||
| </rfc> |