Updated Interaction Diagrams section (added Cancel/Reject incl figures), add vspace for better alignment of titles and figures

master
Bernie Hoeneisen 4 years ago
parent ed7b5827db
commit bdbc68aaaa
  1. 4
      pep-keysync/Makefile
  2. 227
      pep-keysync/draft-hoeneisen-pep-keysync.mkd
  3. 4
      shared/ascii-arts/sync/form-device-group.atxt
  4. 14
      shared/ascii-arts/sync/join-device-group.atxt

@ -23,6 +23,10 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/text-blocks/implementation-status.mkd \
../shared/fence-line.mkd \
../shared/ascii-arts/sync/form-device-group.atxt \
../shared/ascii-arts/sync/form-device-group_reject.atxt \
../shared/ascii-arts/sync/form-device-group_cancel.atxt \
../shared/ascii-arts/sync/join-device-group_reject.atxt \
../shared/ascii-arts/sync/join-device-group_cancel.atxt \
../shared/ascii-arts/sync/join-device-group.atxt \
../shared/text-blocks/more-info-following-code.mkd \
# ../shared/author_tags/claudio_luck.mkd \

@ -227,17 +227,23 @@ her peers are be reflected on any device she uses.
## Interaction Diagrams
The following interaction diagrams depict the implementations for some
of the above Use Case in a simplified manner (as mentioned above, some
aspects are skipped for the sake of better readability). A decription
is added after each diagram.
of the above Use Case in a simplified manner (i.e. some aspects are
skipped for the sake of better readability). A decription is added
after each diagram.
<vspace blankLines="50" />
### Form Device Group
#### Successful Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/form-device-group.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="30" />
As depicted above a user intends to form a Device Group, e.g. in order
to securly share key material among its members. The group is formed
by an 'Offerer'-Device and a Requester device. The name is derived
@ -262,10 +268,11 @@ its sender.
Note: The 'Offerer'-Device MUST NOT start a Negotiation. Thus, it
re-sends its own beacon (for robustness in case earlier beacon
message got lost) and waits. This is shown by Message 0. that is
not required for the process to work.
message got lost) and waits. Message 1(r) depicts the beacon
message sent by the 'Requester'-Device and is not required for the
process to coninue.
2. After determination of the role, the 'Requester'-Device sends a
2. After determination of the role, the 'Requester'-Device sends a
NegotiationRequest message.
3. The 'Requester'-Device displays the Trustwords to the user.
@ -275,19 +282,20 @@ its sender.
5. The 'Offerer'-Device displays the Trustwords to the user.
6. The user compares the Trustwords of both devices and presses the
'Accept'-Button on the 'Requester'-Device.
6. The user compares the Trustwords of both devices. As the Trustwords
are the same on both Devices, the user presses the 'Accept'-Button
on the 'Requester'-Device.
Note 1: The user may also press the 'Accept'-Button on the
'Offerer'-Device. The end result is not affected by which
'Offerer'-Device first. The end result is not affected by which
'Accept'-Button is pressed first. However, the order of the
messages slightly changes.
Note 2: The user may also choose to press the 'Cancel'-Button or
the 'Reject'-Button. However, these cases are explained later.
\[\[ TODO: Add reference if section is ready \]\]
the 'Reject'-Button (see below).
<!-- Add (stable) internal reference -->
7. On reception of the user's 'Accept', the 'Requester'-Device sends a
CommitAcceptRequester message.
@ -298,9 +306,9 @@ its sender.
'Accept'-Button on the 'Offerer'-Device.
Note: The user may also choose to press the 'Cancel'-Button or the
'Reject'-Button. However, these cases are explained later.
'Reject'-Button (see below).
\[\[ TODO: Add reference if section is ready \]\]
<!-- Add (stable) internal reference -->
9. On reception of the user's 'Accept', the 'Offerer'-Device sends
a CommitAcceptRequester message.
@ -317,12 +325,90 @@ its sender.
been successful.
<vspace blankLines="50" />
#### Unsuccessful Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/form-device-group_reject.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="10" />
Messages (1-5) are same as in the successful case (see above)
<!-- Add (stable) internal reference -->
{::include ../shared/fence-line.mkd}
R6. The user compares the Trustwords of both devices. As the
Trustwords do not match, the user presses the 'Reject'-Button on
the 'Requester'-Device.
Note: The user may also press the 'Reject'-Button on the
'Offerer'-Device first. The end result is not affected by which
'Reject'-Button is pressed first. However, the order of the
messages slightly changes.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
R7. On reception of the user's 'Reject', the 'Requester'-Device sends
a CommitReject message.
{::include ../shared/fence-line.mkd}
The both Devices do not Form a Device Group and pEp keySync is
disabled on both devices. As a consequence are no furter attempts to
form a Device Group.
<vspace blankLines="50" />
#### Discontinuation Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/form-device-group_cancel.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="10" />
Messages (1-5) are same as in the successful case (see above)
<!-- Add (stable) internal reference -->
{::include ../shared/fence-line.mkd}
R6. The user decides to discontinue the process and thus presses the
'Cancel'-Button on the 'Requester'-Device.
Note: The user may also press the 'Cancel'-Button on the
'Offerer'-Device first. The end result is not affected by which
'Cancel'-Button is pressed first. However, the order of the
messages slightly changes.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
R7. On reception of the user's 'Cancel', the 'Requester'-Device sends
a rollback message.
{::include ../shared/fence-line.mkd}
The both Devices do not Form a Device Group and pEp keySync will try
again to form a Device Group.
<vspace blankLines="50" />
### Add New Device to Existing Device Group
#### Successful Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/join-device-group.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="10" />
As depicted above a user intends to add a New Device to an existing
Device Group.
@ -332,18 +418,25 @@ allow to identify a received message regarding ongoing transaction and
its sender.
1. During initialization of pEp KeySync the New Device sends a Beacon
message. All Beacon messages sent by the same user are the same
message, i.e. the same instances of message 1.
message.
Note: In the diagram, all Beacon messages 1 are in fact the same
message, those are just shown apart for better readability.
2. Up on reception of a Beacon message from a device not part of a
Device Group, all Grouped Devices are send a NegotiationRequest
message. Messages 2a and 2p are different instances of message 2.
message.
Note: Messages 2(a) and 2(p) are different instances of the
NegotiationRequest message type.
3. All Grouped Devices display the Trustwords to the user.
4. Up on reception of every NegotiationRequest message, the New
Device sends a NegotiationOpen message. Messages 4a and 4p are
different instances of message 4.
Device sends a NegotiationOpen message.
Note: Messages 4(a) and 4(p) are different instances of the
NegotiationOpen message type.
5. The New Device displays the Trustwords to the user.
@ -356,15 +449,15 @@ its sender.
Devices in Group.
Note 2: The user may also press the 'Accept'-Button on the New
Device. The end result is not affected by which 'Accept'-Button is
pressed first. However, the order and number of the messages
change.
Device first. The end result is not affected by which
'Accept'-Button is pressed first. However, the order and number of
the messages change.
Note 3: The user may also choose to press the 'Cancel'-Button or
the 'Reject'-Button. However, these cases are explained later.
\[\[ TODO: Add reference if section is ready \]\]
the 'Reject'-Button (see below).
<!-- Add (stable) internal reference -->
7. On reception of the user's 'Accept', the Active Grouped Device
sends a TrustThisKey message, which is consumed by the Passive
Grouped Devices.
@ -394,6 +487,90 @@ its sender.
own private keys. The New Device has successfully joined Device
Group.
Note: In the diagram, all GroupKeys messages 12 are in fact the
same message, those are just shown apart for better readability.
<vspace blankLines="50" />
#### Unsuccessful Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/join-device-group_reject.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="10" />
Messages (1-5) are same as in the successful case (see above)
<!-- Add (stable) internal reference -->
{::include ../shared/fence-line.mkd}
R6. The user compares the Trustwords of both devices. As the
Trustwords do not match, the user presses the 'Reject'-Button on
one of the Grouped Devices.
Note: The user may also press the 'Reject'-Button on the New
Device first. The end result is not affected by which 'Reject'-
Button is pressed first. However, the order and number of the
messages slightly changes.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
R7. On reception of the user's 'Reject', the 'Requester'-Device sends
a 'CommitReject' message.
Note: In the diagram, all CommitRequest messages R7 are in fact
the same message, those are just shown apart for better
readability.
{::include ../shared/fence-line.mkd}
The New Devices does not join the Group and pEp keySync is disabled on
the New Devices. As a consequence, There are no further attempts to
join the Device Group.
<vspace blankLines="50" />
#### Discontinuation Case
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/sync/join-device-group_cancel.atxt}
{::include ../shared/fence-line.mkd}
<vspace blankLines="10" />
Messages (1-5) are same as in the successful case (see above)
<!-- Add (stable) internal reference -->
{::include ../shared/fence-line.mkd}
C6. The user decides to discontinue the process and thus presses the
'Cancel'-Button on one of the Grouped Devices.
Note: The user may also press the 'Cancel'-Button on the New
Device first. The end result is not affected by which 'Cancel'-
Button is pressed first. However, the order and number of the
messages slightly changes.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
C7. On reception of the user's 'Cancel', the 'Requester'-Device sends
a rollback message.
Note: In the diagram, all Rollback messages C7 are in fact the
same message, those are just shown apart for better readability.
{::include ../shared/fence-line.mkd}
The New Devices does not join the Group and pEp keySync will try again
to join the Device Group.
### Exchange Private Keys

