Internet DRAFT - draft-pep-keyreset

draft-pep-keyreset







Network Working Group                                       B. Hoeneisen
Internet-Draft                                            pEp Foundation
Intended status: Standards Track                        16 December 2022
Expires: 19 June 2023


                  pretty Easy privacy (pEp): Key Reset
                         draft-pep-keyreset-00

Abstract

   The pretty Easy privacy (pEp) model and protocols describe a set of
   conventions for the automation of operations traditionally seen as
   barriers to the use and deployment of secure, privacy-preserving end-
   to-end messaging.  These include, but are not limited to, key
   management, key discovery, and private key handling (including peer-
   to-peer synchronization of private keys and other user data across
   devices).

   This document specifies the pEp KeyReset protocol that allows
   applications to provide simple high-level functionality to users
   needing to perform some of the aforementioned functions while still
   ensuring that the appropriate low-level changes in keyrings and trust
   management are handled consistently, and that communication of these
   changes to active partners (where necessary) happens seamlessly,
   without explicit action on the part of the user.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 June 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Hoeneisen                 Expires 19 June 2023                  [Page 1]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Relationship to Other pEp Documents . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.4.  Problem Statement . . . . . . . . . . . . . . . . . . . .   6
       1.4.1.  Context: pEp, Default Keys, and Trust . . . . . . . .   6
       1.4.2.  Problem Summary . . . . . . . . . . . . . . . . . . .   7
     1.5.  Background  . . . . . . . . . . . . . . . . . . . . . . .   8
     1.6.  Use Cases and Requirements  . . . . . . . . . . . . . . .   9
       1.6.1.  Overall Requirements  . . . . . . . . . . . . . . . .   9
       1.6.2.  Example 1: Own Single Key Replacement with New Key  .   9
       1.6.3.  Example 2: Device Compromise - Simple Case (Single
               Device) . . . . . . . . . . . . . . . . . . . . . . .  10
       1.6.4.  Example 3: Encryption to a Revoked pEp Partner Key  .  11
       1.6.5.  Example 4: Manually Changing Use of Incorrect Partner
               Key . . . . . . . . . . . . . . . . . . . . . . . . .  12
       1.6.6.  Example 5: Removing Trust or Mistrust from
               Communications Partner Key  . . . . . . . . . . . . .  12
       1.6.7.  Example 6: KeySync: Reset Own Keys  . . . . . . . . .  13
   2.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .  14
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  14
     2.2.  Functions . . . . . . . . . . . . . . . . . . . . . . . .  15
       2.2.1.  Sending Side  . . . . . . . . . . . . . . . . . . . .  15
       2.2.2.  Receiving Side  . . . . . . . . . . . . . . . . . . .  17
       2.2.3.  DDL Impacts . . . . . . . . . . . . . . . . . . . . .  18
     2.3.  Protocol Descriptions with Examples . . . . . . . . . . .  19
       2.3.1.  Example 1: Own Single Key Replacement with New Key  .  19
       2.3.2.  Example 2: Device Compromise - Simple Case (Single
               Device) . . . . . . . . . . . . . . . . . . . . . . .  20
       2.3.3.  Example 3: Encryption to Revoked pEp Partner Key  . .  20
       2.3.4.  Example 4: Manually Changing Use of Incorrect Partner
               Key . . . . . . . . . . . . . . . . . . . . . . . . .  21
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  24
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25



Hoeneisen                 Expires 19 June 2023                  [Page 2]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Appendix A.  Document Changelog . . . . . . . . . . . . . . . . .  26
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   The pretty Easy privacy (pEp) [I-D.pep-general] protocols describe a
   set of conventions for the automation of operations traditionally
   seen as barriers to the use and deployment of secure end-to-end
   interpersonal messaging.  These include, but are not limited to, key
   management, key discovery, and private key handling.

   pEp 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 need 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 exposing the concept of keys, which goes against pEp's
   "Pretty Easy" principle, or the details of trust management.

   This document specifies the pEp KeyReset protocol that allows
   applications to provide simple high-level functionality to users
   needing to perform some of the aforementioned functions while still
   ensuring that the appropriate low-level changes in keyrings and trust
   management are handled consistently, and that communication of these
   changes to active partners (where necessary) happens seamlessly,
   without explicit action on the part of the user.  Additionally, the
   protocol provides important lower-level internal functionality to
   other internal protocols (e.g., KeySync [I-D.pep-keysync]).

1.1.  Relationship to Other pEp Documents

   While this document provides a general description of pEp KeyReset,
   including use cases, diagrams, and examples of messages that may be
   generated during the KeyReset process, other related documents
   specialize in more particular aspects of the model, or the
   application of pEp on a specific protocol like as follows:

   1.  General description and functionalities of pep (cf. pEp General
       [I-D.pep-general]).

   2.  pEp-enabled applications (e.g., pEp email [I-D.pep-email]).






