More Instant Messaging Interoperability (MIMI) Identity Concepts
draft-mahy-mimi-identity-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Rohan Mahy | ||
| Last updated | 2022-07-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mahy-mimi-identity-00
MIMI BoF R. Mahy
Internet-Draft Wire
Intended status: Informational 11 July 2022
Expires: 12 January 2023
More Instant Messaging Interoperability (MIMI) Identity Concepts
draft-mahy-mimi-identity-00
Abstract
This document discusses concepts in instant messaging identity
interoperability when using end-to-end encryption, for example with
the MLS (Message Layer Security) Protocol. The goal is to explore
the problem space in preparation for framework and requirements
documents.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Mahy Expires 12 January 2023 [Page 1]
Internet-Draft MIMI Identity July 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Types of Identifiers . . . . . . . . . . . . . . . . . . . . 3
3. Representation of identifiers using URIs . . . . . . . . . . 6
4. Different Root of Trust Approaches . . . . . . . . . . . . . 8
4.1. Centralized credential hierarchy . . . . . . . . . . . . 8
4.2. Web of Trust . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Well-known service cross signing . . . . . . . . . . . . 10
4.4. Combining approaches . . . . . . . . . . . . . . . . . . 11
5. Cryptographic mechanisms to make assertions about IM
identifiers . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . 11
5.2. JSON Web Tokens (JWT) with Distributed Proof of Presence
(DPoP) . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Verifiable Credentials . . . . . . . . . . . . . . . . . 15
5.4. Other possible mechanisms . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Normative References . . . . . . . . . . . . . . . . . . . . 17
9. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The IETF began standardization work on interoperable Instant
Messaging in the late 1990s, but since that period, the typical
feature set of these systems has expanded widely and was largely
driven by the industry without much standardization or
interoperability. The MIMI (More Instant Messaging Interop) problem
outline [I-D.mahy-mimi-problem-outline] identifies areas where more
work is needed to build interoperable IM systems.
The largest and most widely deployed Instant Messaging (IM) systems
support end-to-end message encryption using a variant of the Double
Ratchet protocol [DoubleRatchet] popularized by Signal and the
companion X3DH [X3DH] key agreement protocol. Many vendors are also
keen to support the Message Layer Security (MLS) protocol
[I-D.ietf-mls-protocol] and architecture [I-D.ietf-mls-architecture].
These protocols provide confidentiality of sessions (with Double
Ratchet) and groups (with MLS) once the participants in a
conversation have been identified. However, the current state of
most systems require the end user to manually verify key fingerprints
or blindly trust their instant messaging service not to add and
remove participants from their conversations. This problem is
exacerbated when these systems federate or try to interoperate.
Mahy Expires 12 January 2023 [Page 2]
Internet-Draft MIMI Identity July 2022
While some single vendor solutions exist, clearly an interoperable
mechanism for IM identity is needed. First this document attempts to
articulate a clear description and semantics of different identifiers
used in IM systems. Next the document provides an example of how to
represent those identifiers in a common way. Then the document
discusses different trust approaches. Finally the document surveys
various cryptographic methods of making and verifying assertions
about these identifiers.
Arguably, as with email, the success of XMPP [RFC6120] was partially
due to the ease of communicating among XMPP users in different
domains with different XMPP servers, and a single standardized
address format for all XMPP users.
The goal of this document is to explore the problem space, so that
the IETF community can write a consensus requirements document and
framework.
2. Types of Identifiers
IM systems have a number of types of identifiers. Few (or perhaps
no) systems use every type of identifier described here. Not every
configuration of the same application necessarily use the same list
of identifiers.
Domain identifier: A bare domain name is often used for discovery of
a specific IM service such as example.com or im.example.com. Many
proprietary IM systems operate in a single domain and have no
concept of domains or federation.
Handle identifier: A handle is an identifier which represents a user
or service. A handle is usually intended for external sharing
(for example it could appear on or in a paper or electronic
business card). IM systems could have handles which are unscoped
(don't contain a domain) or scoped (contain a domain). Unscoped
handles are often prefixed with a commercial at-sign ("@").
Handles in some services are mutable. For example, @alice_smith
could become @alice_jones or @alex_smith after change of marital
status or gender transition.
Mahy Expires 12 January 2023 [Page 3]
Internet-Draft MIMI Identity July 2022
+=============+=========================+========================+
| Protocol | Identifier Address | Example |
+=============+=========================+========================+
| Jabber/XMPP | Bare JID | juliet@example.com |
+-------------+-------------------------+------------------------+
| SIP | Address of Record (AOR) | sip:juliet@example.com |
+-------------+-------------------------+------------------------+
| IRC | nick | @juliet |
+-------------+-------------------------+------------------------+
| Generic | "unscoped handle" | @juliet |
| example | | |
+-------------+-------------------------+------------------------+
| Generic | "scoped handle" | @juliet@example.com |
| example | | |
+-------------+-------------------------+------------------------+
| Email style | Mailbox address | juliet@example.com |
+-------------+-------------------------+------------------------+
Table 1: some Handle identifier styles
User or account identifier: Many systems have an internal
representation of a user, service, or account separate from the
handle. This is especially useful when the handle is allowed to
change. Unlike the handle, this identifier typically cannot
change. For example the user identifier could be a UUID or a
similar construction. In IRC, a user identifier is prefixed with
a "!" character (example: !jcapulet1583@example.com for the "nick"
@juliet).
Client or Device identifier: Most commercial instant messaging
systems allow a single user to have multiple devices at the same
time, for example a desktop computer and a phone. Usually, each
client instance of the user is represented with a separate
identifier with separate keys. Typically these identifiers are
internal and not visible to the end-user (XMPP fully qualified
JIDs are a rare exception). The client or device identifier is
often based on a UUID, a persistent long-term unique identifier
like an IMEI or MAC address, a sequence number assigned by the IM
service domain, or a combination. In some cases the identifier
may contain the internal user identifier. These identifiers look
quite different across protocols and vendors.
Mahy Expires 12 January 2023 [Page 4]
Internet-Draft MIMI Identity July 2022
+==========+============+===========================================+
| Protocol | Identifier | Example |
| | Address | |
+==========+============+===========================================+
| Jabber/ | Fully- | juliet/balcony@example.com |
| XMPP | qualified | |
| | JID | |
+----------+------------+-------------------------------------------+
| SIP | Contact | sip:juliet@[2001:db8::225:96ff:fe12:3456] |
| | Address | |
+----------+------------+-------------------------------------------+
| Wire | Qualified | 0fd3e0dc-a2ff- |
| | client ID | 4965-8873-509f0af0a75c:072b@example.com |
+----------+------------+-------------------------------------------+
Table 2: some Client/Device identifier styles.
Group Chat or Channel identifier (external): All or nearly all
instant messaging systems have the concept of named groups or
channels which support more than 2 members and whose membership
can change over time. Many IM systems support an external
identifier for these groups and allows them to be addressed. In
IRC and many other systems, they are identified with a "#" (hash-
mark) prefix. The proliferation of hashtags on social media makes
this convention less common on newer systems.
Group, Conversation, or Session identifiers (internal): Most IM
protocols use an internal representation for a group or 1:1 chat.
In MLS this is called the group_id. The Wire protocol uses the
term qualified conversation ID to refer to a group internally
across domains. Among implementations of the Double Ratchet
family of protocols a unidirectional sequence of messages from one
client to another is referred to as a session, and often has an
associated session identifier.
Team or Workspace identifier: A less common type of identifier among
IM systems is used to describe a set of users or accounts. This
is described variously as a team, workspace, or tenant.
One user often has multiple clients (for example a mobile and a
desktop client). A handle usually refers to a single user or rarely
it may redirect to multiple users. In some systems, the user
identifier is a handle. In other systems the user identifier is an
internal representation, for example a UUID. Handles may be changed/
renamed, but hopefully internal user identifiers do not. Likewise,
group conversation identifiers could be internal or external
representations, whereas group names or channel names are often
external friendly representations.
Mahy Expires 12 January 2023 [Page 5]
Internet-Draft MIMI Identity July 2022
It is easy to imagine a loose hierarchy between these identifiers
(domain to user to device), but hard to agree on a specific fixed
structure. In some systems, the group chat or session itself has a
position in the hierarchy underneath the domain, the user, or the
device.
As described in the next section, the author proposes using URIs as a
container for interoperable IM identifiers. All the examples use the
im: URI scheme (defined in [RFC3862]), but any instant messaging
scheme should be acceptable as long as the comparison and validation
rules are clear.
3. Representation of identifiers using URIs
Most if not all of the identifiers described in the previous section
could be represented as URIs. While individual instant messaging
protocol-specific URI schemes may not have been specified with this
use of URIs in mind, the im: URI scheme should be flexible enough to
represent all of or any needed subset of the previously discussed
identifiers.
For example, the XMPP protocol can represent a domain, a handle (bare
JID), or a device (fully qualified JID). Unfortunately its xmpp: URI
scheme was only designed to represent handles and domains, but the
im: URI scheme can represent all XMPP identifiers:
* im:xmpp=example.com (domain only)
* im:xmpp=juliet@example.com (bare JID - handle)
* im:xmpp=juliet/balcony@example.com (fully qualified JID - client/
device)
Likewise the IRC protocol can represent domain, handle (nick), user
(account), and channel. The examples below represent a domain, a
nick, a user, a local channel, abd three ways to specify the projectX
channel.
* im:irc=irc.example.com
* im:irc=irc.example.com/juliet,isuser
* im:irc=irc.example.com/juliet%21jcapulet1583%40example.com,isuser
* im:irc=irc.example.com/%26local_announcements_channel
* im:irc=irc.example.com/#projectX
* im:irc=irc.example.com/%23projectX
* im:irc=irc.example.com/%23projectX
* im:irc=irc.example.com/%23projectX,ischannel
Imagine a hypothetical WXYZ IM protocol with support for all our
identifiers. These could be represented unambiguously using the
conventions below, or with an explicit parameter (ex: ;id-type=):
Mahy Expires 12 January 2023 [Page 6]
Internet-Draft MIMI Identity July 2022
+=======+=======================+===================================+
|id type| unscoped form | domain scoped form |
+=======+=======================+===================================+
|domain | - | example.com |
+-------+-----------------------+-----------------------------------+
|handle | @alice | @alice@example.com |
+-------+-----------------------+-----------------------------------+
|user | BFuVxW5BfJc8R7Qw | BFuVxW5BfJc8R7Qw@example.com |
+-------+-----------------------+-----------------------------------+
|device | BFuVxW5BfJc8R7Qw/072b | BFuVxW5BfJc8R7Qw/072b@example.com |
+-------+-----------------------+-----------------------------------+
|channel| #projectX | #projectX@example.com |
+-------+-----------------------+-----------------------------------+
|team | ##engineering | ##engineering@example.com |
+-------+-----------------------+-----------------------------------+
|channel| ##engineering/projX | ##engineering/projX@example.com |
+-------+-----------------------+-----------------------------------+
|group | $TII9t5viBrXiXc | $TII9t5viBrXiXc@example.com |
|id | | |
+-------+-----------------------+-----------------------------------+
Table 3: examples of all identifier types in the fictional WXYZ
IM protocol
Now imagine that WXYZ reserved the wxyz: URI scheme. The example
below shows how almost any reasonable protocol-specific identifier
scheme can be represented as an im: URI.
wxyz:example.com
wxyz:%40alice@example.com
wxyz:BFuVxW5BfqaMEfJDc8R7Qw/072b@example.com
wxyz:#projectX@example.com
wxyz:##engineering@example.com
wxyz:$TII9t5viBrXiX@example.com
im:wxyz=example.com
im:wxyz=%40alice@example.com
im:wxyz=BFuVxW5BfqaMEfJDc8R7Qw/072b@example.com
im:wxyz=#projectX@example.com
im:wxyz=##engineering@example.com
im:wxyz=$TII9t5viBrXiX@example.com
Figure 1: mapping the identifiers in the fictional WXYZ format
into an im: URI
Note that if there is no domain, an im: URI, or another scheme, could
use local.invalid in place of a resolvable domain name.
Mahy Expires 12 January 2023 [Page 7]
Internet-Draft MIMI Identity July 2022
im:wxyz=%40alice@local.invalid
4. Different Root of Trust Approaches
Different IM applications and different users of these applications
may have different trust needs. The following subsections describe
three specific trust models for example purposes. Note that the
descriptions in this section use certificates in their examples, but
nothing in this section should preclude using a different technology
which provides similar assertions.
4.1. Centralized credential hierarchy
In this environment, end-user devices trust a centralized authority
operating on behalf of their domain (for example, a Certificate
Authority), that is trusted by all the other clients in that domain
(and can be trusted by federated domains). The centralized authority
could easily be associated with a traditional Identity Provider
(IdP). This is a popular trust model for companies running services
for their own employees and contractors. This is also popular with
governments providing services to their employees and contractors or
to residents or citizens for whom they provide services.
For example XYZ Corporation could make an assertion that "I represent
XYZ Corporation and this user demonstrated she is Alice Smith of the
Engineering department of XYZ Corporation."
In this model, a Certificate Authority (CA) run by or on behalf of
the domain generates certificates for one or more of the identifier
types described previously. The specifics of the assertions are very
important for interoperability. Even within this centralized
credential hierarchy model, there are at least three ways to make
assertions about different types of IM identifiers with certificates:
Example 1 (Separate Certs): The CA generates one certificate for a
user Alice which is used to sign Alice's profile. The CA also
generates a separate certificate for Alice's desktop client and a
third for her phone client. The private key in each client
certificate is used to sign MLS KeyPackages or Double Ratchet-
style prekeys.
Example 2 (Single Combined Cert): The CA generates a single
certificate per client which covers both Alice's handle and her
client identifier in the same certificate. The private key in
each of these certificates is used to sign MLS KeyPackages or
Double Ratchet-style prekeys. Note that there is no separate key
pair used to refer to the user distinct from a device. All the
legitimate device key pairs would be able to sign on behalf of the
user.
Mahy Expires 12 January 2023 [Page 8]
Internet-Draft MIMI Identity July 2022
Example 3 (Cascading Certs): The CA generates a single user
certificate for Alice's handle and indicates that the user
certificate can issue its own certificates. The user certificate
then generates one certificate for Alice's desktop client and
another certificate for Alice's phone client. The private key in
each client certificate is used to sign MLS KeyPackages or Double
Ratchet-style prekeys.
What is important in all these examples is that other clients
involved in a session or group chat can validate the relevant
credentials of the other participants in the session or group chat.
Clients would need to be able to configure the relevant trust roots
and walk any hierarchy unambiguously.
When using certificates, this could include associating an Issuer URI
in the issuerAltName with one of the URIs in the subjectAltName of
another cert. Other mechanisms have analogous concepts.
Regardless of the specific implementation, this model features a
strong hierarchy.
The advantage of this approach is to take advantage of a strong
hierarchy which is already in use at an organization, especially if
the organization is using an Identity Provider (IdP) for most of its
services. Even if the IM system is compromised, the presence of
client without the correct end-to-end identity would be detected
immediately.
The disadvantage of this approach is that if the CA colludes with a
malicious IM system or both are compromised, an attacker or malicious
IM system can easily insert a rogue client which would be as trusted
as a legitimate client.
4.2. Web of Trust
In some communities, it may be appropriate to make assertions about
IM identity by relying on a web of trust. The following specific
example of this general method is used by the OMEMO community
presented by [Schaub] and proposed in [Matrix1756]. This document
does not take any position on the specifics of the proposal, but uses
it to illustrate a concrete implementation of a web of trust
involving IM identifiers.
The example uses a web of trust with cross signing as follows:
* Each user (Alice and Bob) has a master key.
* Alice's master key signs exactly two keys:
Mahy Expires 12 January 2023 [Page 9]
Internet-Draft MIMI Identity July 2022
- Alice's device-signing key (which then signs her own device
keys), and
- Alice's user-signing key (which can sign the master key of
other users).
The advantage of this approach is that if Alice's and Bob's keys,
implementations, and devices are not compromised, there is no way the
infrastructure can forge a key for Alice or Bob and insert an
eavesdropper or active attacker. The disadvantages of this approach
are that this requires Alice's device-signing key to be available any
time Alice wants to add a new device, and Alice's user-signing key to
be available anytime she wants to add a new user to her web of trust.
This could either make those operations inconvenient and/or
unnecessarily expose either or both of those keys.
Alice : Bob
+--------+ : +--------+
| master |<---\ /------>| master |
+--------+ \/: +--------+
/ \ / \___ / \
/ \ / : \ / \
+---------+ +---------+ +---------+ +---------+
| device | | user | :| user | | device |
| signing | | signing | :| signing | | signing |
+---------+ +---------+ :+---------+ +---------+
/ \ : / \
+----+ +----+ : +----+ +----+
| A1 | | A2 | : | B1 | | B2 |
+----+ +----+ : +----+ +----+
Figure 2: Alice and Bob cross sign each other's master keys
A detailed architecture for Web of Trust key infrastructure which is
not specific to Instant Messaging systems is the Mathematical Mesh
[I-D.hallambaker-mesh-architecture].
4.3. Well-known service cross signing
In this trust model, a user with several services places a cross
signature for all their services at a well known location on each of
those services (for example a personal web site .well-known page, an
IM profile, the profile page on an open source code repository, a
social media About page, a picture sharing service profile page, a
professional interpersonal-networking site contact page, and a dating
application profile). This concept was perhaps first implemented for
non-technical users by Keybase. The user of this scheme likely
expects that at any given moment there is a risk that one of these
services is compromised or controlled by a malicious entity, but
Mahy Expires 12 January 2023 [Page 10]
Internet-Draft MIMI Identity July 2022
expects the likelihood of all or most of their services being
compromised simultaneously is very low.
The advantage of this approach is that it does not rely on anyone but
the user herself. This disadvantage is that if an attacker is able
to delete or forge cross signatures on a substantial number of the
services, the forged assertions would looks as legitimate as the
authentic assertions (or more convincing).
4.4. Combining approaches
These different trust approaches could be combined, however the
verification rules become more complicated. Among other problems,
implementers need to decide what happens if two different trust
methods come to incompatible conclusions. For example, what should
the application do if web of trust certificates indicate that a
client or user should be trusted, but a centralized hierarchy
indicates a client should not be, or vice versa.
5. Cryptographic mechanisms to make assertions about IM identifiers
5.1. X.509 Certificates
X.509 certificates are a mature technology for making assertions
about identifiers. The supported assertions and identifier formats
used in certificates are somewhat archaic, inflexible, and pedantic,
but well understood. The semantics are always that an Issuer asserts
that a Subject has control of a specific public key key pair. A
handful of additional attributes can be added as X.509 certificate
extensions, although adding new extensions is laborious and time
consuming. In practice new extensions are only added to facilitate
the internals of managing the lifetime, validity, and applicability
of certificates. X.509 extensions are not appropriate for arbitrary
assertions or claims about the Subject.
The Subject field contains a Distinguished Name, whose Common Name
(CN) field can contain free form text. The subjectAltName can
contain multiple other identifiers for the Subject with types such as
a URI, email address, DNS domain names, or Distinguished Name. The
rules about which combinations of extensions are valid are defined in
the Internet certificate profile described in [RFC5280]. As noted in
a previous section of this document, URIs are a natural container for
holding instant messaging identifiers. Implementations need to be
careful to insure that the correct semantics are applied to a URI, as
they may be referring to different objects (ex: a handle versus a
client identifier). There is a corresponding issuerAltName field as
well.
Mahy Expires 12 January 2023 [Page 11]
Internet-Draft MIMI Identity July 2022
Certificates are already supported in MLS as a standard credential
type which can be included in MLS LeafNodes and KeyPackages. [In the
X3DH key agreement protocol (used with Double Ratchet), the first
message in a session between a pair of clients can contain an
optional certificate, but this is not standardized.] Arguably the
biggest drawback to using X.509 certificates is that administratively
it can be difficult to obtain certificates for entities that can also
generate certificates---specifically to issue a certificate with the
standard extension basicContraints=CA:TRUE.]
Mahy Expires 12 January 2023 [Page 12]
Internet-Draft MIMI Identity July 2022
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:dc:7a:4b:89:22:98:32:35:1f:91:84:f7:e9:4e:5d:24:c4
Signature Algorithm: ED25519
Issuer: O = example.com, CN = acme.example.com
Validity
Not Before: Jul 6 06:41:50 2022 GMT
Not After : Oct 4 06:41:49 2022 GMT
Subject: O = example.com, CN = Alice M. Smith
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
a0:6b:14:1e:a8:04:2a:09:6b:62:89:48:7c:da:5c:
68:73:b9:2a:8e:65:50:f9:15:70:bd:91:d7:86:52:
1e:4f
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Agreement
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
4C:EA:12:32:79:03:F6:4F:47:29:37:5F:96:BB:E1:91:5E:FC
X509v3 Authority Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14
Authority Information Access:
OCSP - URI:http://oscp.acme.example.com
CA Issuers - URI:http://acme.example.com/
X509v3 Subject Alternative Name: critical
URI:im:SvPfLlwBQi-6oddVRrkqpw/04c7@example.com,
URI:im:%40alice.smith@example.com
X509v3 Certificate Policies:
[etc....]
Signature Algorithm: ED25519
Signature Value:
da:21:49:cc:7a:ac:ed:7b:27:59:30:81:d9:94:c0:d7:86:e7:
db:b2:c9:ed:72:47:19:01:aa:2a:7f:24:d6:ce:2f:4f:9d:fe:
ab:8b:e2:0e:43:1b:62:b1:1d:12:3f:78:a2:bf:cc:7b:52:ef:
df:c1:94:5a:3f:ca:a1:f6:88:02
Figure 3: mocked up IM client certificate with both client id and
handle
Mahy Expires 12 January 2023 [Page 13]
Internet-Draft MIMI Identity July 2022
If implementing cascading certificates, the Issuer might be a
expressed as a URI in the issuerAltName extension.
TBC
Figure 4: mocked up IM client certificate issued by the domain
for the handle URI as Subject. Then another certificate issued
by the handle URI for the device URI as its Subject.
5.2. JSON Web Tokens (JWT) with Distributed Proof of Presence (DPoP)
JSON Web Signing (JWS) [RFC7515] and JSON Web Tokens (JWT) [RFC7519]
are toolkits for making a variety of cryptographic claims. (CBOR Web
Tokens [RFC8392] are semantically equivalent to JSON Web Tokens.)
JWT is an appealing option for carrying IM identifiers and
assertions, as the container type if flexible and the format is easy
to implement. Unfortunately the semantics for validating identifiers
are not as rigorously specified as for certificates at the time of
this writing, and require additional specification work.
The JWT Distributed Proof of Possession (DPoP) specification
[I-D.ietf-oauth-dpop] adds the ability to make claims which involve
proof of possession of a (typically private) key, and to share those
claims with third parties. The owner of a the key generates a proof
which is used to fetch an access token which can then be verified by
a third party. JWT DPoP was actually created as an improvement over
Bearer tokens used for authentication, so its use as a certificate-
like assertion may require substantial clarification and possibly
additional profile work.
While there is support for token introspection, in general access
tokens need online verification between resources and the token
issuer.
While JWTs can include list of arbitrary claims, there is no native
support for multiple subjects in the same JWT. There is a proposal
to address this limitation with nested JWTs
[I-D.yusef-oauth-nested-jwt].
Mahy Expires 12 January 2023 [Page 14]
Internet-Draft MIMI Identity July 2022
{
"typ": "dpop+jwt",
"alg": "EdDSA",
"jwk": {
"typ": "OKP",
"crv": "Ed25519",
"x": "9kaYCj...3lnwW"
}
}
.
{
"jti": "7535d380-673e-4219-8410-b8df679c306e",
"iat": 1653455836315,
"htm": "POST",
"htu": "https://example.com/client/token",
"nonce": "WE88EvOBzbqGerznM-2P_AadVf7374y0cH19sDSZA2A",
"sub": "im:SvPfLlwBQi-6oddVRrkqpw/04c7@example.com",
"exp": 1661231836315
}
Figure 5: JOSE header and claims sections of a JWT DPoP proof
referring to an IM URI
5.3. Verifiable Credentials
Verifiable Credentials (VC) is a framework for exchanging machine-
readable credentials [W3C.REC-vc-data-model-20191119]. The framework
is well specified and has a very flexbile assertion structure, which
in addition to or in place of basic names and identifiers, can
optionally include arbitrary attributes (ex: security clearance, age,
nationality) up to and including Zero Knowledge Proofs depending on
the profile being used. For example, a verifiable credential could
be used to assert that an IM client belongs to a Customer Support
agent of Sirius Cybernetic Corp, who speaks English and Vogon, and is
qualified to give support for their Ident-I-Eeze product, without
revealing the name of the agent.
The VC specification describes both Verifiable Credentials and
Verifiable Presentations. A Verifiable Credential contains
assertions made by an issuer. Holders assemble credentials into a
Verifiable Presentation. Verifiers can validate the Verifiable
Credentials in the Verifiable Presentation. Specific credential
types are defined by referencing ontologies. The example at the end
of this section uses the VCard ontology [W3C.WD-vcard-rdf-20130924].
Most of the examples for Verifiable Credentials use Decentralized
Identifiers (DIDs), but there is no requirement to use DID or the
associated esoteric cryptography in a specific VC profile. (Indeed
Mahy Expires 12 January 2023 [Page 15]
Internet-Draft MIMI Identity July 2022
the VC profile for COVID-19 for vaccination does not use DIDs). The
most significant problem with VCs are that there is no off-the-shelf
mechanism for proof of possession of a private key, and no consensus
to use VCs for straightforward identity assertions.
{
"sub": "im:SvPfLlwBQi-6oddVRrkqpw/04c7@example.com",
"jti": "http://im.example.com/@alice_smith/devices/04c7",
"iss": "https://im.example.com/keys/issuer.jwk",
"nbf": 1653455836315,
"iat": 1653455836315,
"exp": 1661231836315,
"nonce": "WE88EvOBzbqGerznM-2P_AadVf7374y0cH19sDSZA2A",
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"http://www.w3.org/2006/vcard/ns"
],
"type": ["VerifiableCredential", "ImDeviceCredential"],
"credentialSubject": {
"fn": "Alice M. Smith",
"hasOrganizationName": "Example Corp",
"hasOrganizationalUnit": "Engineering",
"hasInstantMessage": "im:%40alice_smith@example.com",
"hasInstantMessage": "im:SvPfLlwBQi-6oddVRrkqpw/04c7@example.com"
}
}
}
Figure 6: fragment of example claims payload of JWT-based VC
proof referencing the VCard ontology (WIP)
5.4. Other possible mechanisms
Below are other mechanisms which were not investigated due to a lack
of time.
* Anonymous credential schemes which can present attributes without
the long-term identity (ex: travel agent for specific team)
* Zero-knowledge proofs
* Deniable credentials
6. IANA Considerations
This document requires no action by IANA.
Mahy Expires 12 January 2023 [Page 16]
Internet-Draft MIMI Identity July 2022
7. Security Considerations
TBC. (The threat model for interoperable IM systems depends on many
subtle details).
8. Normative References
[I-D.ietf-oauth-dpop]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof-
of-Possession at the Application Layer (DPoP)", Work in
Progress, Internet-Draft, draft-ietf-oauth-dpop-09, 2 June
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
oauth-dpop-09>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862,
DOI 10.17487/RFC3862, August 2004,
<https://www.rfc-editor.org/info/rfc3862>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[W3C.REC-vc-data-model-20191119]
Sporny, M., Noble, G., Longley, D., Burnett, D., and B.
Zundel, "Verifiable Credentials Data Model 1.0", World
Wide Web Consortium Recommendation REC-vc-data-model-
20191119, 19 November 2019,
<https://www.w3.org/TR/2019/REC-vc-data-model-20191119>.
[W3C.WD-vcard-rdf-20130924]
Iannella, R. and J. McKinney, "vCard Ontology", World Wide
Web Consortium WD WD-vcard-rdf-20130924, 24 September
2013, <http://www.w3.org/TR/2013/WD-vcard-rdf-20130924>.
9. Informative References
[DoubleRatchet]
Perrin, T. and M. Marlinspike, "The Double Ratchet
Algorithm", 20 November 2016,
<https://signal.org/docs/specifications/doubleratchet/>.
Mahy Expires 12 January 2023 [Page 17]
Internet-Draft MIMI Identity July 2022
[I-D.hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-architecture-20, 20 April 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-architecture-20>.
[I-D.ietf-mls-architecture]
Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mls-architecture-08, 16 June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
architecture-08>.
[I-D.ietf-mls-protocol]
Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", Work in Progress, Internet-
Draft, draft-ietf-mls-protocol-16, 11 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
protocol-16>.
[I-D.mahy-mimi-problem-outline]
Mahy, R., "More Instant Messaging Interoperability (MIMI)
problem outline", Work in Progress, Internet-Draft, draft-
mahy-mimi-problem-outline-00, 11 July 2022,
<https://datatracker.ietf.org/doc/html/draft-mahy-mimi-
problem-outline-00>.
[I-D.yusef-oauth-nested-jwt]
Shekh-Yusef, R., "Multi-Subject JSON Web Token (JWT)",
Work in Progress, Internet-Draft, draft-yusef-oauth-
nested-jwt-05, 14 June 2022,
<https://datatracker.ietf.org/doc/html/draft-yusef-oauth-
nested-jwt-05>.
[Matrix1756]
Chathi, H., "Cross-signing devices with device signing
keys", 13 December 2018, <https://github.com/matrix-org/
matrix-doc/blob/master/proposals/1756-cross-signing.md>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
Mahy Expires 12 January 2023 [Page 18]
Internet-Draft MIMI Identity July 2022
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[Schaub] Schaub, P., "Cryptographic Identity: Conquering the
Fingerprint Chaos (video)", 6 April 2021,
<https://www.youtube.com/watch?v=oc5844dyrsc>.
[X3DH] Marlinspike, M. and T. Perrin, "The X3DH Key Agreement
Protocol", 4 November 2016,
<https://signal.org/docs/specifications/x3dh/>.
Appendix A. Acknowledgments
The author wishes to thank Richard Barnes, Tom Leavy, Joel Alwen,
Marta Mularczyk, and Rifaat Shekh-Yusef for discussions about this
topic.
Author's Address
Rohan Mahy
Wire
Email: rohan.mahy@wire.com
Mahy Expires 12 January 2023 [Page 19]