diff --git a/pep-keysync/draft-hoeneisen-pep-keysync.mkd b/pep-keysync/draft-hoeneisen-pep-keysync.mkd index 308d8a50..c3d75d8b 100644 --- a/pep-keysync/draft-hoeneisen-pep-keysync.mkd +++ b/pep-keysync/draft-hoeneisen-pep-keysync.mkd @@ -112,26 +112,21 @@ not leaked or exposed to theft. * Beacon (message): A text message that is stored inside the mailbox of the Device Group, which contains control commands and serves as communication channel between the devices of the Device Group. - -[[Do we need these defined? KRB]] -* User: An individual. Typically denoted by use of a User ID or username. - -* Identity: A User plus a unique address, which can be an email address, network - address, URI, etc. A User may have many Identities, one for each unique address. --> # General Description -This section describes the general concepts of pEp KeySync, focusing -on the main procedures in an optimal use case only. Use cases involving -unexpected user behavior, error handling, race conditions and the like are -omitted from this section in order to facilitate a better understanding of the -general concepts of pEp KeySync. Some of these use cases will be discussed in -further detail in {{implementation-description}}, ff.. +This section describes the general concepts of pEp KeySync. It +focusing on the main procedures and on the scenarios where everything +works. Unexpected user behavior, error handling, race conditions and +the like are mostly omitted from this section in order to facilitate a +better understanding of the general concepts of pEp KeySync. Some of +these use cases will be discussed in further detail in +{{implementation-description}}, ff. -## Use Cases +## Use Cases for pEp KeySync ### Forming Device Group @@ -143,30 +138,30 @@ 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 may -use pEp Keysync to form a Device Group and add her devices to it, which will -allow for the exchange of private key information among its members, thus +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. ### Adding New Device to Existing Device Group -Devices Alice_R and Alice_O are now part of a Device Group -(cf. {{forming-device-group}}). Meanwhile, Alice buys another device, Alice_J, +Sometime after devices Alice_R and Alice_O have formed a Device Group +(cf. {{forming-device-group}}), Alice buys another device, Alice_J, which is also configured with pEp-implementing messaging clients and shares the same identity for her preferred communication channel (the aforementioned email address). Alice_J also has a key pair, which was automatically generated by the pEp protocol, just as the grouped devices Alice_R and Alice_O have. But while the grouped devices know each other and have exchanged private keys, Alice_J and the grouped -devices don't know anything each other, and thus Alice does not have full +devices don't know anything each other. Thus, Alice does not have full communication capability across the three devices. -As before with devices Alice_R and Alice_O, Alice may use pEp Keysync to add +As before with devices Alice_R and Alice_O, Alice will use pEp Keysync to add device Alice_J to the existing Device Group, allowing all three devices to exchange private key information, and Alice to have access to her messages from any of them. @@ -180,13 +175,30 @@ All devices from Alice are part of a Device Group expire or get reset , occasionally new key pairs are generated. For Alice to be able to read all encrypted messages on all devices, any new private key needs to be -shared with the other devices in the device group. +shared with the other devices in the device group. All devices of Alice +will keep the other devices updated with the latest private keys. +### Leave 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. + + +### 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 . Alice +will initiates the actions to mitigate the damage. + + [[KRB: Do we need to define Trust above, or possibly here? I think an explanation or reference to pEp trust ratings, etc. would be beneficial to understanding.]] -While sending messages from her pEp KeySynced devices, Alice expects the same -level of privacy she's accustomed to from using one device, i.e., she wants all -of the trust she gave her contacts synchronized. That is, the trust -should be reflected on any device she uses. +[[HB: For the time being, this remains commented due to TrustSync not +being implemented yet. This needs to be dealt with at the time we +include TrustSync.]] + + +While sending messages from her pEp KeySynced devices, Alice expects +the same level of privacy she's accustomed to from using one device, +i.e., she wants all of the trust she gave her contacts +synchronized. Alice ensures that the public keys and trust state +of her peers are be reflected on any device she uses. --> + ## Interaction Diagrams The following interaction diagrams depict the implementations of the