Hoeneisen                 Expires 19 June 2023                  [Page 3]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   3.  Helper functions for peer interaction, which facilitate
       understanding and handling of the cryptographic aspects of pEp
       implementation for users (e.g., pEp Handshake
       [I-D.pep-handshake]).

   4.  Helper functions for interactions between a user's own devices,
       which give the user the ability to run pEp applications on
       different devices at the same time, such as a computer, mobile
       phone, or tablets (e.g., pEp KeySync [I-D.pep-keysync]).

   In addition, there are documents that do not directly depend on this
   one, but provide generic functions needed in pEp, e.g., IANA
   Registration of Trustword Lists [I-D.pep-trustwords].

   [[ Note: At this stage it is not yet clear to us how many of our
   implementation details should be part of new RFCs and where we can
   safely refer to already existing RFCs to clarify which RFCs we rely
   on. ]]

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.3.  Terms

   The following terms are defined for the scope of this document:

   *  pEp Handshake: The process of one user contacting another over an
      independent channel in order to verify Trustwords (or fingerprints
      as a fallback).  This can be done in-person or through established
      verbal communication channels, like a phone call.
      [I-D.pep-handshake]

   *  Trustwords: A scalar-to-word representation of 16-bit numbers (0
      to 65535) to natural language words.  Trustwords are generated
      from the combined public key fingerprints of a both communication
      partners.  Trustwords are used for verification and establishment
      of trust (for the respective keys and communication partners).
      [I-D.pep-trustwords]

   *  Trust On First Use (TOFU): cf. [RFC7435], which states: "In a
      protocol, TOFU calls for accepting and storing a public key or
      credential associated with an asserted Identity, without
      authenticating that assertion.  Subsequent communication that is



Hoeneisen                 Expires 19 June 2023                  [Page 4]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


      authenticated using the cached key or credential is secure against
      an MiTM attack, if such an attack did not succeed during the
      vulnerable initial communication."

   *  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
      form of active wiretapping attack in which the attacker intercepts
      and selectively modifies communicated data to masquerade as one or
      more of the entities involved in a communication association."

      Note: Historically, MITM has stood for '_Man_-in-the-middle'.
      However, to indicate that the entity in the middle is not always a
      human attacker, MITM can also stand for 'Machine-in-the-middle' or
      'Meddler-in-the-middle'.

   *  User: An individual entity using pEp.  A User may have one or more
      Identities.

   *  User-ID: A unique identifier for a given User.

   *  Own User: The pEp user that is controlling the local client in
      question.

   *  Address: An address in pEp means the designator of a destination
      where messages can be routed to and accessed from, e.g., email
      address, Uniform Resource Identifier (URI), Network Access
      Identifier (NAI), phone number, etc.  An address may belong to one
      or more users.  A user may have multiple Addresses.

   *  Identity: A binding between a user (unique User-ID) and an Address
      (email, network ID, URI, etc.).  Each Identity is uniquely
      identified by this binding.  Identities contain a number of
      different pieces of information, often including, but not limited
      to:

      -  User-ID

      -  Address

      -  Default Key

      -  Username

      -  Preferred encryption format

      -  Information about whether this is an Own Identity

      -  ...




Hoeneisen                 Expires 19 June 2023                  [Page 5]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


      A single user may have multiple identities.  See also [RFC4949].

   *  Own Identity: An Identity corresponding to one of the Own User's
      Addresses.

   *  KeySync: A synchronisation protocol for sharing and maintaining
      private keys across a user's pEp installations (cf.
      [I-D.pep-keysync]).

   *  Device Group: A set of devices controlled by one pEp User that
      have successfully completed the KeySync setup process and
      synchronize Indentiy information, such as cryptographic keys.
      This data is synchronized through a common channel for a given
      Identity.  For example, if a user's Identity is tied to a specific
      email address, the common channel for this Identity could be an
      inbox.

   *  Default Key: The Identity's or user's key that is marked as the
      key to be used to encrypt to (in the case of communications
      partners) or to sign with (in the case of the Own User).

   *  Own Key: A public/private keypair corresponding to a user's Own
      Identity.

1.4.  Problem Statement

1.4.1.  Context: pEp, Default Keys, and Trust

   pEp has, for every Identity (where possible), a Default Key used for
   encryption and signing of messages (or their verification/
   decryption).

   For the individual pEp User and corresponding Address, their Own
   Default Key is the key they use to sign messages to others, to
   decrypt messages from communications partners, and to encrypt
   messages to themselves.

   Additionally, however, for every Identity that this User communicates
   with, there is (where available) a Default Key belonging to the
   communications partner which is used to encrypt messages to that
   Identity and to verify messages signed by that Identity.

   A User may have several Identities, and each of those Identities may
   have a distinct Default Key.

   These defaults generally stay stable unless a key becomes invalid or
   unusable.  However, there are times when a User or an internal
   protocol needs to reset these defaults and replace them with new



Hoeneisen                 Expires 19 June 2023                  [Page 6]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   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.

   Within the pEp environment, there are several circumstances under
   which we might need to reset the Default Key that pEp would
   ordinarily use as the Default Key either for the User themselves to
   sign messages and data, or for a communications partner in order to
   encrypt it.  A User may need to revoke one or more of their Own Keys
   due to compromise or accidental creation of a new key.  And
   internally, there are protocols, such as KeySync (cf.
   [I-D.pep-keysync]), which, as part of automated key management, may
   need to securely force removal and regeneration of Default Keys
   across devices.

   And finally, pEp allows Users to assign trust (through the exchange
   of Trustwords) or mistrust to a key associated with an Identity, and
   sometimes Users desire 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.

1.4.2.  Problem Summary

   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
       using the correct key with little or no interaction.

   2.  In the case that a partner is using a key which is either not the
       User's real key or is a key that the User no longer has access
       to, there needs to be a way for that User to contact the partner
       on a second channel to tell them to stop using that key for their
       Address.

   Because we want to abstract the idea of keys away from the User,
   having them only focus on their contacts and the expression of trust
   with these contacts as applied to the sending and receipt of
   messages, pEp must provide a way for apps to create this abstraction
   without needing to retain information about specific keys, especially
   since we want to avoid Users interacting with the idea of keys at all
   costs.