@ -6,10 +6,10 @@
`-------+--------' User `--------+---------'
| | |
| | |
| 0. Beacon (challenge TID) |
| 1(r). Beacon (challenge TID) |
|<--------------------------------------------|
| | |
| 1. Beacon (challenge TID) |
| 1(o). Beacon (challenge TID) |
|-------------------------------------------->|
| | |
| 2. NegotiationRequest |

@ -12,23 +12,23 @@
| | 1. Beacon | |
|----------------------------------------------------->|
| | | |
| 2p. NegotiationRequest |
| 2(p). NegotiationRequest |
|<-----------------------------------------------------|
| | | |
| | 3p. Display Trustwords |
| | 3(p) Display Trustwords |
| |<- - - - - - - - - - - - - - - - - - |
| | | |
| |4p. NegotiationOpen |
| 4(p) NegotiationOpen |
|----------------------------------------------------->|
| | | |
| 2a. NegotiationRequest | |
| 2(a). NegotiationRequest | |
|<---------------------------------| |
| | | |
| | 3a. Display | |
| | Trustwords | |
| | 3(a). Display | |
| | Trustwords | |
| |<- - - - - - - - | |
| | | |
| 4a. NegotiationOpen | |
| 4(a). NegotiationOpen | |
|--------------------------------->| |
| | | |
| 5. Display | | |

Loading…
Cancel
Save