white space only

pep-keysync/draft-hoeneisen-pep-keysync.mkd

@@ -46,9 +46,9 @@ include, but are not limited to, key management, key discovery, and
 private key handling.
 
 This document specifies a protocol for peer-to-peer synchronization of
-private keys across devices belonging to the same user. The pEp KeySync
-protocol also serves as the basis for synchronization of other user data,
-e.g., public keys of peers (including trust information).
+private keys across devices belonging to the same user. The pEp
+KeySync protocol also serves as the basis for synchronization of other
+user data, e.g., public keys of peers (including trust information).
 
 
 --- middle
@@ -57,8 +57,8 @@ e.g., public keys of peers (including trust information).
 
 This document specifies the pEp KeySync Protocol, a means for
 peer-to-peer synchronization of private keys across devices belonging
-to the same user. The pEp KeySync protocol also serves as the
-basis for synchronization of other user data, e.g., public keys of peers
+to the same user. The pEp KeySync protocol also serves as the basis
+for synchronization of other user data, e.g., public keys of peers
 (including trust information).
 
 This part of the pretty Easy privacy (pEp) protocols {{I-D.birk-pep}}
@@ -130,41 +130,41 @@ these use cases will be discussed in further detail in
 
 ### Forming 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 already has its own key pair, which was
-automatically generated by the pEp protocol. Neither device knows anything
-about the other.
+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
+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.
+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.
 
 
 ### Adding New Device to Existing Device Group
 
 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
+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. Thus, Alice does not have full
 communication capability across the three devices.
 
 <!-- Editorial NOTE: Reference forming-device-group may change due to
 autonumbering, ensure it is pointing to the one in this section -->
 
-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.
+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.
 
 
 ### Exchange Private Keys
@@ -175,8 +175,9 @@ All devices from Alice are part of a Device Group
 expire or get reset <!-- TODO: Key Reset Reference, when out --> ,
 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. All devices of Alice
-will keep the other devices updated  with the latest private keys.
+shared with the other devices in the device group. All devices of
+Alice will keep the other devices updated with the latest private
+keys.
 
 <!-- Editorial NOTE: References forming-device-group /
 adding-new-device-to-existing-device-group may change due to
@@ -195,16 +196,17 @@ Group. Alice ensures that this device will leave the 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.
+private keys <!-- TODO: Key Reset Reference, when out -->.  Alice will
+initiates the actions to mitigate the damage.
 
 
 <!--
 
 ### Synchronizing Trust
 
-[[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.]]
+[[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.]]
 
 [[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
@@ -214,8 +216,8 @@ 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.
+synchronized. Alice ensures that the public keys and trust state of
+her peers are be reflected on any device she uses.
 
 -->