Hoeneisen                 Expires 19 June 2023                  [Page 7]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   Thus, we need a way for implementations to provide this functionality
   for both (1) the reset of Own Keys belonging to an Own Identity, and
   (2) such a reset for partner keys belonging to a partner Identity
   which does not require any information about keys from the
   application or external protocol layer, while still ensuring that the
   appropriate low-level (keyring and management database) actions can
   occur appropriately.

   We also need to be able to ensure that the partners regularly
   contacted by a User who has reset their Own Key(s) can be notified
   and informed that they should use the new key (and stop using the old
   one) corresponding to the specific User Address they have been
   communicating with without the need for the User to inform partners
   explicitly while still ensuring some verification that this
   information actually came from the User.

   The KeyReset protocol aims to solve this problem of providing an
   abstraction to the application layer as well as providing both
   opportunistic and situation-based automated communication of changes
   to partners without compromising the trust system and minimizing man-
   in-the-middle attacks.  This can be achieved, e.g., by providing API
   functions which operate at both the User and Identity levels for both
   Own Users and partners.  Implementations ensure mapping of Identity
   information to keys, all necessary key manipulation and management
   database functions as well as automation of the partner-notification
   process.

1.5.  Background

   Early implementations of pEp lacked an easy means for high-level Key
   revocation of Own Keys, for partners to stop using a key at the
   request of the User, and for notification of Default Key changes
   through revocation to communications partners.  This made it very
   difficult to clear Default Key data when desired without forcing
   applications to keep track of Default Key information, and without
   having partners continue encrypting messages to the older Default
   Key. There was no means for applications to simply tell, "please
   reset all key data for this Identity", or to automatically tell
   partners they were using a revoked key and to start using a new one.

   KeyReset provides this functionality, which can be used both by
   applications and by internal protocols to provide these functions
   under a variety of circumstances.








Hoeneisen                 Expires 19 June 2023                  [Page 8]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


1.6.  Use Cases and Requirements

   This section uses key use cases to create a list of requirements the
   KeyReset protocol must fulfill.  This is central to designing a
   solution.

   Note: The requirements are labeled with the letter 'R' followed by a
   consecutive number, e.g., R7.

1.6.1.  Overall Requirements

   One preexisting requirement that impacts all of the examples is this,
   and is driven by one of the principles of the system, which is that
   Users should neither need to know or care about the concept of
   "keys":

   R1:  Default Key removal and/or replacements MUST be possible from
      the application or external protocol level without the application
      or external protocol having to have knowledge of the specific
      Default Key, only the Identity or User.  Implementations use this
      information to determine which keys to reset.

1.6.2.  Example 1: Own Single Key Replacement with New Key

   A pEp User decides, for any reason, that they want to replace their
   current Default Key for one of their Identities.  The key MUST NOT be
   used by communication partners in the future.  The goal is to ensure
   the old key is invalid for future use by communications partners or
   adversaries.

   This creates the following additional requirements (in addition to R1
   above):

   R2:  The protocol MUST provide a mechanism at the cryptographic level
      (e.g., within the keyring) for the revocation of the Own Default
      Key associated with this Identity.

   R3:  The protocol MUST provide a mechanism for the generation of a
      new key pair corresponding to this Identity and to assign this key
      as the Identity default.

   R4:  If the key being replaced was also the User's Default Key, the
      new key generated by R3 above MUST replace the first key in the
      management database as the User Default Key.

   R5:  Communications partners MUST be informed, at the latest at the
      first reply to a message encrypted to the now-revoked key, of the
      revocation of the first key and its replacement with the second.



Hoeneisen                 Expires 19 June 2023                  [Page 9]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   R6:  The notification in R5 MUST include communication of both the
      revocation in R2 via a revocation certificate (signed by the now-
      revoked key) and the public part of the new key pair.

   R7:  The notification in R5 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).

   R8:  The notification in R5 MUST, at a minimum, be signed with the
      private key of the new key pair.

1.6.3.  Example 2: Device Compromise - Simple Case (Single Device)

   A pEp User is forced to unlock and give up their phone at the border.
   (The "device compromise" use case can happen in other ways, but we
   want to initially provide the simplest case, where the User recovers
   the same device after compromise.  Dealing with device compromise
   from another device is handled later).  They want to ensure that the
   keys on that phone are no longer valid for use in order to prevent
   unauthorized parties from decrypting their future communications or
   posing as an imposter, sending mails which can be falsely "verified"
   as them.

   This creates the following requirements:

   R9:  Expanding on R2 above, the protocol MUST provide a mechanism for
      the revocation of all Own Keys at the cryptographic engine level
      (i.e. within the keyring) associated with:

      1.  the User, and

      2.  all of the User's Identities

   R10:  Expanding on R3 above, the protocol MUST provide a mechanism
      for the generation of new keys corresponding to each impacted
      Identity and to assign them as new Default Keys for that
      corresponding Identity.

   R11:  The User Default Key MUST be replaced with one of the new
      Default Keys of the impacted Identities.

   R12:  For each newly-revoked key, communications partners MUST be
      informed from the corresponding Identity they have corresponded
      with of the revocation of the first key and replacement of the
      second according to R5-R8.






Hoeneisen                 Expires 19 June 2023                 [Page 10]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


