Browse Source

fixed a little language

master
Krista Bennett 11 months ago
parent
commit
43b81c2ab9
1 changed files with 14 additions and 7 deletions
  1. +14
    -7
      key_reset_example_spec.md

+ 14
- 7
key_reset_example_spec.md View File

@ -18,8 +18,9 @@ been made to ensure the singular/plural context is clear.*
## Introduction
One of p≡p's challenges as an encryption product which automates as
much of the key management and trust process as possible is that when there are
p≡p is an an encryption product which automates as
much of the key management and trust process as possible. As a result,
one of its greatest challenges is that when there are
key related issues - e.g. compromise, revocation, or simply needing to use a
different default key for a partner - the software must be able to provide both
internal and user access to the ability to change these default keys without actually
@ -93,7 +94,7 @@ upfront for easy reference.
### Problem Description
#### Context: p≡p and default keys
#### Context: p≡p, default keys, and trust
p≡p has, for every [identity](#identity) (where possible), a [default key](#default_key) used for encryption and signing of messages (or their
verification/decryption).
@ -114,7 +115,7 @@ there are times when a user or an internal protocol needs to *reset* these defau
replace them with new ones. Additionally, when a user begins using a new default key,
they may need to communicate this change of desired defaults to communications partners.
Or an automated internal protocol may, for example, have a reason to invalidate one or more
of a user's own keys
of a user's own keys.
Within the p≡p environment, there are several circumstances under which we might need
to reset the default key that p≡p would ordinarily use as the default key either for
@ -123,9 +124,14 @@ order to encrypt it. A user may need to revoke one or more of their own keys due
creation of a new key. And internally, there are protocols, such as [KeySync](#keysync), which, as part of automated
key management, may need to securely force removal and regeneration of default keys across devices.
And finally, p≡p allows users to assign trust (through the exchange of [Trustwords](#trustwords))
or mistrust to a key associated with an identity, and sometimes desires that these values are reset,
either due to error or a change in their own perception of trust. A mechanism needs to be available
to reset this information about keys as well.
#### Problem summary
The big picture problem comes in two parts:
The largest part of the problem comes in two parts:
1. Users who have had their devices/systems compromised need a fast and easy way to ensure that their own default keys are revoked and replaced,
that these changes are communicated to partners as seamlessly as possible, and that their partners are able to start
@ -214,8 +220,9 @@ This creates the following additional requirements in addition to 1. above:
7. The notification in 5. must, at the very least, contain some artifact that requires the private key of
the now-revoked key to produce (e.g. a revocation certificate).
8. The notification in 5. must, at a minimum, be signed with the private key of the new keypair.[^signing_w_revoked]
([^signing_w_revoked]: This is because once revoked, we cannot sign with the old private key.)
8. The notification in 5. must, at a minimum, be signed with the private key of the new keypair. [^signing_w_revoked]
[^signing_w_revoked]: This is because once revoked, we cannot sign with the old private key.
##### <a name="req_ex_2"> Example 2: Device compromise - simple case (single device) </a>


Loading…
Cancel
Save