|
|
|
|
@ -136,22 +136,22 @@ these use cases will be discussed in further detail in
|
|
|
|
|
|
|
|
|
|
## Use Cases for pEp KeySync
|
|
|
|
|
|
|
|
|
|
### Form Device Group
|
|
|
|
|
### Forming a Device Group
|
|
|
|
|
|
|
|
|
|
Our user, Alice, has two devices that are configured with
|
|
|
|
|
pEp-implementing messaging clients and share the same identity for her
|
|
|
|
|
preferred communication channel (for our example, let's use an email
|
|
|
|
|
address). Let's call these devices Alice_R and Alice_O. Each device
|
|
|
|
|
preferred communication channel (in our example: an email communication
|
|
|
|
|
channel with a network address identified by an email address).
|
|
|
|
|
Let us call these devices Alice_R and Alice_O. Each device
|
|
|
|
|
already has its own key pair, which was automatically generated by the
|
|
|
|
|
pEp protocol. Neither device knows anything about the other.
|
|
|
|
|
|
|
|
|
|
Alice wants full communication capability from both of her devices,
|
|
|
|
|
but currently cannot do so, as the devices do not know about each
|
|
|
|
|
other. Alice will use pEp Keysync to form a Device Group and add her
|
|
|
|
|
devices to it. This allows for the exchange of private key information
|
|
|
|
|
among its members. Thus, allowing both devices to have full
|
|
|
|
|
communication capability, and Alice to use her devices as she desires.
|
|
|
|
|
|
|
|
|
|
devices to it. This allows for the exchange of private key data
|
|
|
|
|
among its end-devices. Thus, allowing Alice to have full
|
|
|
|
|
communication capability with both devices.
|
|
|
|
|
|
|
|
|
|
### Add New Device to Existing Device Group
|
|
|
|
|
|
|
|
|
|
@ -192,23 +192,30 @@ add-new-device-to-existing-device-group may change due to
|
|
|
|
|
autonumbering, ensure it is pointing to the one in this section -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Withdraw Device from Device Group
|
|
|
|
|
### Leave Device Group
|
|
|
|
|
|
|
|
|
|
\[\[ TODO: Maybe better title? \]\]
|
|
|
|
|
Alice decides that one of her devices (e.g., her mobile phone) should
|
|
|
|
|
no longer be able to have access to all private keys of the Device
|
|
|
|
|
Group. Alice can manually ensure that this device will leave the Device Group.
|
|
|
|
|
|
|
|
|
|
Alice decides that one of her devices (e.g. her mobile phone) should
|
|
|
|
|
no longer be able to have acces to all private keys of the Device
|
|
|
|
|
Group. Alice ensures that this device will leave the Device Group.
|
|
|
|
|
The Device Group will ensure further communication to be private among the
|
|
|
|
|
remaining Grouped Devices by issuing new Group Keys for all identities
|
|
|
|
|
affected.
|
|
|
|
|
|
|
|
|
|
<!-- TODO: Key Reset reference, when out. -->
|
|
|
|
|
|
|
|
|
|
### Remove other Device from Device Group
|
|
|
|
|
|
|
|
|
|
A device from Alice got stolen or compromised. Thus, she has to ensure
|
|
|
|
|
that this device no longer received updates on private keys from other
|
|
|
|
|
devices in the same Device Group. This involves to revoke many of her
|
|
|
|
|
private keys <!-- TODO: Key Reset Reference, when out -->. Alice will
|
|
|
|
|
initiates the actions to mitigate the damage.
|
|
|
|
|
A device from Alice got stolen or got compromised. Thus, she has to ensure
|
|
|
|
|
that this device no longer receives updates on private keys from other
|
|
|
|
|
devices in the same Device Group.
|
|
|
|
|
|
|
|
|
|
From one of her other remaining Grouped Devices the process to issue new
|
|
|
|
|
Group Keys for all identities affected can be started, such as to mitigate
|
|
|
|
|
the damage to the extent that an attacker able to unlock the end-device
|
|
|
|
|
might be able to read all past messages.
|
|
|
|
|
|
|
|
|
|
<!-- TODO: Key Reset reference, when out. -->
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
|
|
|
|
|
|