1.6.4.  Example 3: Encryption to a Revoked pEp Partner Key

   A pEp User, Alice, has the public key of another pEp User, Bob. Bob
   has done a KeyReset of his Own Key, but Alice is not among the people
   he has yet notified of this change.  Because Alice does not know that
   Bob has a new key, the public key she uses to encrypt to him
   corresponds to a key he has already revoked and does not want others
   to use.  While the initial encryption to Bob using this key cannot be
   stopped, as Alice is unaware of its invalidity, Bob needs to be
   certain that on the next round of communication originating from
   Alice, she uses the correct new key to encrypt to him, replacing the
   older key as its default in the corresponding Bob Identity in her
   database.

   That said, if Alice and Bob have exchanged Trustwords and Bob's old
   key was trusted (creating a "green" channel in the parlance of the
   applications), Bob's new key should not retain this trust; rather,
   Alice and Bob should have to exchange Trustwords again to establish
   trust for this particular new key, while still maintaining other
   communications channel information, such as whether or not Bob is a
   pEp User.

   This creates the following additional requirements:

   R13:  The protocol MUST detect when a message has been sent to an Own
      Key that is revoked

   R14:  If such a message was sent by a pEp User, then the protocol
      MUST, as a response, generate and send a notification to the
      relevant partner as specified in R5-R8.

   The pEp communications partner must have the means to process and
   validate such a notification.  This creates the following relevant
   requirements:

   R15:  The protocol MUST provide the means for processing and
      validating notifications as specified in R5-R8.  This requires
      R16-R21:

   R16:  The protocol MUST verify that the notification contains at
      least one artifact signed by the now-revoked previous key.

   R17:  The protocol MUST process the revocation certificate of the
      sender, recording the revocation with the cryptographic engine and
      mistrusting the revoked key in the management database.  This
      certificate fulfills the requirements R5-R8 above.

   R18:  The protocol MUST verify that this revoked key corresponds to



Hoeneisen                 Expires 19 June 2023                 [Page 11]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


      the extant Default Key of the User.

   R19:  The protocol MUST verify that the replacement key is attached
      to the message and corresponds to the key information given in the
      received KeyReset message.

   R20:  The protocol MUST set the received key as the Default Key for
      the communications partner.

   R21:  The protocol MUST ensure that any trusted status gained by the
      previous exchange of Trustwords with the sending partner is
      removed; trusted status can only be set with the new key upon a
      new exchange of Trustwords.

1.6.5.  Example 4: Manually Changing Use of Incorrect Partner Key

   A pEp User has a key set as default for a communications partner that
   this partner does not want used for communication for a particular
   Address (and, thus, in pEp terms, a particular Identity).  However,
   that partner is not using, and may not have access to, the KeyReset
   mechanism for that key.  This could happen if the partner is an
   OpenPGP partner, if the partner only had their private key on one
   device which is now inaccessible to them, or if the partner does not
   intend to revoke that key, they simply do not want it used for the
   Address associated with the Identity in question.

   pEp needs to provide a mechanism for the User to manually indicate
   that this key should not be used as the default.

   This creates the following requirement:

   R22:  The protocol MUST provide a means for the User to manually
      remove the Default Key for a partner Identity.

   (Note that if there is a compromise indicated, the pEp protocol
   itself provides the means for Users to mistrust keys of their
   contacts, and that this is not an explicit part of manual KeyReset of
   partner keys.)

1.6.6.  Example 5: Removing Trust or Mistrust from Communications
        Partner Key

   A pEp User may have exchanged Trustwords with a partner and
   accidentally or intentionally confirmed them and want to rescind that
   decision.  Alternately, a pEp User may have mistrusted a partner key
   and want to rescind that decision.

   These two possibilities imply the following requirements:



Hoeneisen                 Expires 19 June 2023                 [Page 12]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   R23:  The protocol MUST provide a means for Users to reset trusted or
      mistrusted status for Default communications partner Keys.

1.6.7.  Example 6: KeySync: Reset Own Keys

   Note that this example requires understanding of the KeySync protocol
   (cf.  [I-D.pep-keysync]), which is out of scope for this document.
   Minimal key terms are defined in the glossary above.

   KeySync is a protocol which allows several of a User's different
   devices running pEp to synchronize and use the same private keys for
   synchronized Own Identities.  This group of devices is called a
   Device Group.

   A User may decide to reset one or more keys associated with
   Identities marked for synchronization.  The request for reset is done
   on a single device, but must be propagated to the other devices.
   Because this is an automated reset of Own private Keys initiated
   externally for the other devices, it has some additional special
   requirements for security reasons, in addition to R9-R12:

   R24:  The protocol MUST provide the means for notifying own devices
      of the reset of shared keys

   R25:  The protocol MUST provide the means for the initiating device
      to communicate KeyReset information in a message signed by one of
      the keys to be reset, which will still be valid from the recipient
      device point of view upon receipt

   R26:  The protocol MUST provide the means for the initiating device
      to fulfill R9-R12, while still fulfilling R25.

   R27:  The protocol MUST provide the means for communicating the
      following additional KeyReset information to non-initiating
      devices within the Device Group:

      1.  Identities impacted

      2.  New public/private key material for the respective replacement
          Default Keys and their binding

      3.  Mapping of old Defaults Keys to new keys

   R28:  The protocol MUST provide the means for receipt and
      verification of this reset communication by non-initiating devices
      in the Device Group, including ensuring signature by an Own,
      extant Key from one the synchronized Identities in the Device
      Group.



Hoeneisen                 Expires 19 June 2023                 [Page 13]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   R29:  The protocol MUST provide the means for the import and setting
      of these replacement keys according to their respective,
      Identities, along with local revocation of the Default Keys being
      replaced, according to R2 and R4 for each respective Identity, as
      well as enabling communications corresponding to R5-R8 when in
      receipt of messages to a revoked key.

   R30:  If initial opportunistic notification of recent contact
      partners is desired as part of the implementation, then the
      initiating device MUST perform the unsolicited notification to
      contact partners according to R12.

2.  Implementation

2.1.  Overview

   Note: In the following the term "application" refers to the part of
   the implementation that directly interacts with the User.  The
   "application" may be integrated in a whole implementation or be in a
   separate code base that interacts e.g., with an underlying library or
   "engine".  In the former case the term "application" refers to the
   code parts that directly interact with the User.

   This specification defines the functions addressing the requirements
   above.  It also includes high-level APIs.  The KeyReset protocol is
   divided into sender and receiver functions.  A KeyReset function
   affects either all of a User's Default Keys in the database or only
   the Default Key associated with a specific Identity.  These functions
   are further subdivided into those (in addition to local processing)
   also affecting peers (communication partners) and those affecting
   other devices of the same User (KeySync, cf. [I-D.pep-keysync]).

   These functions are opaque to the upper layers; any necessary
   communications MUST be dropped into the applications message queue
   directly by the protocol, and all underlying database manipulation,
   key generation, etc.  MUST be performed without further interaction
   with the application.

   The implementation MUST evaluate the input Identity (or Identities,
   if only the User is specified), determine whether it is an Own
   Identity or a partner Identity, and process the reset appropriately
   according to the requirements.  This includes management database
   manipulation, Default Key setting, and (where appropriate) key
   revocation, key generation, as well as sending of any initial
   KeyReset notification messages.






Hoeneisen                 Expires 19 June 2023                 [Page 14]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   On receiving KeyReset messages, the implementation MUST process the
   KeyReset messages - both from partner Identities and from Own
   Identities - and interact with them in accordance with the
   requirements above.

   Implementations MAY also provide a mechanism for opportunistic
   notification of recently contacted partners (where "recently
   contacted" indicates contacts originating from the User, i.e. not
   received communications) at the time an Own Key Reset is made.  Such
   a mechanism can speed up the process of appropriate key usage by
   frequent communications partners, as there is no delay until the
   first message encrypted with a revoked key is received and replied
   to.

2.2.  Functions

2.2.1.  Sending Side

2.2.1.1.  Key Reset Identity

      key_reset_identity(pEp_SESSION session, pEp_identity* ident, const
      char* fpr)

   This function resets the default management database status for the
   Identity / key pair provided: The key identified by fpr MUST be
   removed as a Default Key for this identity and any trusted or
   mistrusted status MUST be removed from the trust database for this
   key and this Identity's User.  If the Identity provided corresponds
   to an Own Identity and a private key, this key MUST be revoked, a new
   key MUST be generated, and the reset MUST be communicated to recently
   contacted pEp partners for this Identity.

   If fpr is empty, then whatever key is set as the default for this
   Identity MUST be treated as above.  Note that if the KeyReset by this
   function is the default for any other User or Identity, it MUST be
   unset as the default for that Identity.

2.2.1.2.  Key Reset User

      key_reset_user(pEp_SESSION session, const char* user_id, const
      char* fpr)

   This function effectively applies the function key_reset_identity()
   (cf.  Section 2.2.1.1) to a series of Identities corresponding to the
   User (as indicated by user_id), as follows:

   1.  If the User is a communications partner (not the Own User):




Hoeneisen                 Expires 19 June 2023                 [Page 15]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


       1.  If the key identified by fpr is present, key_reset_identity()
           (cf.  Section 2.2.1.1) MUST be applied for each of the
           partner's Identities containing fpr as the Default Key.

       2.  Otherwise, a key_reset_identity() (cf.  Section 2.2.1.1) MUST
           be performed on ALL of the partner's Identities corresponding
           to their user_id (with an empty fpr as defined in
           Section 2.2.1.1).

   2.  If the user_id indicates the Own User:

   3.  If the key identified by fpr is present, key_reset_identity()
       (cf.  Section 2.2.1.1) MUST be applied for each of the partner's
       Identities containing fpr as the Default Key.  Note: The
       functionality is the same with the communications partner case
       (see above).

   4.  Otherwise the function key_reset_all_own_keys() (cf.
       Section 2.2.1.3) MUST be executed.

   Note: key_reset_identity() (cf.  Section 2.2.1.1) and
   key_reset_all_own_keys() (cf.  Section 2.2.1.3) MUST also unset as
   default every key which is reset, for all Users and Identities.

2.2.1.3.  Key Reset All Own Keys

      key_reset_all_own_keys(pEp_SESSION session)

   This function MUST revoke and mistrust all Own Keys, generate new
   keys for all Own Identities, and MAY opportunistically communicate
   KeyReset information to people we have recently contacted.  This
   function effectively performs the work of key_reset_identity() (cf.
   Section 2.2.1.1) for every Own Identity and Own Default Key.

   Note that if any Identities share one of these Own Keys as their
   Default Key, they will each have different (separate) new Default
   Keys after completion.

2.2.1.4.  Key Reset Own Grouped Keys

      key_reset_own_grouped_keys(pEp_SESSION session)

   This function is, on the surface, like key_reset_all_own_keys() (cf.
   Section 2.2.1.3), however it MUST be applied to (and only to) the
   Default Keys for Identities that are marked for synchronization as
   part of a KeySync (cf.  [I-D.pep-keysync]) Device Group.
   Furthermore, because of the fact that these are synchronized
   Identities, this function performs some additional work.



Hoeneisen                 Expires 19 June 2023                 [Page 16]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   In addition to what is defined in key_reset_all_own_keys() (cf.
   Section 2.2.1.3), this function MUST create a special KeyReset
   message to be used internally in order to communicate to each grouped
   device the following information:

   1.  The Identity whose Default Key is to be revoked

   2.  The Default Key for each corresponding Identity to revoke

   3.  The new Default Key which will replace each Default Key (for each
       corresponding Identity)

   4.  The public/private key pair for each corresponding replacement
       key

   This whole message MUST be encrypted to and, more importantly, signed
   by one of the device group's current valid keys at the time the reset
   function is called.  This function MUST first produce and sign this
   KeyReset message, and then perform (on the caller device) the
   revocation functionality associated with KeyReset of Own Keys and
   replace them with the new defaults it generated and sent.

   The device on which this function is called is the sole device
   responsible for communicating any opportunistic KeyReset messages to
   partners as described in the requirements section above.

2.2.2.  Receiving Side

2.2.2.1.  Processing Received key_reset_identity() and key_reset_user()
          Messages

   Practically speaking, from the receiver point of view, this will only
   involve individual messages issued by function key_reset_identity()
   (cf.  Section 2.2.1.1).

   For any given message, the recipient MUST verify that:

   1.  there is an extant matching Identity,

   2.  they have the key being reset in their keyring,

   3.  if the key is present, that they have imported a revocation
       (which implies an object signed by the known private key of the
       sender)

   4.  that the public part of the replacement key indicated in the
       KeyReset message is attached and imported




Hoeneisen                 Expires 19 June 2023                 [Page 17]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   If all of these conditions are true, the recipient MUST replace the
   new key as the default for this Identity in their database and
   mistrust the revoked key.

   Note that if the reset key is not the Default Key for this Identity,
   the database will not change, but the revocation certificate will be
   imported as well as the new key.  This means that if another Identity
   contains the to-be-replaced key as a Default Key, it will not be
   valid; however, it will not be unset as the Default Key for that
   Identity until the engine tries to use it, and it will not be
   replaced by the newly-sent key unless a specific KeyReset message is
   received for that Identity indicating it should do so.

2.2.2.2.  Processing Received key_reset_own_grouped_keys() Messages

   Processing received key_reset_own_grouped_keys() (cf.
   Section 2.2.1.4) messages is perhaps the most security-critical part
   of the protocol from the User's perspective, as it is processed
   automatically, it changes the User's Default private Keys, and it
   revokes their extant private keys.

   When receiving a key_reset_own_grouped_keys() (cf.  Section 2.2.1.4)
   message, the implementation MUST verify that the key used to sign the
   message corresponds to the Default Own Identity it was sent from,
   that the corresponding key is still valid, and that it contains a
   private key.  Note that because key_reset_own_grouped_keys() (cf.
   Section 2.2.1.4) does not send revocation certificates, but rather
   references to these keys to devices in the Device Group indicating
   which keys to replace and revoke locally, this key will still be
   valid if it is an actionable and correct own grouped KeyReset
   message.

   Should this be the case, for every transmitted Identity and
   replacement key pair, the recipient device MUST revoke the old key
   for that Identity and replace it with the indicated new key (instead
   of generating a new key).  Recipient devices MUST not send out
   KeyReset notifications to partners, as this is handled by the device
   that generated the reset message.

   These new keys MUST then be trusted as new keys and operation can
   continue as normal.

2.2.3.  DDL Impacts

   Implementation requires the following features, many of which were
   present before KeyReset was implemented:





Hoeneisen                 Expires 19 June 2023                 [Page 18]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   1.  A social_graph table, binding partner Identities with the
       addresses the User has contacted them from.  This is to avoid
       exposing Own User aliases to the partner when sending KeyReset
       messages and ensures there is a match between the Address the
       reset is for and the Identity the partner associates with the key
       to be reset on the recipient end.  Note that only Identities the
       User as proactively contacted themselves are contained in this
       table, an important note for 2).

   2.  Timestamps on Identities indicating recent access or update.
       This is used to filter which partners to opportunistically
       contact.  Note that only Identities which the User has
       intentionally communicated with (rather than just receiving a
       message from) will be sent these opportunistic messages; this is
       to prevent spammers from receiving KeyReset messages.

   Other tables and fields (e.g., main_key_fpr for Identity Default
   Keys, etc) are already integral to the system and are used here, but
   their DDL semantics remain unaltered.

2.3.  Protocol Descriptions with Examples

   In this section, we take the indicated use cases from the
   requirements section and show how the protocol operates.

2.3.1.  Example 1: Own Single Key Replacement with New Key

   Recall that the pEp User, in this example, wants to replace one
   Default Key from one Identity.

   The application must provide a way for the user to select the
   Identity (presumably by Address) they wish to reset.  Since the
   application does not keep track of the Default Key for that Address,
   but does have a constant representation of the own user_id, it will
   call key_reset_identity with the session argument, the appropriate
   Own Identity, and an empty fpr.

   The implementation then:

   1.  retrieves the Own Identity, including the Default Key
       fingerprint, and

   2.  if it is not already revoked and contains a private key:

       1.   tells the cryptographic engine to revoke the private key,

       2.   asks the cryptographic engine to generate a new public/
            private key pair,



Hoeneisen                 Expires 19 June 2023                 [Page 19]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


       3.   records the binding of the revoked key and its replacement
            in the key management database,

       4.   sets the new key as the Identity default,

       5.   replaces the User Default Key with the new one if the
            Identity Default Key and the User Default Key were the same,

       6.   mistrusts the old key in the management database,

       7.   repeats ii-vi for any other Own Identity for which this key
            was the default,

       8.   searches the Identity database for any Identities in the
            social graph which have been actively contacted by this
            Identity and whose Identities have been updated in the last
            two weeks,

       9.   generates KeyReset messages as described in requirements
            R5-R8 for each of those Identities from the reset Identity,
            and

       10.  places those messages into the application message queue,
            which is sent in at session initialization (if there is no
            message queue present, no messages are sent).

2.3.2.  Example 2: Device Compromise - Simple Case (Single Device)

   This example featured a pEp User which wanted to reset all of their
   Own Keys on their single, ungrouped device and wished to invalidate
   their keys for future use.

   In this case, the application provides a mechanism for the User to
   simply reset all Own Keys.  This will call key_reset_all_own_keys()
   with the current session as the argument.

   The engine will then use its knowledge of its own user_id to fetch
   all Own Identities, and then, for each Own Identity, proceed as in
   step 2 of Example 1 above.

2.3.3.  Example 3: Encryption to Revoked pEp Partner Key

   In this example, a pEp User, Alice, only has an outdated key from her
   pEp communications partner, Bob. Bob has revoked the key, but Alice
   is unaware of it, and so sends Bob a message encrypted to the key he
   has revoked.





Hoeneisen                 Expires 19 June 2023                 [Page 20]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   Bob, who still has the revoked key in his keyring and can decrypt
   with it, decrypts and verifies Alice's message as usual.  However, in
   decrypt_message(), the engine notes that Alice is using one of Bob's
   revoked, mistrusted keys.

   The engine looks up the revoked key in the database.  If its
   replacement key is his current default, it creates a KeyReset message
   for Alice containing the revocation certificate of the old key (this
   can be done by just sending the revoked key, which contains the
   revocation certificate), his new key along with the specified
   KeyReset information.

   If, however, the engine notes that the key that replaced his revoked
   key is also revoked, it follows the chain of replacements until it
   finds the current valid Default Key and uses this in the KeyReset
   message.

   Alice then receives Bob's message.  On decrypting his message, the
   engine will import both the new key and the revocation certificate.
   On processing the KeyReset message, the engine will, if it notes that
   the old key is now revoked in her keyring and the message is signed
   by the new key, mistrust Bob's old Default Key and replace the
   Default Key for Bob's respective Identity with the new key; however,
   no trust status will carry over to the new key.

   If Alice wishes to trust Bob's new key, she will contact Bob on a
   side channel and exchange Trustwords for their combined public keys
   and set the trust for the new key pair if she can verify them.

2.3.4.  Example 4: Manually Changing Use of Incorrect Partner Key

   There are two likely scenarios which generate this use case: Bob is
   an OpenPGP user with several keys, and Alice's pEp installation has
   chosen to make the wrong one the default, or perhaps Bob is a pEp
   User who has reinstalled his client several times without resetting
   keys, and thus has partners who have an unusable (for Bob) public key
   for him.

   In either event, Bob contacts Alice and says, "Hey, I need you to
   stop using that public key" in the first case, or in the second,
   "Hey, I can't decrypt the messages you sent me."










Hoeneisen                 Expires 19 June 2023                 [Page 21]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   In both cases, the application provides the means for Alice to either
   reset an Identity or reset the User (note that in engine parlance
   this is resetting the key of the Identity or User, but the
   application does not keep track of keys).  Presuming the application
   allows resets at the Identity level of granularity (e.g., contact
   address rather than contact), it will call key_reset_identity() with
   Bob's Identity and an empty fpr.

   The engine will then see that this is a partner Identity and remove
   the current Default Key as the default as well as resetting its trust
   status in the database.  This will leave an empty default.

   If, on the other hand, only the User (e.g., the User's keys) is
   available as a reset option in the application UI, the application
   will call key_reset_user with Bob's user_id and an empty fpr.  This
   will repeat the process above for individual Identities for each of
   Bob's known Identities.

   Bob should then mail Alice again.  If he is mailing from a pEp
   client, he will automatically attach his new key and it should be
   selected as the default on receipt.  If it was a full User reset, he
   will at some point need to mail from all impacted accounts in order
   to ensure Alice has keys for each.  If Alice and Bob wish to trust
   these keys, they must exchange Trustwords (possibly again) for each
   impacted Identity.

   If Bob is mailing from an OpenPGP client, he should simply attach his
   key to a message and mail Alice at his earliest convenience.

2.3.4.1.  Example 5: Removing Trust or Mistrust From Communications
          Partner Key

   Recall that this involves a User wanting to reset the trusted or
   mistrusted status of a communications partner Identity.

   The application must provide the means for the User to select an
   Identity whose trust should be reset.  This functionality should call
   key_reset_identity() or key_reset_user() as in example 4 and will
   take the same steps with the same remedy.

2.3.4.2.  Example 6: KeySync: Reset Own Keys

   In this example, the User wishes to reset the synchronized keys in a
   Device Group using KeySync (cf.  [I-D.pep-keysync]).







Hoeneisen                 Expires 19 June 2023                 [Page 22]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   There are a couple of examples where this could happen - a grouped
   device is reset with reset_all_own_keys(), and some of the Identities
   corresponding to some keys are marked for synchronization, or as an
   internal function, a device leaves a Device Group and the remaining
   member devices need to revoke old keys and set new ones.

2.3.4.2.1.  Manual Reset of Grouped Keys

   In the first case, reset_all_own_keys() separates out the Identities
   which are synchronized Identities and which ones are non-synchronized
   Identities.  Non-synchronized Identities are subjected to the same
   treatment as examples 1/2.  The remaining Identities are processed
   with key_reset_own_grouped_keys(); through this function, the engine
   collects all Identities which are marked for synchronization and
   proceeds as specified in key_reset_own_grouped_keys() (from the
   initiating device) and the processing description for KeyReset
   messages generated by key_reset_own_grouped_keys() (for the recipient
   devices).

2.3.4.2.2.  Leaving a Device Group

   In the case where the User decides to take a device out of a Device
   Group, this part of the protocol becomes more complicated.  We divide
   the actors, at first, into two groups: the leaver, and the remaining
   group.

   When the leaving device calls leave_device_group() within the KeySync
   protocol, two sets of events are triggered, one set for the leaving
   device, and one for the remaining group.

   The leaving device notifies the group it is leaving, unmarks all of
   its Identities for synchronization, and then resets all of them
   locally via key_reset_user() and proceeds as with Example 2.

   The group, on the other hand, chooses a leader.  This leader calls
   key_reset_own_grouped_keys() and both the leader, as the initiating
   device, and the rest of the group, as recipient devices, proceed as
   under manual reset of grouped keys above in this example.

3.  Security Considerations

   The Privacy Considerations outlined in Section 4 may also impose
   risks to security.  In particular a compromised private key may be
   misused (e.g. impersonation) and remain undetected until the
   communication partner (and all its devices) gets aware of the
   KeyReset (see also Section 4).





Hoeneisen                 Expires 19 June 2023                 [Page 23]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


4.  Privacy Considerations

   KeyReset messages are not sent immediately to all communication
   partners, which may use the revoked key.  Thus, there is a period of
   time during which incoming communication from peers, that did not get
   a KeyReset message yet, may no longer be private.  To mitigate this
   risk, implementations should provide a mechanism for sending instant
   KeyReset notifications to previously contacted communication partners
   (cf.  Section 2.1).

   In case a communication partner uses two or more devices that are not
   part of a Device Group for KeySync (cf.  [I-D.pep-keysync]), the
   KeyReset messages may be consumed by one device of a User, while the
   other devices remain unaware of the KeyReset (at least until they
   have a chance to consume a follow-up KeyReset message).  As a
   consequence, incoming communication from such peers may no longer be
   private (at least for some time).  To mitigate this risk implementers
   should implement pEp KeySync and Users should be advised to form
   Device Groups with all their devices.

   Depending on the implementation of the peer, communication partners
   may not be able to consume a KeyReset message and act on it.  As a
   consequence such communication partners continue to use keys that
   have been reset so that incoming communication from such peers may no
   longer be private.  This concerns mainly non-pEp implementations, but
   also pEp implementations that have not implemented pEp KeyReset.

   Note: The above mentioned issues exist similarly also with other
   encryption protocols, when a key is compromised and peers are unaware
   of it.

5.  IANA Considerations

   This document has no actions for IANA.

6.  Acknowledgments

   The concept of KeyReset was invented and further developed by Volker
   Birk.

   A substantial amount of content taken over to this document has been
   originally drafted by Krista Bennett.

   Additionally, the authors would like to thank the following people
   who provided substantial contributions, helpful comments or
   suggestions for this document: Hernani Marques, Linda Carmen Schmid,
   and Luca Saiu.




Hoeneisen                 Expires 19 June 2023                 [Page 24]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   This work was initially created by pEp Foundation, and then reviewed
   and extended with funding by the Internet Society's Beyond the Net
   Programme on standardizing pEp.  [ISOC.bnet]

7.  References

7.1.  Normative References

   [I-D.pep-general]
              Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy
              privacy (pEp): Privacy by Default", Work in Progress,
              Internet-Draft, draft-pep-general-01, 21 October 2022,
              <https://www.ietf.org/archive/id/draft-pep-general-
              01.txt>.

   [I-D.pep-keysync]
              Birk, V., Hoeneisen, B., and K. Bristol, "pretty Easy
              privacy (pEp): Key Synchronization Protocol (KeySync)",
              Work in Progress, Internet-Draft, draft-pep-keysync-02, 13
              July 2020, <https://www.ietf.org/archive/id/draft-pep-
              keysync-02.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <https://www.rfc-editor.org/info/rfc7435>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [I-D.pep-email]
              Marques, H., "pretty Easy privacy (pEp): Email Formats and
              Protocols", Work in Progress, Internet-Draft, draft-pep-
              email-01, 2 November 2020,
              <https://www.ietf.org/archive/id/draft-pep-email-01.txt>.





Hoeneisen                 Expires 19 June 2023                 [Page 25]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   [I-D.pep-handshake]
              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
              Contact and Channel Authentication through Handshake",
              Work in Progress, Internet-Draft, draft-marques-pep-
              handshake-05, 8 July 2020,
              <https://www.ietf.org/archive/id/draft-marques-pep-
              handshake-05.txt>.

   [I-D.pep-trustwords]
              Hoeneisen, B. and H. Marques, "IANA Registration of
              Trustword Lists: Guide, Template and IANA Considerations",
              Work in Progress, Internet-Draft, draft-birk-pep-
              trustwords-05, 9 January 2020,
              <https://www.ietf.org/archive/id/draft-birk-pep-
              trustwords-05.txt>.

   [ISOC.bnet]
              Simao, I., "Beyond the Net. 12 Innovative Projects
              Selected for Beyond the Net Funding. Implementing Privacy
              via Mass Encryption: Standardizing pretty Easy privacy's
              protocols", June 2017, <https://www.internetsociety.org/
              blog/2017/06/12-innovative-projects-selected-for-beyond-
              the-net-funding/>.

Appendix A.  Document Changelog

   [[ RFC Editor: This section is to be removed before publication ]]

   *  draft-pep-keyreset-00:

      -  Initial version

Appendix B.  Open Issues

   [[ RFC Editor: This section should be empty and is to be removed
   before publication ]]

   *  Check whether in IETF there is a concept of "technical messages",
      i.e. messages that are meant for the client, but not for the User.

Author's Address

   Bernie Hoeneisen
   pEp Foundation
   Oberer Graben 4
   CH- 8400 Winterthur
   Switzerland
   Email: bernie.hoeneisen@pep.foundation



Hoeneisen                 Expires 19 June 2023                 [Page 26]

Internet-Draft     pretty Easy privacy (pEp) Key Reset     December 2022


   URI:   https://pep.foundation/


















































Hoeneisen                 Expires 19 June 2023                 [Page 27]