self hydra?
authorBernie Hoeneisen <b@hoeneisen.ch>
Mon, 04 Nov 2019 22:57:49 +0100
changeset 119888beea5440f5
parent 1197 ba804933c4f8
parent 1195 9ed6bffbe529
child 1199 897f859f2a36
self hydra?
     1.1 --- a/pep/Makefile	Mon Nov 04 22:53:17 2019 +0100
     1.2 +++ b/pep/Makefile	Mon Nov 04 22:57:49 2019 +0100
     1.3 @@ -1,7 +1,7 @@
     1.4  #!/usr/bin/make -f
     1.5  
     1.6  NAME := draft-birk-pep
     1.7 -REV := 05
     1.8 +REV := 06
     1.9  DRAFT := $(NAME)-$(REV)
    1.10  
    1.11  OUTPUTS = $(DRAFT).xml $(DRAFT).txt $(DRAFT).html
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/pep/archive/draft-birk-pep-05.html	Mon Nov 04 22:57:49 2019 +0100
     2.3 @@ -0,0 +1,1590 @@
     2.4 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
     2.5 +  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
     2.6 +
     2.7 +<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     2.8 +<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     2.9 +  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
    2.10 +
    2.11 +  <title>pretty Easy privacy (pEp): Privacy by Default</title>
    2.12 +
    2.13 +  <style type="text/css" title="Xml2Rfc (sans serif)">
    2.14 +  /*<![CDATA[*/
    2.15 +	  a {
    2.16 +	  text-decoration: none;
    2.17 +	  }
    2.18 +      /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
    2.19 +      a.info {
    2.20 +          /* This is the key. */
    2.21 +          position: relative;
    2.22 +          z-index: 24;
    2.23 +          text-decoration: none;
    2.24 +      }
    2.25 +      a.info:hover {
    2.26 +          z-index: 25;
    2.27 +          color: #FFF; background-color: #900;
    2.28 +      }
    2.29 +      a.info span { display: none; }
    2.30 +      a.info:hover span.info {
    2.31 +          /* The span will display just on :hover state. */
    2.32 +          display: block;
    2.33 +          position: absolute;
    2.34 +          font-size: smaller;
    2.35 +          top: 2em; left: -5em; width: 15em;
    2.36 +          padding: 2px; border: 1px solid #333;
    2.37 +          color: #900; background-color: #EEE;
    2.38 +          text-align: left;
    2.39 +      }
    2.40 +	  a.smpl {
    2.41 +	  color: black;
    2.42 +	  }
    2.43 +	  a:hover {
    2.44 +	  text-decoration: underline;
    2.45 +	  }
    2.46 +	  a:active {
    2.47 +	  text-decoration: underline;
    2.48 +	  }
    2.49 +	  address {
    2.50 +	  margin-top: 1em;
    2.51 +	  margin-left: 2em;
    2.52 +	  font-style: normal;
    2.53 +	  }
    2.54 +	  body {
    2.55 +	  color: black;
    2.56 +	  font-family: verdana, helvetica, arial, sans-serif;
    2.57 +	  font-size: 10pt;
    2.58 +	  max-width: 55em;
    2.59 +	  
    2.60 +	  }
    2.61 +	  cite {
    2.62 +	  font-style: normal;
    2.63 +	  }
    2.64 +	  dd {
    2.65 +	  margin-right: 2em;
    2.66 +	  }
    2.67 +	  dl {
    2.68 +	  margin-left: 2em;
    2.69 +	  }
    2.70 +	
    2.71 +	  ul.empty {
    2.72 +	  list-style-type: none;
    2.73 +	  }
    2.74 +	  ul.empty li {
    2.75 +	  margin-top: .5em;
    2.76 +	  }
    2.77 +	  dl p {
    2.78 +	  margin-left: 0em;
    2.79 +	  }
    2.80 +	  dt {
    2.81 +	  margin-top: .5em;
    2.82 +	  }
    2.83 +	  h1 {
    2.84 +	  font-size: 14pt;
    2.85 +	  line-height: 21pt;
    2.86 +	  page-break-after: avoid;
    2.87 +	  }
    2.88 +	  h1.np {
    2.89 +	  page-break-before: always;
    2.90 +	  }
    2.91 +	  h1 a {
    2.92 +	  color: #333333;
    2.93 +	  }
    2.94 +	  h2 {
    2.95 +	  font-size: 12pt;
    2.96 +	  line-height: 15pt;
    2.97 +	  page-break-after: avoid;
    2.98 +	  }
    2.99 +	  h3, h4, h5, h6 {
   2.100 +	  font-size: 10pt;
   2.101 +	  page-break-after: avoid;
   2.102 +	  }
   2.103 +	  h2 a, h3 a, h4 a, h5 a, h6 a {
   2.104 +	  color: black;
   2.105 +	  }
   2.106 +	  img {
   2.107 +	  margin-left: 3em;
   2.108 +	  }
   2.109 +	  li {
   2.110 +	  margin-left: 2em;
   2.111 +	  margin-right: 2em;
   2.112 +	  }
   2.113 +	  ol {
   2.114 +	  margin-left: 2em;
   2.115 +	  margin-right: 2em;
   2.116 +	  }
   2.117 +	  ol p {
   2.118 +	  margin-left: 0em;
   2.119 +	  }
   2.120 +	  p {
   2.121 +	  margin-left: 2em;
   2.122 +	  margin-right: 2em;
   2.123 +	  }
   2.124 +	  pre {
   2.125 +	  margin-left: 3em;
   2.126 +	  background-color: lightyellow;
   2.127 +	  padding: .25em;
   2.128 +	  }
   2.129 +	  pre.text2 {
   2.130 +	  border-style: dotted;
   2.131 +	  border-width: 1px;
   2.132 +	  background-color: #f0f0f0;
   2.133 +	  width: 69em;
   2.134 +	  }
   2.135 +	  pre.inline {
   2.136 +	  background-color: white;
   2.137 +	  padding: 0em;
   2.138 +	  }
   2.139 +	  pre.text {
   2.140 +	  border-style: dotted;
   2.141 +	  border-width: 1px;
   2.142 +	  background-color: #f8f8f8;
   2.143 +	  width: 69em;
   2.144 +	  }
   2.145 +	  pre.drawing {
   2.146 +	  border-style: solid;
   2.147 +	  border-width: 1px;
   2.148 +	  background-color: #f8f8f8;
   2.149 +	  padding: 2em;
   2.150 +	  }
   2.151 +	  table {
   2.152 +	  margin-left: 2em;
   2.153 +	  }
   2.154 +	  table.tt {
   2.155 +	  vertical-align: top;
   2.156 +	  }
   2.157 +	  table.full {
   2.158 +	  border-style: outset;
   2.159 +	  border-width: 1px;
   2.160 +	  }
   2.161 +	  table.headers {
   2.162 +	  border-style: outset;
   2.163 +	  border-width: 1px;
   2.164 +	  }
   2.165 +	  table.tt td {
   2.166 +	  vertical-align: top;
   2.167 +	  }
   2.168 +	  table.full td {
   2.169 +	  border-style: inset;
   2.170 +	  border-width: 1px;
   2.171 +	  }
   2.172 +	  table.tt th {
   2.173 +	  vertical-align: top;
   2.174 +	  }
   2.175 +	  table.full th {
   2.176 +	  border-style: inset;
   2.177 +	  border-width: 1px;
   2.178 +	  }
   2.179 +	  table.headers th {
   2.180 +	  border-style: none none inset none;
   2.181 +	  border-width: 1px;
   2.182 +	  }
   2.183 +	  table.left {
   2.184 +	  margin-right: auto;
   2.185 +	  }
   2.186 +	  table.right {
   2.187 +	  margin-left: auto;
   2.188 +	  }
   2.189 +	  table.center {
   2.190 +	  margin-left: auto;
   2.191 +	  margin-right: auto;
   2.192 +	  }
   2.193 +	  caption {
   2.194 +	  caption-side: bottom;
   2.195 +	  font-weight: bold;
   2.196 +	  font-size: 9pt;
   2.197 +	  margin-top: .5em;
   2.198 +	  }
   2.199 +	
   2.200 +	  table.header {
   2.201 +	  border-spacing: 1px;
   2.202 +	  width: 95%;
   2.203 +	  font-size: 10pt;
   2.204 +	  color: white;
   2.205 +	  }
   2.206 +	  td.top {
   2.207 +	  vertical-align: top;
   2.208 +	  }
   2.209 +	  td.topnowrap {
   2.210 +	  vertical-align: top;
   2.211 +	  white-space: nowrap; 
   2.212 +	  }
   2.213 +	  table.header td {
   2.214 +	  background-color: gray;
   2.215 +	  width: 50%;
   2.216 +	  }
   2.217 +	  table.header a {
   2.218 +	  color: white;
   2.219 +	  }
   2.220 +	  td.reference {
   2.221 +	  vertical-align: top;
   2.222 +	  white-space: nowrap;
   2.223 +	  padding-right: 1em;
   2.224 +	  }
   2.225 +	  thead {
   2.226 +	  display:table-header-group;
   2.227 +	  }
   2.228 +	  ul.toc, ul.toc ul {
   2.229 +	  list-style: none;
   2.230 +	  margin-left: 1.5em;
   2.231 +	  margin-right: 0em;
   2.232 +	  padding-left: 0em;
   2.233 +	  }
   2.234 +	  ul.toc li {
   2.235 +	  line-height: 150%;
   2.236 +	  font-weight: bold;
   2.237 +	  font-size: 10pt;
   2.238 +	  margin-left: 0em;
   2.239 +	  margin-right: 0em;
   2.240 +	  }
   2.241 +	  ul.toc li li {
   2.242 +	  line-height: normal;
   2.243 +	  font-weight: normal;
   2.244 +	  font-size: 9pt;
   2.245 +	  margin-left: 0em;
   2.246 +	  margin-right: 0em;
   2.247 +	  }
   2.248 +	  li.excluded {
   2.249 +	  font-size: 0pt;
   2.250 +	  }
   2.251 +	  ul p {
   2.252 +	  margin-left: 0em;
   2.253 +	  }
   2.254 +	
   2.255 +	  .comment {
   2.256 +	  background-color: yellow;
   2.257 +	  }
   2.258 +	  .center {
   2.259 +	  text-align: center;
   2.260 +	  }
   2.261 +	  .error {
   2.262 +	  color: red;
   2.263 +	  font-style: italic;
   2.264 +	  font-weight: bold;
   2.265 +	  }
   2.266 +	  .figure {
   2.267 +	  font-weight: bold;
   2.268 +	  text-align: center;
   2.269 +	  font-size: 9pt;
   2.270 +	  }
   2.271 +	  .filename {
   2.272 +	  color: #333333;
   2.273 +	  font-weight: bold;
   2.274 +	  font-size: 12pt;
   2.275 +	  line-height: 21pt;
   2.276 +	  text-align: center;
   2.277 +	  }
   2.278 +	  .fn {
   2.279 +	  font-weight: bold;
   2.280 +	  }
   2.281 +	  .hidden {
   2.282 +	  display: none;
   2.283 +	  }
   2.284 +	  .left {
   2.285 +	  text-align: left;
   2.286 +	  }
   2.287 +	  .right {
   2.288 +	  text-align: right;
   2.289 +	  }
   2.290 +	  .title {
   2.291 +	  color: #990000;
   2.292 +	  font-size: 18pt;
   2.293 +	  line-height: 18pt;
   2.294 +	  font-weight: bold;
   2.295 +	  text-align: center;
   2.296 +	  margin-top: 36pt;
   2.297 +	  }
   2.298 +	  .vcardline {
   2.299 +	  display: block;
   2.300 +	  }
   2.301 +	  .warning {
   2.302 +	  font-size: 14pt;
   2.303 +	  background-color: yellow;
   2.304 +	  }
   2.305 +	
   2.306 +	
   2.307 +	  @media print {
   2.308 +	  .noprint {
   2.309 +		display: none;
   2.310 +	  }
   2.311 +	
   2.312 +	  a {
   2.313 +		color: black;
   2.314 +		text-decoration: none;
   2.315 +	  }
   2.316 +	
   2.317 +	  table.header {
   2.318 +		width: 90%;
   2.319 +	  }
   2.320 +	
   2.321 +	  td.header {
   2.322 +		width: 50%;
   2.323 +		color: black;
   2.324 +		background-color: white;
   2.325 +		vertical-align: top;
   2.326 +		font-size: 12pt;
   2.327 +	  }
   2.328 +	
   2.329 +	  ul.toc a::after {
   2.330 +		content: leader('.') target-counter(attr(href), page);
   2.331 +	  }
   2.332 +	
   2.333 +	  ul.ind li li a {
   2.334 +		content: target-counter(attr(href), page);
   2.335 +	  }
   2.336 +	
   2.337 +	  .print2col {
   2.338 +		column-count: 2;
   2.339 +		-moz-column-count: 2;
   2.340 +		column-fill: auto;
   2.341 +	  }
   2.342 +	  }
   2.343 +	
   2.344 +	  @page {
   2.345 +	  @top-left {
   2.346 +		   content: "Internet-Draft"; 
   2.347 +	  } 
   2.348 +	  @top-right {
   2.349 +		   content: "December 2010"; 
   2.350 +	  } 
   2.351 +	  @top-center {
   2.352 +		   content: "Abbreviated Title";
   2.353 +	  } 
   2.354 +	  @bottom-left {
   2.355 +		   content: "Doe"; 
   2.356 +	  } 
   2.357 +	  @bottom-center {
   2.358 +		   content: "Expires June 2011"; 
   2.359 +	  } 
   2.360 +	  @bottom-right {
   2.361 +		   content: "[Page " counter(page) "]"; 
   2.362 +	  } 
   2.363 +	  }
   2.364 +	
   2.365 +	  @page:first { 
   2.366 +		@top-left {
   2.367 +		  content: normal;
   2.368 +		}
   2.369 +		@top-right {
   2.370 +		  content: normal;
   2.371 +		}
   2.372 +		@top-center {
   2.373 +		  content: normal;
   2.374 +		}
   2.375 +	  }
   2.376 +  /*]]>*/
   2.377 +  </style>
   2.378 +
   2.379 +  <link href="#rfc.toc" rel="Contents">
   2.380 +<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
   2.381 +<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Relationship to other pEp documents">
   2.382 +<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Requirements Language">
   2.383 +<link href="#rfc.section.1.3" rel="Chapter" title="1.3 Terms">
   2.384 +<link href="#rfc.section.2" rel="Chapter" title="2 Protocol&#8217;s Core Design Principles">
   2.385 +<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Privacy by Default">
   2.386 +<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Data Minimization">
   2.387 +<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Interoperability">
   2.388 +<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Peer-to-Peer">
   2.389 +<link href="#rfc.section.2.5" rel="Chapter" title="2.5 User Interaction">
   2.390 +<link href="#rfc.section.3" rel="Chapter" title="3 Identity System">
   2.391 +<link href="#rfc.section.3.1" rel="Chapter" title="3.1 User">
   2.392 +<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Address">
   2.393 +<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Key">
   2.394 +<link href="#rfc.section.3.4" rel="Chapter" title="3.4 Identity">
   2.395 +<link href="#rfc.section.4" rel="Chapter" title="4 Key Management">
   2.396 +<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Key Generation">
   2.397 +<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Private Keys">
   2.398 +<link href="#rfc.section.4.2.1" rel="Chapter" title="4.2.1 Storage">
   2.399 +<link href="#rfc.section.4.2.2" rel="Chapter" title="4.2.2 Passphrase">
   2.400 +<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Key Reset">
   2.401 +<link href="#rfc.section.4.4" rel="Chapter" title="4.4 Public Key Distribution">
   2.402 +<link href="#rfc.section.4.4.1" rel="Chapter" title="4.4.1 UX Considerations">
   2.403 +<link href="#rfc.section.4.4.2" rel="Chapter" title="4.4.2 No addition of unnecessary metadata">
   2.404 +<link href="#rfc.section.4.4.3" rel="Chapter" title="4.4.3 No centralized public key storage or retrieval by default">
   2.405 +<link href="#rfc.section.4.4.4" rel="Chapter" title="4.4.4 Example message flow">
   2.406 +<link href="#rfc.section.4.5" rel="Chapter" title="4.5 Key Reset">
   2.407 +<link href="#rfc.section.5" rel="Chapter" title="5 Trust Management">
   2.408 +<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Privacy Status">
   2.409 +<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Handshake">
   2.410 +<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Trust Rating">
   2.411 +<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Trust Revoke">
   2.412 +<link href="#rfc.section.6" rel="Chapter" title="6 Synchronization">
   2.413 +<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Private Key Synchronization">
   2.414 +<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Trust Synchronization">
   2.415 +<link href="#rfc.section.7" rel="Chapter" title="7 Interoperability">
   2.416 +<link href="#rfc.section.8" rel="Chapter" title="8 Options in pEp">
   2.417 +<link href="#rfc.section.8.1" rel="Chapter" title="8.1 Option &#8220;Passive Mode&#8221;">
   2.418 +<link href="#rfc.section.8.2" rel="Chapter" title="8.2 Option &#8220;Disable Protection&#8221;">
   2.419 +<link href="#rfc.section.8.3" rel="Chapter" title="8.3 Option &#8220;Extra Keys&#8221;">
   2.420 +<link href="#rfc.section.8.3.1" rel="Chapter" title="8.3.1 Use Case for Organizations">
   2.421 +<link href="#rfc.section.8.3.2" rel="Chapter" title="8.3.2 Use Case for Key Synchronization">
   2.422 +<link href="#rfc.section.8.4" rel="Chapter" title="8.4 Option &#8220;Blacklist Keys&#8221;">
   2.423 +<link href="#rfc.section.9" rel="Chapter" title="9 Security Considerations">
   2.424 +<link href="#rfc.section.10" rel="Chapter" title="10 Privacy Considerations">
   2.425 +<link href="#rfc.section.11" rel="Chapter" title="11 IANA Considerations">
   2.426 +<link href="#rfc.section.12" rel="Chapter" title="12 Implementation Status">
   2.427 +<link href="#rfc.section.12.1" rel="Chapter" title="12.1 Introduction">
   2.428 +<link href="#rfc.section.12.2" rel="Chapter" title="12.2 Current software implementing pEp">
   2.429 +<link href="#rfc.section.12.3" rel="Chapter" title="12.3 Reference implementation of pEp&#8217;s core">
   2.430 +<link href="#rfc.section.12.4" rel="Chapter" title="12.4 Abstract Crypto API examples">
   2.431 +<link href="#rfc.section.13" rel="Chapter" title="13 Notes">
   2.432 +<link href="#rfc.section.14" rel="Chapter" title="14 Acknowledgments">
   2.433 +<link href="#rfc.references" rel="Chapter" title="15 References">
   2.434 +<link href="#rfc.references.1" rel="Chapter" title="15.1 Normative References">
   2.435 +<link href="#rfc.references.2" rel="Chapter" title="15.2 Informative References">
   2.436 +<link href="#rfc.appendix.A" rel="Chapter" title="A Code Excerpts">
   2.437 +<link href="#rfc.appendix.A.1" rel="Chapter" title="A.1 pEp Identity">
   2.438 +<link href="#rfc.appendix.A.1.1" rel="Chapter" title="A.1.1 Corresponding SQL">
   2.439 +<link href="#rfc.appendix.A.2" rel="Chapter" title="A.2 pEp Communication Type">
   2.440 +<link href="#rfc.appendix.A.3" rel="Chapter" title="A.3 Abstract Crypto API examples">
   2.441 +<link href="#rfc.appendix.A.3.1" rel="Chapter" title="A.3.1 Encrypting a Message">
   2.442 +<link href="#rfc.appendix.A.3.2" rel="Chapter" title="A.3.2 Decrypting a Message">
   2.443 +<link href="#rfc.appendix.A.3.3" rel="Chapter" title="A.3.3 Obtain Common Trustwords">
   2.444 +<link href="#rfc.appendix.B" rel="Chapter" title="B Document Changelog">
   2.445 +<link href="#rfc.appendix.C" rel="Chapter" title="C Open Issues">
   2.446 +<link href="#rfc.authors" rel="Chapter">
   2.447 +
   2.448 +
   2.449 +  <meta name="generator" content="xml2rfc version 2.9.6 - https://tools.ietf.org/tools/xml2rfc" />
   2.450 +  <link rel="schema.dct" href="http://purl.org/dc/terms/" />
   2.451 +
   2.452 +  <meta name="dct.creator" content="Birk, V., Marques, H., and B. Hoeneisen" />
   2.453 +  <meta name="dct.identifier" content="urn:ietf:id:draft-birk-pep-05" />
   2.454 +  <meta name="dct.issued" scheme="ISO8601" content="2019-11-04" />
   2.455 +  <meta name="dct.abstract" content="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 interpersonal 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). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level.  Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation.  This document outlines the general design choices and principles of pEp." />
   2.456 +  <meta name="description" content="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 interpersonal 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). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level.  Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation.  This document outlines the general design choices and principles of pEp." />
   2.457 +
   2.458 +</head>
   2.459 +
   2.460 +<body>
   2.461 +
   2.462 +  <table class="header">
   2.463 +    <tbody>
   2.464 +    
   2.465 +    	<tr>
   2.466 +<td class="left">Network Working Group</td>
   2.467 +<td class="right">V. Birk</td>
   2.468 +</tr>
   2.469 +<tr>
   2.470 +<td class="left">Internet-Draft</td>
   2.471 +<td class="right">H. Marques</td>
   2.472 +</tr>
   2.473 +<tr>
   2.474 +<td class="left">Intended status: Standards Track</td>
   2.475 +<td class="right">B. Hoeneisen</td>
   2.476 +</tr>
   2.477 +<tr>
   2.478 +<td class="left">Expires: May 7, 2020</td>
   2.479 +<td class="right">pEp Foundation</td>
   2.480 +</tr>
   2.481 +<tr>
   2.482 +<td class="left"></td>
   2.483 +<td class="right">November 04, 2019</td>
   2.484 +</tr>
   2.485 +
   2.486 +    	
   2.487 +    </tbody>
   2.488 +  </table>
   2.489 +
   2.490 +  <p class="title">pretty Easy privacy (pEp): Privacy by Default<br />
   2.491 +  <span class="filename">draft-birk-pep-05</span></p>
   2.492 +  
   2.493 +  <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
   2.494 +<p>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 interpersonal 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). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level.  Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation.  This document outlines the general design choices and principles of pEp.</p>
   2.495 +<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
   2.496 +<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
   2.497 +<p>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/.</p>
   2.498 +<p>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."</p>
   2.499 +<p>This Internet-Draft will expire on May 7, 2020.</p>
   2.500 +<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
   2.501 +<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
   2.502 +<p>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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
   2.503 +
   2.504 +  
   2.505 +  <hr class="noprint" />
   2.506 +  <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
   2.507 +  <ul class="toc">
   2.508 +
   2.509 +  	<li>1.   <a href="#rfc.section.1">Introduction</a>
   2.510 +</li>
   2.511 +<ul><li>1.1.   <a href="#rfc.section.1.1">Relationship to other pEp documents</a>
   2.512 +</li>
   2.513 +<li>1.2.   <a href="#rfc.section.1.2">Requirements Language</a>
   2.514 +</li>
   2.515 +<li>1.3.   <a href="#rfc.section.1.3">Terms</a>
   2.516 +</li>
   2.517 +</ul><li>2.   <a href="#rfc.section.2">Protocol&#8217;s Core Design Principles</a>
   2.518 +</li>
   2.519 +<ul><li>2.1.   <a href="#rfc.section.2.1">Privacy by Default</a>
   2.520 +</li>
   2.521 +<li>2.2.   <a href="#rfc.section.2.2">Data Minimization</a>
   2.522 +</li>
   2.523 +<li>2.3.   <a href="#rfc.section.2.3">Interoperability</a>
   2.524 +</li>
   2.525 +<li>2.4.   <a href="#rfc.section.2.4">Peer-to-Peer</a>
   2.526 +</li>
   2.527 +<li>2.5.   <a href="#rfc.section.2.5">User Interaction</a>
   2.528 +</li>
   2.529 +</ul><li>3.   <a href="#rfc.section.3">Identity System</a>
   2.530 +</li>
   2.531 +<ul><li>3.1.   <a href="#rfc.section.3.1">User</a>
   2.532 +</li>
   2.533 +<li>3.2.   <a href="#rfc.section.3.2">Address</a>
   2.534 +</li>
   2.535 +<li>3.3.   <a href="#rfc.section.3.3">Key</a>
   2.536 +</li>
   2.537 +<li>3.4.   <a href="#rfc.section.3.4">Identity</a>
   2.538 +</li>
   2.539 +</ul><li>4.   <a href="#rfc.section.4">Key Management</a>
   2.540 +</li>
   2.541 +<ul><li>4.1.   <a href="#rfc.section.4.1">Key Generation</a>
   2.542 +</li>
   2.543 +<li>4.2.   <a href="#rfc.section.4.2">Private Keys</a>
   2.544 +</li>
   2.545 +<ul><li>4.2.1.   <a href="#rfc.section.4.2.1">Storage</a>
   2.546 +</li>
   2.547 +<li>4.2.2.   <a href="#rfc.section.4.2.2">Passphrase</a>
   2.548 +</li>
   2.549 +</ul><li>4.3.   <a href="#rfc.section.4.3">Key Reset</a>
   2.550 +</li>
   2.551 +<li>4.4.   <a href="#rfc.section.4.4">Public Key Distribution</a>
   2.552 +</li>
   2.553 +<ul><li>4.4.1.   <a href="#rfc.section.4.4.1">UX Considerations</a>
   2.554 +</li>
   2.555 +<li>4.4.2.   <a href="#rfc.section.4.4.2">No addition of unnecessary metadata</a>
   2.556 +</li>
   2.557 +<li>4.4.3.   <a href="#rfc.section.4.4.3">No centralized public key storage or retrieval by default</a>
   2.558 +</li>
   2.559 +<li>4.4.4.   <a href="#rfc.section.4.4.4">Example message flow</a>
   2.560 +</li>
   2.561 +</ul><li>4.5.   <a href="#rfc.section.4.5">Key Reset</a>
   2.562 +</li>
   2.563 +</ul><li>5.   <a href="#rfc.section.5">Trust Management</a>
   2.564 +</li>
   2.565 +<ul><li>5.1.   <a href="#rfc.section.5.1">Privacy Status</a>
   2.566 +</li>
   2.567 +<li>5.2.   <a href="#rfc.section.5.2">Handshake</a>
   2.568 +</li>
   2.569 +<li>5.3.   <a href="#rfc.section.5.3">Trust Rating</a>
   2.570 +</li>
   2.571 +<li>5.4.   <a href="#rfc.section.5.4">Trust Revoke</a>
   2.572 +</li>
   2.573 +</ul><li>6.   <a href="#rfc.section.6">Synchronization</a>
   2.574 +</li>
   2.575 +<ul><li>6.1.   <a href="#rfc.section.6.1">Private Key Synchronization</a>
   2.576 +</li>
   2.577 +<li>6.2.   <a href="#rfc.section.6.2">Trust Synchronization</a>
   2.578 +</li>
   2.579 +</ul><li>7.   <a href="#rfc.section.7">Interoperability</a>
   2.580 +</li>
   2.581 +<li>8.   <a href="#rfc.section.8">Options in pEp</a>
   2.582 +</li>
   2.583 +<ul><li>8.1.   <a href="#rfc.section.8.1">Option &#8220;Passive Mode&#8221;</a>
   2.584 +</li>
   2.585 +<li>8.2.   <a href="#rfc.section.8.2">Option &#8220;Disable Protection&#8221;</a>
   2.586 +</li>
   2.587 +<li>8.3.   <a href="#rfc.section.8.3">Option &#8220;Extra Keys&#8221;</a>
   2.588 +</li>
   2.589 +<ul><li>8.3.1.   <a href="#rfc.section.8.3.1">Use Case for Organizations</a>
   2.590 +</li>
   2.591 +<li>8.3.2.   <a href="#rfc.section.8.3.2">Use Case for Key Synchronization</a>
   2.592 +</li>
   2.593 +</ul><li>8.4.   <a href="#rfc.section.8.4">Option &#8220;Blacklist Keys&#8221;</a>
   2.594 +</li>
   2.595 +</ul><li>9.   <a href="#rfc.section.9">Security Considerations</a>
   2.596 +</li>
   2.597 +<li>10.   <a href="#rfc.section.10">Privacy Considerations</a>
   2.598 +</li>
   2.599 +<li>11.   <a href="#rfc.section.11">IANA Considerations</a>
   2.600 +</li>
   2.601 +<li>12.   <a href="#rfc.section.12">Implementation Status</a>
   2.602 +</li>
   2.603 +<ul><li>12.1.   <a href="#rfc.section.12.1">Introduction</a>
   2.604 +</li>
   2.605 +<li>12.2.   <a href="#rfc.section.12.2">Current software implementing pEp</a>
   2.606 +</li>
   2.607 +<li>12.3.   <a href="#rfc.section.12.3">Reference implementation of pEp&#8217;s core</a>
   2.608 +</li>
   2.609 +<li>12.4.   <a href="#rfc.section.12.4">Abstract Crypto API examples</a>
   2.610 +</li>
   2.611 +</ul><li>13.   <a href="#rfc.section.13">Notes</a>
   2.612 +</li>
   2.613 +<li>14.   <a href="#rfc.section.14">Acknowledgments</a>
   2.614 +</li>
   2.615 +<li>15.   <a href="#rfc.references">References</a>
   2.616 +</li>
   2.617 +<ul><li>15.1.   <a href="#rfc.references.1">Normative References</a>
   2.618 +</li>
   2.619 +<li>15.2.   <a href="#rfc.references.2">Informative References</a>
   2.620 +</li>
   2.621 +</ul><li>Appendix A.   <a href="#rfc.appendix.A">Code Excerpts</a>
   2.622 +</li>
   2.623 +<ul><li>A.1.   <a href="#rfc.appendix.A.1">pEp Identity</a>
   2.624 +</li>
   2.625 +<ul><li>A.1.1.   <a href="#rfc.appendix.A.1.1">Corresponding SQL</a>
   2.626 +</li>
   2.627 +</ul><li>A.2.   <a href="#rfc.appendix.A.2">pEp Communication Type</a>
   2.628 +</li>
   2.629 +<li>A.3.   <a href="#rfc.appendix.A.3">Abstract Crypto API examples</a>
   2.630 +</li>
   2.631 +<ul><li>A.3.1.   <a href="#rfc.appendix.A.3.1">Encrypting a Message</a>
   2.632 +</li>
   2.633 +<li>A.3.2.   <a href="#rfc.appendix.A.3.2">Decrypting a Message</a>
   2.634 +</li>
   2.635 +<li>A.3.3.   <a href="#rfc.appendix.A.3.3">Obtain Common Trustwords</a>
   2.636 +</li>
   2.637 +</ul></ul><li>Appendix B.   <a href="#rfc.appendix.B">Document Changelog</a>
   2.638 +</li>
   2.639 +<li>Appendix C.   <a href="#rfc.appendix.C">Open Issues</a>
   2.640 +</li>
   2.641 +<li><a href="#rfc.authors">Authors' Addresses</a>
   2.642 +</li>
   2.643 +
   2.644 +
   2.645 +  </ul>
   2.646 +
   2.647 +  <h1 id="rfc.section.1">
   2.648 +<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
   2.649 +</h1>
   2.650 +<p id="rfc.section.1.p.1">Secure and private communications are vital for many different reasons, and there are particular properties that privacy-preserving protocols need to fulfill in order to best serve users. In particular, <a href="#RFC8280" class="xref">[RFC8280]</a> has identified and documented important principles such as data minimization, the end-to-end principle, and interoperability as integral properties which enable access to Human Rights. Today&#8217;s applications widely lack privacy support that ordinary users can easily adapt. The pretty Easy privacy (pEp) protocols generally conform to the principles outlined in <a href="#RFC8280" class="xref">[RFC8280]</a>, and, as such, can facilitate the adoption and correct usage of secure and private communications technology.</p>
   2.651 +<p id="rfc.section.1.p.2">The pretty Easy privacy (pEp) protocols are propositions to the Internet community to create software for peers to automatically encrypt, anonymize (where possible), and verify their daily written digital communications.  This is achieved by building upon already existing standards and tools and automating each step a user needs to carry out in order to engage in secure end-to-end encrypted communications.  Significantly, the pEp protocols describe how do to this without dependence on centralized infrastructures.</p>
   2.652 +<p id="rfc.section.1.p.3">The pEp project emerged from the CryptoParty movement. During that time, the initiators learned that while step-by-step guides can help some users engage in secure end-to-end communications, it is both more effective and convenient for the vast majority of users if these step-by-step guides are put into running code (following a protocol), which automates the initial configuration and general usage of cryptographic tools. To facilitate this goal, pEp proposes the automation of key management, key discovery, and key synchronization through an in-band approach which follows the end-to-end principle.</p>
   2.653 +<p id="rfc.section.1.p.4">To mitigate man-in-the-middle attacks (MITM) by an active adversary, and as the only manual step users carry out in the course of the protocols, the proposed Trustwords <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a> mechanism uses natural language representations of two peers&#8217; fingerprints for users to verify their trust in a paired communication channel.</p>
   2.654 +<p id="rfc.section.1.p.5">The privacy-by-default principles that pEp introduces are in accordance with the perspective outlined in <a href="#RFC7435" class="xref">[RFC7435]</a>, aiming to provide opportunistic security in the sense of &#8220;some protection most of the time&#8221;.  This is done, however, with the subtle but important difference that when privacy is weighed against security, the choice defaults to privacy.  Therefore, data minimization is a primary goal in pEp (e.g., hiding subject lines and headers unnecessary for email transport inside the encrypted payload of a message).</p>
   2.655 +<p id="rfc.section.1.p.6">The pEp propositions are focused on (but not limited to) written digital communications and cover asynchronous (offline) types of communications like email as well as synchronous (online) types such as chat.</p>
   2.656 +<p id="rfc.section.1.p.7">pEp&#8217;s goal is to bridge different standardized and widely-used communications channels such that users can reach communications partners in the most privacy-enhancing way possible.</p>
   2.657 +<h1 id="rfc.section.1.1">
   2.658 +<a href="#rfc.section.1.1">1.1.</a> <a href="#relationship-to-other-pep-documents" id="relationship-to-other-pep-documents">Relationship to other pEp documents</a>
   2.659 +</h1>
   2.660 +<p id="rfc.section.1.1.p.1">While this document outlines the general design choices and principles of pEp, other related documents specialize in more particular aspects of the model, or the application of pEp on a specific protocol like as follows:</p>
   2.661 +<p></p>
   2.662 +
   2.663 +<ol>
   2.664 +<li>pEp-enabled applications (e.g., pEp email <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>).</li>
   2.665 +<li>Helper functions for peer interaction, which facilitate understanding and handling of the cryptographic aspects of pEp implementation for users (e.g., pEp Handshake <a href="#I-D.marques-pep-handshake" class="xref">[I-D.marques-pep-handshake]</a>).</li>
   2.666 +<li>Helper functions for interactions between a user&#8217;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 <a href="#I-D.hoeneisen-pep-keysync" class="xref">[I-D.hoeneisen-pep-keysync]</a>).</li>
   2.667 +</ol>
   2.668 +<p id="rfc.section.1.1.p.3">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 <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a>.</p>
   2.669 +<p id="rfc.section.1.1.p.4">[[ 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. ]]</p>
   2.670 +<h1 id="rfc.section.1.2">
   2.671 +<a href="#rfc.section.1.2">1.2.</a> <a href="#requirements-language" id="requirements-language">Requirements Language</a>
   2.672 +</h1>
   2.673 +<p id="rfc.section.1.2.p.1">The key words &#8220;MUST&#8221;, &#8220;MUST NOT&#8221;, &#8220;REQUIRED&#8221;, &#8220;SHALL&#8221;, &#8220;SHALL NOT&#8221;, &#8220;SHOULD&#8221;, &#8220;SHOULD NOT&#8221;, &#8220;RECOMMENDED&#8221;, &#8220;MAY&#8221;, and &#8220;OPTIONAL&#8221; in this document are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
   2.674 +<h1 id="rfc.section.1.3">
   2.675 +<a href="#rfc.section.1.3">1.3.</a> <a href="#terms" id="terms">Terms</a>
   2.676 +</h1>
   2.677 +<p id="rfc.section.1.3.p.1">The following terms are defined for the scope of this document:</p>
   2.678 +<p></p>
   2.679 +
   2.680 +<ul>
   2.681 +<li>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. <a href="#I-D.marques-pep-handshake" class="xref">[I-D.marques-pep-handshake]</a>
   2.682 +</li>
   2.683 +<li>Trustwords: A scalar-to-word representation of 16-bit numbers (0 to 65535) to natural language words. When doing a Handshake, peers are shown combined Trustwords of both public keys involved to ease the comparison. <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a>
   2.684 +</li>
   2.685 +</ul>
   2.686 +<p></p>
   2.687 +
   2.688 +<ul><li>Trust On First Use (TOFU): cf. <a href="#RFC7435" class="xref">[RFC7435]</a>, which states: &#8220;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 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.&#8221;</li></ul>
   2.689 +<p></p>
   2.690 +
   2.691 +<ul><li>Man-in-the-middle (MITM) attack: cf. <a href="#RFC4949" class="xref">[RFC4949]</a>, which states: &#8220;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.&#8221;</li></ul>
   2.692 +<h1 id="rfc.section.2">
   2.693 +<a href="#rfc.section.2">2.</a> <a href="#protocols-core-design-principles" id="protocols-core-design-principles">Protocol&#8217;s Core Design Principles</a>
   2.694 +</h1>
   2.695 +<h1 id="rfc.section.2.1">
   2.696 +<a href="#rfc.section.2.1">2.1.</a> <a href="#privacy-by-default" id="privacy-by-default">Privacy by Default</a>
   2.697 +</h1>
   2.698 +<p id="rfc.section.2.1.p.1">pEp&#8217;s most important goal is to ensure privacy above all else. To clarify, pEp&#8217;s protocol defaults are designed to maximize both security and privacy, but in the few cases where achieving both more privacy and more security are in conflict, pEp chooses more privacy.</p>
   2.699 +<p id="rfc.section.2.1.p.2">In contrast to pEp&#8217;s prioritization of user privacy, OpenPGP&#8217;s Web-of-Trust (WoT) releases user and trust level relationships to the public.  In addition, queries to OpenPGP keyservers dynamically disclose the social graph, indicating a user&#8217;s intent to communicate with specific peers.  Similar issues exist in other security protocols that rely upon a centralized trust model, such as the certificate revocation protocols used in XPKI (S&#8203;/&#8203;MIME).</p>
   2.700 +<p id="rfc.section.2.1.p.3">[[<strong>TODO</strong>: Fix the wording and reference to XPKI, S&#8203;/&#8203;MIME]].</p>
   2.701 +<p id="rfc.section.2.1.p.4">In pEp messaging (e.g., when using HTML) content and information SHALL NOT be obtained from remote locations as this constitutes a privacy breach.</p>
   2.702 +<p id="rfc.section.2.1.p.5">Because of the inherent privacy risks in using remote or centralized infrastructures, implementations of pEp messaging, by default, SHALL NOT obtain content and information from remote or centralized locations, as this constitutes a privacy breach. In email this issue exists with HTML mails.</p>
   2.703 +<h1 id="rfc.section.2.2">
   2.704 +<a href="#rfc.section.2.2">2.2.</a> <a href="#data-minimization" id="data-minimization">Data Minimization</a>
   2.705 +</h1>
   2.706 +<p id="rfc.section.2.2.p.1">Data minimization keeps data spare and hides all technically concealable information whenever possible. It is an important design goal of pEp.</p>
   2.707 +<h1 id="rfc.section.2.3">
   2.708 +<a href="#rfc.section.2.3">2.3.</a> <a href="#interoperability" id="interoperability">Interoperability</a>
   2.709 +</h1>
   2.710 +<p id="rfc.section.2.3.p.1">The proposed pEp protocols seek interoperability with established message formats, as well as cryptographic security protocols and their widespread implementations.</p>
   2.711 +<p id="rfc.section.2.3.p.2">To achieve this interoperability, pEp MUST follow Postel&#8217;s Robustness Principle outlined in <a href="#RFC1122" class="xref">[RFC1122]</a>: &#8220;Be liberal in what you accept, and conservative in what you send.&#8221;</p>
   2.712 +<p id="rfc.section.2.3.p.3">Particularly, pEp applies Postel&#8217;s principle as follows:</p>
   2.713 +<p></p>
   2.714 +
   2.715 +<ul>
   2.716 +<li>pEp is conservative (strict) in requirements for pEp implementations and how they interact with pEp or other compatible implementations.</li>
   2.717 +<li>pEp liberally accepts input from non-pEp implementations. For example, in email, pEp will not produce outgoing messages, but will transparently support decryption of incoming PGP/INLINE messages.</li>
   2.718 +<li>Finally, where pEp requires divergence from established RFCs due to privacy concerns (e.g., from OpenPGP propositions as defined in <a href="#OpenPGP" class="xref">[OpenPGP]</a>, options SHOULD be implemented which empower the user to override pEp&#8217;s defaults.</li>
   2.719 +</ul>
   2.720 +<h1 id="rfc.section.2.4">
   2.721 +<a href="#rfc.section.2.4">2.4.</a> <a href="#peer-to-peer" id="peer-to-peer">Peer-to-Peer</a>
   2.722 +</h1>
   2.723 +<p id="rfc.section.2.4.p.1">Messaging and verification processes in pEp are designed to work in a peer-to-peer (P2P) manner, without the involvement of intermediaries.</p>
   2.724 +<p id="rfc.section.2.4.p.2">This means there MUST NOT be any pEp-specific central services whatsoever needed for pEp implementations, both in the case of verification of peers and for the actual encryption.</p>
   2.725 +<p id="rfc.section.2.4.p.3">However, implementers of pEp MAY provide options for interoperation with providers of centralized infrastructures (e.g., to enable users to communicate with their peers on platforms with vendor lock-in).</p>
   2.726 +<p id="rfc.section.2.4.p.4">Trust provided by global Certificate Authorities (e.g., commercial X.509 CAs) SHALL NOT be signaled as trustworthy (cf. <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a>) to users of pEp (e.g., when interoperating with peers using S&#8203;/&#8203;MIME) by default.</p>
   2.727 +<h1 id="rfc.section.2.5">
   2.728 +<a href="#rfc.section.2.5">2.5.</a> <a href="#user-interaction" id="user-interaction">User Interaction</a>
   2.729 +</h1>
   2.730 +<p id="rfc.section.2.5.p.1">Implementers of pEp MUST NOT expose users to technical terms and views, especially those specific to cryptography, like &#8220;keys&#8221;, &#8220;certificates&#8221;, or &#8220;fingerprints&#8221;. Users may explicitly opt-in to see such terms wanting seeking for more options; i.e., advanced settings MAY be available, and in some cases, these options may be required.</p>
   2.731 +<p id="rfc.section.2.5.p.2">The authors believe that widespread adoption of end-to-end cryptography is possible if users are not required to understand cryptography and key management. This belief forms the central goal of pEp, which is that users can simply rely on the principles of Privacy by Default.</p>
   2.732 +<p id="rfc.section.2.5.p.3">On the other hand, to preserve usability, users MUST NOT be required to wait for cryptographic tasks such as key generation to complete before being able to use their respective message client for its default purpose. In short, pEp implementers MUST ensure that the ability to draft, send, and receive messages is always preserved, even if that means a message is sent unencrypted, in accordance with the Opportunistic Security approach outlined in <a href="#RFC7435" class="xref">[RFC7435]</a>.</p>
   2.733 +<p id="rfc.section.2.5.p.4">In turn, pEp implementers MUST ensure that a distinguishable privacy status is clearly visible to the user, both on a per-contact as well as per-message level. This allows users to assess both the privacy level for the message and the trust level of its intended recipients before choosing to send it.</p>
   2.734 +<p id="rfc.section.2.5.p.5">[[ <strong>NOTE</strong>: We are aware of the fact that usually UX requirements are not part of RFCs. However, in order to encourage massive adoption of secure end-to-end encryption while at the same time avoiding putting users at risk, we believe certain straightforward signaling requirements for users to be a good idea, just as it is currently done for already-popular instant messaging services. ]]</p>
   2.735 +<h1 id="rfc.section.3">
   2.736 +<a href="#rfc.section.3">3.</a> <a href="#identity-system" id="identity-system">Identity System</a>
   2.737 +</h1>
   2.738 +<p id="rfc.section.3.p.1">Everyone has the right to choose how to reveal themselves to the world, both offline and online. This is an important element to maintain psychological, physical, and digital privacy. As such, pEp users MUST have the option to choose their identity, and they MUST have the ability to maintain multiple identities.</p>
   2.739 +<p id="rfc.section.3.p.2">These different identities MUST NOT be externally correlatable with each other by default.  On the other hand, combining different identities when such information is known MUST be supported (alias support).</p>
   2.740 +<h1 id="rfc.section.3.1">
   2.741 +<a href="#rfc.section.3.1">3.1.</a> <a href="#user" id="user">User</a>
   2.742 +</h1>
   2.743 +<p id="rfc.section.3.1.p.1">A user is a real world human being or a group of human beings. If it is a single human being, it can be called person.</p>
   2.744 +<p id="rfc.section.3.1.p.2">A user is identified by a user ID (user_id). The user_id SHOULD be a UUID, it MAY be an arbitrary unique string.</p>
   2.745 +<p id="rfc.section.3.1.p.3">The own user can have a user_id like all other users. If the own user does not have a user_id, then it is assigned a &#8220;pEp_own_userId&#8221; instead.</p>
   2.746 +<p id="rfc.section.3.1.p.4">A user can have a default key.  [[ TODO: Provide ref explaining this. ]]</p>
   2.747 +<h1 id="rfc.section.3.2">
   2.748 +<a href="#rfc.section.3.2">3.2.</a> <a href="#address" id="address">Address</a>
   2.749 +</h1>
   2.750 +<p id="rfc.section.3.2.p.1">A pEp address is a network address, e.g., an SMTP address or another Universal Resource Identifier (URI).</p>
   2.751 +<p id="rfc.section.3.2.p.2">[[ Note: It might be necessary to introduce further addressing schemes through IETF contributions or IANA registrations, e.g., implementing pEp to bridge to popular messaging services with no URIs defined. ]]</p>
   2.752 +<h1 id="rfc.section.3.3">
   2.753 +<a href="#rfc.section.3.3">3.3.</a> <a href="#key" id="key">Key</a>
   2.754 +</h1>
   2.755 +<p id="rfc.section.3.3.p.1">A key is an OpenPGP-compatible asymmetric cryptographic key pair.</p>
   2.756 +<p id="rfc.section.3.3.p.2">Keys in pEp are identified by the full fingerprint (fpr) of the public key.  The fingerprint is to be obtained from the specific cryptographic service used to handle the keys. The canonical representation in pEp is upper-case hexadecimal with zero-padding and no separators or spaces.</p>
   2.757 +<h1 id="rfc.section.3.4">
   2.758 +<a href="#rfc.section.3.4">3.4.</a> <a href="#identity" id="identity">Identity</a>
   2.759 +</h1>
   2.760 +<p id="rfc.section.3.4.p.1">An identity is a representation of a user, encapsulating how this user appears within the network of a messaging system. This representation may or may not be pseudonymous in nature.</p>
   2.761 +<p id="rfc.section.3.4.p.2">An identity is defined by mapping a user_id to an address. If no user_id is known, it is guessed by mapping a username to an address.</p>
   2.762 +<p id="rfc.section.3.4.p.3">An identity can have a temporary user_id as a placeholder until a real user_id is known.</p>
   2.763 +<p id="rfc.section.3.4.p.4">In pEp a different key pair for each (e.g., email) account MUST be created.  This allows a user to retain different identities, which are not correlated by the usage of the same key for all of those. This is beneficial in terms of privacy.</p>
   2.764 +<p id="rfc.section.3.4.p.5">A user MAY have a default key; each identity a user has MAY have a default key (of its own).  When both an Identity and the related User have a default key set, the Identity&#8217;s default key MUST override the User&#8217;s default key.</p>
   2.765 +<p id="rfc.section.3.4.p.6">[[ TODO: Provide ref explaining this. ]]</p>
   2.766 +<p id="rfc.section.3.4.p.7">In <a href="#pep-identity" class="xref">Appendix A.1</a>, the definition of a pEp identity can be found according to the reference implementation by the pEp engine.</p>
   2.767 +<h1 id="rfc.section.4">
   2.768 +<a href="#rfc.section.4">4.</a> <a href="#key-management" id="key-management">Key Management</a>
   2.769 +</h1>
   2.770 +<p id="rfc.section.4.p.1">In order to achieve the goal of widespread adoption of secure communications, key management in pEp MUST be automated.</p>
   2.771 +<h1 id="rfc.section.4.1">
   2.772 +<a href="#rfc.section.4.1">4.1.</a> <a href="#key-generation" id="key-generation">Key Generation</a>
   2.773 +</h1>
   2.774 +<p id="rfc.section.4.1.p.1">A pEp implementation MUST ensure that cryptographic keys for every configured identity are available. If a corresponding key pair for the identity of a user is found and said identity fulfills the requirements (e.g., for email, as set out in <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>), said key pair MUST be reused. Otherwise a new key pair MUST be generated. This may be carried out instantly upon its configuration.</p>
   2.775 +<p id="rfc.section.4.1.p.2">On devices with limited processing power (e.g., mobile devices) the key generation may take more time than a user is willing to wait. If this is the case, users SHOULD NOT be stopped from communicating, i.e., the key generation process SHOULD be carried out in the background.</p>
   2.776 +<h1 id="rfc.section.4.2">
   2.777 +<a href="#rfc.section.4.2">4.2.</a> <a href="#private-keys" id="private-keys">Private Keys</a>
   2.778 +</h1>
   2.779 +<h1 id="rfc.section.4.2.1">
   2.780 +<a href="#rfc.section.4.2.1">4.2.1.</a> <a href="#storage" id="storage">Storage</a>
   2.781 +</h1>
   2.782 +<p id="rfc.section.4.2.1.p.1">Private keys in pEp implementations MUST always be held on the end user&#8217;s device(s): pEp implementers MUST NOT rely on private keys stored in centralized remote locations. This applies even for key storages where the private keys are protected with sufficiently long passphrases. It is considered a violation of pEp&#8217;s P2P design principle to rely on centralized infrastructures (cf. <a href="#peer-to-peer" class="xref">Section 2.4</a>). This also applies for pEp implementations created for applications not residing on a user&#8217;s device (e.g., web-based MUAs). In such cases, pEp implementations MUST be done in a way such that the locally-held private key can neither be directly accessed nor leaked to the outside world.</p>
   2.783 +<p id="rfc.section.4.2.1.p.2">[[ Note: It is particularly important that browser add-ons implementing pEp functionality do not obtain their cryptographic code from a centralized (cloud) service, as this must be considered a centralized attack vector allowing for backdoors, negatively impacting privacy. ]]</p>
   2.784 +<p id="rfc.section.4.2.1.p.3">Cf. <a href="#private-key-synchronization" class="xref">Section 6.1</a> for a means to synchronize private keys among different devices of the same network address in a secure manner.</p>
   2.785 +<h1 id="rfc.section.4.2.2">
   2.786 +<a href="#rfc.section.4.2.2">4.2.2.</a> <a href="#passphrase" id="passphrase">Passphrase</a>
   2.787 +</h1>
   2.788 +<p id="rfc.section.4.2.2.p.1">Passphrases to protect a user&#8217;s private key MUST be supported by pEp implementations, but MUST NOT be enforced by default. That is, if a pEp implementation finds a suitable (i.e., secure enough) cryptographic setup, which uses passphrases, pEp implementations MUST provide a way to unlock the key. However, if a new key pair is generated for a given identity, no passphrase MUST be put in place. The authors assume that the enforcement of secure (i.e., unique and long enough) passphrases would massively reduce the number of pEp users (by hassling them), while providing little to no additional privacy for the common cases of passive monitoring being carried out by corporations or state-level actors.</p>
   2.789 +<h1 id="rfc.section.4.3">
   2.790 +<a href="#rfc.section.4.3">4.3.</a> <a href="#key-reset" id="key-reset">Key Reset</a>
   2.791 +</h1>
   2.792 +<h1 id="rfc.section.4.4">
   2.793 +<a href="#rfc.section.4.4">4.4.</a> <a href="#public-key-distribution" id="public-key-distribution">Public Key Distribution</a>
   2.794 +</h1>
   2.795 +<p id="rfc.section.4.4.p.1">As the key is available (cf. <a href="#key-generation" class="xref">Section 4.1</a>) implementers of pEp are REQUIRED to ensure that the identity&#8217;s public key is attached to every outgoing message. However, this MAY be omitted if the peer has previously received a message encrypted with the public key of the sender.</p>
   2.796 +<p id="rfc.section.4.4.p.2">The sender&#8217;s public key SHOULD be sent encrypted whenever possible, i.e., when a public key of the receiving peer is available.  If no encryption key of the recipient is available, the sender&#8217;s public key MAY be sent unencrypted. In either case, this approach ensures that messaging clients (e.g., MUAs that at least implement OpenPGP) do not need to have pEp implemented to see a user&#8217;s public key. Such peers thus have the chance to (automatically) import the sender&#8217;s public key.</p>
   2.797 +<p id="rfc.section.4.4.p.3">If there is already a known public key from the sender of a message and it is still valid and not expired, new keys MUST NOT be used for future communication unless they are signed by the previous key (to avoid a MITM attack). Messages MUST always be encrypted with the receiving peer&#8217;s oldest public key, as long as it is valid and not expired.</p>
   2.798 +<h1 id="rfc.section.4.4.1">
   2.799 +<a href="#rfc.section.4.4.1">4.4.1.</a> <a href="#ux-considerations" id="ux-considerations">UX Considerations</a>
   2.800 +</h1>
   2.801 +<p id="rfc.section.4.4.1.p.1">Implementers of pEp SHALL prevent the display of public keys attached to messages (e.g, in email) to the user in order to prevent user confusion by files they are potentially unaware of how to handle.</p>
   2.802 +<h1 id="rfc.section.4.4.2">
   2.803 +<a href="#rfc.section.4.4.2">4.4.2.</a> <a href="#no-addition-of-unnecessary-metadata" id="no-addition-of-unnecessary-metadata">No addition of unnecessary metadata</a>
   2.804 +</h1>
   2.805 +<p id="rfc.section.4.4.2.p.1">Metadata, such as email headers, MUST NOT be added in order to announce a user&#8217;s public key. This is considered unnecessary information leakage, may affect user privacy, and may be subject to a country&#8217;s data retention laws (cf. <a href="#data-minimization" class="xref">Section 2.2</a>). Furthermore, this may affect interoperability to existing users that have no knowledge of such header fields, such as users of OpenPGP in email, and lose the ability to import any keys distributed in this way as a result. The ability to extract and receive public keys from such metadata SHOULD be supported, however, in the event these approaches become widespread.</p>
   2.806 +<h1 id="rfc.section.4.4.3">
   2.807 +<a href="#rfc.section.4.4.3">4.4.3.</a> <a href="#no-centralized-public-key-storage-or-retrieval-by-default" id="no-centralized-public-key-storage-or-retrieval-by-default">No centralized public key storage or retrieval by default</a>
   2.808 +</h1>
   2.809 +<p id="rfc.section.4.4.3.p.1">Keyservers or generally intermediate approaches to obtain a peer&#8217;s public key SHALL NOT be used by default. On the other hand, the user MAY be provided with the option to opt-in for remote locations to obtain keys, considering the widespread adoption of such approaches for key distribution.</p>
   2.810 +<p id="rfc.section.4.4.3.p.2">Keys generated or obtained by pEp clients MUST NOT be uploaded to any (intermediate) keystore locations without the user&#8217;s explicit consent.</p>
   2.811 +<h1 id="rfc.section.4.4.4">
   2.812 +<a href="#rfc.section.4.4.4">4.4.4.</a> <a href="#example-message-flow" id="example-message-flow">Example message flow</a>
   2.813 +</h1>
   2.814 +<p id="rfc.section.4.4.4.p.1">The following example roughly describes a pEp scenario with a typical initial message flow to demonstrate key exchange and basic trust management:</p>
   2.815 +<p id="rfc.section.4.4.4.p.2">The following example describes a pEp scenario between two users &#8211; Alice and Bob &#8211; in order to demonstrate the message flow that occurs when exchanging keys and determining basic trust management for the first time:</p>
   2.816 +<p></p>
   2.817 +
   2.818 +<ol>
   2.819 +<li>Alice &#8211; knowing nothing of Bob &#8211; sends a message to Bob. As Alice has no public key from Bob, this message is sent out unencrypted. However, Alice&#8217;s public key is automatically attached.</li>
   2.820 +<li>Bob receives Alice&#8217;s message and her public key. He is able to reply to her and encrypt the message. His public key is automatically attached to the message. Because he has her public key now, Alice&#8217;s rating in his message client changes to &#8216;encrypted&#8217;. From a UX perspective, this status is displayed in yellow (cf. <a href="#trust-rating" class="xref">Section 5.3</a>).</li>
   2.821 +<li>Alice receives Bob&#8217;s key. As of now Alice is also able to send secure messages to Bob. The rating for Bob changes to &#8220;encrypted&#8221; (with yellow color) in Alice&#8217;s messaging client (cf. <a href="#trust-rating" class="xref">Section 5.3</a>).</li>
   2.822 +<li>Alice receives Bob&#8217;s reply with his public key attached. Now, Alice can send secure messages to Bob as well. The rating for Bob changes to yellow, or &#8216;encrypted&#8217;, in Alice&#8217;s messaging client <a href="#trust-rating" class="xref">Section 5.3</a>.</li>
   2.823 +<li>If Alice and Bob want to prevent man-in-the-middle (MITM) attacks, they can engage in a pEp Handshake comparing their so-called Trustwords (cf. <a href="#handshake" class="xref">Section 5.2</a>) and confirm this process if those match. After doing so, their identity rating changes to &#8220;encrypted and authenticated&#8221; (cf. <a href="#trust-rating" class="xref">Section 5.3</a>), which (UX-wise) can be displayed using a green color. See also <a href="#trust-management" class="xref">Section 5</a>.</li>
   2.824 +<li>Alice and Bob can encrypt now, but they are not yet authenticated, leaving them vulnerable to man-in-the-middle (MitM) attacks. To prevent this from occurring, Alice and Bob can engage in a pEp Handshake to compare their Trustwords (cf. <a href="#handshake" class="xref">Section 5.2</a>) and confirm if they match. After this step is performed, their respective identity ratings change to &#8220;encrypted and authenticated&#8221;, which is represented by a green color (cf. <a href="#trust-management" class="xref">Section 5</a>.</li>
   2.825 +</ol>
   2.826 +<pre>
   2.827 +          -----                                       -----
   2.828 +          | A |                                       | B |
   2.829 +          -----                                       -----
   2.830 +            |                                           |
   2.831 ++------------------------+                 +------------------------+
   2.832 +| auto-generate key pair |                 | auto-generate key pair |
   2.833 +|    (if no key yet)     |                 |    (if no key yet)     |
   2.834 ++------------------------+                 +------------------------+
   2.835 +            |                                           |
   2.836 ++-----------------------+                   +-----------------------+
   2.837 +| Privacy Status for B: |                   | Privacy Status for A: |
   2.838 +|     *Unencrypted*     |                   |     *Unencrypted*     |
   2.839 ++-----------------------+                   +-----------------------+
   2.840 +            |                                           |
   2.841 +            |   A sends message to B (Public Key        |
   2.842 +            |   attached) / optionally signed, but      |
   2.843 +            |               NOT ENCRYPTED               |
   2.844 +            +------------------------------------------&gt;|
   2.845 +            |                                           |
   2.846 +            |                               +-----------------------+
   2.847 +            |                               | Privacy Status for A: |
   2.848 +            |                               |      *Encrypted*      |
   2.849 +            |                               +-----------------------+
   2.850 +            |                                           |
   2.851 +            |      B sends message to A (Public Key     |
   2.852 +            |      attached) / signed and ENCRYPTED     |
   2.853 +            |&lt;------------------------------------------+
   2.854 +            |                                           |
   2.855 ++-----------------------+                               |
   2.856 +| Privacy Status for B: |                               |
   2.857 +|      *Encrypted*      |                               |
   2.858 ++-----------------------+                               |
   2.859 +            |                                           |
   2.860 +            |   A and B successfully compare their      |
   2.861 +            |   Trustwords over an alternative channel  |
   2.862 +            |   (e.g., phone line)                      |
   2.863 +            |&lt;-- -- -- -- -- -- -- -- -- -- -- -- -- --&gt;|
   2.864 +            |                                           |
   2.865 ++-----------------------+                   +-----------------------+
   2.866 +| Privacy Status for B: |                   | Privacy Status for A: |
   2.867 +|       *Trusted*       |                   |       *Trusted*       |
   2.868 ++-----------------------+                   +-----------------------+
   2.869 +            |                                           |
   2.870 +
   2.871 +
   2.872 +</pre>
   2.873 +<h1 id="rfc.section.4.5">
   2.874 +<a href="#rfc.section.4.5">4.5.</a> <a href="#key-reset-1" id="key-reset-1">Key Reset</a>
   2.875 +</h1>
   2.876 +<p id="rfc.section.4.5.p.1">[[ TODO: This section will explain how to deal with invalid keys, e.g., if expired or (potentially) leaked. ]]</p>
   2.877 +<h1 id="rfc.section.5">
   2.878 +<a href="#rfc.section.5">5.</a> <a href="#trust-management" id="trust-management">Trust Management</a>
   2.879 +</h1>
   2.880 +<p id="rfc.section.5.p.1">[[ TODO: Intro ]]</p>
   2.881 +<h1 id="rfc.section.5.1">
   2.882 +<a href="#rfc.section.5.1">5.1.</a> <a href="#privacy-status" id="privacy-status">Privacy Status</a>
   2.883 +</h1>
   2.884 +<p id="rfc.section.5.1.p.1">The trust status for an identity can change due to a number of factors.  These shifts will cause the color code assigned to this identity to change accordingly, and is applied to future communications with this identity.</p>
   2.885 +<p id="rfc.section.5.1.p.2">For end-users, the most important component of pEp, which MUST be made visible on a per-recipient and per-message level, is the Privacy Status.</p>
   2.886 +<p id="rfc.section.5.1.p.3">By colors, symbols and texts a user SHALL immediately understand how private</p>
   2.887 +<p></p>
   2.888 +
   2.889 +<ul>
   2.890 +<li>a communication channel with a given peer was or ought to be and</li>
   2.891 +<li>a given message was or ought to be.</li>
   2.892 +</ul>
   2.893 +<h1 id="rfc.section.5.2">
   2.894 +<a href="#rfc.section.5.2">5.2.</a> <a href="#handshake" id="handshake">Handshake</a>
   2.895 +</h1>
   2.896 +<p id="rfc.section.5.2.p.1">To establishing trust between peers and to upgrade Privacy Status, pEp defines a handshake, which is specified in <a href="#I-D.marques-pep-handshake" class="xref">[I-D.marques-pep-handshake]</a>.</p>
   2.897 +<p id="rfc.section.5.2.p.2">In pEp, Trustwords <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a> are used for users to compare the authenticity of peers in order to mitigate MITM attacks.</p>
   2.898 +<p id="rfc.section.5.2.p.3">By default, Trustwords MUST be used to represent two peers&#8217; fingerprints of their public keys in pEp implementations.</p>
   2.899 +<p id="rfc.section.5.2.p.4">In order to retain compatibility with peers not using pEp implementations (e.g., Mail User Agents (MUAs) with OpenPGP implementations without Trustwords), it is REQUIRED that pEp implementers give the user the choice to show both peers&#8217; fingerprints instead of just their common Trustwords.</p>
   2.900 +<h1 id="rfc.section.5.3">
   2.901 +<a href="#rfc.section.5.3">5.3.</a> <a href="#trust-rating" id="trust-rating">Trust Rating</a>
   2.902 +</h1>
   2.903 +<p id="rfc.section.5.3.p.1">pEp includes a Trust Rating system defining Rating and Color Codes to express the Privacy Status of a peer or message <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a>. The ratings are labeled, e.g., as &#8220;Unencrypted&#8221;, &#8220;Encrypted&#8221;, &#8220;Trusted&#8221;, &#8220;Under Attack&#8221;, etc. The Privacy Status in its most general form is expressed with traffic lights semantics (and respective symbols and texts), whereas the three colors yellow, green and red can be applied for any peer or message &#8211; like this immediately indicating how secure and trustworthy (and thus private) a communication was or ought to be considered.</p>
   2.904 +<p id="rfc.section.5.3.p.2">The pEp Trust Rating system with all its states and respective representations to be followed is outlined in <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a>.</p>
   2.905 +<p id="rfc.section.5.3.p.3">Note: An example for the rating of communication types, the definition of the data structure by the pEp Engine reference implementation is provided in <a href="#pep-communication-type" class="xref">Appendix A.2</a>.</p>
   2.906 +<h1 id="rfc.section.5.4">
   2.907 +<a href="#rfc.section.5.4">5.4.</a> <a href="#trust-revoke" id="trust-revoke">Trust Revoke</a>
   2.908 +</h1>
   2.909 +<p id="rfc.section.5.4.p.1">[[ TODO: This section will explain how to deal with the situation when a peer can no longer be trusted, e.g., if a peer&#8217;s device is compromised. ]]</p>
   2.910 +<h1 id="rfc.section.6">
   2.911 +<a href="#rfc.section.6">6.</a> <a href="#synchronization" id="synchronization">Synchronization</a>
   2.912 +</h1>
   2.913 +<p id="rfc.section.6.p.1">An important feature of pEp is to assist the user to run pEp applications on different devices, such as personal computers, mobile phones and tablets, at the same time. Therefore, state needs to be synchronized among the different devices.</p>
   2.914 +<h1 id="rfc.section.6.1">
   2.915 +<a href="#rfc.section.6.1">6.1.</a> <a href="#private-key-synchronization" id="private-key-synchronization">Private Key Synchronization</a>
   2.916 +</h1>
   2.917 +<p id="rfc.section.6.1.p.1">The pEp KeySync protocol (cf. <a href="#I-D.hoeneisen-pep-keysync" class="xref">[I-D.hoeneisen-pep-keysync]</a>) is a decentralized proposition which defines how pEp users can distribute their private keys among their different devices in a user-authenticated manner.  This allows users to read their messages across their various devices, as long as they share a common address, such as an email account.</p>
   2.918 +<h1 id="rfc.section.6.2">
   2.919 +<a href="#rfc.section.6.2">6.2.</a> <a href="#trust-synchronization" id="trust-synchronization">Trust Synchronization</a>
   2.920 +</h1>
   2.921 +<p id="rfc.section.6.2.p.1">[[ TODO: This section will explain how trust and other related state is synchronized among different devices in a user-authenticated manner. ]]</p>
   2.922 +<h1 id="rfc.section.7">
   2.923 +<a href="#rfc.section.7">7.</a> <a href="#interoperability-1" id="interoperability-1">Interoperability</a>
   2.924 +</h1>
   2.925 +<p id="rfc.section.7.p.1">pEp aims to be interoperable with existing applications designed to enable privacy, e.g., OpenPGP and S&#8203;/&#8203;MIME in email.</p>
   2.926 +<h1 id="rfc.section.8">
   2.927 +<a href="#rfc.section.8">8.</a> <a href="#options-in-pep" id="options-in-pep">Options in pEp</a>
   2.928 +</h1>
   2.929 +<p id="rfc.section.8.p.1">In this section a non-exhaustive selection of options is provided.</p>
   2.930 +<h1 id="rfc.section.8.1">
   2.931 +<a href="#rfc.section.8.1">8.1.</a> <a href="#option-passive-mode" id="option-passive-mode">Option &#8220;Passive Mode&#8221;</a>
   2.932 +</h1>
   2.933 +<p id="rfc.section.8.1.p.1">By default, the sender attaches its public key to any outgoing message (cf. <a href="#public-key-distribution" class="xref">Section 4.4</a>). For situations where a sender wants to ensure that it only attaches a public key to an Internet user which has a pEp implementation, a Passive Mode MUST be made available.</p>
   2.934 +<h1 id="rfc.section.8.2">
   2.935 +<a href="#rfc.section.8.2">8.2.</a> <a href="#option-disable-protection" id="option-disable-protection">Option &#8220;Disable Protection&#8221;</a>
   2.936 +</h1>
   2.937 +<p id="rfc.section.8.2.p.1">Using this option, protection can be disabled generally or selectively.  Implementers of pEp MUST provide an option &#8220;Disable Protection&#8221; to allow a user to disable encryption and signing for:</p>
   2.938 +<p></p>
   2.939 +
   2.940 +<ol>
   2.941 +<li>all communication</li>
   2.942 +<li>specific contacts</li>
   2.943 +<li>specific messages</li>
   2.944 +</ol>
   2.945 +<p id="rfc.section.8.2.p.3">The public key still attached, unless the option &#8220;Passive Mode&#8221; (cf. <a href="#option-passive-mode" class="xref">Section 8.1</a>) is activated at the same time.</p>
   2.946 +<h1 id="rfc.section.8.3">
   2.947 +<a href="#rfc.section.8.3">8.3.</a> <a href="#option-extra-keys" id="option-extra-keys">Option &#8220;Extra Keys&#8221;</a>
   2.948 +</h1>
   2.949 +<h1 id="rfc.section.8.3.1">
   2.950 +<a href="#rfc.section.8.3.1">8.3.1.</a> <a href="#use-case-for-organizations" id="use-case-for-organizations">Use Case for Organizations</a>
   2.951 +</h1>
   2.952 +<p id="rfc.section.8.3.1.p.1">For internal or enterprise environments, authorized personnel may need to centrally decrypt user messages for archival or other legal purposes.  Therefore, pEp implementers MAY provide an &#8220;Extra Keys&#8221; option in which a message is encrypted with at least one additional public key.  The corresponding secret key(s) are intended to be secured by CISO staff or other authorized personnel for the organization.</p>
   2.953 +<p id="rfc.section.8.3.1.p.2">However, it is crucial that the &#8220;Extra Keys&#8221; feature MUST NOT be activated by default for any network address, and is intended to be an option used only for organization-specific identities, as well as their corresponding network addresses and accounts. The &#8220;Extra Keys&#8221; feature SHOULD NOT be applied to the private identities, addresses, or accounts a user might possess once it is activated.</p>
   2.954 +<h1 id="rfc.section.8.3.2">
   2.955 +<a href="#rfc.section.8.3.2">8.3.2.</a> <a href="#use-case-for-key-synchronization" id="use-case-for-key-synchronization">Use Case for Key Synchronization</a>
   2.956 +</h1>
   2.957 +<p id="rfc.section.8.3.2.p.1">The &#8220;Extra Keys&#8221; feature also plays a role during pEp&#8217;s KeySync protocols, where the additional keys are used to decipher message transactions by both parties involved during the negotiation process for private key synchronization. During the encrypted (but untrusted) transactions, KeySync messages are not just encrypted with the sending device&#8217;s default key, but also with the default keys of both parties involved in the synchronization process.</p>
   2.958 +<h1 id="rfc.section.8.4">
   2.959 +<a href="#rfc.section.8.4">8.4.</a> <a href="#option-blacklist-keys" id="option-blacklist-keys">Option &#8220;Blacklist Keys&#8221;</a>
   2.960 +</h1>
   2.961 +<p id="rfc.section.8.4.p.1">A &#8220;Blacklist Keys&#8221; option MAY be provided for an advanced user, allowing them to disable keys of peers that they no longer want to use in new communications. However, the keys SHALL NOT be deleted. It MUST still be possible to verify and decipher past communications that used these keys.</p>
   2.962 +<h1 id="rfc.section.9">
   2.963 +<a href="#rfc.section.9">9.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
   2.964 +</h1>
   2.965 +<p id="rfc.section.9.p.1">By attaching the sender&#8217;s public key to outgoing messages, Trust on First Use (TOFU) is established. However, this is prone to MITM attacks.  Cryptographic key subversion is considered Pervasive Monitoring (PM) according to <a href="#RFC7258" class="xref">[RFC7258]</a>. Those attacks can be mitigated, if the involved users compare their common Trustwords. This possibility MUST be made easily accessible to pEp users in the user interface implementation. If for compatibility reasons (e.g., with OpenPGP users) no Trustwords can be used, then a comparatively easy way to verify the respective public key fingerprints MUST be implemented.</p>
   2.966 +<p id="rfc.section.9.p.2">As the use of passphrases for private keys is not advised, devices themselves SHOULD use encryption.</p>
   2.967 +<h1 id="rfc.section.10">
   2.968 +<a href="#rfc.section.10">10.</a> <a href="#privacy-considerations" id="privacy-considerations">Privacy Considerations</a>
   2.969 +</h1>
   2.970 +<p id="rfc.section.10.p.1">[[ TODO ]]</p>
   2.971 +<h1 id="rfc.section.11">
   2.972 +<a href="#rfc.section.11">11.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
   2.973 +</h1>
   2.974 +<p id="rfc.section.11.p.1">This document has no actions for IANA.</p>
   2.975 +<h1 id="rfc.section.12">
   2.976 +<a href="#rfc.section.12">12.</a> <a href="#implementation-status" id="implementation-status">Implementation Status</a>
   2.977 +</h1>
   2.978 +<h1 id="rfc.section.12.1">
   2.979 +<a href="#rfc.section.12.1">12.1.</a> <a href="#introduction-1" id="introduction-1">Introduction</a>
   2.980 +</h1>
   2.981 +<p id="rfc.section.12.1.p.1">This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <a href="#RFC7942" class="xref">[RFC7942]</a>.  The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.  This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</p>
   2.982 +<p id="rfc.section.12.1.p.2">According to <a href="#RFC7942" class="xref">[RFC7942]</a>, &#8220;[&#8230;] this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit.&#8221;</p>
   2.983 +<h1 id="rfc.section.12.2">
   2.984 +<a href="#rfc.section.12.2">12.2.</a> <a href="#current-software-implementing-pep" id="current-software-implementing-pep">Current software implementing pEp</a>
   2.985 +</h1>
   2.986 +<p id="rfc.section.12.2.p.1">The following software implementing the pEp protocols (to varying degrees) already exists:</p>
   2.987 +<p></p>
   2.988 +
   2.989 +<ul>
   2.990 +<li>pEp for Outlook as add-on for Microsoft Outlook, release <a href="#SRC.pepforoutlook" class="xref">[SRC.pepforoutlook]</a>
   2.991 +</li>
   2.992 +<li>pEp for Android (based on a fork of the K9 MUA), release <a href="#SRC.pepforandroid" class="xref">[SRC.pepforandroid]</a>
   2.993 +</li>
   2.994 +<li>Enigmail/pEp as add-on for Mozilla Thunderbird, release <a href="#SRC.enigmailpep" class="xref">[SRC.enigmailpep]</a>
   2.995 +</li>
   2.996 +<li>pEp for iOS (implemented in a new MUA), beta <a href="#SRC.pepforios" class="xref">[SRC.pepforios]</a>
   2.997 +</li>
   2.998 +</ul>
   2.999 +<p id="rfc.section.12.2.p.3">pEp for Android, iOS and Outlook are provided by pEp Security, a commercial entity specializing in end-user software implementing pEp while Enigmail/pEp is pursued as community project, supported by the pEp Foundation.</p>
  2.1000 +<p id="rfc.section.12.2.p.4">All software is available as Free Software and published also in source form.</p>
  2.1001 +<h1 id="rfc.section.12.3">
  2.1002 +<a href="#rfc.section.12.3">12.3.</a> <a href="#reference-implementation-of-peps-core" id="reference-implementation-of-peps-core">Reference implementation of pEp&#8217;s core</a>
  2.1003 +</h1>
  2.1004 +<p id="rfc.section.12.3.p.1">The pEp Foundation provides a reference implementation of pEp&#8217;s core principles and functionalities, which go beyond the documentation status of this Internet-Draft. <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a></p>
  2.1005 +<p id="rfc.section.12.3.p.2">pEp&#8217;s reference implementation is composed of pEp Engine and pEp Adapters (or bindings), alongside with some libraries which pEp Engine relies on to function on certain platforms (like a NetPGP fork we maintain for the iOS platform).</p>
  2.1006 +<p id="rfc.section.12.3.p.3">The pEp engine is a Free Software library encapsulating implementations of:</p>
  2.1007 +<p></p>
  2.1008 +
  2.1009 +<ul><li>Key Management</li></ul>
  2.1010 +<p></p>
  2.1011 +
  2.1012 +<ul class="empty"><li>Key Management in pEp engine is based on GnuPG key chains (NetPGP on iOS).  Keys are stored in an OpenPGP compatible format and can be used for different crypto implementations.</li></ul>
  2.1013 +<p></p>
  2.1014 +
  2.1015 +<ul><li>Trust Rating</li></ul>
  2.1016 +<p></p>
  2.1017 +
  2.1018 +<ul class="empty"><li>pEp engine is sporting a two phase trust rating system. In phase one there is a rating based on channel, crypto and key security named &#8220;comm_types&#8221;. In phase 2 these are mapped to user representable values which have attached colors to present them in traffic light semantics.</li></ul>
  2.1019 +<p></p>
  2.1020 +
  2.1021 +<ul><li>Abstract Crypto API</li></ul>
  2.1022 +<p></p>
  2.1023 +
  2.1024 +<ul class="empty"><li>The Abstract Crypto API is providing functions to encrypt and decrypt data or full messages without requiring an application programmer to understand the different formats and standards.</li></ul>
  2.1025 +<p></p>
  2.1026 +
  2.1027 +<ul><li>Message Transports</li></ul>
  2.1028 +<p></p>
  2.1029 +
  2.1030 +<ul class="empty"><li>pEp engine will support a growing list of Message Transports to support any widespread text messaging system including email, SMS, XMPP and many more.</li></ul>
  2.1031 +<p id="rfc.section.12.3.p.12">pEp engine is written in C99 programming language. It is not meant to be used in application code directly. Instead, pEp engine is coming together with a list of software adapters for a variety of programming languages and development environments, which are:</p>
  2.1032 +<p></p>
  2.1033 +
  2.1034 +<ul>
  2.1035 +<li>pEp COM Server Adapter</li>
  2.1036 +<li>pEp JNI Adapter</li>
  2.1037 +<li>pEp JSON Adapter</li>
  2.1038 +<li>pEp ObjC (and Swift) Adapter</li>
  2.1039 +<li>pEp Python Adapter</li>
  2.1040 +<li>pEp Qt Adapter</li>
  2.1041 +</ul>
  2.1042 +<h1 id="rfc.section.12.4">
  2.1043 +<a href="#rfc.section.12.4">12.4.</a> <a href="#abstract-crypto-api-examples" id="abstract-crypto-api-examples">Abstract Crypto API examples</a>
  2.1044 +</h1>
  2.1045 +<p id="rfc.section.12.4.p.1">A selection of code excerpts from the pEp Engine reference implementation (encrypt message, decrypt message, and obtain trustwords) can be found in <a href="#abstract-crypto-api-examples-1" class="xref">Appendix A.3</a>.</p>
  2.1046 +<h1 id="rfc.section.13">
  2.1047 +<a href="#rfc.section.13">13.</a> <a href="#notes" id="notes">Notes</a>
  2.1048 +</h1>
  2.1049 +<p id="rfc.section.13.p.1">The pEp logo and &#8220;pretty Easy privacy&#8221; are registered trademarks owned by the non-profit pEp Foundation based in Switzerland.</p>
  2.1050 +<p id="rfc.section.13.p.2">Primarily, we want to ensure the following:</p>
  2.1051 +<p></p>
  2.1052 +
  2.1053 +<ul>
  2.1054 +<li>Software using the trademarks MUST be backdoor-free.</li>
  2.1055 +<li>Software using the trademarks MUST be accompanied by a serious (detailed) code audit carried out by a reputable third-party, for any proper release.</li>
  2.1056 +</ul>
  2.1057 +<p id="rfc.section.13.p.4">The pEp Foundation will help to support any community-run (non-commercial) project with the latter, be it organizationally or financially.</p>
  2.1058 +<p id="rfc.section.13.p.5">Through this, the foundation wants to make sure that software using the pEp trademarks is as safe as possible from a security and privacy point of view.</p>
  2.1059 +<h1 id="rfc.section.14">
  2.1060 +<a href="#rfc.section.14">14.</a> <a href="#acknowledgments" id="acknowledgments">Acknowledgments</a>
  2.1061 +</h1>
  2.1062 +<p id="rfc.section.14.p.1">The authors would like to thank the following people who provided substantial contributions, helpful comments or suggestions for this document: Alexey Melnikov, Athena Schumacher, Ben Campbell, Brian Trammell, Bron Gondwana, Claudio Luck, Daniel Kahn Gillmor, Enrico Tomae, Eric Rescorla, Gabriele Lenzini, Hans-Peter Dittler, Iraklis Symeonidis, Kelly Bristol, Krista Bennett, Mirja Kuehlewind, Nana Kerlstetter, Neal Walfield, Pete Resnick, Russ Housley, S. Shelburn, and Stephen Farrel.</p>
  2.1063 +<p id="rfc.section.14.p.2">This work was initially created by pEp Foundation, and then reviewed and extended with funding by the Internet Society&#8217;s Beyond the Net Programme on standardizing pEp. <a href="#ISOC.bnet" class="xref">[ISOC.bnet]</a></p>
  2.1064 +<h1 id="rfc.references">
  2.1065 +<a href="#rfc.references">15.</a> References</h1>
  2.1066 +<h1 id="rfc.references.1">
  2.1067 +<a href="#rfc.references.1">15.1.</a> Normative References</h1>
  2.1068 +<table><tbody>
  2.1069 +<tr>
  2.1070 +<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
  2.1071 +<td class="top">
  2.1072 +<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
  2.1073 +</tr>
  2.1074 +<tr>
  2.1075 +<td class="reference"><b id="RFC4949">[RFC4949]</b></td>
  2.1076 +<td class="top">
  2.1077 +<a>Shirey, R.</a>, "<a href="https://tools.ietf.org/html/rfc4949">Internet Security Glossary, Version 2</a>", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.</td>
  2.1078 +</tr>
  2.1079 +<tr>
  2.1080 +<td class="reference"><b id="RFC7435">[RFC7435]</b></td>
  2.1081 +<td class="top">
  2.1082 +<a>Dukhovni, V.</a>, "<a href="https://tools.ietf.org/html/rfc7435">Opportunistic Security: Some Protection Most of the Time</a>", RFC 7435, DOI 10.17487/RFC7435, December 2014.</td>
  2.1083 +</tr>
  2.1084 +</tbody></table>
  2.1085 +<h1 id="rfc.references.2">
  2.1086 +<a href="#rfc.references.2">15.2.</a> Informative References</h1>
  2.1087 +<table><tbody>
  2.1088 +<tr>
  2.1089 +<td class="reference"><b id="I-D.birk-pep-trustwords">[I-D.birk-pep-trustwords]</b></td>
  2.1090 +<td class="top">
  2.1091 +<a>Hoeneisen, B.</a> and <a>H. Marques</a>, "<a href="https://tools.ietf.org/html/draft-birk-pep-trustwords-04">IANA Registration of Trustword Lists: Guide, Template and IANA Considerations</a>", Internet-Draft draft-birk-pep-trustwords-04, July 2019.</td>
  2.1092 +</tr>
  2.1093 +<tr>
  2.1094 +<td class="reference"><b id="I-D.hoeneisen-pep-keysync">[I-D.hoeneisen-pep-keysync]</b></td>
  2.1095 +<td class="top">
  2.1096 +<a>Hoeneisen, B.</a>, <a>Marques, H.</a> and <a>K. Bristol</a>, "<a href="https://tools.ietf.org/html/draft-hoeneisen-pep-keysync-01">pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync)</a>", Internet-Draft draft-hoeneisen-pep-keysync-01, October 2019.</td>
  2.1097 +</tr>
  2.1098 +<tr>
  2.1099 +<td class="reference"><b id="I-D.marques-pep-email">[I-D.marques-pep-email]</b></td>
  2.1100 +<td class="top">
  2.1101 +<a>Marques, H.</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-email-02">pretty Easy privacy (pEp): Email Formats and Protocols</a>", Internet-Draft draft-marques-pep-email-02, October 2018.</td>
  2.1102 +</tr>
  2.1103 +<tr>
  2.1104 +<td class="reference"><b id="I-D.marques-pep-handshake">[I-D.marques-pep-handshake]</b></td>
  2.1105 +<td class="top">
  2.1106 +<a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-handshake-03">pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake</a>", Internet-Draft draft-marques-pep-handshake-03, July 2019.</td>
  2.1107 +</tr>
  2.1108 +<tr>
  2.1109 +<td class="reference"><b id="I-D.marques-pep-rating">[I-D.marques-pep-rating]</b></td>
  2.1110 +<td class="top">
  2.1111 +<a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-rating-02">pretty Easy privacy (pEp): Mapping of Privacy Rating</a>", Internet-Draft draft-marques-pep-rating-02, July 2019.</td>
  2.1112 +</tr>
  2.1113 +<tr>
  2.1114 +<td class="reference"><b id="ISOC.bnet">[ISOC.bnet]</b></td>
  2.1115 +<td class="top">
  2.1116 +<a>Simao, I.</a>, "<a href="https://www.internetsociety.org/blog/2017/06/12-innovative-projects-selected-for-beyond-the-net-funding/">Beyond the Net. 12 Innovative Projects Selected for Beyond the Net Funding. Implementing Privacy via Mass Encryption: Standardizing pretty Easy privacy&#8217;s protocols</a>", June 2017.</td>
  2.1117 +</tr>
  2.1118 +<tr>
  2.1119 +<td class="reference"><b id="OpenPGP">[OpenPGP]</b></td>
  2.1120 +<td class="top">
  2.1121 +<a>Callas, J.</a>, <a>Donnerhacke, L.</a>, <a>Finney, H.</a>, <a>Shaw, D.</a> and <a>R. Thayer</a>, "<a href="https://tools.ietf.org/html/rfc4880">OpenPGP Message Format</a>", RFC 4880, DOI 10.17487/RFC4880, November 2007.</td>
  2.1122 +</tr>
  2.1123 +<tr>
  2.1124 +<td class="reference"><b id="RFC1122">[RFC1122]</b></td>
  2.1125 +<td class="top">
  2.1126 +<a>Braden, R.</a>, "<a href="https://tools.ietf.org/html/rfc1122">Requirements for Internet Hosts - Communication Layers</a>", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989.</td>
  2.1127 +</tr>
  2.1128 +<tr>
  2.1129 +<td class="reference"><b id="RFC7258">[RFC7258]</b></td>
  2.1130 +<td class="top">
  2.1131 +<a>Farrell, S.</a> and <a>H. Tschofenig</a>, "<a href="https://tools.ietf.org/html/rfc7258">Pervasive Monitoring Is an Attack</a>", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014.</td>
  2.1132 +</tr>
  2.1133 +<tr>
  2.1134 +<td class="reference"><b id="RFC7942">[RFC7942]</b></td>
  2.1135 +<td class="top">
  2.1136 +<a>Sheffer, Y.</a> and <a>A. Farrel</a>, "<a href="https://tools.ietf.org/html/rfc7942">Improving Awareness of Running Code: The Implementation Status Section</a>", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016.</td>
  2.1137 +</tr>
  2.1138 +<tr>
  2.1139 +<td class="reference"><b id="RFC8280">[RFC8280]</b></td>
  2.1140 +<td class="top">
  2.1141 +<a>ten Oever, N.</a> and <a>C. Cath</a>, "<a href="https://tools.ietf.org/html/rfc8280">Research into Human Rights Protocol Considerations</a>", RFC 8280, DOI 10.17487/RFC8280, October 2017.</td>
  2.1142 +</tr>
  2.1143 +<tr>
  2.1144 +<td class="reference"><b id="SRC.enigmailpep">[SRC.enigmailpep]</b></td>
  2.1145 +<td class="top">"<a href="https://enigmail.net/index.php/en/download/source-code">Source code for Enigmail/pEp</a>", July 2019.</td>
  2.1146 +</tr>
  2.1147 +<tr>
  2.1148 +<td class="reference"><b id="SRC.pepcore">[SRC.pepcore]</b></td>
  2.1149 +<td class="top">"<a href="https://pep.foundation/dev/">Core source code and reference implementation of pEp (engine and adapters)</a>", July 2018.</td>
  2.1150 +</tr>
  2.1151 +<tr>
  2.1152 +<td class="reference"><b id="SRC.pepforandroid">[SRC.pepforandroid]</b></td>
  2.1153 +<td class="top">"<a href="https://pep-security.lu/gitlab/android/pep">Source code for pEp for Android</a>", July 2019.</td>
  2.1154 +</tr>
  2.1155 +<tr>
  2.1156 +<td class="reference"><b id="SRC.pepforios">[SRC.pepforios]</b></td>
  2.1157 +<td class="top">"<a href="https://pep-security.ch/dev/repos/pEp_for_iOS/">Source code for pEp for iOS</a>", July 2019.</td>
  2.1158 +</tr>
  2.1159 +<tr>
  2.1160 +<td class="reference"><b id="SRC.pepforoutlook">[SRC.pepforoutlook]</b></td>
  2.1161 +<td class="top">"<a href="https://pep-security.lu/dev/repos/pEp_for_Outlook/">Source code for pEp for Outlook</a>", July 2019.</td>
  2.1162 +</tr>
  2.1163 +</tbody></table>
  2.1164 +<h1 id="rfc.appendix.A">
  2.1165 +<a href="#rfc.appendix.A">Appendix A.</a> <a href="#code-excerpts" id="code-excerpts">Code Excerpts</a>
  2.1166 +</h1>
  2.1167 +<p id="rfc.section.A.p.1">This section provides excerpts of the running code from the pEp reference implementation pEp engine (C99 programming language).</p>
  2.1168 +<h1 id="rfc.appendix.A.1">
  2.1169 +<a href="#rfc.appendix.A.1">A.1.</a> <a href="#pep-identity" id="pep-identity">pEp Identity</a>
  2.1170 +</h1>
  2.1171 +<p id="rfc.section.A.1.p.1">How the pEp identity is defined in the data structure (cf. src/pEpEngine.h):</p>
  2.1172 +<pre>
  2.1173 +typedef struct _pEp_identity {
  2.1174 +    char *address;            // C string with address UTF-8 encoded
  2.1175 +    char *fpr;                // C string with fingerprint UTF-8
  2.1176 +                              // encoded
  2.1177 +    char *user_id;            // C string with user ID UTF-8 encoded
  2.1178 +    char *username;           // C string with user name UTF-8
  2.1179 +                              // encoded
  2.1180 +    PEP_comm_type comm_type;  // type of communication with this ID
  2.1181 +    char lang[3];             // language of conversation
  2.1182 +                              // ISO 639-1 ALPHA-2, last byte is 0
  2.1183 +    bool me;                  // if this is the local user
  2.1184 +                              // herself/himself
  2.1185 +    identity_flags_t flags;   // identity_flag1 | identity_flag2
  2.1186 +                              // | ...
  2.1187 +} pEp_identity;
  2.1188 +</pre>
  2.1189 +<h1 id="rfc.appendix.A.1.1">
  2.1190 +<a href="#rfc.appendix.A.1.1">A.1.1.</a> <a href="#corresponding-sql" id="corresponding-sql">Corresponding SQL</a>
  2.1191 +</h1>
  2.1192 +<p id="rfc.section.A.1.1.p.1">Relational table scheme excerpts (in SQL) used in current pEp implementations, held locally for every pEp installation in a SQLite database:</p>
  2.1193 +<pre>
  2.1194 +CREATE TABLE person (
  2.1195 +   id text primary key,
  2.1196 +   username text not null,
  2.1197 +   main_key_id text
  2.1198 +       references pgp_keypair (fpr)
  2.1199 +       on delete set null,
  2.1200 +   lang text,
  2.1201 +   comment text,
  2.1202 +   device_group text,
  2.1203 +   is_pep_user integer default 0
  2.1204 +);
  2.1205 +
  2.1206 +CREATE TABLE identity (
  2.1207 +   address text,
  2.1208 +   user_id text
  2.1209 +       references person (id)
  2.1210 +       on delete cascade on update cascade,
  2.1211 +   main_key_id text
  2.1212 +       references pgp_keypair (fpr)
  2.1213 +       on delete set null,
  2.1214 +   comment text,
  2.1215 +   flags integer default 0,
  2.1216 +   is_own integer default 0,
  2.1217 +   timestamp integer default (datetime('now')),
  2.1218 +   primary key (address, user_id)
  2.1219 +);
  2.1220 +
  2.1221 +CREATE TABLE pgp_keypair (
  2.1222 +   fpr text primary key,
  2.1223 +   created integer,
  2.1224 +   expires integer,
  2.1225 +   comment text,
  2.1226 +   flags integer default 0
  2.1227 +);
  2.1228 +CREATE INDEX pgp_keypair_expires on pgp_keypair (
  2.1229 +   expires
  2.1230 +);
  2.1231 +</pre>
  2.1232 +<h1 id="rfc.appendix.A.2">
  2.1233 +<a href="#rfc.appendix.A.2">A.2.</a> <a href="#pep-communication-type" id="pep-communication-type">pEp Communication Type</a>
  2.1234 +</h1>
  2.1235 +<p id="rfc.section.A.2.p.1">In the following, is an example for the rating of communication types as defined by a data structure (cf. src/pEpEngine.h <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a>):</p>
  2.1236 +<pre>
  2.1237 +typedef enum _PEP_comm_type {
  2.1238 +    PEP_ct_unknown = 0,
  2.1239 +
  2.1240 +    // range 0x01 to 0x09: no encryption, 0x0a to 0x0e:
  2.1241 +    // nothing reasonable
  2.1242 +
  2.1243 +    PEP_ct_no_encryption = 0x01, // generic
  2.1244 +    PEP_ct_no_encrypted_channel = 0x02,
  2.1245 +    PEP_ct_key_not_found = 0x03,
  2.1246 +    PEP_ct_key_expired = 0x04,
  2.1247 +    PEP_ct_key_revoked = 0x05,
  2.1248 +    PEP_ct_key_b0rken = 0x06,
  2.1249 +    PEP_ct_my_key_not_included = 0x09,
  2.1250 +
  2.1251 +    PEP_ct_security_by_obscurity = 0x0a,
  2.1252 +    PEP_ct_b0rken_crypto = 0x0b,
  2.1253 +    PEP_ct_key_too_short = 0x0c,
  2.1254 +
  2.1255 +    PEP_ct_compromized = 0x0e, // known compromized connection
  2.1256 +    PEP_ct_mistrusted = 0x0f, // known mistrusted key
  2.1257 +
  2.1258 +    // range 0x10 to 0x3f: unconfirmed encryption
  2.1259 +
  2.1260 +    PEP_ct_unconfirmed_encryption = 0x10, // generic
  2.1261 +    PEP_ct_OpenPGP_weak_unconfirmed = 0x11, // RSA 1024 is weak
  2.1262 +
  2.1263 +    PEP_ct_to_be_checked = 0x20, // generic
  2.1264 +    PEP_ct_SMIME_unconfirmed = 0x21,
  2.1265 +    PEP_ct_CMS_unconfirmed = 0x22,
  2.1266 +
  2.1267 +    PEP_ct_strong_but_unconfirmed = 0x30, // generic
  2.1268 +    PEP_ct_OpenPGP_unconfirmed = 0x38, // key at least 2048 bit
  2.1269 +                                       // RSA or EC
  2.1270 +    PEP_ct_OTR_unconfirmed = 0x3a,
  2.1271 +
  2.1272 +    // range 0x40 to 0x7f: unconfirmed encryption and anonymization
  2.1273 +
  2.1274 +    PEP_ct_unconfirmed_enc_anon = 0x40, // generic
  2.1275 +    PEP_ct_pEp_unconfirmed = 0x7f,
  2.1276 +
  2.1277 +    PEP_ct_confirmed = 0x80, // this bit decides if trust
  2.1278 +                             // is confirmed
  2.1279 +
  2.1280 +    // range 0x81 to 0x8f: reserved
  2.1281 +    // range 0x90 to 0xbf: confirmed encryption
  2.1282 +
  2.1283 +    PEP_ct_confirmed_encryption = 0x90, // generic
  2.1284 +    PEP_ct_OpenPGP_weak = 0x91, // RSA 1024 is weak (unused)
  2.1285 +
  2.1286 +    PEP_ct_to_be_checked_confirmed = 0xa0, //generic
  2.1287 +    PEP_ct_SMIME = 0xa1,
  2.1288 +    PEP_ct_CMS = 0xa2,
  2.1289 +
  2.1290 +    PEP_ct_strong_encryption = 0xb0, // generic
  2.1291 +    PEP_ct_OpenPGP = 0xb8, // key at least 2048 bit RSA or EC
  2.1292 +    PEP_ct_OTR = 0xba,
  2.1293 +
  2.1294 +    // range 0xc0 to 0xff: confirmed encryption and anonymization
  2.1295 +
  2.1296 +    PEP_ct_confirmed_enc_anon = 0xc0, // generic
  2.1297 +    PEP_ct_pEp = 0xff
  2.1298 +} PEP_comm_type;
  2.1299 +</pre>
  2.1300 +<h1 id="rfc.appendix.A.3">
  2.1301 +<a href="#rfc.appendix.A.3">A.3.</a> <a href="#abstract-crypto-api-examples-1" id="abstract-crypto-api-examples-1">Abstract Crypto API examples</a>
  2.1302 +</h1>
  2.1303 +<p id="rfc.section.A.3.p.1">The following code excerpts are from the pEp Engine reference implementation, to be found in src/message_api.h.</p>
  2.1304 +<p id="rfc.section.A.3.p.2">[[ Note: Just a selection; more functionality is available. ]]</p>
  2.1305 +<h1 id="rfc.appendix.A.3.1">
  2.1306 +<a href="#rfc.appendix.A.3.1">A.3.1.</a> <a href="#encrypting-a-message" id="encrypting-a-message">Encrypting a Message</a>
  2.1307 +</h1>
  2.1308 +<p id="rfc.section.A.3.1.p.1">Cf. src/message_api.h <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a>:</p>
  2.1309 +<pre>
  2.1310 +// encrypt_message() - encrypt message in memory
  2.1311 +//
  2.1312 +//  parameters:
  2.1313 +//      session (in)     session handle
  2.1314 +//      src (in)         message to encrypt
  2.1315 +//      extra (in)       extra keys for encryption
  2.1316 +//      dst (out)        pointer to new encrypted message or NULL if
  2.1317 +//                       no encryption could take place
  2.1318 +//      enc_format (in)  encrypted format
  2.1319 +//      flags (in)       flags to set special encryption features
  2.1320 +//
  2.1321 +//  return value:
  2.1322 +//      PEP_STATUS_OK           on success
  2.1323 +//      PEP_KEY_HAS_AMBIG_NAME  at least one of the recipient
  2.1324 +//                              keys has an ambiguous name
  2.1325 +//      PEP_UNENCRYPTED         no recipients with usable key, 
  2.1326 +//                              message is left unencrypted,
  2.1327 +//                              and key is attached to it
  2.1328 +//
  2.1329 +//  caveat:
  2.1330 +//      the ownership of src remains with the caller
  2.1331 +//      the ownership of dst goes to the caller
  2.1332 +DYNAMIC_API PEP_STATUS encrypt_message(
  2.1333 +        PEP_SESSION session,
  2.1334 +        message *src,
  2.1335 +        stringlist_t *extra,
  2.1336 +        message **dst,
  2.1337 +        PEP_enc_format enc_format,
  2.1338 +        PEP_encrypt_flags_t flags
  2.1339 +);
  2.1340 +</pre>
  2.1341 +<p id="rfc.section.A.3.1.p.2">Cf. src/message_api.h <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a>:</p>
  2.1342 +<h1 id="rfc.appendix.A.3.2">
  2.1343 +<a href="#rfc.appendix.A.3.2">A.3.2.</a> <a href="#decrypting-a-message" id="decrypting-a-message">Decrypting a Message</a>
  2.1344 +</h1>
  2.1345 +<p id="rfc.section.A.3.2.p.1">Cf. src/message_api.h <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a>:</p>
  2.1346 +<pre>
  2.1347 +// decrypt_message() - decrypt message in memory
  2.1348 +//
  2.1349 +//  parameters:
  2.1350 +//      session (in)   session handle
  2.1351 +//      src (in)       message to decrypt
  2.1352 +//      dst (out)      pointer to new decrypted message
  2.1353 +//                     or NULL on failure
  2.1354 +//      keylist (out)  stringlist with keyids
  2.1355 +//      rating (out)   rating for the message
  2.1356 +//      flags (out)    flags to signal special decryption features
  2.1357 +//
  2.1358 +//  return value:
  2.1359 +//      error status 
  2.1360 +//      or PEP_DECRYPTED if message decrypted but not verified
  2.1361 +//      or PEP_CANNOT_REENCRYPT if message was decrypted (and
  2.1362 +//         possibly verified) but a reencryption operation is
  2.1363 +//         expected by the caller and failed
  2.1364 +//      or PEP_STATUS_OK on success
  2.1365 +//
  2.1366 +//  flag values:
  2.1367 +//      in:
  2.1368 +//          PEP_decrypt_flag_untrusted_server
  2.1369 +//              used to signal that decrypt function should engage in 
  2.1370 +//              behaviour specified for when the server storing the 
  2.1371 +//              source is untrusted
  2.1372 +//      out:
  2.1373 +//          PEP_decrypt_flag_own_private_key
  2.1374 +//              private key was imported for one of our addresses
  2.1375 +//              (NOT trusted or set to be used - handshake/trust is
  2.1376 +//              required for that)
  2.1377 +//          PEP_decrypt_flag_src_modified
  2.1378 +//              indicates that the src object has been modified. At
  2.1379 +//              the moment, this is always as a direct result of the 
  2.1380 +//              behaviour driven by the input flags. This flag is the 
  2.1381 +//              ONLY value that should be relied upon to see if such 
  2.1382 +//              changes have taken place.
  2.1383 +//          PEP_decrypt_flag_consume
  2.1384 +//              used by sync 
  2.1385 +//          PEP_decrypt_flag_ignore
  2.1386 +//              used by sync 
  2.1387 +//
  2.1388 +//
  2.1389 +// caveat:
  2.1390 +//      the ownership of src remains with the caller - however, the
  2.1391 +//      contents might be modified (strings freed and allocated anew 
  2.1392 +//      or set to NULL, etc) intentionally; when this happens,
  2.1393 +//      PEP_decrypt_flag_src_modified is set.
  2.1394 +//      the ownership of dst goes to the caller
  2.1395 +//      the ownership of keylist goes to the caller
  2.1396 +//      if src is unencrypted this function returns PEP_UNENCRYPTED
  2.1397 +//      and sets
  2.1398 +//      dst to NULL
  2.1399 +DYNAMIC_API PEP_STATUS decrypt_message(
  2.1400 +        PEP_SESSION session,
  2.1401 +        message *src,
  2.1402 +        message **dst,
  2.1403 +        stringlist_t **keylist,
  2.1404 +        PEP_rating *rating,
  2.1405 +        PEP_decrypt_flags_t *flags
  2.1406 +);
  2.1407 +</pre>
  2.1408 +<h1 id="rfc.appendix.A.3.3">
  2.1409 +<a href="#rfc.appendix.A.3.3">A.3.3.</a> <a href="#obtain-common-trustwords" id="obtain-common-trustwords">Obtain Common Trustwords</a>
  2.1410 +</h1>
  2.1411 +<p id="rfc.section.A.3.3.p.1">Cf. src/message_api.h <a href="#SRC.pepcore" class="xref">[SRC.pepcore]</a>:</p>
  2.1412 +<pre>
  2.1413 +// get_trustwords() - get full trustwords string
  2.1414 +//                    for a *pair* of identities
  2.1415 +//
  2.1416 +//    parameters:
  2.1417 +//        session (in)  session handle
  2.1418 +//        id1 (in)      identity of first party in communication
  2.1419 +//                      - fpr can't be NULL  
  2.1420 +//        id2 (in)      identity of second party in communication
  2.1421 +//                      - fpr can't be NULL
  2.1422 +//        lang (in)     C string with ISO 639-1 language code
  2.1423 +//        words (out)   pointer to C string with all trustwords
  2.1424 +//                      UTF-8 encoded, separated by a blank each
  2.1425 +//                      NULL if language is not supported or
  2.1426 +//                      trustword wordlist is damaged or unavailable
  2.1427 +//        wsize (out)   length of full trustwords string
  2.1428 +//        full (in)     if true, generate ALL trustwords for these
  2.1429 +//                      identities.
  2.1430 +//                      else, generate a fixed-size subset.
  2.1431 +//                      (TODO: fixed-minimum-entropy subset
  2.1432 +//                      in next version)
  2.1433 +//
  2.1434 +//    return value:
  2.1435 +//        PEP_STATUS_OK            trustwords retrieved
  2.1436 +//        PEP_OUT_OF_MEMORY        out of memory
  2.1437 +//        PEP_TRUSTWORD_NOT_FOUND  at least one trustword not found
  2.1438 +//
  2.1439 +//    caveat:
  2.1440 +//        the word pointer goes to the ownership of the caller
  2.1441 +//        the caller is responsible to free() it
  2.1442 +//        (on Windoze use pEp_free())
  2.1443 +//
  2.1444 +DYNAMIC_API PEP_STATUS get_trustwords(
  2.1445 +  PEP_SESSION session, const pEp_identity* id1,
  2.1446 +  const pEp_identity* id2, const char* lang,
  2.1447 +  char **words, size_t *wsize, bool full
  2.1448 +);
  2.1449 +</pre>
  2.1450 +<h1 id="rfc.appendix.B">
  2.1451 +<a href="#rfc.appendix.B">Appendix B.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
  2.1452 +</h1>
  2.1453 +<p id="rfc.section.B.p.1">[[ RFC Editor: This section is to be removed before publication ]]</p>
  2.1454 +<p></p>
  2.1455 +
  2.1456 +<ul>
  2.1457 +<li>draft-birk-pep-05: <ul>
  2.1458 +<li>Change authors</li>
  2.1459 +<li>Minor changes, especially in identity system</li>
  2.1460 +</ul>
  2.1461 +</li>
  2.1462 +<li>draft-birk-pep-04: <ul>
  2.1463 +<li>Fix internal reference</li>
  2.1464 +<li>Add IANA Considerations section</li>
  2.1465 +<li>Add other use case of Extra Keys</li>
  2.1466 +<li>Add Claudio Luck as author</li>
  2.1467 +<li>Incorporate review changes by Kelly Bristol and Nana Karlstetter</li>
  2.1468 +</ul>
  2.1469 +</li>
  2.1470 +<li>draft-birk-pep-03: <ul>
  2.1471 +<li>Major restructure of the document</li>
  2.1472 +<li>Adapt authors to the actual authors and extend Acknowledgments section</li>
  2.1473 +<li>Added several new sections, e.g., Key Reset, Trust Revoke, Trust Synchronization, Private Key Export / Import, Privacy Considerations (content yet mostly TODO)</li>
  2.1474 +<li>Added reference to HRPC work / RFC8280 <ul><li>Added text and figure to better explain pEp&#8217;s automated Key Exchange and Trust management (basic message flow)</li></ul>
  2.1475 +</li>
  2.1476 +<li>Lots of improvement in text and editorial changes</li>
  2.1477 +</ul>
  2.1478 +</li>
  2.1479 +<li>draft-birk-pep-02: <ul>
  2.1480 +<li>Move (updated) code to Appendix</li>
  2.1481 +<li>Add Changelog to Appendix</li>
  2.1482 +<li>Add Open Issue section to Appendix</li>
  2.1483 +<li>Fix description of what Extra Keys are</li>
  2.1484 +<li>Fix Passive Mode description</li>
  2.1485 +<li>Better explain pEp&#8217;s identity system</li>
  2.1486 +</ul>
  2.1487 +</li>
  2.1488 +<li>draft-birk-pep-01: <ul><li>Mostly editorial</li></ul>
  2.1489 +</li>
  2.1490 +<li>draft-birk-pep-00: <ul><li>Initial version</li></ul>
  2.1491 +</li>
  2.1492 +</ul>
  2.1493 +<h1 id="rfc.appendix.C">
  2.1494 +<a href="#rfc.appendix.C">Appendix C.</a> <a href="#open-issues" id="open-issues">Open Issues</a>
  2.1495 +</h1>
  2.1496 +<p id="rfc.section.C.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication ]]</p>
  2.1497 +<p></p>
  2.1498 +
  2.1499 +<ul>
  2.1500 +<li>Shorten Introduction and Abstract</li>
  2.1501 +<li>References to RFC6973 (Privacy Considerations)</li>
  2.1502 +<li>Add references to prior work, and what differs here - PEM (cf. RFC1421-1424)</li>
  2.1503 +<li>Better explain Passive Mode</li>
  2.1504 +<li>Better explain / illustrate pEp&#8217;s identity system</li>
  2.1505 +<li>Explain Concept of Key Mapping (e.g. to S&#8203;/&#8203;MIME, which is to be refined in pEp application docs auch as pEp email <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>)</li>
  2.1506 +<li>Add more information to deal with organizational requirements</li>
  2.1507 +<li>Add text to Key Reset (<a href="#key-reset" class="xref">Section 4.3</a>) as well as reference as soon as available</li>
  2.1508 +<li>Add text to Trust Revoke (<a href="#trust-revoke" class="xref">Section 5.4</a>) as well as reference as soon as available</li>
  2.1509 +<li>Add text to Trust Synchronization (<a href="#trust-synchronization" class="xref">Section 6.2</a>) as well as reference as soon as available</li>
  2.1510 +</ul>
  2.1511 +<p></p>
  2.1512 +
  2.1513 +<ul>
  2.1514 +<li>Add text to Privacy Considerations (<a href="#privacy-considerations" class="xref">Section 10</a>)</li>
  2.1515 +<li>Scan for leftovers of email-specific stuff and move it to pEp email I-D <a href="#I-D.marques-pep-email" class="xref">[I-D.marques-pep-email]</a>, while replacing it herein with generic descriptions.</li>
  2.1516 +</ul>
  2.1517 +<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
  2.1518 +<div class="avoidbreak">
  2.1519 +  <address class="vcard">
  2.1520 +	<span class="vcardline">
  2.1521 +	  <span class="fn">Volker Birk</span> 
  2.1522 +	  <span class="n hidden">
  2.1523 +		<span class="family-name">Birk</span>
  2.1524 +	  </span>
  2.1525 +	</span>
  2.1526 +	<span class="org vcardline">pEp Foundation</span>
  2.1527 +	<span class="adr">
  2.1528 +	  <span class="vcardline">Oberer Graben 4</span>
  2.1529 +
  2.1530 +	  <span class="vcardline">
  2.1531 +		<span class="locality">CH-8400 Winterthur</span>,  
  2.1532 +		<span class="region"></span>
  2.1533 +		<span class="code"></span>
  2.1534 +	  </span>
  2.1535 +	  <span class="country-name vcardline">Switzerland</span>
  2.1536 +	</span>
  2.1537 +	<span class="vcardline">EMail: <a href="mailto:volker.birk@pep.foundation">volker.birk@pep.foundation</a></span>
  2.1538 +
  2.1539 +<span class="vcardline">URI: <a href="https://pep.foundation/">https://pep.foundation/</a></span>
  2.1540 +
  2.1541 +  </address>
  2.1542 +</div><div class="avoidbreak">
  2.1543 +  <address class="vcard">
  2.1544 +	<span class="vcardline">
  2.1545 +	  <span class="fn">Hernani Marques</span> 
  2.1546 +	  <span class="n hidden">
  2.1547 +		<span class="family-name">Marques</span>
  2.1548 +	  </span>
  2.1549 +	</span>
  2.1550 +	<span class="org vcardline">pEp Foundation</span>
  2.1551 +	<span class="adr">
  2.1552 +	  <span class="vcardline">Oberer Graben 4</span>
  2.1553 +
  2.1554 +	  <span class="vcardline">
  2.1555 +		<span class="locality">CH-8400 Winterthur</span>,  
  2.1556 +		<span class="region"></span>
  2.1557 +		<span class="code"></span>
  2.1558 +	  </span>
  2.1559 +	  <span class="country-name vcardline">Switzerland</span>
  2.1560 +	</span>
  2.1561 +	<span class="vcardline">EMail: <a href="mailto:hernani.marques@pep.foundation">hernani.marques@pep.foundation</a></span>
  2.1562 +
  2.1563 +<span class="vcardline">URI: <a href="https://pep.foundation/">https://pep.foundation/</a></span>
  2.1564 +
  2.1565 +  </address>
  2.1566 +</div><div class="avoidbreak">
  2.1567 +  <address class="vcard">
  2.1568 +	<span class="vcardline">
  2.1569 +	  <span class="fn">Bernie Hoeneisen</span> 
  2.1570 +	  <span class="n hidden">
  2.1571 +		<span class="family-name">Hoeneisen</span>
  2.1572 +	  </span>
  2.1573 +	</span>
  2.1574 +	<span class="org vcardline">pEp Foundation</span>
  2.1575 +	<span class="adr">
  2.1576 +	  <span class="vcardline">Oberer Graben 4</span>
  2.1577 +
  2.1578 +	  <span class="vcardline">
  2.1579 +		<span class="locality">CH-8400 Winterthur</span>,  
  2.1580 +		<span class="region"></span>
  2.1581 +		<span class="code"></span>
  2.1582 +	  </span>
  2.1583 +	  <span class="country-name vcardline">Switzerland</span>
  2.1584 +	</span>
  2.1585 +	<span class="vcardline">EMail: <a href="mailto:bernie.hoeneisen@pep.foundation">bernie.hoeneisen@pep.foundation</a></span>
  2.1586 +
  2.1587 +<span class="vcardline">URI: <a href="https://pep.foundation/">https://pep.foundation/</a></span>
  2.1588 +
  2.1589 +  </address>
  2.1590 +</div>
  2.1591 +
  2.1592 +</body>
  2.1593 +</html>
     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/pep/archive/draft-birk-pep-05.txt	Mon Nov 04 22:57:49 2019 +0100
     3.3 @@ -0,0 +1,1848 @@
     3.4 +
     3.5 +
     3.6 +
     3.7 +
     3.8 +Network Working Group                                            V. Birk
     3.9 +Internet-Draft                                                H. Marques
    3.10 +Intended status: Standards Track                            B. Hoeneisen
    3.11 +Expires: May 7, 2020                                      pEp Foundation
    3.12 +                                                       November 04, 2019
    3.13 +
    3.14 +
    3.15 +             pretty Easy privacy (pEp): Privacy by Default
    3.16 +                           draft-birk-pep-05
    3.17 +
    3.18 +Abstract
    3.19 +
    3.20 +   The pretty Easy privacy (pEp) model and protocols describe a set of
    3.21 +   conventions for the automation of operations traditionally seen as
    3.22 +   barriers to the use and deployment of secure, privacy-preserving end-
    3.23 +   to-end interpersonal messaging.  These include, but are not limited
    3.24 +   to, key management, key discovery, and private key handling
    3.25 +   (including peer-to-peer synchronization of private keys and other
    3.26 +   user data across devices).  Human Rights-enabling principles like
    3.27 +   Data Minimization, End-to-End and Interoperability are explicit
    3.28 +   design goals.  For the goal of usable privacy, pEp introduces means
    3.29 +   to verify communication between peers and proposes a trust-rating
    3.30 +   system to denote secure types of communications and signal the
    3.31 +   privacy level available on a per-user and per-message level.
    3.32 +   Significantly, the pEp protocols build on already available security
    3.33 +   formats and message transports (e.g., PGP/MIME with email), and are
    3.34 +   written with the intent to be interoperable with already widely-
    3.35 +   deployed systems in order to ease adoption and implementation.  This
    3.36 +   document outlines the general design choices and principles of pEp.
    3.37 +
    3.38 +Status of This Memo
    3.39 +
    3.40 +   This Internet-Draft is submitted in full conformance with the
    3.41 +   provisions of BCP 78 and BCP 79.
    3.42 +
    3.43 +   Internet-Drafts are working documents of the Internet Engineering
    3.44 +   Task Force (IETF).  Note that other groups may also distribute
    3.45 +   working documents as Internet-Drafts.  The list of current Internet-
    3.46 +   Drafts is at https://datatracker.ietf.org/drafts/current/.
    3.47 +
    3.48 +   Internet-Drafts are draft documents valid for a maximum of six months
    3.49 +   and may be updated, replaced, or obsoleted by other documents at any
    3.50 +   time.  It is inappropriate to use Internet-Drafts as reference
    3.51 +   material or to cite them other than as "work in progress."
    3.52 +
    3.53 +   This Internet-Draft will expire on May 7, 2020.
    3.54 +
    3.55 +
    3.56 +
    3.57 +
    3.58 +
    3.59 +Birk, et al.               Expires May 7, 2020                  [Page 1]
    3.60 +
    3.61 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
    3.62 +
    3.63 +
    3.64 +Copyright Notice
    3.65 +
    3.66 +   Copyright (c) 2019 IETF Trust and the persons identified as the
    3.67 +   document authors.  All rights reserved.
    3.68 +
    3.69 +   This document is subject to BCP 78 and the IETF Trust's Legal
    3.70 +   Provisions Relating to IETF Documents
    3.71 +   (https://trustee.ietf.org/license-info) in effect on the date of
    3.72 +   publication of this document.  Please review these documents
    3.73 +   carefully, as they describe your rights and restrictions with respect
    3.74 +   to this document.  Code Components extracted from this document must
    3.75 +   include Simplified BSD License text as described in Section 4.e of
    3.76 +   the Trust Legal Provisions and are provided without warranty as
    3.77 +   described in the Simplified BSD License.
    3.78 +
    3.79 +Table of Contents
    3.80 +
    3.81 +   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
    3.82 +     1.1.  Relationship to other pEp documents . . . . . . . . . . .   5
    3.83 +     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
    3.84 +     1.3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   5
    3.85 +   2.  Protocol's Core Design Principles . . . . . . . . . . . . . .   6
    3.86 +     2.1.  Privacy by Default  . . . . . . . . . . . . . . . . . . .   6
    3.87 +     2.2.  Data Minimization . . . . . . . . . . . . . . . . . . . .   7
    3.88 +     2.3.  Interoperability  . . . . . . . . . . . . . . . . . . . .   7
    3.89 +     2.4.  Peer-to-Peer  . . . . . . . . . . . . . . . . . . . . . .   7
    3.90 +     2.5.  User Interaction  . . . . . . . . . . . . . . . . . . . .   8
    3.91 +   3.  Identity System . . . . . . . . . . . . . . . . . . . . . . .   8
    3.92 +     3.1.  User  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.93 +     3.2.  Address . . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.94 +     3.3.  Key . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.95 +     3.4.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.96 +   4.  Key Management  . . . . . . . . . . . . . . . . . . . . . . .  10
    3.97 +     4.1.  Key Generation  . . . . . . . . . . . . . . . . . . . . .  10
    3.98 +     4.2.  Private Keys  . . . . . . . . . . . . . . . . . . . . . .  10
    3.99 +       4.2.1.  Storage . . . . . . . . . . . . . . . . . . . . . . .  10
   3.100 +       4.2.2.  Passphrase  . . . . . . . . . . . . . . . . . . . . .  11
   3.101 +     4.3.  Key Reset . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.102 +     4.4.  Public Key Distribution . . . . . . . . . . . . . . . . .  11
   3.103 +       4.4.1.  UX Considerations . . . . . . . . . . . . . . . . . .  12
   3.104 +       4.4.2.  No addition of unnecessary metadata . . . . . . . . .  12
   3.105 +       4.4.3.  No centralized public key storage or retrieval by
   3.106 +               default . . . . . . . . . . . . . . . . . . . . . . .  12
   3.107 +       4.4.4.  Example message flow  . . . . . . . . . . . . . . . .  12
   3.108 +     4.5.  Key Reset . . . . . . . . . . . . . . . . . . . . . . . .  15
   3.109 +   5.  Trust Management  . . . . . . . . . . . . . . . . . . . . . .  15
   3.110 +     5.1.  Privacy Status  . . . . . . . . . . . . . . . . . . . . .  15
   3.111 +     5.2.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .  15
   3.112 +
   3.113 +
   3.114 +
   3.115 +Birk, et al.               Expires May 7, 2020                  [Page 2]
   3.116 +
   3.117 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.118 +
   3.119 +
   3.120 +     5.3.  Trust Rating  . . . . . . . . . . . . . . . . . . . . . .  16
   3.121 +     5.4.  Trust Revoke  . . . . . . . . . . . . . . . . . . . . . .  16
   3.122 +   6.  Synchronization . . . . . . . . . . . . . . . . . . . . . . .  16
   3.123 +     6.1.  Private Key Synchronization . . . . . . . . . . . . . . .  16
   3.124 +     6.2.  Trust Synchronization . . . . . . . . . . . . . . . . . .  16
   3.125 +   7.  Interoperability  . . . . . . . . . . . . . . . . . . . . . .  17
   3.126 +   8.  Options in pEp  . . . . . . . . . . . . . . . . . . . . . . .  17
   3.127 +     8.1.  Option "Passive Mode" . . . . . . . . . . . . . . . . . .  17
   3.128 +     8.2.  Option "Disable Protection" . . . . . . . . . . . . . . .  17
   3.129 +     8.3.  Option "Extra Keys" . . . . . . . . . . . . . . . . . . .  17
   3.130 +       8.3.1.  Use Case for Organizations  . . . . . . . . . . . . .  17
   3.131 +       8.3.2.  Use Case for Key Synchronization  . . . . . . . . . .  18
   3.132 +     8.4.  Option "Blacklist Keys" . . . . . . . . . . . . . . . . .  18
   3.133 +   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   3.134 +   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
   3.135 +   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   3.136 +   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  19
   3.137 +     12.1.  Introduction . . . . . . . . . . . . . . . . . . . . . .  19
   3.138 +     12.2.  Current software implementing pEp  . . . . . . . . . . .  19
   3.139 +     12.3.  Reference implementation of pEp's core . . . . . . . . .  20
   3.140 +     12.4.  Abstract Crypto API examples . . . . . . . . . . . . . .  21
   3.141 +   13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   3.142 +   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21
   3.143 +   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   3.144 +     15.1.  Normative References . . . . . . . . . . . . . . . . . .  22
   3.145 +     15.2.  Informative References . . . . . . . . . . . . . . . . .  22
   3.146 +   Appendix A.  Code Excerpts  . . . . . . . . . . . . . . . . . . .  24
   3.147 +     A.1.  pEp Identity  . . . . . . . . . . . . . . . . . . . . . .  24
   3.148 +       A.1.1.  Corresponding SQL . . . . . . . . . . . . . . . . . .  24
   3.149 +     A.2.  pEp Communication Type  . . . . . . . . . . . . . . . . .  25
   3.150 +     A.3.  Abstract Crypto API examples  . . . . . . . . . . . . . .  27
   3.151 +       A.3.1.  Encrypting a Message  . . . . . . . . . . . . . . . .  27
   3.152 +       A.3.2.  Decrypting a Message  . . . . . . . . . . . . . . . .  28
   3.153 +       A.3.3.  Obtain Common Trustwords  . . . . . . . . . . . . . .  30
   3.154 +   Appendix B.  Document Changelog . . . . . . . . . . . . . . . . .  30
   3.155 +   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  32
   3.156 +   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
   3.157 +
   3.158 +1.  Introduction
   3.159 +
   3.160 +   Secure and private communications are vital for many different
   3.161 +   reasons, and there are particular properties that privacy-preserving
   3.162 +   protocols need to fulfill in order to best serve users.  In
   3.163 +   particular, [RFC8280] has identified and documented important
   3.164 +   principles such as data minimization, the end-to-end principle, and
   3.165 +   interoperability as integral properties which enable access to Human
   3.166 +   Rights.  Today's applications widely lack privacy support that
   3.167 +   ordinary users can easily adapt.  The pretty Easy privacy (pEp)
   3.168 +
   3.169 +
   3.170 +
   3.171 +Birk, et al.               Expires May 7, 2020                  [Page 3]
   3.172 +
   3.173 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.174 +
   3.175 +
   3.176 +   protocols generally conform to the principles outlined in [RFC8280],
   3.177 +   and, as such, can facilitate the adoption and correct usage of secure
   3.178 +   and private communications technology.
   3.179 +
   3.180 +   The pretty Easy privacy (pEp) protocols are propositions to the
   3.181 +   Internet community to create software for peers to automatically
   3.182 +   encrypt, anonymize (where possible), and verify their daily written
   3.183 +   digital communications.  This is achieved by building upon already
   3.184 +   existing standards and tools and automating each step a user needs to
   3.185 +   carry out in order to engage in secure end-to-end encrypted
   3.186 +   communications.  Significantly, the pEp protocols describe how do to
   3.187 +   this without dependence on centralized infrastructures.
   3.188 +
   3.189 +   The pEp project emerged from the CryptoParty movement.  During that
   3.190 +   time, the initiators learned that while step-by-step guides can help
   3.191 +   some users engage in secure end-to-end communications, it is both
   3.192 +   more effective and convenient for the vast majority of users if these
   3.193 +   step-by-step guides are put into running code (following a protocol),
   3.194 +   which automates the initial configuration and general usage of
   3.195 +   cryptographic tools.  To facilitate this goal, pEp proposes the
   3.196 +   automation of key management, key discovery, and key synchronization
   3.197 +   through an in-band approach which follows the end-to-end principle.
   3.198 +
   3.199 +   To mitigate man-in-the-middle attacks (MITM) by an active adversary,
   3.200 +   and as the only manual step users carry out in the course of the
   3.201 +   protocols, the proposed Trustwords [I-D.birk-pep-trustwords]
   3.202 +   mechanism uses natural language representations of two peers'
   3.203 +   fingerprints for users to verify their trust in a paired
   3.204 +   communication channel.
   3.205 +
   3.206 +   The privacy-by-default principles that pEp introduces are in
   3.207 +   accordance with the perspective outlined in [RFC7435], aiming to
   3.208 +   provide opportunistic security in the sense of "some protection most
   3.209 +   of the time".  This is done, however, with the subtle but important
   3.210 +   difference that when privacy is weighed against security, the choice
   3.211 +   defaults to privacy.  Therefore, data minimization is a primary goal
   3.212 +   in pEp (e.g., hiding subject lines and headers unnecessary for email
   3.213 +   transport inside the encrypted payload of a message).
   3.214 +
   3.215 +   The pEp propositions are focused on (but not limited to) written
   3.216 +   digital communications and cover asynchronous (offline) types of
   3.217 +   communications like email as well as synchronous (online) types such
   3.218 +   as chat.
   3.219 +
   3.220 +   pEp's goal is to bridge different standardized and widely-used
   3.221 +   communications channels such that users can reach communications
   3.222 +   partners in the most privacy-enhancing way possible.
   3.223 +
   3.224 +
   3.225 +
   3.226 +
   3.227 +Birk, et al.               Expires May 7, 2020                  [Page 4]
   3.228 +
   3.229 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.230 +
   3.231 +
   3.232 +1.1.  Relationship to other pEp documents
   3.233 +
   3.234 +   While this document outlines the general design choices and
   3.235 +   principles of pEp, other related documents specialize in more
   3.236 +   particular aspects of the model, or the application of pEp on a
   3.237 +   specific protocol like as follows:
   3.238 +
   3.239 +   1.  pEp-enabled applications (e.g., pEp email
   3.240 +       [I-D.marques-pep-email]).
   3.241 +
   3.242 +   2.  Helper functions for peer interaction, which facilitate
   3.243 +       understanding and handling of the cryptographic aspects of pEp
   3.244 +       implementation for users (e.g., pEp Handshake
   3.245 +       [I-D.marques-pep-handshake]).
   3.246 +
   3.247 +   3.  Helper functions for interactions between a user's own devices,
   3.248 +       which give the user the ability to run pEp applications on
   3.249 +       different devices at the same time, such as a computer, mobile
   3.250 +       phone, or tablets (e.g., pEp KeySync
   3.251 +       [I-D.hoeneisen-pep-keysync]).
   3.252 +
   3.253 +   In addition, there are documents that do not directly depend on this
   3.254 +   one, but provide generic functions needed in pEp, e.g., IANA
   3.255 +   Registration of Trustword Lists [I-D.birk-pep-trustwords].
   3.256 +
   3.257 +   [[ Note: At this stage it is not yet clear to us how many of our
   3.258 +   implementation details should be part of new RFCs and where we can
   3.259 +   safely refer to already existing RFCs to clarify which RFCs we rely
   3.260 +   on. ]]
   3.261 +
   3.262 +1.2.  Requirements Language
   3.263 +
   3.264 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   3.265 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   3.266 +   document are to be interpreted as described in [RFC2119].
   3.267 +
   3.268 +1.3.  Terms
   3.269 +
   3.270 +   The following terms are defined for the scope of this document:
   3.271 +
   3.272 +   o  pEp Handshake: The process of one user contacting another over an
   3.273 +      independent channel in order to verify Trustwords (or fingerprints
   3.274 +      as a fallback).  This can be done in-person or through established
   3.275 +      verbal communication channels, like a phone call.
   3.276 +      [I-D.marques-pep-handshake]
   3.277 +
   3.278 +   o  Trustwords: A scalar-to-word representation of 16-bit numbers (0
   3.279 +      to 65535) to natural language words.  When doing a Handshake,
   3.280 +
   3.281 +
   3.282 +
   3.283 +Birk, et al.               Expires May 7, 2020                  [Page 5]
   3.284 +
   3.285 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.286 +
   3.287 +
   3.288 +      peers are shown combined Trustwords of both public keys involved
   3.289 +      to ease the comparison.  [I-D.birk-pep-trustwords]
   3.290 +
   3.291 +   o  Trust On First Use (TOFU): cf. [RFC7435], which states: "In a
   3.292 +      protocol, TOFU calls for accepting and storing a public key or
   3.293 +      credential associated with an asserted identity, without
   3.294 +      authenticating that assertion.  Subsequent communication that is
   3.295 +      authenticated using the cached key or credential is secure against
   3.296 +      an MiTM attack, if such an attack did not succeed during the
   3.297 +      vulnerable initial communication."
   3.298 +
   3.299 +   o  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
   3.300 +      form of active wiretapping attack in which the attacker intercepts
   3.301 +      and selectively modifies communicated data to masquerade as one or
   3.302 +      more of the entities involved in a communication association."
   3.303 +
   3.304 +2.  Protocol's Core Design Principles
   3.305 +
   3.306 +2.1.  Privacy by Default
   3.307 +
   3.308 +   pEp's most important goal is to ensure privacy above all else.  To
   3.309 +   clarify, pEp's protocol defaults are designed to maximize both
   3.310 +   security and privacy, but in the few cases where achieving both more
   3.311 +   privacy and more security are in conflict, pEp chooses more privacy.
   3.312 +
   3.313 +   In contrast to pEp's prioritization of user privacy, OpenPGP's Web-
   3.314 +   of-Trust (WoT) releases user and trust level relationships to the
   3.315 +   public.  In addition, queries to OpenPGP keyservers dynamically
   3.316 +   disclose the social graph, indicating a user's intent to communicate
   3.317 +   with specific peers.  Similar issues exist in other security
   3.318 +   protocols that rely upon a centralized trust model, such as the
   3.319 +   certificate revocation protocols used in XPKI (S/MIME).
   3.320 +
   3.321 +   [[*TODO*: Fix the wording and reference to XPKI, S/MIME]].
   3.322 +
   3.323 +   In pEp messaging (e.g., when using HTML) content and information
   3.324 +   SHALL NOT be obtained from remote locations as this constitutes a
   3.325 +   privacy breach.
   3.326 +
   3.327 +   Because of the inherent privacy risks in using remote or centralized
   3.328 +   infrastructures, implementations of pEp messaging, by default, SHALL
   3.329 +   NOT obtain content and information from remote or centralized
   3.330 +   locations, as this constitutes a privacy breach.  In email this issue
   3.331 +   exists with HTML mails.
   3.332 +
   3.333 +
   3.334 +
   3.335 +
   3.336 +
   3.337 +
   3.338 +
   3.339 +Birk, et al.               Expires May 7, 2020                  [Page 6]
   3.340 +
   3.341 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.342 +
   3.343 +
   3.344 +2.2.  Data Minimization
   3.345 +
   3.346 +   Data minimization keeps data spare and hides all technically
   3.347 +   concealable information whenever possible.  It is an important design
   3.348 +   goal of pEp.
   3.349 +
   3.350 +2.3.  Interoperability
   3.351 +
   3.352 +   The proposed pEp protocols seek interoperability with established
   3.353 +   message formats, as well as cryptographic security protocols and
   3.354 +   their widespread implementations.
   3.355 +
   3.356 +   To achieve this interoperability, pEp MUST follow Postel's Robustness
   3.357 +   Principle outlined in [RFC1122]: "Be liberal in what you accept, and
   3.358 +   conservative in what you send."
   3.359 +
   3.360 +   Particularly, pEp applies Postel's principle as follows:
   3.361 +
   3.362 +   o  pEp is conservative (strict) in requirements for pEp
   3.363 +      implementations and how they interact with pEp or other compatible
   3.364 +      implementations.
   3.365 +
   3.366 +   o  pEp liberally accepts input from non-pEp implementations.  For
   3.367 +      example, in email, pEp will not produce outgoing messages, but
   3.368 +      will transparently support decryption of incoming PGP/INLINE
   3.369 +      messages.
   3.370 +
   3.371 +   o  Finally, where pEp requires divergence from established RFCs due
   3.372 +      to privacy concerns (e.g., from OpenPGP propositions as defined in
   3.373 +      [OpenPGP], options SHOULD be implemented which empower the user to
   3.374 +      override pEp's defaults.
   3.375 +
   3.376 +2.4.  Peer-to-Peer
   3.377 +
   3.378 +   Messaging and verification processes in pEp are designed to work in a
   3.379 +   peer-to-peer (P2P) manner, without the involvement of intermediaries.
   3.380 +
   3.381 +   This means there MUST NOT be any pEp-specific central services
   3.382 +   whatsoever needed for pEp implementations, both in the case of
   3.383 +   verification of peers and for the actual encryption.
   3.384 +
   3.385 +   However, implementers of pEp MAY provide options for interoperation
   3.386 +   with providers of centralized infrastructures (e.g., to enable users
   3.387 +   to communicate with their peers on platforms with vendor lock-in).
   3.388 +
   3.389 +   Trust provided by global Certificate Authorities (e.g., commercial
   3.390 +   X.509 CAs) SHALL NOT be signaled as trustworthy (cf.
   3.391 +
   3.392 +
   3.393 +
   3.394 +
   3.395 +Birk, et al.               Expires May 7, 2020                  [Page 7]
   3.396 +
   3.397 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.398 +
   3.399 +
   3.400 +   [I-D.marques-pep-rating]) to users of pEp (e.g., when interoperating
   3.401 +   with peers using S/MIME) by default.
   3.402 +
   3.403 +2.5.  User Interaction
   3.404 +
   3.405 +   Implementers of pEp MUST NOT expose users to technical terms and
   3.406 +   views, especially those specific to cryptography, like "keys",
   3.407 +   "certificates", or "fingerprints".  Users may explicitly opt-in to
   3.408 +   see such terms wanting seeking for more options; i.e., advanced
   3.409 +   settings MAY be available, and in some cases, these options may be
   3.410 +   required.
   3.411 +
   3.412 +   The authors believe that widespread adoption of end-to-end
   3.413 +   cryptography is possible if users are not required to understand
   3.414 +   cryptography and key management.  This belief forms the central goal
   3.415 +   of pEp, which is that users can simply rely on the principles of
   3.416 +   Privacy by Default.
   3.417 +
   3.418 +   On the other hand, to preserve usability, users MUST NOT be required
   3.419 +   to wait for cryptographic tasks such as key generation to complete
   3.420 +   before being able to use their respective message client for its
   3.421 +   default purpose.  In short, pEp implementers MUST ensure that the
   3.422 +   ability to draft, send, and receive messages is always preserved,
   3.423 +   even if that means a message is sent unencrypted, in accordance with
   3.424 +   the Opportunistic Security approach outlined in [RFC7435].
   3.425 +
   3.426 +   In turn, pEp implementers MUST ensure that a distinguishable privacy
   3.427 +   status is clearly visible to the user, both on a per-contact as well
   3.428 +   as per-message level.  This allows users to assess both the privacy
   3.429 +   level for the message and the trust level of its intended recipients
   3.430 +   before choosing to send it.
   3.431 +
   3.432 +   [[ *NOTE*: We are aware of the fact that usually UX requirements are
   3.433 +   not part of RFCs.  However, in order to encourage massive adoption of
   3.434 +   secure end-to-end encryption while at the same time avoiding putting
   3.435 +   users at risk, we believe certain straightforward signaling
   3.436 +   requirements for users to be a good idea, just as it is currently
   3.437 +   done for already-popular instant messaging services. ]]
   3.438 +
   3.439 +3.  Identity System
   3.440 +
   3.441 +   Everyone has the right to choose how to reveal themselves to the
   3.442 +   world, both offline and online.  This is an important element to
   3.443 +   maintain psychological, physical, and digital privacy.  As such, pEp
   3.444 +   users MUST have the option to choose their identity, and they MUST
   3.445 +   have the ability to maintain multiple identities.
   3.446 +
   3.447 +
   3.448 +
   3.449 +
   3.450 +
   3.451 +Birk, et al.               Expires May 7, 2020                  [Page 8]
   3.452 +
   3.453 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.454 +
   3.455 +
   3.456 +   These different identities MUST NOT be externally correlatable with
   3.457 +   each other by default.  On the other hand, combining different
   3.458 +   identities when such information is known MUST be supported (alias
   3.459 +   support).
   3.460 +
   3.461 +3.1.  User
   3.462 +
   3.463 +   A user is a real world human being or a group of human beings.  If it
   3.464 +   is a single human being, it can be called person.
   3.465 +
   3.466 +   A user is identified by a user ID (user_id).  The user_id SHOULD be a
   3.467 +   UUID, it MAY be an arbitrary unique string.
   3.468 +
   3.469 +   The own user can have a user_id like all other users.  If the own
   3.470 +   user does not have a user_id, then it is assigned a "pEp_own_userId"
   3.471 +   instead.
   3.472 +
   3.473 +   A user can have a default key.  [[ TODO: Provide ref explaining this.
   3.474 +   ]]
   3.475 +
   3.476 +3.2.  Address
   3.477 +
   3.478 +   A pEp address is a network address, e.g., an SMTP address or another
   3.479 +   Universal Resource Identifier (URI).
   3.480 +
   3.481 +   [[ Note: It might be necessary to introduce further addressing
   3.482 +   schemes through IETF contributions or IANA registrations, e.g.,
   3.483 +   implementing pEp to bridge to popular messaging services with no URIs
   3.484 +   defined. ]]
   3.485 +
   3.486 +3.3.  Key
   3.487 +
   3.488 +   A key is an OpenPGP-compatible asymmetric cryptographic key pair.
   3.489 +
   3.490 +   Keys in pEp are identified by the full fingerprint (fpr) of the
   3.491 +   public key.  The fingerprint is to be obtained from the specific
   3.492 +   cryptographic service used to handle the keys.  The canonical
   3.493 +   representation in pEp is upper-case hexadecimal with zero-padding and
   3.494 +   no separators or spaces.
   3.495 +
   3.496 +3.4.  Identity
   3.497 +
   3.498 +   An identity is a representation of a user, encapsulating how this
   3.499 +   user appears within the network of a messaging system.  This
   3.500 +   representation may or may not be pseudonymous in nature.
   3.501 +
   3.502 +   An identity is defined by mapping a user_id to an address.  If no
   3.503 +   user_id is known, it is guessed by mapping a username to an address.
   3.504 +
   3.505 +
   3.506 +
   3.507 +Birk, et al.               Expires May 7, 2020                  [Page 9]
   3.508 +
   3.509 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.510 +
   3.511 +
   3.512 +   An identity can have a temporary user_id as a placeholder until a
   3.513 +   real user_id is known.
   3.514 +
   3.515 +   In pEp a different key pair for each (e.g., email) account MUST be
   3.516 +   created.  This allows a user to retain different identities, which
   3.517 +   are not correlated by the usage of the same key for all of those.
   3.518 +   This is beneficial in terms of privacy.
   3.519 +
   3.520 +   A user MAY have a default key; each identity a user has MAY have a
   3.521 +   default key (of its own).  When both an Identity and the related User
   3.522 +   have a default key set, the Identity's default key MUST override the
   3.523 +   User's default key.
   3.524 +
   3.525 +   [[ TODO: Provide ref explaining this. ]]
   3.526 +
   3.527 +   In Appendix A.1, the definition of a pEp identity can be found
   3.528 +   according to the reference implementation by the pEp engine.
   3.529 +
   3.530 +4.  Key Management
   3.531 +
   3.532 +   In order to achieve the goal of widespread adoption of secure
   3.533 +   communications, key management in pEp MUST be automated.
   3.534 +
   3.535 +4.1.  Key Generation
   3.536 +
   3.537 +   A pEp implementation MUST ensure that cryptographic keys for every
   3.538 +   configured identity are available.  If a corresponding key pair for
   3.539 +   the identity of a user is found and said identity fulfills the
   3.540 +   requirements (e.g., for email, as set out in
   3.541 +   [I-D.marques-pep-email]), said key pair MUST be reused.  Otherwise a
   3.542 +   new key pair MUST be generated.  This may be carried out instantly
   3.543 +   upon its configuration.
   3.544 +
   3.545 +   On devices with limited processing power (e.g., mobile devices) the
   3.546 +   key generation may take more time than a user is willing to wait.  If
   3.547 +   this is the case, users SHOULD NOT be stopped from communicating,
   3.548 +   i.e., the key generation process SHOULD be carried out in the
   3.549 +   background.
   3.550 +
   3.551 +4.2.  Private Keys
   3.552 +
   3.553 +4.2.1.  Storage
   3.554 +
   3.555 +   Private keys in pEp implementations MUST always be held on the end
   3.556 +   user's device(s): pEp implementers MUST NOT rely on private keys
   3.557 +   stored in centralized remote locations.  This applies even for key
   3.558 +   storages where the private keys are protected with sufficiently long
   3.559 +   passphrases.  It is considered a violation of pEp's P2P design
   3.560 +
   3.561 +
   3.562 +
   3.563 +Birk, et al.               Expires May 7, 2020                 [Page 10]
   3.564 +
   3.565 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.566 +
   3.567 +
   3.568 +   principle to rely on centralized infrastructures (cf.  Section 2.4).
   3.569 +   This also applies for pEp implementations created for applications
   3.570 +   not residing on a user's device (e.g., web-based MUAs).  In such
   3.571 +   cases, pEp implementations MUST be done in a way such that the
   3.572 +   locally-held private key can neither be directly accessed nor leaked
   3.573 +   to the outside world.
   3.574 +
   3.575 +   [[ Note: It is particularly important that browser add-ons
   3.576 +   implementing pEp functionality do not obtain their cryptographic code
   3.577 +   from a centralized (cloud) service, as this must be considered a
   3.578 +   centralized attack vector allowing for backdoors, negatively
   3.579 +   impacting privacy. ]]
   3.580 +
   3.581 +   Cf. Section 6.1 for a means to synchronize private keys among
   3.582 +   different devices of the same network address in a secure manner.
   3.583 +
   3.584 +4.2.2.  Passphrase
   3.585 +
   3.586 +   Passphrases to protect a user's private key MUST be supported by pEp
   3.587 +   implementations, but MUST NOT be enforced by default.  That is, if a
   3.588 +   pEp implementation finds a suitable (i.e., secure enough)
   3.589 +   cryptographic setup, which uses passphrases, pEp implementations MUST
   3.590 +   provide a way to unlock the key.  However, if a new key pair is
   3.591 +   generated for a given identity, no passphrase MUST be put in place.
   3.592 +   The authors assume that the enforcement of secure (i.e., unique and
   3.593 +   long enough) passphrases would massively reduce the number of pEp
   3.594 +   users (by hassling them), while providing little to no additional
   3.595 +   privacy for the common cases of passive monitoring being carried out
   3.596 +   by corporations or state-level actors.
   3.597 +
   3.598 +4.3.  Key Reset
   3.599 +
   3.600 +4.4.  Public Key Distribution
   3.601 +
   3.602 +   As the key is available (cf.  Section 4.1) implementers of pEp are
   3.603 +   REQUIRED to ensure that the identity's public key is attached to
   3.604 +   every outgoing message.  However, this MAY be omitted if the peer has
   3.605 +   previously received a message encrypted with the public key of the
   3.606 +   sender.
   3.607 +
   3.608 +   The sender's public key SHOULD be sent encrypted whenever possible,
   3.609 +   i.e., when a public key of the receiving peer is available.  If no
   3.610 +   encryption key of the recipient is available, the sender's public key
   3.611 +   MAY be sent unencrypted.  In either case, this approach ensures that
   3.612 +   messaging clients (e.g., MUAs that at least implement OpenPGP) do not
   3.613 +   need to have pEp implemented to see a user's public key.  Such peers
   3.614 +   thus have the chance to (automatically) import the sender's public
   3.615 +   key.
   3.616 +
   3.617 +
   3.618 +
   3.619 +Birk, et al.               Expires May 7, 2020                 [Page 11]
   3.620 +
   3.621 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.622 +
   3.623 +
   3.624 +   If there is already a known public key from the sender of a message
   3.625 +   and it is still valid and not expired, new keys MUST NOT be used for
   3.626 +   future communication unless they are signed by the previous key (to
   3.627 +   avoid a MITM attack).  Messages MUST always be encrypted with the
   3.628 +   receiving peer's oldest public key, as long as it is valid and not
   3.629 +   expired.
   3.630 +
   3.631 +4.4.1.  UX Considerations
   3.632 +
   3.633 +   Implementers of pEp SHALL prevent the display of public keys attached
   3.634 +   to messages (e.g, in email) to the user in order to prevent user
   3.635 +   confusion by files they are potentially unaware of how to handle.
   3.636 +
   3.637 +4.4.2.  No addition of unnecessary metadata
   3.638 +
   3.639 +   Metadata, such as email headers, MUST NOT be added in order to
   3.640 +   announce a user's public key.  This is considered unnecessary
   3.641 +   information leakage, may affect user privacy, and may be subject to a
   3.642 +   country's data retention laws (cf.  Section 2.2).  Furthermore, this
   3.643 +   may affect interoperability to existing users that have no knowledge
   3.644 +   of such header fields, such as users of OpenPGP in email, and lose
   3.645 +   the ability to import any keys distributed in this way as a result.
   3.646 +   The ability to extract and receive public keys from such metadata
   3.647 +   SHOULD be supported, however, in the event these approaches become
   3.648 +   widespread.
   3.649 +
   3.650 +4.4.3.  No centralized public key storage or retrieval by default
   3.651 +
   3.652 +   Keyservers or generally intermediate approaches to obtain a peer's
   3.653 +   public key SHALL NOT be used by default.  On the other hand, the user
   3.654 +   MAY be provided with the option to opt-in for remote locations to
   3.655 +   obtain keys, considering the widespread adoption of such approaches
   3.656 +   for key distribution.
   3.657 +
   3.658 +   Keys generated or obtained by pEp clients MUST NOT be uploaded to any
   3.659 +   (intermediate) keystore locations without the user's explicit
   3.660 +   consent.
   3.661 +
   3.662 +4.4.4.  Example message flow
   3.663 +
   3.664 +   The following example roughly describes a pEp scenario with a typical
   3.665 +   initial message flow to demonstrate key exchange and basic trust
   3.666 +   management:
   3.667 +
   3.668 +   The following example describes a pEp scenario between two users -
   3.669 +   Alice and Bob - in order to demonstrate the message flow that occurs
   3.670 +   when exchanging keys and determining basic trust management for the
   3.671 +   first time:
   3.672 +
   3.673 +
   3.674 +
   3.675 +Birk, et al.               Expires May 7, 2020                 [Page 12]
   3.676 +
   3.677 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.678 +
   3.679 +
   3.680 +   1.  Alice - knowing nothing of Bob - sends a message to Bob. As Alice
   3.681 +       has no public key from Bob, this message is sent out unencrypted.
   3.682 +       However, Alice's public key is automatically attached.
   3.683 +
   3.684 +   2.  Bob receives Alice's message and her public key.  He is able to
   3.685 +       reply to her and encrypt the message.  His public key is
   3.686 +       automatically attached to the message.  Because he has her public
   3.687 +       key now, Alice's rating in his message client changes to
   3.688 +       'encrypted'.  From a UX perspective, this status is displayed in
   3.689 +       yellow (cf.  Section 5.3).
   3.690 +
   3.691 +   3.  Alice receives Bob's key.  As of now Alice is also able to send
   3.692 +       secure messages to Bob. The rating for Bob changes to "encrypted"
   3.693 +       (with yellow color) in Alice's messaging client (cf.
   3.694 +       Section 5.3).
   3.695 +
   3.696 +   4.  Alice receives Bob's reply with his public key attached.  Now,
   3.697 +       Alice can send secure messages to Bob as well.  The rating for
   3.698 +       Bob changes to yellow, or 'encrypted', in Alice's messaging
   3.699 +       client Section 5.3.
   3.700 +
   3.701 +   5.  If Alice and Bob want to prevent man-in-the-middle (MITM)
   3.702 +       attacks, they can engage in a pEp Handshake comparing their so-
   3.703 +       called Trustwords (cf.  Section 5.2) and confirm this process if
   3.704 +       those match.  After doing so, their identity rating changes to
   3.705 +       "encrypted and authenticated" (cf.  Section 5.3), which (UX-wise)
   3.706 +       can be displayed using a green color.  See also Section 5.
   3.707 +
   3.708 +   6.  Alice and Bob can encrypt now, but they are not yet
   3.709 +       authenticated, leaving them vulnerable to man-in-the-middle
   3.710 +       (MitM) attacks.  To prevent this from occurring, Alice and Bob
   3.711 +       can engage in a pEp Handshake to compare their Trustwords (cf.
   3.712 +       Section 5.2) and confirm if they match.  After this step is
   3.713 +       performed, their respective identity ratings change to "encrypted
   3.714 +       and authenticated", which is represented by a green color (cf.
   3.715 +       Section 5.
   3.716 +
   3.717 +
   3.718 +
   3.719 +
   3.720 +
   3.721 +
   3.722 +
   3.723 +
   3.724 +
   3.725 +
   3.726 +
   3.727 +
   3.728 +
   3.729 +
   3.730 +
   3.731 +Birk, et al.               Expires May 7, 2020                 [Page 13]
   3.732 +
   3.733 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.734 +
   3.735 +
   3.736 +             -----                                       -----
   3.737 +             | A |                                       | B |
   3.738 +             -----                                       -----
   3.739 +               |                                           |
   3.740 +   +------------------------+                 +------------------------+
   3.741 +   | auto-generate key pair |                 | auto-generate key pair |
   3.742 +   |    (if no key yet)     |                 |    (if no key yet)     |
   3.743 +   +------------------------+                 +------------------------+
   3.744 +               |                                           |
   3.745 +   +-----------------------+                   +-----------------------+
   3.746 +   | Privacy Status for B: |                   | Privacy Status for A: |
   3.747 +   |     *Unencrypted*     |                   |     *Unencrypted*     |
   3.748 +   +-----------------------+                   +-----------------------+
   3.749 +               |                                           |
   3.750 +               |   A sends message to B (Public Key        |
   3.751 +               |   attached) / optionally signed, but      |
   3.752 +               |               NOT ENCRYPTED               |
   3.753 +               +------------------------------------------>|
   3.754 +               |                                           |
   3.755 +               |                               +-----------------------+
   3.756 +               |                               | Privacy Status for A: |
   3.757 +               |                               |      *Encrypted*      |
   3.758 +               |                               +-----------------------+
   3.759 +               |                                           |
   3.760 +               |      B sends message to A (Public Key     |
   3.761 +               |      attached) / signed and ENCRYPTED     |
   3.762 +               |<------------------------------------------+
   3.763 +               |                                           |
   3.764 +   +-----------------------+                               |
   3.765 +   | Privacy Status for B: |                               |
   3.766 +   |      *Encrypted*      |                               |
   3.767 +   +-----------------------+                               |
   3.768 +               |                                           |
   3.769 +               |   A and B successfully compare their      |
   3.770 +               |   Trustwords over an alternative channel  |
   3.771 +               |   (e.g., phone line)                      |
   3.772 +               |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->|
   3.773 +               |                                           |
   3.774 +   +-----------------------+                   +-----------------------+
   3.775 +   | Privacy Status for B: |                   | Privacy Status for A: |
   3.776 +   |       *Trusted*       |                   |       *Trusted*       |
   3.777 +   +-----------------------+                   +-----------------------+
   3.778 +               |                                           |
   3.779 +
   3.780 +
   3.781 +
   3.782 +
   3.783 +
   3.784 +
   3.785 +
   3.786 +
   3.787 +Birk, et al.               Expires May 7, 2020                 [Page 14]
   3.788 +
   3.789 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.790 +
   3.791 +
   3.792 +4.5.  Key Reset
   3.793 +
   3.794 +   [[ TODO: This section will explain how to deal with invalid keys,
   3.795 +   e.g., if expired or (potentially) leaked. ]]
   3.796 +
   3.797 +5.  Trust Management
   3.798 +
   3.799 +   [[ TODO: Intro ]]
   3.800 +
   3.801 +5.1.  Privacy Status
   3.802 +
   3.803 +   The trust status for an identity can change due to a number of
   3.804 +   factors.  These shifts will cause the color code assigned to this
   3.805 +   identity to change accordingly, and is applied to future
   3.806 +   communications with this identity.
   3.807 +
   3.808 +   For end-users, the most important component of pEp, which MUST be
   3.809 +   made visible on a per-recipient and per-message level, is the Privacy
   3.810 +   Status.
   3.811 +
   3.812 +   By colors, symbols and texts a user SHALL immediately understand how
   3.813 +   private
   3.814 +
   3.815 +   o  a communication channel with a given peer was or ought to be and
   3.816 +
   3.817 +   o  a given message was or ought to be.
   3.818 +
   3.819 +5.2.  Handshake
   3.820 +
   3.821 +   To establishing trust between peers and to upgrade Privacy Status,
   3.822 +   pEp defines a handshake, which is specified in
   3.823 +   [I-D.marques-pep-handshake].
   3.824 +
   3.825 +   In pEp, Trustwords [I-D.birk-pep-trustwords] are used for users to
   3.826 +   compare the authenticity of peers in order to mitigate MITM attacks.
   3.827 +
   3.828 +   By default, Trustwords MUST be used to represent two peers'
   3.829 +   fingerprints of their public keys in pEp implementations.
   3.830 +
   3.831 +   In order to retain compatibility with peers not using pEp
   3.832 +   implementations (e.g., Mail User Agents (MUAs) with OpenPGP
   3.833 +   implementations without Trustwords), it is REQUIRED that pEp
   3.834 +   implementers give the user the choice to show both peers'
   3.835 +   fingerprints instead of just their common Trustwords.
   3.836 +
   3.837 +
   3.838 +
   3.839 +
   3.840 +
   3.841 +
   3.842 +
   3.843 +Birk, et al.               Expires May 7, 2020                 [Page 15]
   3.844 +
   3.845 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.846 +
   3.847 +
   3.848 +5.3.  Trust Rating
   3.849 +
   3.850 +   pEp includes a Trust Rating system defining Rating and Color Codes to
   3.851 +   express the Privacy Status of a peer or message
   3.852 +   [I-D.marques-pep-rating].  The ratings are labeled, e.g., as
   3.853 +   "Unencrypted", "Encrypted", "Trusted", "Under Attack", etc.  The
   3.854 +   Privacy Status in its most general form is expressed with traffic
   3.855 +   lights semantics (and respective symbols and texts), whereas the
   3.856 +   three colors yellow, green and red can be applied for any peer or
   3.857 +   message - like this immediately indicating how secure and trustworthy
   3.858 +   (and thus private) a communication was or ought to be considered.
   3.859 +
   3.860 +   The pEp Trust Rating system with all its states and respective
   3.861 +   representations to be followed is outlined in
   3.862 +   [I-D.marques-pep-rating].
   3.863 +
   3.864 +   Note: An example for the rating of communication types, the
   3.865 +   definition of the data structure by the pEp Engine reference
   3.866 +   implementation is provided in Appendix A.2.
   3.867 +
   3.868 +5.4.  Trust Revoke
   3.869 +
   3.870 +   [[ TODO: This section will explain how to deal with the situation
   3.871 +   when a peer can no longer be trusted, e.g., if a peer's device is
   3.872 +   compromised. ]]
   3.873 +
   3.874 +6.  Synchronization
   3.875 +
   3.876 +   An important feature of pEp is to assist the user to run pEp
   3.877 +   applications on different devices, such as personal computers, mobile
   3.878 +   phones and tablets, at the same time.  Therefore, state needs to be
   3.879 +   synchronized among the different devices.
   3.880 +
   3.881 +6.1.  Private Key Synchronization
   3.882 +
   3.883 +   The pEp KeySync protocol (cf.  [I-D.hoeneisen-pep-keysync]) is a
   3.884 +   decentralized proposition which defines how pEp users can distribute
   3.885 +   their private keys among their different devices in a user-
   3.886 +   authenticated manner.  This allows users to read their messages
   3.887 +   across their various devices, as long as they share a common address,
   3.888 +   such as an email account.
   3.889 +
   3.890 +6.2.  Trust Synchronization
   3.891 +
   3.892 +   [[ TODO: This section will explain how trust and other related state
   3.893 +   is synchronized among different devices in a user-authenticated
   3.894 +   manner. ]]
   3.895 +
   3.896 +
   3.897 +
   3.898 +
   3.899 +Birk, et al.               Expires May 7, 2020                 [Page 16]
   3.900 +
   3.901 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.902 +
   3.903 +
   3.904 +7.  Interoperability
   3.905 +
   3.906 +   pEp aims to be interoperable with existing applications designed to
   3.907 +   enable privacy, e.g., OpenPGP and S/MIME in email.
   3.908 +
   3.909 +8.  Options in pEp
   3.910 +
   3.911 +   In this section a non-exhaustive selection of options is provided.
   3.912 +
   3.913 +8.1.  Option "Passive Mode"
   3.914 +
   3.915 +   By default, the sender attaches its public key to any outgoing
   3.916 +   message (cf.  Section 4.4).  For situations where a sender wants to
   3.917 +   ensure that it only attaches a public key to an Internet user which
   3.918 +   has a pEp implementation, a Passive Mode MUST be made available.
   3.919 +
   3.920 +8.2.  Option "Disable Protection"
   3.921 +
   3.922 +   Using this option, protection can be disabled generally or
   3.923 +   selectively.  Implementers of pEp MUST provide an option "Disable
   3.924 +   Protection" to allow a user to disable encryption and signing for:
   3.925 +
   3.926 +   1.  all communication
   3.927 +
   3.928 +   2.  specific contacts
   3.929 +
   3.930 +   3.  specific messages
   3.931 +
   3.932 +   The public key still attached, unless the option "Passive Mode" (cf.
   3.933 +   Section 8.1) is activated at the same time.
   3.934 +
   3.935 +8.3.  Option "Extra Keys"
   3.936 +
   3.937 +8.3.1.  Use Case for Organizations
   3.938 +
   3.939 +   For internal or enterprise environments, authorized personnel may
   3.940 +   need to centrally decrypt user messages for archival or other legal
   3.941 +   purposes.  Therefore, pEp implementers MAY provide an "Extra Keys"
   3.942 +   option in which a message is encrypted with at least one additional
   3.943 +   public key.  The corresponding secret key(s) are intended to be
   3.944 +   secured by CISO staff or other authorized personnel for the
   3.945 +   organization.
   3.946 +
   3.947 +   However, it is crucial that the "Extra Keys" feature MUST NOT be
   3.948 +   activated by default for any network address, and is intended to be
   3.949 +   an option used only for organization-specific identities, as well as
   3.950 +   their corresponding network addresses and accounts.  The "Extra Keys"
   3.951 +
   3.952 +
   3.953 +
   3.954 +
   3.955 +Birk, et al.               Expires May 7, 2020                 [Page 17]
   3.956 +
   3.957 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
   3.958 +
   3.959 +
   3.960 +   feature SHOULD NOT be applied to the private identities, addresses,
   3.961 +   or accounts a user might possess once it is activated.
   3.962 +
   3.963 +8.3.2.  Use Case for Key Synchronization
   3.964 +
   3.965 +   The "Extra Keys" feature also plays a role during pEp's KeySync
   3.966 +   protocols, where the additional keys are used to decipher message
   3.967 +   transactions by both parties involved during the negotiation process
   3.968 +   for private key synchronization.  During the encrypted (but
   3.969 +   untrusted) transactions, KeySync messages are not just encrypted with
   3.970 +   the sending device's default key, but also with the default keys of
   3.971 +   both parties involved in the synchronization process.
   3.972 +
   3.973 +8.4.  Option "Blacklist Keys"
   3.974 +
   3.975 +   A "Blacklist Keys" option MAY be provided for an advanced user,
   3.976 +   allowing them to disable keys of peers that they no longer want to
   3.977 +   use in new communications.  However, the keys SHALL NOT be deleted.
   3.978 +   It MUST still be possible to verify and decipher past communications
   3.979 +   that used these keys.
   3.980 +
   3.981 +9.  Security Considerations
   3.982 +
   3.983 +   By attaching the sender's public key to outgoing messages, Trust on
   3.984 +   First Use (TOFU) is established.  However, this is prone to MITM
   3.985 +   attacks.  Cryptographic key subversion is considered Pervasive
   3.986 +   Monitoring (PM) according to [RFC7258].  Those attacks can be
   3.987 +   mitigated, if the involved users compare their common Trustwords.
   3.988 +   This possibility MUST be made easily accessible to pEp users in the
   3.989 +   user interface implementation.  If for compatibility reasons (e.g.,
   3.990 +   with OpenPGP users) no Trustwords can be used, then a comparatively
   3.991 +   easy way to verify the respective public key fingerprints MUST be
   3.992 +   implemented.
   3.993 +
   3.994 +   As the use of passphrases for private keys is not advised, devices
   3.995 +   themselves SHOULD use encryption.
   3.996 +
   3.997 +10.  Privacy Considerations
   3.998 +
   3.999 +   [[ TODO ]]
  3.1000 +
  3.1001 +11.  IANA Considerations
  3.1002 +
  3.1003 +   This document has no actions for IANA.
  3.1004 +
  3.1005 +
  3.1006 +
  3.1007 +
  3.1008 +
  3.1009 +
  3.1010 +
  3.1011 +Birk, et al.               Expires May 7, 2020                 [Page 18]
  3.1012 +
  3.1013 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1014 +
  3.1015 +
  3.1016 +12.  Implementation Status
  3.1017 +
  3.1018 +12.1.  Introduction
  3.1019 +
  3.1020 +   This section records the status of known implementations of the
  3.1021 +   protocol defined by this specification at the time of posting of this
  3.1022 +   Internet-Draft, and is based on a proposal described in [RFC7942].
  3.1023 +   The description of implementations in this section is intended to
  3.1024 +   assist the IETF in its decision processes in progressing drafts to
  3.1025 +   RFCs.  Please note that the listing of any individual implementation
  3.1026 +   here does not imply endorsement by the IETF.  Furthermore, no effort
  3.1027 +   has been spent to verify the information presented here that was
  3.1028 +   supplied by IETF contributors.  This is not intended as, and must not
  3.1029 +   be construed to be, a catalog of available implementations or their
  3.1030 +   features.  Readers are advised to note that other implementations may
  3.1031 +   exist.
  3.1032 +
  3.1033 +   According to [RFC7942], "[...] this will allow reviewers and working
  3.1034 +   groups to assign due consideration to documents that have the benefit
  3.1035 +   of running code, which may serve as evidence of valuable
  3.1036 +   experimentation and feedback that have made the implemented protocols
  3.1037 +   more mature.  It is up to the individual working groups to use this
  3.1038 +   information as they see fit."
  3.1039 +
  3.1040 +12.2.  Current software implementing pEp
  3.1041 +
  3.1042 +   The following software implementing the pEp protocols (to varying
  3.1043 +   degrees) already exists:
  3.1044 +
  3.1045 +   o  pEp for Outlook as add-on for Microsoft Outlook, release
  3.1046 +      [SRC.pepforoutlook]
  3.1047 +
  3.1048 +   o  pEp for Android (based on a fork of the K9 MUA), release
  3.1049 +      [SRC.pepforandroid]
  3.1050 +
  3.1051 +   o  Enigmail/pEp as add-on for Mozilla Thunderbird, release
  3.1052 +      [SRC.enigmailpep]
  3.1053 +
  3.1054 +   o  pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
  3.1055 +
  3.1056 +   pEp for Android, iOS and Outlook are provided by pEp Security, a
  3.1057 +   commercial entity specializing in end-user software implementing pEp
  3.1058 +   while Enigmail/pEp is pursued as community project, supported by the
  3.1059 +   pEp Foundation.
  3.1060 +
  3.1061 +   All software is available as Free Software and published also in
  3.1062 +   source form.
  3.1063 +
  3.1064 +
  3.1065 +
  3.1066 +
  3.1067 +Birk, et al.               Expires May 7, 2020                 [Page 19]
  3.1068 +
  3.1069 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1070 +
  3.1071 +
  3.1072 +12.3.  Reference implementation of pEp's core
  3.1073 +
  3.1074 +   The pEp Foundation provides a reference implementation of pEp's core
  3.1075 +   principles and functionalities, which go beyond the documentation
  3.1076 +   status of this Internet-Draft.  [SRC.pepcore]
  3.1077 +
  3.1078 +   pEp's reference implementation is composed of pEp Engine and pEp
  3.1079 +   Adapters (or bindings), alongside with some libraries which pEp
  3.1080 +   Engine relies on to function on certain platforms (like a NetPGP fork
  3.1081 +   we maintain for the iOS platform).
  3.1082 +
  3.1083 +   The pEp engine is a Free Software library encapsulating
  3.1084 +   implementations of:
  3.1085 +
  3.1086 +   o  Key Management
  3.1087 +
  3.1088 +      Key Management in pEp engine is based on GnuPG key chains (NetPGP
  3.1089 +      on iOS).  Keys are stored in an OpenPGP compatible format and can
  3.1090 +      be used for different crypto implementations.
  3.1091 +
  3.1092 +   o  Trust Rating
  3.1093 +
  3.1094 +      pEp engine is sporting a two phase trust rating system.  In phase
  3.1095 +      one there is a rating based on channel, crypto and key security
  3.1096 +      named "comm_types".  In phase 2 these are mapped to user
  3.1097 +      representable values which have attached colors to present them in
  3.1098 +      traffic light semantics.
  3.1099 +
  3.1100 +   o  Abstract Crypto API
  3.1101 +
  3.1102 +      The Abstract Crypto API is providing functions to encrypt and
  3.1103 +      decrypt data or full messages without requiring an application
  3.1104 +      programmer to understand the different formats and standards.
  3.1105 +
  3.1106 +   o  Message Transports
  3.1107 +
  3.1108 +      pEp engine will support a growing list of Message Transports to
  3.1109 +      support any widespread text messaging system including email, SMS,
  3.1110 +      XMPP and many more.
  3.1111 +
  3.1112 +   pEp engine is written in C99 programming language.  It is not meant
  3.1113 +   to be used in application code directly.  Instead, pEp engine is
  3.1114 +   coming together with a list of software adapters for a variety of
  3.1115 +   programming languages and development environments, which are:
  3.1116 +
  3.1117 +   o  pEp COM Server Adapter
  3.1118 +
  3.1119 +   o  pEp JNI Adapter
  3.1120 +
  3.1121 +
  3.1122 +
  3.1123 +Birk, et al.               Expires May 7, 2020                 [Page 20]
  3.1124 +
  3.1125 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1126 +
  3.1127 +
  3.1128 +   o  pEp JSON Adapter
  3.1129 +
  3.1130 +   o  pEp ObjC (and Swift) Adapter
  3.1131 +
  3.1132 +   o  pEp Python Adapter
  3.1133 +
  3.1134 +   o  pEp Qt Adapter
  3.1135 +
  3.1136 +12.4.  Abstract Crypto API examples
  3.1137 +
  3.1138 +   A selection of code excerpts from the pEp Engine reference
  3.1139 +   implementation (encrypt message, decrypt message, and obtain
  3.1140 +   trustwords) can be found in Appendix A.3.
  3.1141 +
  3.1142 +13.  Notes
  3.1143 +
  3.1144 +   The pEp logo and "pretty Easy privacy" are registered trademarks
  3.1145 +   owned by the non-profit pEp Foundation based in Switzerland.
  3.1146 +
  3.1147 +   Primarily, we want to ensure the following:
  3.1148 +
  3.1149 +   o  Software using the trademarks MUST be backdoor-free.
  3.1150 +
  3.1151 +   o  Software using the trademarks MUST be accompanied by a serious
  3.1152 +      (detailed) code audit carried out by a reputable third-party, for
  3.1153 +      any proper release.
  3.1154 +
  3.1155 +   The pEp Foundation will help to support any community-run (non-
  3.1156 +   commercial) project with the latter, be it organizationally or
  3.1157 +   financially.
  3.1158 +
  3.1159 +   Through this, the foundation wants to make sure that software using
  3.1160 +   the pEp trademarks is as safe as possible from a security and privacy
  3.1161 +   point of view.
  3.1162 +
  3.1163 +14.  Acknowledgments
  3.1164 +
  3.1165 +   The authors would like to thank the following people who provided
  3.1166 +   substantial contributions, helpful comments or suggestions for this
  3.1167 +   document: Alexey Melnikov, Athena Schumacher, Ben Campbell, Brian
  3.1168 +   Trammell, Bron Gondwana, Claudio Luck, Daniel Kahn Gillmor, Enrico
  3.1169 +   Tomae, Eric Rescorla, Gabriele Lenzini, Hans-Peter Dittler, Iraklis
  3.1170 +   Symeonidis, Kelly Bristol, Krista Bennett, Mirja Kuehlewind, Nana
  3.1171 +   Kerlstetter, Neal Walfield, Pete Resnick, Russ Housley, S.  Shelburn,
  3.1172 +   and Stephen Farrel.
  3.1173 +
  3.1174 +
  3.1175 +
  3.1176 +
  3.1177 +
  3.1178 +
  3.1179 +Birk, et al.               Expires May 7, 2020                 [Page 21]
  3.1180 +
  3.1181 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1182 +
  3.1183 +
  3.1184 +   This work was initially created by pEp Foundation, and then reviewed
  3.1185 +   and extended with funding by the Internet Society's Beyond the Net
  3.1186 +   Programme on standardizing pEp.  [ISOC.bnet]
  3.1187 +
  3.1188 +15.  References
  3.1189 +
  3.1190 +15.1.  Normative References
  3.1191 +
  3.1192 +   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  3.1193 +              Requirement Levels", BCP 14, RFC 2119,
  3.1194 +              DOI 10.17487/RFC2119, March 1997,
  3.1195 +              <https://www.rfc-editor.org/info/rfc2119>.
  3.1196 +
  3.1197 +   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
  3.1198 +              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
  3.1199 +              <https://www.rfc-editor.org/info/rfc4949>.
  3.1200 +
  3.1201 +   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
  3.1202 +              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
  3.1203 +              December 2014, <https://www.rfc-editor.org/info/rfc7435>.
  3.1204 +
  3.1205 +15.2.  Informative References
  3.1206 +
  3.1207 +   [I-D.birk-pep-trustwords]
  3.1208 +              Hoeneisen, B. and H. Marques, "IANA Registration of
  3.1209 +              Trustword Lists: Guide, Template and IANA Considerations",
  3.1210 +              draft-birk-pep-trustwords-04 (work in progress), July
  3.1211 +              2019.
  3.1212 +
  3.1213 +   [I-D.hoeneisen-pep-keysync]
  3.1214 +              Hoeneisen, B., Marques, H., and K. Bristol, "pretty Easy
  3.1215 +              privacy (pEp): Key Synchronization Protocol (KeySync)",
  3.1216 +              draft-hoeneisen-pep-keysync-01 (work in progress), October
  3.1217 +              2019.
  3.1218 +
  3.1219 +   [I-D.marques-pep-email]
  3.1220 +              Marques, H., "pretty Easy privacy (pEp): Email Formats and
  3.1221 +              Protocols", draft-marques-pep-email-02 (work in progress),
  3.1222 +              October 2018.
  3.1223 +
  3.1224 +   [I-D.marques-pep-handshake]
  3.1225 +              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
  3.1226 +              Contact and Channel Authentication through Handshake",
  3.1227 +              draft-marques-pep-handshake-03 (work in progress), July
  3.1228 +              2019.
  3.1229 +
  3.1230 +
  3.1231 +
  3.1232 +
  3.1233 +
  3.1234 +
  3.1235 +Birk, et al.               Expires May 7, 2020                 [Page 22]
  3.1236 +
  3.1237 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1238 +
  3.1239 +
  3.1240 +   [I-D.marques-pep-rating]
  3.1241 +              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
  3.1242 +              Mapping of Privacy Rating", draft-marques-pep-rating-02
  3.1243 +              (work in progress), July 2019.
  3.1244 +
  3.1245 +   [ISOC.bnet]
  3.1246 +              Simao, I., "Beyond the Net. 12 Innovative Projects
  3.1247 +              Selected for Beyond the Net Funding. Implementing Privacy
  3.1248 +              via Mass Encryption: Standardizing pretty Easy privacy's
  3.1249 +              protocols", June 2017, <https://www.internetsociety.org/
  3.1250 +              blog/2017/06/12-innovative-projects-selected-for-beyond-
  3.1251 +              the-net-funding/>.
  3.1252 +
  3.1253 +   [OpenPGP]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
  3.1254 +              Thayer, "OpenPGP Message Format", RFC 4880,
  3.1255 +              DOI 10.17487/RFC4880, November 2007,
  3.1256 +              <https://www.rfc-editor.org/info/rfc4880>.
  3.1257 +
  3.1258 +   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
  3.1259 +              Communication Layers", STD 3, RFC 1122,
  3.1260 +              DOI 10.17487/RFC1122, October 1989,
  3.1261 +              <https://www.rfc-editor.org/info/rfc1122>.
  3.1262 +
  3.1263 +   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
  3.1264 +              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
  3.1265 +              2014, <https://www.rfc-editor.org/info/rfc7258>.
  3.1266 +
  3.1267 +   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
  3.1268 +              Code: The Implementation Status Section", BCP 205,
  3.1269 +              RFC 7942, DOI 10.17487/RFC7942, July 2016,
  3.1270 +              <https://www.rfc-editor.org/info/rfc7942>.
  3.1271 +
  3.1272 +   [RFC8280]  ten Oever, N. and C. Cath, "Research into Human Rights
  3.1273 +              Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
  3.1274 +              October 2017, <https://www.rfc-editor.org/info/rfc8280>.
  3.1275 +
  3.1276 +   [SRC.enigmailpep]
  3.1277 +              "Source code for Enigmail/pEp", July 2019,
  3.1278 +              <https://enigmail.net/index.php/en/download/source-code>.
  3.1279 +
  3.1280 +   [SRC.pepcore]
  3.1281 +              "Core source code and reference implementation of pEp
  3.1282 +              (engine and adapters)", July 2018,
  3.1283 +              <https://pep.foundation/dev/>.
  3.1284 +
  3.1285 +   [SRC.pepforandroid]
  3.1286 +              "Source code for pEp for Android", July 2019,
  3.1287 +              <https://pep-security.lu/gitlab/android/pep>.
  3.1288 +
  3.1289 +
  3.1290 +
  3.1291 +Birk, et al.               Expires May 7, 2020                 [Page 23]
  3.1292 +
  3.1293 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1294 +
  3.1295 +
  3.1296 +   [SRC.pepforios]
  3.1297 +              "Source code for pEp for iOS", July 2019,
  3.1298 +              <https://pep-security.ch/dev/repos/pEp_for_iOS/>.
  3.1299 +
  3.1300 +   [SRC.pepforoutlook]
  3.1301 +              "Source code for pEp for Outlook", July 2019,
  3.1302 +              <https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
  3.1303 +
  3.1304 +Appendix A.  Code Excerpts
  3.1305 +
  3.1306 +   This section provides excerpts of the running code from the pEp
  3.1307 +   reference implementation pEp engine (C99 programming language).
  3.1308 +
  3.1309 +A.1.  pEp Identity
  3.1310 +
  3.1311 +   How the pEp identity is defined in the data structure (cf. src/
  3.1312 +   pEpEngine.h):
  3.1313 +
  3.1314 +   typedef struct _pEp_identity {
  3.1315 +       char *address;            // C string with address UTF-8 encoded
  3.1316 +       char *fpr;                // C string with fingerprint UTF-8
  3.1317 +                                 // encoded
  3.1318 +       char *user_id;            // C string with user ID UTF-8 encoded
  3.1319 +       char *username;           // C string with user name UTF-8
  3.1320 +                                 // encoded
  3.1321 +       PEP_comm_type comm_type;  // type of communication with this ID
  3.1322 +       char lang[3];             // language of conversation
  3.1323 +                                 // ISO 639-1 ALPHA-2, last byte is 0
  3.1324 +       bool me;                  // if this is the local user
  3.1325 +                                 // herself/himself
  3.1326 +       identity_flags_t flags;   // identity_flag1 | identity_flag2
  3.1327 +                                 // | ...
  3.1328 +   } pEp_identity;
  3.1329 +
  3.1330 +A.1.1.  Corresponding SQL
  3.1331 +
  3.1332 +   Relational table scheme excerpts (in SQL) used in current pEp
  3.1333 +   implementations, held locally for every pEp installation in a SQLite
  3.1334 +   database:
  3.1335 +
  3.1336 +
  3.1337 +
  3.1338 +
  3.1339 +
  3.1340 +
  3.1341 +
  3.1342 +
  3.1343 +
  3.1344 +
  3.1345 +
  3.1346 +
  3.1347 +Birk, et al.               Expires May 7, 2020                 [Page 24]
  3.1348 +
  3.1349 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1350 +
  3.1351 +
  3.1352 +   CREATE TABLE person (
  3.1353 +      id text primary key,
  3.1354 +      username text not null,
  3.1355 +      main_key_id text
  3.1356 +          references pgp_keypair (fpr)
  3.1357 +          on delete set null,
  3.1358 +      lang text,
  3.1359 +      comment text,
  3.1360 +      device_group text,
  3.1361 +      is_pep_user integer default 0
  3.1362 +   );
  3.1363 +
  3.1364 +   CREATE TABLE identity (
  3.1365 +      address text,
  3.1366 +      user_id text
  3.1367 +          references person (id)
  3.1368 +          on delete cascade on update cascade,
  3.1369 +      main_key_id text
  3.1370 +          references pgp_keypair (fpr)
  3.1371 +          on delete set null,
  3.1372 +      comment text,
  3.1373 +      flags integer default 0,
  3.1374 +      is_own integer default 0,
  3.1375 +      timestamp integer default (datetime('now')),
  3.1376 +      primary key (address, user_id)
  3.1377 +   );
  3.1378 +
  3.1379 +   CREATE TABLE pgp_keypair (
  3.1380 +      fpr text primary key,
  3.1381 +      created integer,
  3.1382 +      expires integer,
  3.1383 +      comment text,
  3.1384 +      flags integer default 0
  3.1385 +   );
  3.1386 +   CREATE INDEX pgp_keypair_expires on pgp_keypair (
  3.1387 +      expires
  3.1388 +   );
  3.1389 +
  3.1390 +A.2.  pEp Communication Type
  3.1391 +
  3.1392 +   In the following, is an example for the rating of communication types
  3.1393 +   as defined by a data structure (cf. src/pEpEngine.h [SRC.pepcore]):
  3.1394 +
  3.1395 +   typedef enum _PEP_comm_type {
  3.1396 +       PEP_ct_unknown = 0,
  3.1397 +
  3.1398 +       // range 0x01 to 0x09: no encryption, 0x0a to 0x0e:
  3.1399 +       // nothing reasonable
  3.1400 +
  3.1401 +
  3.1402 +
  3.1403 +Birk, et al.               Expires May 7, 2020                 [Page 25]
  3.1404 +
  3.1405 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1406 +
  3.1407 +
  3.1408 +       PEP_ct_no_encryption = 0x01, // generic
  3.1409 +       PEP_ct_no_encrypted_channel = 0x02,
  3.1410 +       PEP_ct_key_not_found = 0x03,
  3.1411 +       PEP_ct_key_expired = 0x04,
  3.1412 +       PEP_ct_key_revoked = 0x05,
  3.1413 +       PEP_ct_key_b0rken = 0x06,
  3.1414 +       PEP_ct_my_key_not_included = 0x09,
  3.1415 +
  3.1416 +       PEP_ct_security_by_obscurity = 0x0a,
  3.1417 +       PEP_ct_b0rken_crypto = 0x0b,
  3.1418 +       PEP_ct_key_too_short = 0x0c,
  3.1419 +
  3.1420 +       PEP_ct_compromized = 0x0e, // known compromized connection
  3.1421 +       PEP_ct_mistrusted = 0x0f, // known mistrusted key
  3.1422 +
  3.1423 +       // range 0x10 to 0x3f: unconfirmed encryption
  3.1424 +
  3.1425 +       PEP_ct_unconfirmed_encryption = 0x10, // generic
  3.1426 +       PEP_ct_OpenPGP_weak_unconfirmed = 0x11, // RSA 1024 is weak
  3.1427 +
  3.1428 +       PEP_ct_to_be_checked = 0x20, // generic
  3.1429 +       PEP_ct_SMIME_unconfirmed = 0x21,
  3.1430 +       PEP_ct_CMS_unconfirmed = 0x22,
  3.1431 +
  3.1432 +       PEP_ct_strong_but_unconfirmed = 0x30, // generic
  3.1433 +       PEP_ct_OpenPGP_unconfirmed = 0x38, // key at least 2048 bit
  3.1434 +                                          // RSA or EC
  3.1435 +       PEP_ct_OTR_unconfirmed = 0x3a,
  3.1436 +
  3.1437 +       // range 0x40 to 0x7f: unconfirmed encryption and anonymization
  3.1438 +
  3.1439 +       PEP_ct_unconfirmed_enc_anon = 0x40, // generic
  3.1440 +       PEP_ct_pEp_unconfirmed = 0x7f,
  3.1441 +
  3.1442 +       PEP_ct_confirmed = 0x80, // this bit decides if trust
  3.1443 +                                // is confirmed
  3.1444 +
  3.1445 +       // range 0x81 to 0x8f: reserved
  3.1446 +       // range 0x90 to 0xbf: confirmed encryption
  3.1447 +
  3.1448 +       PEP_ct_confirmed_encryption = 0x90, // generic
  3.1449 +       PEP_ct_OpenPGP_weak = 0x91, // RSA 1024 is weak (unused)
  3.1450 +
  3.1451 +       PEP_ct_to_be_checked_confirmed = 0xa0, //generic
  3.1452 +       PEP_ct_SMIME = 0xa1,
  3.1453 +       PEP_ct_CMS = 0xa2,
  3.1454 +
  3.1455 +       PEP_ct_strong_encryption = 0xb0, // generic
  3.1456 +
  3.1457 +
  3.1458 +
  3.1459 +Birk, et al.               Expires May 7, 2020                 [Page 26]
  3.1460 +
  3.1461 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1462 +
  3.1463 +
  3.1464 +       PEP_ct_OpenPGP = 0xb8, // key at least 2048 bit RSA or EC
  3.1465 +       PEP_ct_OTR = 0xba,
  3.1466 +
  3.1467 +       // range 0xc0 to 0xff: confirmed encryption and anonymization
  3.1468 +
  3.1469 +       PEP_ct_confirmed_enc_anon = 0xc0, // generic
  3.1470 +       PEP_ct_pEp = 0xff
  3.1471 +   } PEP_comm_type;
  3.1472 +
  3.1473 +A.3.  Abstract Crypto API examples
  3.1474 +
  3.1475 +   The following code excerpts are from the pEp Engine reference
  3.1476 +   implementation, to be found in src/message_api.h.
  3.1477 +
  3.1478 +   [[ Note: Just a selection; more functionality is available. ]]
  3.1479 +
  3.1480 +A.3.1.  Encrypting a Message
  3.1481 +
  3.1482 +   Cf. src/message_api.h [SRC.pepcore]:
  3.1483 +
  3.1484 +
  3.1485 +
  3.1486 +
  3.1487 +
  3.1488 +
  3.1489 +
  3.1490 +
  3.1491 +
  3.1492 +
  3.1493 +
  3.1494 +
  3.1495 +
  3.1496 +
  3.1497 +
  3.1498 +
  3.1499 +
  3.1500 +
  3.1501 +
  3.1502 +
  3.1503 +
  3.1504 +
  3.1505 +
  3.1506 +
  3.1507 +
  3.1508 +
  3.1509 +
  3.1510 +
  3.1511 +
  3.1512 +
  3.1513 +
  3.1514 +
  3.1515 +Birk, et al.               Expires May 7, 2020                 [Page 27]
  3.1516 +
  3.1517 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1518 +
  3.1519 +
  3.1520 +   // encrypt_message() - encrypt message in memory
  3.1521 +   //
  3.1522 +   //  parameters:
  3.1523 +   //      session (in)     session handle
  3.1524 +   //      src (in)         message to encrypt
  3.1525 +   //      extra (in)       extra keys for encryption
  3.1526 +   //      dst (out)        pointer to new encrypted message or NULL if
  3.1527 +   //                       no encryption could take place
  3.1528 +   //      enc_format (in)  encrypted format
  3.1529 +   //      flags (in)       flags to set special encryption features
  3.1530 +   //
  3.1531 +   //  return value:
  3.1532 +   //      PEP_STATUS_OK           on success
  3.1533 +   //      PEP_KEY_HAS_AMBIG_NAME  at least one of the recipient
  3.1534 +   //                              keys has an ambiguous name
  3.1535 +   //      PEP_UNENCRYPTED         no recipients with usable key,
  3.1536 +   //                              message is left unencrypted,
  3.1537 +   //                              and key is attached to it
  3.1538 +   //
  3.1539 +   //  caveat:
  3.1540 +   //      the ownership of src remains with the caller
  3.1541 +   //      the ownership of dst goes to the caller
  3.1542 +   DYNAMIC_API PEP_STATUS encrypt_message(
  3.1543 +           PEP_SESSION session,
  3.1544 +           message *src,
  3.1545 +           stringlist_t *extra,
  3.1546 +           message **dst,
  3.1547 +           PEP_enc_format enc_format,
  3.1548 +           PEP_encrypt_flags_t flags
  3.1549 +   );
  3.1550 +
  3.1551 +   Cf. src/message_api.h [SRC.pepcore]:
  3.1552 +
  3.1553 +A.3.2.  Decrypting a Message
  3.1554 +
  3.1555 +   Cf. src/message_api.h [SRC.pepcore]:
  3.1556 +
  3.1557 +   // decrypt_message() - decrypt message in memory
  3.1558 +   //
  3.1559 +   //  parameters:
  3.1560 +   //      session (in)   session handle
  3.1561 +   //      src (in)       message to decrypt
  3.1562 +   //      dst (out)      pointer to new decrypted message
  3.1563 +   //                     or NULL on failure
  3.1564 +   //      keylist (out)  stringlist with keyids
  3.1565 +   //      rating (out)   rating for the message
  3.1566 +   //      flags (out)    flags to signal special decryption features
  3.1567 +   //
  3.1568 +
  3.1569 +
  3.1570 +
  3.1571 +Birk, et al.               Expires May 7, 2020                 [Page 28]
  3.1572 +
  3.1573 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1574 +
  3.1575 +
  3.1576 +   //  return value:
  3.1577 +   //      error status
  3.1578 +   //      or PEP_DECRYPTED if message decrypted but not verified
  3.1579 +   //      or PEP_CANNOT_REENCRYPT if message was decrypted (and
  3.1580 +   //         possibly verified) but a reencryption operation is
  3.1581 +   //         expected by the caller and failed
  3.1582 +   //      or PEP_STATUS_OK on success
  3.1583 +   //
  3.1584 +   //  flag values:
  3.1585 +   //      in:
  3.1586 +   //          PEP_decrypt_flag_untrusted_server
  3.1587 +   //              used to signal that decrypt function should engage in
  3.1588 +   //              behaviour specified for when the server storing the
  3.1589 +   //              source is untrusted
  3.1590 +   //      out:
  3.1591 +   //          PEP_decrypt_flag_own_private_key
  3.1592 +   //              private key was imported for one of our addresses
  3.1593 +   //              (NOT trusted or set to be used - handshake/trust is
  3.1594 +   //              required for that)
  3.1595 +   //          PEP_decrypt_flag_src_modified
  3.1596 +   //              indicates that the src object has been modified. At
  3.1597 +   //              the moment, this is always as a direct result of the
  3.1598 +   //              behaviour driven by the input flags. This flag is the
  3.1599 +   //              ONLY value that should be relied upon to see if such
  3.1600 +   //              changes have taken place.
  3.1601 +   //          PEP_decrypt_flag_consume
  3.1602 +   //              used by sync
  3.1603 +   //          PEP_decrypt_flag_ignore
  3.1604 +   //              used by sync
  3.1605 +   //
  3.1606 +   //
  3.1607 +   // caveat:
  3.1608 +   //      the ownership of src remains with the caller - however, the
  3.1609 +   //      contents might be modified (strings freed and allocated anew
  3.1610 +   //      or set to NULL, etc) intentionally; when this happens,
  3.1611 +   //      PEP_decrypt_flag_src_modified is set.
  3.1612 +   //      the ownership of dst goes to the caller
  3.1613 +   //      the ownership of keylist goes to the caller
  3.1614 +   //      if src is unencrypted this function returns PEP_UNENCRYPTED
  3.1615 +   //      and sets
  3.1616 +   //      dst to NULL
  3.1617 +   DYNAMIC_API PEP_STATUS decrypt_message(
  3.1618 +           PEP_SESSION session,
  3.1619 +           message *src,
  3.1620 +           message **dst,
  3.1621 +           stringlist_t **keylist,
  3.1622 +           PEP_rating *rating,
  3.1623 +           PEP_decrypt_flags_t *flags
  3.1624 +
  3.1625 +
  3.1626 +
  3.1627 +Birk, et al.               Expires May 7, 2020                 [Page 29]
  3.1628 +
  3.1629 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1630 +
  3.1631 +
  3.1632 +   );
  3.1633 +
  3.1634 +A.3.3.  Obtain Common Trustwords
  3.1635 +
  3.1636 +   Cf. src/message_api.h [SRC.pepcore]:
  3.1637 +
  3.1638 +   // get_trustwords() - get full trustwords string
  3.1639 +   //                    for a *pair* of identities
  3.1640 +   //
  3.1641 +   //    parameters:
  3.1642 +   //        session (in)  session handle
  3.1643 +   //        id1 (in)      identity of first party in communication
  3.1644 +   //                      - fpr can't be NULL
  3.1645 +   //        id2 (in)      identity of second party in communication
  3.1646 +   //                      - fpr can't be NULL
  3.1647 +   //        lang (in)     C string with ISO 639-1 language code
  3.1648 +   //        words (out)   pointer to C string with all trustwords
  3.1649 +   //                      UTF-8 encoded, separated by a blank each
  3.1650 +   //                      NULL if language is not supported or
  3.1651 +   //                      trustword wordlist is damaged or unavailable
  3.1652 +   //        wsize (out)   length of full trustwords string
  3.1653 +   //        full (in)     if true, generate ALL trustwords for these
  3.1654 +   //                      identities.
  3.1655 +   //                      else, generate a fixed-size subset.
  3.1656 +   //                      (TODO: fixed-minimum-entropy subset
  3.1657 +   //                      in next version)
  3.1658 +   //
  3.1659 +   //    return value:
  3.1660 +   //        PEP_STATUS_OK            trustwords retrieved
  3.1661 +   //        PEP_OUT_OF_MEMORY        out of memory
  3.1662 +   //        PEP_TRUSTWORD_NOT_FOUND  at least one trustword not found
  3.1663 +   //
  3.1664 +   //    caveat:
  3.1665 +   //        the word pointer goes to the ownership of the caller
  3.1666 +   //        the caller is responsible to free() it
  3.1667 +   //        (on Windoze use pEp_free())
  3.1668 +   //
  3.1669 +   DYNAMIC_API PEP_STATUS get_trustwords(
  3.1670 +     PEP_SESSION session, const pEp_identity* id1,
  3.1671 +     const pEp_identity* id2, const char* lang,
  3.1672 +     char **words, size_t *wsize, bool full
  3.1673 +   );
  3.1674 +
  3.1675 +Appendix B.  Document Changelog
  3.1676 +
  3.1677 +   [[ RFC Editor: This section is to be removed before publication ]]
  3.1678 +
  3.1679 +   o  draft-birk-pep-05:
  3.1680 +
  3.1681 +
  3.1682 +
  3.1683 +Birk, et al.               Expires May 7, 2020                 [Page 30]
  3.1684 +
  3.1685 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1686 +
  3.1687 +
  3.1688 +      *  Change authors
  3.1689 +
  3.1690 +      *  Minor changes, especially in identity system
  3.1691 +
  3.1692 +   o  draft-birk-pep-04:
  3.1693 +
  3.1694 +      *  Fix internal reference
  3.1695 +
  3.1696 +      *  Add IANA Considerations section
  3.1697 +
  3.1698 +      *  Add other use case of Extra Keys
  3.1699 +
  3.1700 +      *  Add Claudio Luck as author
  3.1701 +
  3.1702 +      *  Incorporate review changes by Kelly Bristol and Nana
  3.1703 +         Karlstetter
  3.1704 +
  3.1705 +   o  draft-birk-pep-03:
  3.1706 +
  3.1707 +      *  Major restructure of the document
  3.1708 +
  3.1709 +      *  Adapt authors to the actual authors and extend Acknowledgments
  3.1710 +         section
  3.1711 +
  3.1712 +      *  Added several new sections, e.g., Key Reset, Trust Revoke,
  3.1713 +         Trust Synchronization, Private Key Export / Import, Privacy
  3.1714 +         Considerations (content yet mostly TODO)
  3.1715 +
  3.1716 +      *  Added reference to HRPC work / RFC8280
  3.1717 +
  3.1718 +         +  Added text and figure to better explain pEp's automated Key
  3.1719 +            Exchange and Trust management (basic message flow)
  3.1720 +
  3.1721 +      *  Lots of improvement in text and editorial changes
  3.1722 +
  3.1723 +   o  draft-birk-pep-02:
  3.1724 +
  3.1725 +      *  Move (updated) code to Appendix
  3.1726 +
  3.1727 +      *  Add Changelog to Appendix
  3.1728 +
  3.1729 +      *  Add Open Issue section to Appendix
  3.1730 +
  3.1731 +      *  Fix description of what Extra Keys are
  3.1732 +
  3.1733 +      *  Fix Passive Mode description
  3.1734 +
  3.1735 +      *  Better explain pEp's identity system
  3.1736 +
  3.1737 +
  3.1738 +
  3.1739 +Birk, et al.               Expires May 7, 2020                 [Page 31]
  3.1740 +
  3.1741 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1742 +
  3.1743 +
  3.1744 +   o  draft-birk-pep-01:
  3.1745 +
  3.1746 +      *  Mostly editorial
  3.1747 +
  3.1748 +   o  draft-birk-pep-00:
  3.1749 +
  3.1750 +      *  Initial version
  3.1751 +
  3.1752 +Appendix C.  Open Issues
  3.1753 +
  3.1754 +   [[ RFC Editor: This section should be empty and is to be removed
  3.1755 +   before publication ]]
  3.1756 +
  3.1757 +   o  Shorten Introduction and Abstract
  3.1758 +
  3.1759 +   o  References to RFC6973 (Privacy Considerations)
  3.1760 +
  3.1761 +   o  Add references to prior work, and what differs here - PEM (cf.
  3.1762 +      RFC1421-1424)
  3.1763 +
  3.1764 +   o  Better explain Passive Mode
  3.1765 +
  3.1766 +   o  Better explain / illustrate pEp's identity system
  3.1767 +
  3.1768 +   o  Explain Concept of Key Mapping (e.g. to S/MIME, which is to be
  3.1769 +      refined in pEp application docs auch as pEp email
  3.1770 +      [I-D.marques-pep-email])
  3.1771 +
  3.1772 +   o  Add more information to deal with organizational requirements
  3.1773 +
  3.1774 +   o  Add text to Key Reset (Section 4.3) as well as reference as soon
  3.1775 +      as available
  3.1776 +
  3.1777 +   o  Add text to Trust Revoke (Section 5.4) as well as reference as
  3.1778 +      soon as available
  3.1779 +
  3.1780 +   o  Add text to Trust Synchronization (Section 6.2) as well as
  3.1781 +      reference as soon as available
  3.1782 +
  3.1783 +   o  Add text to Privacy Considerations (Section 10)
  3.1784 +
  3.1785 +   o  Scan for leftovers of email-specific stuff and move it to pEp
  3.1786 +      email I-D [I-D.marques-pep-email], while replacing it herein with
  3.1787 +      generic descriptions.
  3.1788 +
  3.1789 +
  3.1790 +
  3.1791 +
  3.1792 +
  3.1793 +
  3.1794 +
  3.1795 +Birk, et al.               Expires May 7, 2020                 [Page 32]
  3.1796 +
  3.1797 +Internet-Draft          pretty Easy privacy (pEp)          November 2019
  3.1798 +
  3.1799 +
  3.1800 +Authors' Addresses
  3.1801 +
  3.1802 +   Volker Birk
  3.1803 +   pEp Foundation
  3.1804 +   Oberer Graben 4
  3.1805 +   CH-8400 Winterthur
  3.1806 +   Switzerland
  3.1807 +
  3.1808 +   Email: volker.birk@pep.foundation
  3.1809 +   URI:   https://pep.foundation/
  3.1810 +
  3.1811 +
  3.1812 +   Hernani Marques
  3.1813 +   pEp Foundation
  3.1814 +   Oberer Graben 4
  3.1815 +   CH-8400 Winterthur
  3.1816 +   Switzerland
  3.1817 +
  3.1818 +   Email: hernani.marques@pep.foundation
  3.1819 +   URI:   https://pep.foundation/
  3.1820 +
  3.1821 +
  3.1822 +   Bernie Hoeneisen
  3.1823 +   pEp Foundation
  3.1824 +   Oberer Graben 4
  3.1825 +   CH-8400 Winterthur
  3.1826 +   Switzerland
  3.1827 +
  3.1828 +   Email: bernie.hoeneisen@pep.foundation
  3.1829 +   URI:   https://pep.foundation/
  3.1830 +
  3.1831 +
  3.1832 +
  3.1833 +
  3.1834 +
  3.1835 +
  3.1836 +
  3.1837 +
  3.1838 +
  3.1839 +
  3.1840 +
  3.1841 +
  3.1842 +
  3.1843 +
  3.1844 +
  3.1845 +
  3.1846 +
  3.1847 +
  3.1848 +
  3.1849 +
  3.1850 +
  3.1851 +Birk, et al.               Expires May 7, 2020                 [Page 33]
     4.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.2 +++ b/pep/archive/draft-birk-pep-05.xml	Mon Nov 04 22:57:49 2019 +0100
     4.3 @@ -0,0 +1,3377 @@
     4.4 +<?xml version="1.0" encoding="utf-8"?>
     4.5 +  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
     4.6 +  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->
     4.7 +
     4.8 +<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
     4.9 +]>
    4.10 +
    4.11 +<?rfc toc="yes"?>
    4.12 +<?rfc sortrefs="yes"?>
    4.13 +<?rfc symrefs="yes"?>
    4.14 +<?rfc comments="yes"?>
    4.15 +
    4.16 +<rfc docName="draft-birk-pep-05" category="std">
    4.17 +
    4.18 +  <front>
    4.19 +    <title abbrev="pretty Easy privacy (pEp)">pretty Easy privacy (pEp): Privacy by Default</title>
    4.20 +
    4.21 +    <author initials="V." surname="Birk" fullname="Volker Birk">
    4.22 +      <organization>pEp Foundation</organization>
    4.23 +      <address>
    4.24 +        <postal>
    4.25 +          <street>Oberer Graben 4</street>
    4.26 +          <city>CH-8400 Winterthur</city>
    4.27 +          <country>Switzerland</country>
    4.28 +        </postal>
    4.29 +        <email>volker.birk@pep.foundation</email>
    4.30 +        <uri>https://pep.foundation/</uri>
    4.31 +      </address>
    4.32 +    </author>
    4.33 +    <author initials="H." surname="Marques" fullname="Hernani Marques">
    4.34 +      <organization>pEp Foundation</organization>
    4.35 +      <address>
    4.36 +        <postal>
    4.37 +          <street>Oberer Graben 4</street>
    4.38 +          <city>CH-8400 Winterthur</city>
    4.39 +          <country>Switzerland</country>
    4.40 +        </postal>
    4.41 +        <email>hernani.marques@pep.foundation</email>
    4.42 +        <uri>https://pep.foundation/</uri>
    4.43 +      </address>
    4.44 +    </author>
    4.45 +    <author initials="B." surname="Hoeneisen" fullname="Bernie Hoeneisen">
    4.46 +      <organization>pEp Foundation</organization>
    4.47 +      <address>
    4.48 +        <postal>
    4.49 +          <street>Oberer Graben 4</street>
    4.50 +          <city>CH-8400 Winterthur</city>
    4.51 +          <country>Switzerland</country>
    4.52 +        </postal>
    4.53 +        <email>bernie.hoeneisen@pep.foundation</email>
    4.54 +        <uri>https://pep.foundation/</uri>
    4.55 +      </address>
    4.56 +    </author>
    4.57 +
    4.58 +    <date year="2019" month="November" day="04"/>
    4.59 +
    4.60 +    
    4.61 +    
    4.62 +    
    4.63 +
    4.64 +    <abstract>
    4.65 +
    4.66 +
    4.67 +<t>The pretty Easy privacy (pEp) model and protocols describe a set of conventions
    4.68 +for the automation of operations traditionally seen as barriers to
    4.69 +the use and deployment of secure, privacy-preserving end-to-end interpersonal
    4.70 +messaging. These include, but are not limited to, key management, key
    4.71 +discovery, and private key handling (including peer-to-peer synchronization of
    4.72 +private keys and other user data across devices). Human Rights-enabling
    4.73 +principles like Data Minimization, End-to-End and Interoperability are
    4.74 +explicit design goals. For the goal of usable privacy, pEp
    4.75 +introduces means to verify communication between peers and proposes a 
    4.76 +trust-rating system to denote secure types of communications and signal the
    4.77 +privacy level available on a per-user and per-message level.
    4.78 +Significantly, the pEp protocols build on already available security
    4.79 +formats and message transports (e.g., PGP/MIME with email), and are written
    4.80 +with the intent to be interoperable with already widely-deployed systems
    4.81 +in order to ease adoption and implementation.
    4.82 +This document outlines the general design choices and principles of pEp.</t>
    4.83 +
    4.84 +
    4.85 +
    4.86 +    </abstract>
    4.87 +
    4.88 +
    4.89 +  </front>
    4.90 +
    4.91 +  <middle>
    4.92 +
    4.93 +
    4.94 +<section anchor="introduction" title="Introduction">
    4.95 +
    4.96 +<t>Secure and private communications are vital for many different
    4.97 +reasons, and there are particular properties that privacy-preserving
    4.98 +protocols need to fulfill in order to best serve users. In
    4.99 +particular, <xref target="RFC8280"/> has identified and documented important
   4.100 +principles such as data minimization, the end-to-end principle, and
   4.101 +interoperability as integral properties which enable access to
   4.102 +Human Rights. Today’s applications widely lack privacy support that ordinary 
   4.103 +users can easily adapt. The pretty Easy privacy (pEp) protocols generally
   4.104 +conform to the principles outlined in <xref target="RFC8280"/>, and, as such, can
   4.105 +facilitate the adoption and correct usage of secure and private
   4.106 +communications technology.</t>
   4.107 +
   4.108 +<t>The pretty Easy privacy (pEp) protocols are propositions to the
   4.109 +Internet community to create software for peers to automatically
   4.110 +encrypt, anonymize (where possible), and verify their daily written
   4.111 +digital communications.  This is achieved by building upon already
   4.112 +existing standards and tools and automating each step a user needs to
   4.113 +carry out in order to engage in secure end-to-end encrypted
   4.114 +communications.  Significantly, the pEp protocols describe how do to
   4.115 +this without dependence on centralized infrastructures.</t>
   4.116 +
   4.117 +<t>The pEp project emerged from the CryptoParty movement. During
   4.118 +that time, the initiators learned that while step-by-step guides can
   4.119 +help some users engage in secure end-to-end communications, it is both
   4.120 +more effective and convenient for the vast majority of users if these
   4.121 +step-by-step guides are put into running code (following a protocol), which
   4.122 +automates the initial configuration and general usage of cryptographic
   4.123 +tools. To facilitate this goal, pEp proposes the automation of key
   4.124 +management, key discovery, and key synchronization through an in-band
   4.125 +approach which follows the end-to-end principle.</t>
   4.126 +
   4.127 +<t>To mitigate man-in-the-middle attacks (MITM) by an active adversary,
   4.128 +and as the only manual step users carry out in the course of the
   4.129 +protocols, the proposed Trustwords <xref target="I-D.birk-pep-trustwords"/>
   4.130 +mechanism uses natural language representations of two peers’
   4.131 +fingerprints for users to verify their trust in a paired
   4.132 +communication channel.</t>
   4.133 +
   4.134 +<t>The privacy-by-default principles that pEp introduces are in
   4.135 +accordance with the perspective outlined in <xref target="RFC7435"/>, aiming to
   4.136 +provide opportunistic security in the sense of “some protection most
   4.137 +of the time”.  This is done, however, with the subtle but important
   4.138 +difference that when privacy is weighed against security, the choice
   4.139 +defaults to privacy.  Therefore, data minimization is a primary goal
   4.140 +in pEp (e.g., hiding subject lines and headers unnecessary for email
   4.141 +transport inside the encrypted payload of a message).</t>
   4.142 +
   4.143 +<t>The pEp propositions are focused on (but not limited to) written
   4.144 +digital communications and cover asynchronous (offline) types of
   4.145 +communications like email as well as synchronous (online) types such
   4.146 +as chat.</t>
   4.147 +
   4.148 +<t>pEp’s goal is to bridge different standardized and widely-used
   4.149 +communications channels such that users can reach communications
   4.150 +partners in the most privacy-enhancing way possible.</t>
   4.151 +
   4.152 +<!-- # Rewritten Inroduction from CL: HM to check for merging.
   4.153 +
   4.154 +The pretty Easy privacy (pEp) model and protocols represent an
   4.155 +implementation guideline for bringing Human Rights privacy
   4.156 +principles like data minimization, the end-to-end principle, and
   4.157 +interoperability to existing messaging applications. The pretty Easy
   4.158 +privacy (pEp) protocols are a proposition to the Internet community
   4.159 +to create interoperable software to allow the users to encrypt,
   4.160 +anonymize (where possible), and verify their daily written
   4.161 +communication without application boundaries. pEp does cross-device
   4.162 +trust management such that users are assisted in their privacy
   4.163 +preservation and end-to-end security. Users remain in control of
   4.164 +expressing their personal trust in the correspondents in an easy
   4.165 +way, an information which should be respected by as many
   4.166 +applications as possible.
   4.167 +
   4.168 +Balancing security and privacy in remote communication protocols is
   4.169 +vital for many different reasons, and there are unique properties
   4.170 +that protocols prioritizing privacy-preservation need to fulfill in
   4.171 +order to best serve users. In particular, {{RFC8280}} has identified
   4.172 +and documented essential principles required from a Human Rights
   4.173 +perspective when accessing the Internet, such as data minimization,
   4.174 +the end-to-end principle, and interoperability. While (partial)
   4.175 +implementations of these concepts are already available, today's
   4.176 +applications widely lack privacy support that ordinary users can
   4.177 +easily handle. The pretty Easy privacy (pEp) propositions generally
   4.178 +conform with the principles outlined in {{RFC8280}} as a matter of
   4.179 +course, and as such can be used to facilitate the adoption and
   4.180 +correct usage of secure and private communication technology.
   4.181 +
   4.182 +The pEp initiators learned from the CryptoParty movement, from which
   4.183 +the project emerged, that manually engaging cryptographic services
   4.184 +is only for the few. It is largely more effective and convenient to
   4.185 +automatically bootstrap the security context, and have humans just
   4.186 +do a verification whenever they prefer, and eventually re-use such
   4.187 +pre-verified trust anchors to authenticate further transports
   4.188 +automatically (multi-factor authentication).
   4.189 +
   4.190 +The privacy-by-default principles that pEp introduces are in
   4.191 +accordance with the perspective outlined in {{RFC7435}}, aiming to
   4.192 +provide opportunistic security in the sense of "some protection most
   4.193 +of the time". This is done, however, with the subtle but important
   4.194 +difference that when privacy is weighed against security, the choice
   4.195 +defaults to privacy.
   4.196 +
   4.197 +To mitigate man-in-the-middle attacks (MITM) by an active adversary,
   4.198 +the only manual step users carry out in the course of the pEp
   4.199 +protocol, is the proposed Trustwords {{I-D.birk-pep-trustwords}}
   4.200 +mechanism using natural language representations of two peers'
   4.201 +fingerprints for users to verify their trust in a paired
   4.202 +communication channel.
   4.203 +
   4.204 +The pEp propositions are focused on written digital communication,
   4.205 +but it is not excluded to other forms of communication may build
   4.206 +upon pEp. pEp covers both asynchronous (offline) types of
   4.207 +communication like email as well as synchronous (online) types of
   4.208 +communication such as chat protocols.
   4.209 +
   4.210 +-->
   4.211 +
   4.212 +<section anchor="relationship-to-other-pep-documents" title="Relationship to other pEp documents">
   4.213 +
   4.214 +<!-- TODO (HM): Merge -->
   4.215 +
   4.216 +<t>While this document outlines the general design choices and
   4.217 +principles of pEp, other related documents specialize in more
   4.218 +particular aspects of the model, or the application of pEp on a
   4.219 +specific protocol like as follows:</t>
   4.220 +
   4.221 +<t><list style="numbers">
   4.222 +  <t>pEp-enabled applications (e.g., pEp email
   4.223 +<xref target="I-D.marques-pep-email"/>).</t>
   4.224 +  <t>Helper functions for peer interaction, which facilitate understanding 
   4.225 +and handling of the cryptographic aspects of pEp implementation for 
   4.226 +users (e.g., pEp Handshake <xref target="I-D.marques-pep-handshake"/>).</t>
   4.227 +  <t>Helper functions for interactions between a user’s own devices, which give 
   4.228 +the user the ability to run pEp applications on different devices at the same 
   4.229 +time, such as a computer, mobile phone, or tablets (e.g., pEp KeySync
   4.230 +<xref target="I-D.hoeneisen-pep-keysync"/>).</t>
   4.231 +</list></t>
   4.232 +
   4.233 +<t>In addition, there are documents that do not directly depend on this
   4.234 +one, but provide generic functions needed in pEp, e.g., IANA
   4.235 +Registration of Trustword Lists <xref target="I-D.birk-pep-trustwords"/>.</t>
   4.236 +
   4.237 +<t>[[ Note: At this stage it is not yet clear to us how many of our
   4.238 +  implementation details should be part of new RFCs and where
   4.239 +  we can safely refer to already existing RFCs to clarify which RFCs
   4.240 +  we rely on. ]]</t>
   4.241 +
   4.242 +<!-- # Terms -->
   4.243 +<!-- # Normative language -->
   4.244 +
   4.245 +</section>
   4.246 +<section anchor="requirements-language" title="Requirements Language">
   4.247 +
   4.248 +<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
   4.249 +“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
   4.250 +document are to be interpreted as described in <xref target="RFC2119"/>.</t>
   4.251 +
   4.252 +<!-- ## Terms -->
   4.253 +
   4.254 +</section>
   4.255 +<section anchor="terms" title="Terms">
   4.256 +
   4.257 +<t>The following terms are defined for the scope of this document:</t>
   4.258 +
   4.259 +<t><list style="symbols">
   4.260 +  <t>pEp Handshake: The process of one user contacting another over an
   4.261 +independent channel in order to verify Trustwords (or fingerprints
   4.262 +as a fallback). This can be done in-person or through established
   4.263 +verbal communication channels, like a phone
   4.264 +call. <xref target="I-D.marques-pep-handshake"/></t>
   4.265 +  <t>Trustwords: A scalar-to-word representation of 16-bit numbers (0 to
   4.266 +65535) to natural language words. When doing a Handshake, peers are
   4.267 +shown combined Trustwords of both public keys involved to ease the
   4.268 +comparison. <xref target="I-D.birk-pep-trustwords"/></t>
   4.269 +</list></t>
   4.270 +
   4.271 +<!--
   4.272 +
   4.273 +[KRB] If my suggestions above are kept [[pEp Handshake]], there is no
   4.274 +need to have the second sentence about the Handshake, as it's already
   4.275 +been related in the Handshake definition.
   4.276 +
   4.277 +-->
   4.278 +
   4.279 +<t><list style="symbols">
   4.280 +  <t>Trust On First Use (TOFU): cf. <xref target="RFC7435"/>, which states: “In a
   4.281 +protocol, TOFU calls for accepting and storing a public key or
   4.282 +credential associated with an asserted identity, without
   4.283 +authenticating that assertion. Subsequent communication that is
   4.284 +authenticated using the cached key or credential is secure against
   4.285 +an MiTM attack, if such an attack did not succeed during the
   4.286 +vulnerable initial communication.”</t>
   4.287 +</list></t>
   4.288 +
   4.289 +<!-- TODO: Make clear that we use TOFU without T. -->
   4.290 +
   4.291 +<t><list style="symbols">
   4.292 +  <t>Man-in-the-middle (MITM) attack: cf. <xref target="RFC4949"/>, which states: “A
   4.293 +form of active wiretapping attack in which the attacker intercepts
   4.294 +and selectively modifies communicated data to masquerade as one or
   4.295 +more of the entities involved in a communication association.”</t>
   4.296 +</list></t>
   4.297 +
   4.298 +<!-- Out of scope:
   4.299 +Qualified Electronic Signature
   4.300 +: An electronic signature created with the intention to comply with official regulations or mutual agreements, usually to settle contractual terms electronically on par with traditional methods. Technically they may build upon the same protocols as pEp does, but pEp does not give them any particular meaning. Qualified Electronic Signatures are defined for example by the Swiss Federal Law Nr 943.03 on Certification Services, and the EU Regulation No 910/2014 (eIDAS Regulation).
   4.301 +-->
   4.302 +
   4.303 +<!-- To be discussed (if left in, adjust formating): 
   4.304 +OUTGOING MESSAGE
   4.305 +: A message which is being prepared with the intent to, or was already sent to other correspondents. Outgoing messages may be transient and quickly discarded, or being archived.
   4.306 +
   4.307 +INCOMING MESSAGE
   4.308 +: A message which is being received, or was previously received from other correspondents. Incoming messages are always persistent and never discarded, and may be archived.
   4.309 +-->
   4.310 +
   4.311 +</section>
   4.312 +</section>
   4.313 +<section anchor="protocols-core-design-principles" title="Protocol’s Core Design Principles">
   4.314 +
   4.315 +<section anchor="privacy-by-default" title="Privacy by Default">
   4.316 +
   4.317 +<t>pEp’s most important goal is to ensure privacy above all else. To clarify,
   4.318 +pEp’s protocol defaults are designed to maximize both security and privacy,
   4.319 +but in the few cases where achieving both more privacy and more security are in
   4.320 +conflict, pEp chooses more privacy.</t>
   4.321 +
   4.322 +<t>In contrast to pEp’s prioritization of user privacy, OpenPGP’s
   4.323 +Web-of-Trust (WoT) releases user and trust level relationships to the public.
   4.324 +In addition, queries to OpenPGP keyservers dynamically disclose the social 
   4.325 +graph, indicating a user’s intent to communicate with specific peers.
   4.326 +Similar issues exist in other security protocols that rely upon a 
   4.327 +centralized trust model, such as the certificate revocation protocols used in 
   4.328 +XPKI (S/MIME).</t>
   4.329 +
   4.330 +<t>[[<spanx style="strong">TODO</spanx>: Fix the wording and reference to XPKI, S/MIME]].</t>
   4.331 +
   4.332 +<t>In pEp messaging (e.g., when using HTML) content and information
   4.333 +SHALL NOT be obtained from remote locations as this constitutes a
   4.334 +privacy breach.</t>
   4.335 +
   4.336 +<t>Because of the inherent privacy risks in using remote or
   4.337 +centralized infrastructures, implementations of pEp messaging, by default, 
   4.338 +SHALL NOT obtain content and information from remote or centralized locations,
   4.339 +as this constitutes a privacy breach. In email this issue exists with HTML
   4.340 +mails.</t>
   4.341 +
   4.342 +<!-- ### Linking Correspondents to Contact Cards -->
   4.343 +
   4.344 +<!-- TODO: To be discussed; not only because of the content / the phrasing,
   4.345 +     but also because of the location.
   4.346 +
   4.347 +Users tend to manage databases of contact information about other
   4.348 +correspondents. Such databases contain information about different
   4.349 +addresses used by other correspondents which the user considers to be
   4.350 +reaching the same correspondent (potentially with different degrees of
   4.351 +end-to-end confidentiality).
   4.352 +
   4.353 +A software usually can't properly infere these relationships just
   4.354 +from the addresses. Engineers usually improve the result of their
   4.355 +software by handing out personalized tokens (e.g. HTTP cookies) and
   4.356 +looking for them in incoming correspondence, to do cross-channel
   4.357 +correlation and tracking.
   4.358 +
   4.359 +Such technology represents an attempt to breack privacy. pEp software
   4.360 +MUST NOT actively employ such technology, but SHOULD integrate with
   4.361 +contacts management and other information bases to passively learn
   4.362 +these associations which the local user already made.
   4.363 +
   4.364 +Basically speaking, it should be the user who actively breaks other
   4.365 +users' privacy, not the software, which should not anticipate and
   4.366 +automate the privacy breaking.
   4.367 +
   4.368 +
   4.369 +\[\ **NOTE**: having a hard time to specify this in exact terms, as
   4.370 +most terms are not yet introcuced at this point: identities, users,
   4.371 +end-to-end, ... \]\]
   4.372 +
   4.373 +-->
   4.374 +
   4.375 +</section>
   4.376 +<section anchor="data-minimization" title="Data Minimization">
   4.377 +
   4.378 +<t>Data minimization keeps data spare and hides all technically 
   4.379 +concealable information whenever possible. It is an important design goal of
   4.380 +pEp.</t>
   4.381 +
   4.382 +</section>
   4.383 +<section anchor="interoperability" title="Interoperability">
   4.384 +
   4.385 +<t>The proposed pEp protocols seek interoperability with established message 
   4.386 +formats, as well as cryptographic security protocols and their widespread 
   4.387 +implementations.</t>
   4.388 +
   4.389 +<!-- TODO: Understandability difficult; to be discussed. 
   4.390 +
   4.391 +Two integration strategies are considered:
   4.392 +
   4.393 + 1. install asymmetric keys which have been produced and transferred
   4.394 + under control of pEp into the existing cryptographic security
   4.395 + services of a transport, to measure and defend the end-to-end
   4.396 + principle,
   4.397 + 
   4.398 + 1. wrapping messages, for transparently transporting them over
   4.399 + alternative transports.
   4.400 +
   4.401 +Seamless communication between users of software, which implement pEp,
   4.402 +and users of other software, which employ the same encryption services
   4.403 +and technically allow for maintaining the same level of end-to-end
   4.404 +encryption, MUST be guaranteed.
   4.405 +
   4.406 +-->
   4.407 +
   4.408 +<t>To achieve this interoperability, pEp MUST follow Postel’s Robustness 
   4.409 +Principle outlined in <xref target="RFC1122"/>: “Be liberal in what you accept, and 
   4.410 +conservative in what you send.”</t>
   4.411 +
   4.412 +<t>Particularly, pEp applies Postel’s principle as follows:</t>
   4.413 +
   4.414 +<t><list style="symbols">
   4.415 +  <t>pEp is conservative (strict) in requirements for pEp
   4.416 +implementations and how they interact with pEp or other compatible
   4.417 +implementations.</t>
   4.418 +  <t>pEp liberally accepts input from non-pEp implementations. For example, in 
   4.419 +email, pEp will not produce outgoing messages, but will transparently 
   4.420 +support decryption of incoming PGP/INLINE messages.</t>
   4.421 +  <t>Finally, where pEp requires divergence from established RFCs due to privacy 
   4.422 +concerns (e.g., from OpenPGP propositions as defined in <xref target="OpenPGP"/>, options 
   4.423 +SHOULD be implemented which empower the user to override pEp’s defaults.</t>
   4.424 +</list></t>
   4.425 +
   4.426 +<!-- (e.g., from OpenPGP propositions as defined in {{TLS}}; TLS? -->
   4.427 +
   4.428 +<!-- TODO: Discuss contents on this and references for next I-D revision.
   4.429 +
   4.430 +\[\[ **TODO**: Keyreset and Keysync are ASN.1 specified, so that vendor-independent integration is easily possible. \]\]
   4.431 +
   4.432 +\[\[ **TODO**: tcpdump dissector anyone? \]\]
   4.433 +
   4.434 +-->
   4.435 +
   4.436 +<!-- Review (HM), maybe link to existing RFCs:
   4.437 +
   4.438 +## End-to-End {#end-to-end}
   4.439 +
   4.440 +\[\[ **TODO**: Peer-to-Peer means that all nodes have symmetric
   4.441 +capabilities; it does not exclude hierarchies or even central
   4.442 +infrastructure. Some P2P networks have "super nodes", some have
   4.443 +central lists to boostrap the network. While End-to-End means that a
   4.444 +network can not be partitioned in any way to learn from the
   4.445 +communication flowing over the intercepted vertices. They are
   4.446 +complementary but independent concepts. \]\]
   4.447 +
   4.448 +-->
   4.449 +
   4.450 +</section>
   4.451 +<section anchor="peer-to-peer" title="Peer-to-Peer">
   4.452 +
   4.453 +<t>Messaging and verification processes in pEp are designed to work in a
   4.454 +peer-to-peer (P2P) manner, without the involvement of intermediaries.</t>
   4.455 +
   4.456 +<t>This means there MUST NOT be any pEp-specific central services
   4.457 +whatsoever needed for pEp implementations, both in the case of 
   4.458 +verification of peers and for the actual encryption.</t>
   4.459 +
   4.460 +<t>However, implementers of pEp MAY provide options for interoperation with
   4.461 +providers of centralized infrastructures (e.g., to enable users to
   4.462 +communicate with their peers on platforms with vendor lock-in).</t>
   4.463 +
   4.464 +<!-- TODO - to be discussed: Perhaps approaches of Qualified Signatures are, 
   4.465 +     technically speaking, covered by this; this can also be generalized under 
   4.466 +     an own chapter. -->
   4.467 +
   4.468 +<t>Trust provided by global Certificate Authorities (e.g., commercial
   4.469 +X.509 CAs) SHALL NOT be signaled as trustworthy
   4.470 +(cf. <xref target="I-D.marques-pep-rating"/>) to users of pEp (e.g., when
   4.471 +interoperating with peers using S/MIME) by default.</t>
   4.472 +
   4.473 +</section>
   4.474 +<section anchor="user-interaction" title="User Interaction">
   4.475 +
   4.476 +<!-- TODO (HM): Decide whether parts of this goes to handshake draft -->
   4.477 +
   4.478 +<t>Implementers of pEp MUST NOT expose users to technical terms and views, 
   4.479 +especially those specific to cryptography, like “keys”, “certificates”, or 
   4.480 +“fingerprints”. Users may explicitly opt-in to see such terms wanting seeking 
   4.481 +for more options; i.e., advanced settings MAY be available, and in some cases, 
   4.482 +these options may be required.</t>
   4.483 +
   4.484 +<t>The authors believe that widespread adoption of end-to-end cryptography is
   4.485 +possible if users are not required to understand cryptography and key 
   4.486 +management. This belief forms the central goal of pEp, which is that users
   4.487 +can simply rely on the principles of Privacy by Default.</t>
   4.488 +
   4.489 +<t>On the other hand, to preserve usability, users MUST NOT be required to wait
   4.490 +for cryptographic tasks such as key generation to complete before being able to
   4.491 +use their respective message client for its default purpose. In short, pEp
   4.492 +implementers MUST ensure that the ability to draft, send, and receive messages
   4.493 +is always preserved, even if that means a message is sent unencrypted, in
   4.494 +accordance with the Opportunistic Security approach outlined in <xref target="RFC7435"/>.</t>
   4.495 +
   4.496 +<t>In turn, pEp implementers MUST ensure that a distinguishable privacy status is
   4.497 +clearly visible to the user, both on a per-contact as well as per-message
   4.498 +level. This allows users to assess both the privacy level for the 
   4.499 +message and the trust level of its intended recipients before choosing to send
   4.500 +it.</t>
   4.501 +
   4.502 +<t>[[ <spanx style="strong">NOTE</spanx>: We are aware of the fact that usually UX requirements are
   4.503 +not part of RFCs. However, in order to encourage massive adoption of
   4.504 +secure end-to-end encryption while at the same time avoiding putting
   4.505 +users at risk, we believe certain straightforward signaling
   4.506 +requirements for users to be a good idea, just as it is currently done
   4.507 +for already-popular instant messaging services. ]]</t>
   4.508 +
   4.509 +<!-- TODO [nk]:
   4.510 +
   4.511 +**[nk] I think this point could be strengthened, maybe something like: By including a UX structure that is so without any complexities or possibilities for the user to make mistakes pEp enables and accelerates the Human Right respecting aspects of the underlying technology.
   4.512 +
   4.513 +-->
   4.514 +
   4.515 +<!-- TODO: The concrete, respective dialogs belong to the Handshaking and Sync 
   4.516 +     drafts. 
   4.517 +
   4.518 +Possibly to be included:
   4.519 +
   4.520 +../shared/ascii-arts/trustwords_schematic.mkd
   4.521 +
   4.522 +../shared/ascii-arts/handshaking_dialog_insecure.mkd
   4.523 +
   4.524 +../shared/ascii-arts/handshaking_dialog_secure.mkd
   4.525 +
   4.526 +../shared/ascii-arts/sync/pep_sync_handhsaking_dialog.mkd
   4.527 +
   4.528 +-->
   4.529 +
   4.530 +</section>
   4.531 +</section>
   4.532 +<section anchor="identity-system" title="Identity System">
   4.533 +
   4.534 +<t>Everyone has the right to choose how to reveal themselves to the world, both 
   4.535 +offline and online. This is an important element to maintain psychological,
   4.536 +physical, and digital privacy. As such, pEp users MUST have the option to
   4.537 +choose their identity, and they MUST have the ability to maintain multiple
   4.538 +identities.</t>
   4.539 +
   4.540 +<t>These different identities MUST NOT be externally correlatable with
   4.541 +each other by default.  On the other hand, combining different
   4.542 +identities when such information is known MUST be supported (alias
   4.543 +support).</t>
   4.544 +
   4.545 +<section anchor="user" title="User">
   4.546 +
   4.547 +<t>A user is a real world human being or a group of human beings. If it is a 
   4.548 +single human being, it can be called person.</t>
   4.549 +
   4.550 +<t>A user is identified by a user ID (user_id). The user_id SHOULD be a UUID, it 
   4.551 +MAY be an arbitrary unique string.</t>
   4.552 +
   4.553 +<t>The own user can have a user_id like all other users. If the own user does not
   4.554 +have a user_id, then it is assigned a “pEp_own_userId” instead.</t>
   4.555 +
   4.556 +<t>A user can have a default key.
   4.557 +[[ TODO: Provide ref explaining this. ]]</t>
   4.558 +
   4.559 +<!-- TODO: To be discussed.
   4.560 +
   4.561 +To provide for this separation, pEp will create dedicated keys for
   4.562 +every identity defined.
   4.563 +
   4.564 + * By default, all identities MUST NOT be externally correlatable.
   4.565 + The user MAY override this through advanced usage, e.g., by importing
   4.566 + external keys.
   4.567 +
   4.568 +-->
   4.569 +
   4.570 +<!-- Identities != Aliases; to be refined later.
   4.571 +
   4.572 +pEp assists the user in learning different identities of
   4.573 +correspondents (aliases).
   4.574 +
   4.575 +\[\[ **TODO**: Define how the incoming own identity must be matched
   4.576 +when multiple identities are matched from To, Cc etc. \]\]
   4.577 +
   4.578 +-->
   4.579 +
   4.580 +<!--
   4.581 +{::  include ../shared/ascii-arts/pep_id_system.mkd}
   4.582 +
   4.583 +\[\[ TODO: Verify figure \]\]
   4.584 +
   4.585 +
   4.586 +## Terms
   4.587 +
   4.588 +\[\[ TODO: Adjust Terms to figure, formulate more understandable,
   4.589 +     maybe leave out some details of data model that are specific to
   4.590 +     implementation. \[\]
   4.591 +
   4.592 +-->
   4.593 +
   4.594 +</section>
   4.595 +<section anchor="address" title="Address">
   4.596 +
   4.597 +<t>A pEp address is a network address, e.g., an SMTP address or another
   4.598 +Universal Resource Identifier (URI).</t>
   4.599 +
   4.600 +<t>[[ Note: It might be necessary to introduce further addressing
   4.601 +schemes through IETF contributions or IANA registrations, e.g.,
   4.602 +implementing pEp to bridge to popular messaging services with no URIs
   4.603 +defined. ]]</t>
   4.604 +
   4.605 +</section>
   4.606 +<section anchor="key" title="Key">
   4.607 +
   4.608 +<t>A key is an OpenPGP-compatible asymmetric cryptographic key pair.</t>
   4.609 +
   4.610 +<t>Keys in pEp are identified by the full fingerprint (fpr) of the public key. 
   4.611 +The fingerprint is to be obtained from the specific cryptographic service used 
   4.612 +to handle the keys. The canonical representation in pEp is upper-case 
   4.613 +hexadecimal with zero-padding and no separators or spaces.</t>
   4.614 +
   4.615 +</section>
   4.616 +<section anchor="identity" title="Identity">
   4.617 +
   4.618 +<t>An identity is a representation of a user, encapsulating how this user appears 
   4.619 +within the network of a messaging system. This representation may or may not 
   4.620 +be pseudonymous in nature.</t>
   4.621 +
   4.622 +<t>An identity is defined by mapping a user_id to an address. If no user_id is
   4.623 +known, it is guessed by mapping a username to an address.</t>
   4.624 +
   4.625 +<t>An identity can have a temporary user_id as a placeholder until a
   4.626 +real user_id is known.</t>
   4.627 +
   4.628 +<t>In pEp a different key pair for each (e.g., email) account MUST be created. 
   4.629 +This allows a user to retain different identities, which are not correlated by 
   4.630 +the usage of the same key for all of those. This is beneficial in terms of 
   4.631 +privacy.</t>
   4.632 +
   4.633 +<t>A user MAY have a default key; each identity a user has MAY have a default key
   4.634 +(of its own).  When both an Identity and the related User have a default key 
   4.635 +set, the Identity’s default key MUST override the User’s default key.</t>
   4.636 +
   4.637 +<t>[[ TODO: Provide ref explaining this. ]]</t>
   4.638 +
   4.639 +<t>In <xref target="pep-identity"/>, the definition of a pEp identity can be found
   4.640 +according to the reference implementation by the pEp engine.</t>
   4.641 +
   4.642 +<!-- TODO: To be discussed:
   4.643 +
   4.644 +## Trust Reflection
   4.645 +
   4.646 +The pEp model is designed such that users can choose one of their
   4.647 +identities (pseudonymous) and express their trust in other
   4.648 +correspondents (mainly the trust in them to preserve privacy).
   4.649 +
   4.650 +Reasons for an user to mistrust correspondents are both rational and
   4.651 +irrational. Some of the rational reasons for mistrusting an ongoing
   4.652 +correspondence can be automated by pEp. Mainly, weak cryptography is
   4.653 +a reason to assume no privacy guarantees. 
   4.654 +
   4.655 +-->
   4.656 +
   4.657 +<!-- Detecting tracking
   4.658 +cookies would be another reason -->
   4.659 +<!--
   4.660 +For the computation of the trust rating, pEp requires a data model
   4.661 +which accumulates the learnings from the user, their inputs, and the
   4.662 +learnings from past correspondence.
   4.663 +-->
   4.664 +
   4.665 +<!-- TODO: To be discussed. 
   4.666 +
   4.667 +### Key {#elements-key}
   4.668 +
   4.669 +In some cryptographic services the key is stored in a certificate,
   4.670 +which encodes additional information collected from third-parties,
   4.671 +like signatures from certificate authorities or attestations from
   4.672 +identity systems. E.g. in OpenPGP, keys are analogous to certificates
   4.673 +and contain (non-local) third-party signatures, if not carefully
   4.674 +stripped.
   4.675 +
   4.676 +When keys are to be distributed via the pEp protocols to other
   4.677 +correspondents, all third-party signatures and all metadata which is
   4.678 +not required to prove possession of the private key, MUST be stripped
   4.679 +from the copy which is being transferred. The key basically is to be
   4.680 +reduced to a self-signed key only. Note that the same limitation does
   4.681 +not apply for the purpose of keysync among an established device
   4.682 +group.
   4.683 +
   4.684 +
   4.685 +\[\[ **TODO**: must probably intro certificate-signing-requests here
   4.686 +\]\]
   4.687 +
   4.688 +The same asymmetric keys MAY be reused with different cryptographic
   4.689 +services<!-\- cryptotech -\->. Converted copies of the original key MAY
   4.690 +be generated, stored and distributed.
   4.691 +
   4.692 +\[\[ **TODO**: CL: Whenever possible, this SHOULD++ be avoided.
   4.693 +Instead new keys SHOULD be generated, and a proof of holding both
   4.694 +keys should be sent to the peers which extend the trust according to
   4.695 +their estimate of the hardness of the new crypto. Otherwise the keys
   4.696 +weaken by the sum of bugs in all crypto services used concurrently.
   4.697 +\]\]
   4.698 +
   4.699 +Temporary symmetric keys (secrets), for example channel session keys,
   4.700 +may be obtained or generated and mapped to a key (Key Mapping).
   4.701 +
   4.702 +-->
   4.703 +
   4.704 +<!-- TODO: To be discussed 
   4.705 +
   4.706 +#### Keygrip {#elements-keygrip}
   4.707 +
   4.708 +\[\[ **TODO**: \]\]
   4.709 +
   4.710 +Given that we envision to reuse keys across protocols, we should
   4.711 +study the Keygrip further (or do we use it already?)
   4.712 +
   4.713 +\[2\] The keygrip is a unique identifier for a key pair, it is
   4.714 +independent of any protocol, so that the same key can be used with
   4.715 +different protocols. PKCS-15 calls this a subjectKeyHash; it can be
   4.716 +calculated using Libgcrypt's gcry_pk_get_keygrip ().
   4.717 +
   4.718 +\[\[ **TODO**: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/keyformat.txt;h=42c4b1f06faf1bbe71ffadc2fee0fad6bec91a97;hb=refs/heads/master \]\]
   4.719 +
   4.720 +-->
   4.721 +
   4.722 +<!--
   4.723 +
   4.724 +### User {#elements-user}
   4.725 +
   4.726 +\[\[ TODO: user or person? KB: User. Person is an internal DB term.
   4.727 +\]\]
   4.728 +
   4.729 +A user is a supposed distinct physical person or a supposed uniform
   4.730 +group of people eventually participating in a conversation, i.e.
   4.731 +sending and receiving messages. The attribution depends on the
   4.732 +knowledge and point-of-view of the participant, and may differ among
   4.733 +participants of the same conversation.
   4.734 +
   4.735 +A user is locally represented by just a user ID (user_id), which MUST
   4.736 +NOT be disclosed to other participants. The user_id MUST be a unique
   4.737 +string, it MAY be an arbitrary unique string, e.g., a pointer or
   4.738 +foreign primary key into a contacts management application. In lack
   4.739 +of a better source, it SHOULD be a UUID.
   4.740 +
   4.741 +No constrain on the user_id exists for the local pEp user itself. In
   4.742 +lack of a better user_id for the local user, instead of an UUID, the
   4.743 +user_id SHOULD be "pEp_own_userId" (without the quotes).
   4.744 +
   4.745 +-->
   4.746 +
   4.747 +<!-- TODO: To be discussed
   4.748 +
   4.749 +#### User's Default Key
   4.750 +
   4.751 +Any user can be optionally assigned a default key (cf. {{elements-key}}).
   4.752 +
   4.753 +<!-\- Multiple default keys per crypto type -\->
   4.754 +
   4.755 +TODO: A different default key can be assigned to each cryptographic
   4.756 +system supported, e.g. a default key for ECDSA, one for ED25519, and
   4.757 +one for RSA.
   4.758 +
   4.759 +A default key which is considered weak MUST be ignored.
   4.760 +
   4.761 +A default key MUST otherwise override any automatically elected key.
   4.762 +
   4.763 +Keys which are generated automatically by pEp to bootstrap the
   4.764 +protocol MUST NOT be set as default keys automatically.
   4.765 +
   4.766 +-->
   4.767 +
   4.768 +<!-- TODO: To be discussed
   4.769 +
   4.770 +### Identity {#elements-identity}
   4.771 +
   4.772 +While a user's user_id is an element for matching the messages to
   4.773 +correspondents only in the local context and is not to be disclosed,
   4.774 +Identities are those elements signaled between correspondents and are
   4.775 +potentially encoded with the message (connection oriented transports
   4.776 +may not do this, but routing oriented transports require this
   4.777 +information).
   4.778 +
   4.779 +An identity is a label (possibly a pseudonymous) notified by a
   4.780 +sender. Multiple correspondents may use the same label, such that
   4.781 +there is generally no one-to-one mapping from an identity to an user.
   4.782 +
   4.783 +Matching of users is possible in the context of a message. There are
   4.784 +three properties considered:
   4.785 +
   4.786 + * is the address known
   4.787 + * are the users related to the address trusted
   4.788 + * \[\[ **TODO** \]\]
   4.789 +
   4.790 +An identity is defined as a mapping of a user_id to an address (cf.
   4.791 +{{elements-address}}). If no user_id is known at the time of processing an
   4.792 +address, the Identity has to be appropriately guessed. Guessing
   4.793 +depends on context, and may involve querying a local contact list
   4.794 +manager.
   4.795 +
   4.796 +\[\[ **TODO**: add an exhaustive intro/teaser why we need contact
   4.797 +list integration to perform well. \]\]
   4.798 +
   4.799 +An Identity can have a temporary user_id as a placeholder until a
   4.800 +real user_id is known.
   4.801 +
   4.802 +\[\[ **TODO**: should such a temporary user_id be exclusive to this
   4.803 +Identity, should it be "garbage collected", should it be available to
   4.804 +match with other Identities... lots of questions about the
   4.805 +referencial DB / OO model here. \]\]
   4.806 +
   4.807 +An Identity can have a default key (cf. {{elements-key}}). When both an
   4.808 +Identity and the related User have a default key set, the Identity's
   4.809 +default key MUST override the User's default key.
   4.810 +
   4.811 +\[\[ **TODO**: see User's Default Key for copy+paste MUST/SHOULD here\]\]
   4.812 +
   4.813 +\[\[ **NOTE**: This is the reason why in current pEp implementations
   4.814 +for each (email) account a different key pair is created, which
   4.815 +allows a user to retain different identities. \]\]
   4.816 +
   4.817 +In {{pep-identity}} you can find how a pEp identity is defined in the
   4.818 +reference implementation of the pEp Engine.
   4.819 +
   4.820 +-->
   4.821 +
   4.822 +<!--
   4.823 +
   4.824 +### Alias {#elements-alias}
   4.825 +
   4.826 +\[\[TODO\]\]
   4.827 +
   4.828 +### Address {#elements-address}
   4.829 +
   4.830 +-->
   4.831 +
   4.832 +<!--
   4.833 +Original:
   4.834 +An address is a network address, e.g., an SMTP address or another URI.
   4.835 +
   4.836 +The problem with this definition is that: - it is not "functional",
   4.837 +so it assumes there is a solid static address out there in every type
   4.838 +of network/channel. - it leads to assume that an incoming message may
   4.839 +usually be labeled with a source address, which is a strong
   4.840 +requirement. -->
   4.841 +
   4.842 +<!-- TODO: To be discussed.
   4.843 +
   4.844 +An address is a resource identifier, which can be associated to a
   4.845 +network interface, and which the network interface can use to send a
   4.846 +message to a correspondent. It is either an SMTP address or an URI.
   4.847 +
   4.848 +\[\[ **TODO**: what about channels that don't tell us where a
   4.849 +message comes from? \]\]
   4.850 +
   4.851 +\[\[ **TODO**: question will arise: why not use mailto:// for SMTP
   4.852 +address ? \]\]
   4.853 +
   4.854 +\[\[ **NOTE**: It might be necessary to introduce further addressing
   4.855 +schemes through IETF contributions or IANA registrations, e.g.,
   4.856 +implementing pEp to bridge to popular messaging services with no URIs
   4.857 +defined. \]\]
   4.858 +
   4.859 +-->
   4.860 +
   4.861 +<!--
   4.862 +
   4.863 +## Opportunistic Protection
   4.864 +
   4.865 +Opportunistic protection provides for cryptographic keys to be
   4.866 +exchanged end-to-end, such that messages can be eventually verified
   4.867 +and encrypted.
   4.868 +
   4.869 +### Handshake Initialization Protocol
   4.870 +
   4.871 +The basic protocol of pEp is a simple two-step handshake which is
   4.872 +continuously running.
   4.873 +
   4.874 + * In every message delivered, the public key of the sender, and any
   4.875 + pending revocation certificate concerning the sender, MUST be
   4.876 + additionally delivered (guarding some exceptional use cases
   4.877 + described later).
   4.878 +
   4.879 +-->
   4.880 +
   4.881 +<!-- this is to keep XML2RFC happy for a picture followin a list element -->
   4.882 +
   4.883 +<!-- TODO: to be discussed; consider commented out until Message Archiving and Journaling -->
   4.884 +
   4.885 +<!-- TODO: To be discussed
   4.886 +
   4.887 +The sequence diagram of the basic protocol is rather trivial. 
   4.888 +
   4.889 +Possibly to be included:
   4.890 +
   4.891 +../shared/ascii-art/basic_pep_protocol_interchange.mkd -->
   4.892 +
   4.893 +<!-- To be discussed
   4.894 +
   4.895 +With no auxiliary support like pre-shared secrets, or exercising
   4.896 +trust in external third-parties, this is the fastest way to
   4.897 +automatically assist Bob in starting an encrypted conversation with
   4.898 +Alice.
   4.899 +
   4.900 +-->
   4.901 +<!-- 
   4.902 +The protocol has two advantages: it requires no external input to
   4.903 +start functioning, and it works fully asynchronous and in-band. The
   4.904 +protocol has two drawbacks though, which pEp explicitely accepts;
   4.905 +first, Alice may totally renounce privacy in her first message, i.e.,
   4.906 +until she receives a reply from Bob; and second, both won't
   4.907 +immediately authenticate their channel once they start the encrypted
   4.908 +communication.
   4.909 +
   4.910 +**[KRB] The pEp protocol has two advantages: it requires no external input in order to start functioning, and it works fully asynchronous and in-band.  The protocol has two drawbacks, however, which pEp explicitly acknowledges: first, a user may totally renounce privacy in their first message for whatever reason (e.g., until they receive a reply from the intended recipient), and second, both users won't (don't might be better here) immediately authenticate their channel once encrypted communication has begun."
   4.911 +
   4.912 +But still, it is a huge advancement over sticking with plaintext
   4.913 +communication forever; at this point, a passive eavesdropper is
   4.914 +already locked out. And an active attacker only has a short
   4.915 +window-of-opportunity to attack. 
   4.916 +
   4.917 +**[KRB] "Despite these drawbacks, the pEp protocol is a huge improvement over plaintext communication in that a passive eavesdropper is already locked out of the communication, and an active attacker has their attack window-of-opportunity shortened drastically."
   4.918 +
   4.919 +-->
   4.920 +
   4.921 +<!-- To be discussed
   4.922 +
   4.923 +The exact format is transport specific, in particular, the
   4.924 +cryptographic material may be sent in three different ways.
   4.925 +
   4.926 + 1. On a transport for structured messages (e.g. {{MIME}} based email), it 
   4.927 +may be bundled with the original message, resulting in a replacement framing 
   4.928 +message
   4.929 + 0. The cryptographic service may embed it into the cryptographic envelope in a transport specific way (e.g. {{SMIME}})
   4.930 + 0. Additional technical messages may be sent precursing the actual message. \[\[TODO: Such messages MUST be cryptographically interlinked such that partial reception remains totally useless to the recipient.\]\]
   4.931 +
   4.932 +Different variants of the above may be used during initialization and
   4.933 +in the loop state.
   4.934 +
   4.935 +Let's say Alice sets up a second device, and configures it with her
   4.936 +same identity. pEp MUST first create a new key. Alice now ends up
   4.937 +with two separate keys on two devices. Alice immediately sends a
   4.938 +second message to Bob from her new device (Message 3 in {{pEp_F_2}}).
   4.939 +Her new device has not yet learned the public key of Bob, so Message
   4.940 +3 is sent unencrypted again.
   4.941 +
   4.942 +Check figure:
   4.943 +
   4.944 +../shared/ascii-art/todo_second_device_in_use.mkd
   4.945 +
   4.946 +Neither Alice nor Bob really care about the details, and if it was
   4.947 +not for the pEp protocol, they would continue to send and receive
   4.948 +messages in clear text. pEp wants to improve this, and wants to
   4.949 +provide encryption whenever possible. But pEp never stops anyone from
   4.950 +sending a message, if by no means it can't start encrypting
   4.951 +automatically.
   4.952 +
   4.953 + * pEp, in it's default configuration, MUST NOT, ever, prevent the
   4.954 + user from sending a message or interrupt this process with questions
   4.955 + * It MUST clearly signal the predicted privacy rating for the
   4.956 + outgoing message though.
   4.957 +
   4.958 +\[\[ **TODO**: we just introduced rating *prediction* without prior
   4.959 +explanation \]\]
   4.960 +
   4.961 +Alice, who is sending her first message to Bob on her additional
   4.962 +device, will clearly see that pEp predicts a low privacy for her
   4.963 +outgoing message.
   4.964 +
   4.965 +Check figure:
   4.966 +
   4.967 +../shared/ascii-art/todo_received_message_from_unlinked_additional_device.mkd
   4.968 +
   4.969 +Now Bob sees a message and a new PubKey_A2 from Alice, while he
   4.970 +previously learned PubKey_A from her. Bob's pEp is giving this a low
   4.971 +rating. As Bob and Alice have not expressed trust in their
   4.972 +connection yet, pEp now accepts Alice's second key. Still, the
   4.973 +first learned key is preferred, which is Alices first key, which
   4.974 +residing on her first computer.
   4.975 +
   4.976 + * For any identity, pEp MUST use the first learned key for
   4.977 + encryption, otherwise a man-in-the-middle could succesfully install
   4.978 + an additional key by forging a message. - The recipient MUST
   4.979 + maintain the validity records of learned keys independently, but the
   4.980 + validity MUST NOT exceed those encoded in the received keys.
   4.981 +
   4.982 +\[\[ **TODO**: add note if pEp requires valid network time, I think
   4.983 +it could be designed such that it's not required\]\]
   4.984 +
   4.985 +\[\[ **TODO**: why not encrypt to all still valid keys on a given
   4.986 +transport?\]\]
   4.987 +
   4.988 +Note that the case above depicts the worst case scenario. When Alice
   4.989 +started using her new computer, she may have re-read Message 2 of Bob
   4.990 +on the new device, and pEp would have immediately learned Bob's
   4.991 +public key, so that outgoing Message 3 would've already been
   4.992 +encrypted. This is covered in the transports model with the incoming
   4.993 +and outgoing messages property, described later. TODO
   4.994 +
   4.995 +-->
   4.996 +
   4.997 +<!-- TODO: Eventually move this to another chapter or the Key Sync draft
   4.998 +
   4.999 +### Private Device Pairing
  4.1000 +
  4.1001 +To read Bob's message on her second device, she needs to pair them,
  4.1002 +which engages the keysync protocol. Ideally, Alice's oldest key would
  4.1003 +automatically find its way onto all of her devices. Unfortunately,
  4.1004 +pEp synchronization cannot occur fully automatically. Alice first
  4.1005 +needs to be guided through another function of pEp, which is mutual
  4.1006 +authentication. For this, Alice operates both of her devices, and
  4.1007 +once she has selected the common account or has entered an address of the
  4.1008 +other device, she has to compare the public key fingerprints of both
  4.1009 +devices (simplified through the use of Trustwords). If she confirms
  4.1010 +on both devices, each of them will mark the other's public key as
  4.1011 +trusted, and register it under the same "own" user.
  4.1012 +
  4.1013 +TODO; check candidate figure:
  4.1014 +
  4.1015 +../shared/ascii-art/todo_device_pairing.mkd
  4.1016 +
  4.1017 +Note that the transport for synchronization messages and the
  4.1018 +transport for the users messages MAY be separate transports.
  4.1019 +
  4.1020 +### Automatic Key Management {#pEp-key-mgmt}
  4.1021 +
  4.1022 +#### Synchronization
  4.1023 +
  4.1024 +At this point in time both devices disclose all of their private keys
  4.1025 +(one each) to each other, and Alice can now read Bob's messages
  4.1026 +on both of her devices.
  4.1027 +
  4.1028 +-->
  4.1029 +
  4.1030 +<!-- TODO: To be discussed
  4.1031 +
  4.1032 +## Pervasive Forwarding {#pEp-forwarding}
  4.1033 +
  4.1034 +### Transports and Selection
  4.1035 +
  4.1036 +Applications implementing the pEp protocol SHOULD subsidiarily offer
  4.1037 +their transport service for use by other applications. pEp will
  4.1038 +automatically prefer Transports with higher privacy or security
  4.1039 +properties.
  4.1040 +
  4.1041 +Messages are addressed to identities; and identities are supposed at
  4.1042 +a number of network addresses. Upon sending, network addresses are
  4.1043 +translated to a transport selection and the establishment of a
  4.1044 +channel; the message is then encoded specifically for the transport,
  4.1045 +and eventually tagged as a pEp message.
  4.1046 +
  4.1047 +A transport MAY be realized over an object store to which the
  4.1048 +participants have shared access.
  4.1049 +
  4.1050 +In particular, for exchanging sync messages between the users own
  4.1051 +devices, one or more object store per identity, and one or more
  4.1052 +identities per object store may be used to relay the messages. A
  4.1053 +common example of such an object store is an IMAP Mailbox.
  4.1054 +
  4.1055 +<!-\- the sync protocol MUST run independent instances for each identity, for 
  4.1056 +not leaking information over a disjoint subset of shared mailboxes -\->
  4.1057 +
  4.1058 +Other than a shared object store or, more generally, a shared
  4.1059 +database, the following integration patterns may be encountered:
  4.1060 +
  4.1061 + * message queues, eventually supporting point-to-point (unicast),
  4.1062 + multipoint (multicast), one-to-all (broadcast) delivery, with
  4.1063 + address-sharing (load-balancing at receiver or sender side) and
  4.1064 + depending on the topology and address as a context (anycast).
  4.1065 + * file passing (e.g. key import)
  4.1066 + * remote procedure calling (RPC)
  4.1067 +
  4.1068 +Note that integration patters are a functional model; and for any
  4.1069 +transport natively designed to best suit one of them, there exists
  4.1070 +concepts to adapt software written for another one. Some functional
  4.1071 +guarantees are usually not maintained through such a layer of
  4.1072 +virtualization. pEp tries to predict the conservation of privacy
  4.1073 +across such layers of virtualization.
  4.1074 +
  4.1075 +
  4.1076 +### Use to Cryptographic Services
  4.1077 +
  4.1078 +<!-\- The proper title would be "Implementation of Cryptographic
  4.1079 +Services", but most people associate other meaning to
  4.1080 +"implementation" as it is meant in object oriented programming -\->
  4.1081 +
  4.1082 +pEp in itself does not introduce a new cryptographic service. It
  4.1083 +requires the transport to have default encryption services and
  4.1084 +standards for encoding and decoding such messages. pEp defines an
  4.1085 +interface which must be implemented by the transport's cryptographic
  4.1086 +service. One transport MAY have multiple cryptographic services.
  4.1087 +
  4.1088 +pEp requires access
  4.1089 +
  4.1090 + * to the public key
  4.1091 + * to the fingerprint
  4.1092 + * the ciphersuite in use for a message
  4.1093 + * the list of private keys
  4.1094 + * encryption and decryption function
  4.1095 + * signature and verification function
  4.1096 +
  4.1097 +pEp must also be able to
  4.1098 +
  4.1099 + * create a new key pair
  4.1100 + * revoke a key pair
  4.1101 + * import private keys
  4.1102 +
  4.1103 +-->
  4.1104 +
  4.1105 +<!-- NOTE: a system architecture design comment __
  4.1106 + 
  4.1107 + - export private keys
  4.1108 +
  4.1109 +The requirement "export a private key" would be VERY limiting. PKCS
  4.1110 +#11 (OASIS Standard) is important here. - People want private keys to
  4.1111 +be managed by secure elements, and their main job is to NOT hand out
  4.1112 +the private key. Instead, what is often possible is to bring two such
  4.1113 +secure elements "in touch", and obtain a "transport cetificate" from
  4.1114 +the receiving one, hand it to the sending one, and if the sending one
  4.1115 +validates it, it will hand out the private key encrypted to the
  4.1116 +transport certificate. - This is not too dissimilar on what we do
  4.1117 +with keysync. Making this requirement "functional" instead of
  4.1118 +"procedural", gives us more room to integrate with existing crypto
  4.1119 +services. 
  4.1120 +
  4.1121 + * transfer a private key to a remote key store
  4.1122 +
  4.1123 +-->
  4.1124 +
  4.1125 +<!-- TODO: To be discussed.
  4.1126 +
  4.1127 +### Message Decoding and Encoding {#message-codec}
  4.1128 +
  4.1129 +If a transport already has a facility to use end-to-end keys (and the
  4.1130 +transport is generally considered integral), pEp should convert and
  4.1131 +install the "own" key.<!-\- CL: reuse of keys is bad practice -\->
  4.1132 +
  4.1133 +\[\[ **TODO**: we have a problem here: we don't always hold the
  4.1134 +private key in a file. \]\]
  4.1135 +
  4.1136 +The trust rating of a transport depends on the protocol, and an
  4.1137 +ongoing analysis of the general community. \[\[ **TODO**: Online
  4.1138 +registry ahead? \]\]
  4.1139 +
  4.1140 +Whenever the transport of a message is not sufficiently rated
  4.1141 +trustworthy, pEp will engage the handshake protocol, and eventually
  4.1142 +protect messages cryptographically by wrapping them.
  4.1143 +
  4.1144 +Each iteration of wrapping is an operation in three stages, which
  4.1145 +each is to be done according to the specific transport selected and
  4.1146 +the specific cryptographic services in use:
  4.1147 +
  4.1148 + * stage 1 - encoding a pEp structured message into an "inner"
  4.1149 + message
  4.1150 +
  4.1151 + * stage 2 - wrapping a cleartext message with an "outer" message,
  4.1152 + which may also contain public keys and revocation certifications,
  4.1153 + and then represents the cleartext to be submitted to the
  4.1154 + cryptographic functions;
  4.1155 +
  4.1156 + * stage 3 - cryptographically protect the "outer" message for
  4.1157 + confidentiality and integrity and encode it such that it can be
  4.1158 + transported ("transport" message)
  4.1159 +
  4.1160 +-->
  4.1161 +
  4.1162 +<!-- TODO: To be discussed; especially to be discussed in which I-Ds
  4.1163 +     and when to add it. For the general draft, explanations to
  4.1164 +     email-specific.
  4.1165 +
  4.1166 +### Message Wrapping and Tunneling
  4.1167 +
  4.1168 +\[\[ **TODO**: Quick Intro to Tunneling vs Transport, and various Onion Schemes, and Mixnet \]\]
  4.1169 +
  4.1170 +Routed networks require that a message carries a destination address,
  4.1171 +and often also a source address. This is metadata being leaked, and
  4.1172 +most often it is cleartext information. {{pEp_F_5}} shows in a
  4.1173 +sequence diagram how an eavesdropper (here depicted as a Three-Letter
  4.1174 +Agency), sees a message directed from Alice to Bob being sent from
  4.1175 +Alice to Bob.
  4.1176 +
  4.1177 +Check figure:
  4.1178 +
  4.1179 +../shared/ascii-art/todo_eavesdropping_in_transit.mkd
  4.1180 +
  4.1181 +A workaround for Alice is to start wrapping the messages and
  4.1182 +directing them to a relaying party. In the simplest case she requires
  4.1183 +Bobs Corporation Transfer Agent to cooperate, so that she can link
  4.1184 +the message to a generic corporate address. {{pEp_F_6}} depicts how
  4.1185 +the eavesdropper now only sees Alice communicating with Bobs
  4.1186 +Corporation.
  4.1187 +
  4.1188 +Check figure:
  4.1189 +
  4.1190 +../shared/ascii-art/todo_onion_routing.mkd
  4.1191 +
  4.1192 +
  4.1193 +Alice can apply the wrapping recursively. An Internet Service
  4.1194 +Provider may also offer a relying service. {{pEp_F_7}} shows that by
  4.1195 +double wrapping the message, the eavesdropper starts to read less and
  4.1196 +less meaningful metadata from the messages, in this case a message
  4.1197 +from Alices ISP to Bobs Corporation.
  4.1198 +
  4.1199 +Check figure:
  4.1200 +
  4.1201 +../shared/ascii-art/todo_multiple_wrapping_onion_routing.mkd
  4.1202 +
  4.1203 +Nesting of messages is an important concept in pEp.
  4.1204 +
  4.1205 + * On a transport which supports structured messages and an
  4.1206 + extensible schema, an encoding for wrapping messages MUST be
  4.1207 + defined.
  4.1208 +
  4.1209 + * On a transport which supports message types and new message types
  4.1210 + can be allocated, a message type and an coding for a pEp message
  4.1211 + MUST be provided.
  4.1212 +
  4.1213 +See {{message-codec}} for more technical
  4.1214 +specification.
  4.1215 +
  4.1216 +\[\[ **TODO**: add the steps for wrapping a message, using the
  4.1217 +various abstracted elements \]\]
  4.1218 +
  4.1219 +\[\[ **TODO**: add a paragraph about wrapping when a final public key
  4.1220 +is not known \]\]
  4.1221 +
  4.1222 +-->
  4.1223 +
  4.1224 +<!-- TODO: This - with the mention of "server" - mostly belongs to email; to
  4.1225 +     be discussed how to frame that.
  4.1226 +
  4.1227 +## Message Archiving and Journaling
  4.1228 +
  4.1229 +\[\[ **TODO**: say more on archival/journal. \]\]
  4.1230 +
  4.1231 +Check figure:
  4.1232 +
  4.1233 +../shared/ascii-art/todo_trusted_and_untrusted_server.mkd -->
  4.1234 +
  4.1235 +<!-- TODO: To be discussed / maybe commented out
  4.1236 +
  4.1237 +## Information Base Synchronization
  4.1238 +
  4.1239 +While the pEp protocol is applied to incoming and outcoing messages,
  4.1240 +information is accumulated which will enhance the future
  4.1241 +qualification of trust and increase the protection of messages.
  4.1242 +Cryptographic details, connected transports and applications, trust
  4.1243 +and mistrust input form the user, and the address book is among the
  4.1244 +information collected.
  4.1245 +
  4.1246 +For the user experience across the data terminal equipment (e.g.
  4.1247 +MUAs) to remain consistent, Synchronization of these properties is
  4.1248 +necessary.
  4.1249 +
  4.1250 +\[\[ **TODO**: give an overview on what object types the sync stack
  4.1251 +needs (pEp elements, contacts, keys, ...) \]\]
  4.1252 +
  4.1253 +-->
  4.1254 +
  4.1255 +<!-- TODO: Fill out TODOs.
  4.1256 +
  4.1257 +### Base Protocol
  4.1258 +
  4.1259 +base_prepare_message
  4.1260 +base_decorate_message
  4.1261 +base_extract_message
  4.1262 +
  4.1263 +
  4.1264 +### Device Groups
  4.1265 +
  4.1266 +\[\[TODO\]\]
  4.1267 +
  4.1268 +### Private Keys
  4.1269 +
  4.1270 +\[\[TODO\]\]
  4.1271 +
  4.1272 +### Trust Records
  4.1273 +
  4.1274 +\[\[TODO\]\]
  4.1275 +
  4.1276 +### Public Keys
  4.1277 +
  4.1278 +\[\[TODO\]\]
  4.1279 +
  4.1280 +-->
  4.1281 +
  4.1282 +</section>
  4.1283 +</section>
  4.1284 +<section anchor="key-management" title="Key Management">
  4.1285 +
  4.1286 +<t>In order to achieve the goal of widespread adoption of secure
  4.1287 +communications, key management in pEp MUST be automated.</t>
  4.1288 +
  4.1289 +<section anchor="key-generation" title="Key Generation">
  4.1290 +
  4.1291 +<t>A pEp implementation MUST ensure that cryptographic keys for every
  4.1292 +configured identity are available. If a corresponding key pair for the
  4.1293 +identity of a user is found and said identity fulfills the
  4.1294 +requirements (e.g., for email, as set out in
  4.1295 +<xref target="I-D.marques-pep-email"/>), said key pair MUST be reused. Otherwise a
  4.1296 +new key pair MUST be generated. This may be carried out instantly upon
  4.1297 +its configuration.</t>
  4.1298 +
  4.1299 +<t>On devices with limited processing power (e.g., mobile devices) the key
  4.1300 +generation may take more time than a user is willing to wait. If this
  4.1301 +is the case, users SHOULD NOT be stopped from communicating, i.e., the
  4.1302 +key generation process SHOULD be carried out in the background.</t>
  4.1303 +
  4.1304 +</section>
  4.1305 +<section anchor="private-keys" title="Private Keys">
  4.1306 +
  4.1307 +<section anchor="storage" title="Storage">
  4.1308 +
  4.1309 +<t>Private keys in pEp implementations MUST always be held on the end
  4.1310 +user’s device(s): pEp implementers MUST NOT rely on private keys
  4.1311 +stored in centralized remote locations. This applies even for key
  4.1312 +storages where the private keys are protected with sufficiently long
  4.1313 +passphrases. It is considered a violation of pEp’s P2P design
  4.1314 +principle to rely on centralized infrastructures
  4.1315 +(cf. <xref target="peer-to-peer"/>). This also applies for pEp implementations
  4.1316 +created for applications not residing on a user’s device (e.g.,
  4.1317 +web-based MUAs). In such cases, pEp implementations MUST be done in a
  4.1318 +way such that the locally-held private key can neither be directly accessed 
  4.1319 +nor leaked to the outside world.</t>
  4.1320 +
  4.1321 +<t>[[ Note: It is particularly important that browser add-ons implementing pEp
  4.1322 +  functionality do not obtain their cryptographic code from a
  4.1323 +  centralized (cloud) service, as this must be considered a
  4.1324 +  centralized attack vector allowing for backdoors, negatively
  4.1325 +  impacting privacy. ]]</t>
  4.1326 +
  4.1327 +<t>Cf. <xref target="private-key-synchronization"/> for a means to synchronize
  4.1328 +private keys among different devices of the same network address in a 
  4.1329 +secure manner.</t>
  4.1330 +
  4.1331 +</section>
  4.1332 +<section anchor="passphrase" title="Passphrase">
  4.1333 +
  4.1334 +<t>Passphrases to protect a user’s private key MUST be supported by pEp
  4.1335 +implementations, but MUST NOT be enforced by default. That is, if a
  4.1336 +pEp implementation finds a suitable (i.e., secure enough) cryptographic
  4.1337 +setup, which uses passphrases, pEp implementations MUST provide a way
  4.1338 +to unlock the key. However, if a new key pair is generated for a given
  4.1339 +identity, no passphrase MUST be put in place. The authors assume that
  4.1340 +the enforcement of secure (i.e., unique and long enough) passphrases
  4.1341 +would massively reduce the number of pEp users (by hassling them),
  4.1342 +while providing little to no additional privacy for the common
  4.1343 +cases of passive monitoring being carried out by corporations or
  4.1344 +state-level actors.</t>
  4.1345 +
  4.1346 +</section>
  4.1347 +</section>
  4.1348 +<section anchor="key-reset" title="Key Reset">
  4.1349 +
  4.1350 +<!-- TODO: discuss that with backup / reformulate; less informal style.
  4.1351 +
  4.1352 +Now, Bob was unlucky and got his computer infected, so that he is
  4.1353 +setting it up anew. On the fresh system, while his previous key is
  4.1354 +recovered from the backup, the key itself was compromised, such that
  4.1355 +it needs to be replaced.
  4.1356 +
  4.1357 + * When a key is recovered from backup, it SHOULD be replaced.
  4.1358 +
  4.1359 +-->
  4.1360 +
  4.1361 +<!-- TODO: Check what can be kept here. -->
  4.1362 +
  4.1363 +<!-- To be discussed
  4.1364 +
  4.1365 +Assume Bob chooses to "reset" pEp. This means that pEp is resetting
  4.1366 +his "own" identity, revoking all keys and creating a new one alongside
  4.1367 +with a key revocation certificate for the old key. From now on, all of 
  4.1368 +Bob's messages will contain the new public key, whereas the old ones 
  4.1369 +will be revoked.
  4.1370 +
  4.1371 +
  4.1372 + * When pEp receives a revocation certificate through a pEp specific
  4.1373 + transport format, it MUST mark all the learned keys as revoked,
  4.1374 + while,
  4.1375 +
  4.1376 + * when pEp receives a revocation certificate through a non-pEp
  4.1377 + specific transport format, it MUST mark only the specified key as
  4.1378 + revoked.
  4.1379 + 
  4.1380 + * Revocation certificates MUST be accepted from any source, given
  4.1381 + that they pass cryptographic scrutiny (i.e., that they are valid).
  4.1382 + 
  4.1383 + * The message delivering the revocation certificate MAY be signed by
  4.1384 + the key the revoked certificate concerns.
  4.1385 + 
  4.1386 + * A revocation certificate for an "own" key MAY be received; in such
  4.1387 + a case, an "own" identity reset must be triggered.
  4.1388 + 
  4.1389 + * It is a considered a good course of action to submit revocation
  4.1390 + certificates or private keys to the issuer, shall third-party
  4.1391 + private keys be found in leaked datasets. Submission MAY be
  4.1392 + anonymous.
  4.1393 + 
  4.1394 + * Receiving an "own" private key from a non-"own" identity MUST
  4.1395 + trigger an "own" identity reset.
  4.1396 +
  4.1397 +Bob has now replaced his key. Alice wouldn't know anything of Bob's
  4.1398 +new key until receiving a message from Bob. This is why Bobs pEp
  4.1399 +sends a technical message to all recent correspondents. If Alice is
  4.1400 +not a recent correspondent, and she suddenly starts writing to Bob
  4.1401 +again, she will see a lowered rating because of the timeframe<!-\-
  4.1402 +MUST! -\->, and she'll be using Bob's deprecated key which she
  4.1403 +still considers valid. Bob can then still decrypt the received
  4.1404 +message, but will also see a lowered rating, because of the revoked
  4.1405 +key being used. For opportunistic protection, it is still better to
  4.1406 +use a deprecated key, than sending messages plaintext.
  4.1407 +
  4.1408 +This key rollover was almost transparent for Bob and Alice. The
  4.1409 +previous time Bob went through this, he hadn't done a backup, and things
  4.1410 +didn't go as smoothly. He had lost his previous key, and pEp could not
  4.1411 +deliver the revocation certificate automatically. Bob then needed
  4.1412 +\[\[ **TODO**: Bob does not really know this need \]\] to write Alice
  4.1413 +a short enquiry, to please reset the trust on his identity. Alice
  4.1414 +heard about Bob's issue before, and followed up, and Alice's pEp then
  4.1415 +blacklisted all the previously acquired keys. The most recent key attached
  4.1416 +was then the new oldest valid key learned, ready to be used.
  4.1417 +
  4.1418 +-->
  4.1419 +
  4.1420 +<!-- TODO: to be discuss in relation to actual practice
  4.1421 +
  4.1422 +### Private Key Export / Import
  4.1423 +
  4.1424 +A private key can be exported from one device for import onto
  4.1425 +another device.  When pEp's Key Sync (cf. {{private-key-synchronization}}) is 
  4.1426 +not available or not desired to be used, this is largely a manual process.
  4.1427 +
  4.1428 +-->
  4.1429 +
  4.1430 +</section>
  4.1431 +<section anchor="public-key-distribution" title="Public Key Distribution">
  4.1432 +
  4.1433 +<t>As the key is available (cf. <xref target="key-generation"/>) implementers
  4.1434 +of pEp are REQUIRED to ensure that the identity’s public key is
  4.1435 +attached to every outgoing message. However, this MAY be omitted if
  4.1436 +the peer has previously received a message encrypted with the public key
  4.1437 +of the sender.</t>
  4.1438 +
  4.1439 +<t>The sender’s public key SHOULD be sent encrypted whenever possible,
  4.1440 +i.e., when a public key of the receiving peer is available.
  4.1441 +If no encryption key of the recipient is available, the sender’s
  4.1442 +public key MAY be sent unencrypted. In either case, this approach
  4.1443 +ensures that messaging clients (e.g., MUAs that at least implement
  4.1444 +OpenPGP) do not need to have pEp implemented to see a user’s public
  4.1445 +key. Such peers thus have the chance to (automatically) import the
  4.1446 +sender’s public key.</t>
  4.1447 +
  4.1448 +<t>If there is already a known public key from the sender of a message
  4.1449 +and it is still valid and not expired, new keys MUST NOT be used for
  4.1450 +future communication unless they are signed by the previous key (to
  4.1451 +avoid a MITM attack). Messages MUST always be encrypted with the
  4.1452 +receiving peer’s oldest public key, as long as it is valid and not
  4.1453 +expired.</t>
  4.1454 +
  4.1455 +<section anchor="ux-considerations" title="UX Considerations">
  4.1456 +
  4.1457 +<t>Implementers of pEp SHALL prevent the display of public keys attached to
  4.1458 +messages (e.g, in email) to the user in order to prevent
  4.1459 +user confusion by files they are potentially unaware of how to handle.</t>
  4.1460 +
  4.1461 +</section>
  4.1462 +<section anchor="no-addition-of-unnecessary-metadata" title="No addition of unnecessary metadata">
  4.1463 +
  4.1464 +<t>Metadata, such as email headers, MUST NOT be added in order to announce 
  4.1465 +a user’s public key. This is considered unnecessary information leakage, may 
  4.1466 +affect user privacy, and may be subject to a country’s data retention laws (cf. <xref target="data-minimization"/>). Furthermore, this may affect interoperability to 
  4.1467 +existing users that have no knowledge of such header fields, such as users of 
  4.1468 +OpenPGP in email, and lose the ability to import any keys distributed in this 
  4.1469 +way as a result. The ability to extract and receive public keys from such
  4.1470 +metadata SHOULD be supported, however, in the event these approaches become
  4.1471 +widespread.</t>
  4.1472 +
  4.1473 +</section>
  4.1474 +<section anchor="no-centralized-public-key-storage-or-retrieval-by-default" title="No centralized public key storage or retrieval by default">
  4.1475 +
  4.1476 +<t>Keyservers or generally intermediate approaches to obtain a peer’s
  4.1477 +public key SHALL NOT be used by default. On the other hand, the user
  4.1478 +MAY be provided with the option to opt-in for remote locations to
  4.1479 +obtain keys, considering the widespread adoption of such approaches
  4.1480 +for key distribution.</t>
  4.1481 +
  4.1482 +<t>Keys generated or obtained by pEp clients MUST NOT be uploaded to any
  4.1483 +(intermediate) keystore locations without the user’s explicit consent.</t>
  4.1484 +
  4.1485 +</section>
  4.1486 +<section anchor="example-message-flow" title="Example message flow">
  4.1487 +
  4.1488 +<t>The following example roughly describes a pEp scenario with a typical
  4.1489 +initial message flow to demonstrate key exchange and basic trust
  4.1490 +management:</t>
  4.1491 +
  4.1492 +<t>The following example describes a pEp scenario between two users – Alice 
  4.1493 +and Bob – in order to demonstrate the message flow that occurs when exchanging
  4.1494 +keys and determining basic trust management for the first time:</t>
  4.1495 +
  4.1496 +<t><list style="numbers">
  4.1497 +  <t>Alice – knowing nothing of Bob – sends a message to Bob. As Alice
  4.1498 +has no public key from Bob, this message is sent out
  4.1499 +unencrypted. However, Alice’s public key is automatically attached.</t>
  4.1500 +  <t>Bob receives Alice’s message and her public key. He is able to reply to her
  4.1501 +and encrypt the message. His public key is automatically attached to the 
  4.1502 +message. Because he has her public key now, Alice’s rating in his message 
  4.1503 +client changes to ‘encrypted’. From a UX perspective, this status is 
  4.1504 +displayed in yellow (cf. <xref target="trust-rating"/>).</t>
  4.1505 +  <t>Alice receives Bob’s key. As of now Alice is also able to send
  4.1506 +secure messages to Bob. The rating for Bob changes to “encrypted”
  4.1507 +(with yellow color) in Alice’s messaging client
  4.1508 +(cf. <xref target="trust-rating"/>).</t>
  4.1509 +  <t>Alice receives Bob’s reply with his public key attached. Now, Alice can 
  4.1510 +send secure messages to Bob as well. The rating for Bob changes to yellow, 
  4.1511 +or ‘encrypted’, in Alice’s messaging client <xref target="trust-rating"/>.</t>
  4.1512 +  <t>If Alice and Bob want to prevent man-in-the-middle (MITM) attacks,
  4.1513 +they can engage in a pEp Handshake comparing their so-called
  4.1514 +Trustwords (cf. <xref target="handshake"/>) and confirm this process if those
  4.1515 +match. After doing so, their identity rating changes to “encrypted
  4.1516 +and authenticated” (cf. <xref target="trust-rating"/>), which (UX-wise) can be
  4.1517 +displayed using a green color. See also <xref target="trust-management"/>.</t>
  4.1518 +  <t>Alice and Bob can encrypt now, but they are not yet authenticated, leaving 
  4.1519 +them vulnerable to man-in-the-middle (MitM) attacks. To prevent this from 
  4.1520 +occurring, Alice and Bob can engage in a pEp Handshake to compare their 
  4.1521 +Trustwords (cf. <xref target="handshake"/>) and confirm if they match. After this step 
  4.1522 +is performed, their respective identity ratings change to 
  4.1523 +“encrypted and authenticated”, which is represented by a green color 
  4.1524 +(cf. <xref target="trust-management"/>.</t>
  4.1525 +</list></t>
  4.1526 +
  4.1527 +<figure><artwork><![CDATA[
  4.1528 +          -----                                       -----
  4.1529 +          | A |                                       | B |
  4.1530 +          -----                                       -----
  4.1531 +            |                                           |
  4.1532 ++------------------------+                 +------------------------+
  4.1533 +| auto-generate key pair |                 | auto-generate key pair |
  4.1534 +|    (if no key yet)     |                 |    (if no key yet)     |
  4.1535 ++------------------------+                 +------------------------+
  4.1536 +            |                                           |
  4.1537 ++-----------------------+                   +-----------------------+
  4.1538 +| Privacy Status for B: |                   | Privacy Status for A: |
  4.1539 +|     *Unencrypted*     |                   |     *Unencrypted*     |
  4.1540 ++-----------------------+                   +-----------------------+
  4.1541 +            |                                           |
  4.1542 +            |   A sends message to B (Public Key        |
  4.1543 +            |   attached) / optionally signed, but      |
  4.1544 +            |               NOT ENCRYPTED               |
  4.1545 +            +------------------------------------------>|
  4.1546 +            |                                           |
  4.1547 +            |                               +-----------------------+
  4.1548 +            |                               | Privacy Status for A: |
  4.1549 +            |                               |      *Encrypted*      |
  4.1550 +            |                               +-----------------------+
  4.1551 +            |                                           |
  4.1552 +            |      B sends message to A (Public Key     |
  4.1553 +            |      attached) / signed and ENCRYPTED     |
  4.1554 +            |<------------------------------------------+
  4.1555 +            |                                           |
  4.1556 ++-----------------------+                               |
  4.1557 +| Privacy Status for B: |                               |
  4.1558 +|      *Encrypted*      |                               |
  4.1559 ++-----------------------+                               |
  4.1560 +            |                                           |
  4.1561 +            |   A and B successfully compare their      |
  4.1562 +            |   Trustwords over an alternative channel  |
  4.1563 +            |   (e.g., phone line)                      |
  4.1564 +            |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->|
  4.1565 +            |                                           |
  4.1566 ++-----------------------+                   +-----------------------+
  4.1567 +| Privacy Status for B: |                   | Privacy Status for A: |
  4.1568 +|       *Trusted*       |                   |       *Trusted*       |
  4.1569 ++-----------------------+                   +-----------------------+
  4.1570 +            |                                           |
  4.1571 +
  4.1572 +
  4.1573 +]]></artwork></figure>
  4.1574 +
  4.1575 +</section>
  4.1576 +</section>
  4.1577 +<section anchor="key-reset-1" title="Key Reset">
  4.1578 +
  4.1579 +<t>[[ TODO: This section will explain how to deal with invalid keys, e.g.,
  4.1580 +if expired or (potentially) leaked. ]]</t>
  4.1581 +
  4.1582 +<!-- TODO: Perhaps comment out. -->
  4.1583 +
  4.1584 +</section>
  4.1585 +</section>
  4.1586 +<section anchor="trust-management" title="Trust Management">
  4.1587 +
  4.1588 +<t>[[ TODO: Intro ]]</t>
  4.1589 +
  4.1590 +<section anchor="privacy-status" title="Privacy Status">
  4.1591 +
  4.1592 +<t>The trust status for an identity can change due to a number of factors.
  4.1593 +These shifts will cause the color code assigned to this identity to change 
  4.1594 +accordingly, and is applied to future communications with this identity.</t>
  4.1595 +
  4.1596 +<t>For end-users, the most important component of pEp, which MUST be made
  4.1597 +visible on a per-recipient and per-message level, is the Privacy
  4.1598 +Status.</t>
  4.1599 +
  4.1600 +<t>By colors, symbols and texts a user SHALL immediately understand how
  4.1601 +private</t>
  4.1602 +
  4.1603 +<t><list style="symbols">
  4.1604 +  <t>a communication channel with a given peer was or ought to be and</t>
  4.1605 +  <t>a given message was or ought to be.</t>
  4.1606 +</list></t>
  4.1607 +
  4.1608 +</section>
  4.1609 +<section anchor="handshake" title="Handshake">
  4.1610 +
  4.1611 +<t>To establishing trust between peers and to upgrade Privacy Status, pEp
  4.1612 +defines a handshake, which is specified in
  4.1613 +<xref target="I-D.marques-pep-handshake"/>.</t>
  4.1614 +
  4.1615 +<t>In pEp, Trustwords <xref target="I-D.birk-pep-trustwords"/> are used for users to
  4.1616 +compare the authenticity of peers in order to mitigate MITM attacks.</t>
  4.1617 +
  4.1618 +<t>By default, Trustwords MUST be used to represent two peers’
  4.1619 +fingerprints of their public keys in pEp implementations.</t>
  4.1620 +
  4.1621 +<t>In order to retain compatibility with peers not using pEp
  4.1622 +implementations (e.g., Mail User Agents (MUAs) with OpenPGP
  4.1623 +implementations without Trustwords), it is REQUIRED that pEp
  4.1624 +implementers give the user the choice to show both peers’ fingerprints
  4.1625 +instead of just their common Trustwords.</t>
  4.1626 +
  4.1627 +</section>
  4.1628 +<section anchor="trust-rating" title="Trust Rating">
  4.1629 +
  4.1630 +<t>pEp includes a Trust Rating system defining Rating and Color Codes to
  4.1631 +express the Privacy Status of a peer or message
  4.1632 +<xref target="I-D.marques-pep-rating"/>. The ratings are labeled, e.g., as “Unencrypted”,
  4.1633 +“Encrypted”, “Trusted”, “Under Attack”, etc. The Privacy Status in
  4.1634 +its most general form is expressed with traffic lights semantics (and
  4.1635 +respective symbols and texts), whereas the three colors yellow, green
  4.1636 +and red can be applied for any peer or message – like this
  4.1637 +immediately indicating how secure and trustworthy (and thus private) a
  4.1638 +communication was or ought to be considered.</t>
  4.1639 +
  4.1640 +<!-- In cases no (special) Privacy Status can be inferred for peers or
  4.1641 +messages, no color (or the gray color) MUST be shown and respective
  4.1642 +texts -\- being "unknown" or "unreliable" -\- MUST be shown.  -->
  4.1643 +
  4.1644 +<t>The pEp Trust Rating system with all its states and respective
  4.1645 +representations to be followed is outlined in
  4.1646 +<xref target="I-D.marques-pep-rating"/>.</t>
  4.1647 +
  4.1648 +<t>Note: An example for the rating of communication types, the definition of
  4.1649 +the data structure by the pEp Engine reference implementation
  4.1650 +is provided in <xref target="pep-communication-type"/>.</t>
  4.1651 +
  4.1652 +</section>
  4.1653 +<section anchor="trust-revoke" title="Trust Revoke">
  4.1654 +
  4.1655 +<t>[[ TODO: This section will explain how to deal with the situation
  4.1656 +     when a peer can no longer be trusted, e.g., if a peer’s device is
  4.1657 +     compromised. ]]</t>
  4.1658 +
  4.1659 +</section>
  4.1660 +</section>
  4.1661 +<section anchor="synchronization" title="Synchronization">
  4.1662 +
  4.1663 +<t>An important feature of pEp is to assist the user to run pEp applications
  4.1664 +on different devices, such as personal computers, mobile phones and tablets, 
  4.1665 +at the same time. Therefore, state needs to be synchronized among the different
  4.1666 +devices.</t>
  4.1667 +
  4.1668 +<section anchor="private-key-synchronization" title="Private Key Synchronization">
  4.1669 +
  4.1670 +<t>The pEp KeySync protocol (cf. <xref target="I-D.hoeneisen-pep-keysync"/>) is a 
  4.1671 +decentralized proposition which defines how pEp users can distribute their
  4.1672 +private keys among their different devices in a user-authenticated manner.
  4.1673 +This allows users to read their messages across their various devices, as long
  4.1674 +as they share a common address, such as an email account.</t>
  4.1675 +
  4.1676 +</section>
  4.1677 +<section anchor="trust-synchronization" title="Trust Synchronization">
  4.1678 +
  4.1679 +<t>[[ TODO: This section will explain how trust and other related state
  4.1680 +is synchronized among different devices in a user-authenticated manner. ]]</t>
  4.1681 +
  4.1682 +</section>
  4.1683 +</section>
  4.1684 +<section anchor="interoperability-1" title="Interoperability">
  4.1685 +
  4.1686 +<t>pEp aims to be interoperable with existing applications designed to
  4.1687 +enable privacy, e.g., OpenPGP and S/MIME in email.</t>
  4.1688 +
  4.1689 +</section>
  4.1690 +<section anchor="options-in-pep" title="Options in pEp">
  4.1691 +
  4.1692 +<t>In this section a non-exhaustive selection of options is provided.</t>
  4.1693 +
  4.1694 +<section anchor="option-passive-mode" title="Option “Passive Mode”">
  4.1695 +
  4.1696 +<t>By default, the sender attaches its public key to any outgoing message
  4.1697 +(cf. <xref target="public-key-distribution"/>). For situations where a sender wants
  4.1698 +to ensure that it only attaches a public key to an Internet user which
  4.1699 +has a pEp implementation, a Passive Mode MUST be made available.</t>
  4.1700 +
  4.1701 +</section>
  4.1702 +<section anchor="option-disable-protection" title="Option “Disable Protection”">
  4.1703 +
  4.1704 +<t>Using this option, protection can be disabled generally or selectively.
  4.1705 +Implementers of pEp MUST provide an option “Disable Protection” to
  4.1706 +allow a user to disable encryption and signing for:</t>
  4.1707 +
  4.1708 +<t><list style="numbers">
  4.1709 +  <t>all communication</t>
  4.1710 +  <t>specific contacts</t>
  4.1711 +  <t>specific messages</t>
  4.1712 +</list></t>
  4.1713 +
  4.1714 +<t>The public key still attached, unless the option “Passive Mode”
  4.1715 +(cf. <xref target="option-passive-mode"/>) is activated at the same time.</t>
  4.1716 +
  4.1717 +</section>
  4.1718 +<section anchor="option-extra-keys" title="Option “Extra Keys”">
  4.1719 +
  4.1720 +<section anchor="use-case-for-organizations" title="Use Case for Organizations">
  4.1721 +
  4.1722 +<t>For internal or enterprise environments, authorized personnel may need to
  4.1723 +centrally decrypt user messages for archival or other legal purposes.
  4.1724 +Therefore, pEp implementers MAY provide an “Extra Keys” option in which a
  4.1725 +message is encrypted with at least one additional public key.
  4.1726 +The corresponding secret key(s) are intended to be secured by CISO staff or
  4.1727 +other authorized personnel for the organization.</t>
  4.1728 +
  4.1729 +<t>However, it is crucial that the “Extra Keys” feature MUST NOT be activated by
  4.1730 +default for any network address, and is intended to be an option used only for
  4.1731 +organization-specific identities, as well as their corresponding network
  4.1732 +addresses and accounts. The “Extra Keys” feature SHOULD NOT be applied to the
  4.1733 +private identities, addresses, or accounts a user might possess once it is
  4.1734 +activated.</t>
  4.1735 +
  4.1736 +</section>
  4.1737 +<section anchor="use-case-for-key-synchronization" title="Use Case for Key Synchronization">
  4.1738 +
  4.1739 +<t>The “Extra Keys” feature also plays a role during pEp’s KeySync protocols,
  4.1740 +where the additional keys are used to decipher message transactions by both
  4.1741 +parties involved during the negotiation process for private key
  4.1742 +synchronization. During the encrypted (but untrusted) transactions, KeySync
  4.1743 +messages are not just encrypted with the sending device’s default key,
  4.1744 +but also with the default keys of both parties involved in the synchronization
  4.1745 +process.</t>
  4.1746 +
  4.1747 +</section>
  4.1748 +</section>
  4.1749 +<section anchor="option-blacklist-keys" title="Option “Blacklist Keys”">
  4.1750 +
  4.1751 +<t>A “Blacklist Keys” option MAY be provided for an advanced user,
  4.1752 +allowing them to disable keys of peers that they no longer want to use in
  4.1753 +new communications. However, the keys SHALL NOT be deleted. It MUST still
  4.1754 +be possible to verify and decipher past communications that used these keys.</t>
  4.1755 +
  4.1756 +</section>
  4.1757 +</section>
  4.1758 +<section anchor="security-considerations" title="Security Considerations">
  4.1759 +
  4.1760 +<t>By attaching the sender’s public key to outgoing messages, Trust on
  4.1761 +First Use (TOFU) is established. However, this is prone to MITM
  4.1762 +attacks.  Cryptographic key subversion is considered Pervasive
  4.1763 +Monitoring (PM) according to <xref target="RFC7258"/>. Those attacks can be
  4.1764 +mitigated, if the involved users compare their common Trustwords. This
  4.1765 +possibility MUST be made easily accessible to pEp users in the user
  4.1766 +interface implementation. If for compatibility reasons (e.g., with
  4.1767 +OpenPGP users) no Trustwords can be used, then a comparatively easy way
  4.1768 +to verify the respective public key fingerprints MUST be implemented.</t>
  4.1769 +
  4.1770 +<t>As the use of passphrases for private keys is not advised, devices
  4.1771 +themselves SHOULD use encryption.</t>
  4.1772 +
  4.1773 +</section>
  4.1774 +<section anchor="privacy-considerations" title="Privacy Considerations">
  4.1775 +
  4.1776 +<t>[[ TODO ]]</t>
  4.1777 +
  4.1778 +</section>
  4.1779 +<section anchor="iana-considerations" title="IANA Considerations">
  4.1780 +
  4.1781 +<t>This document has no actions for IANA.</t>
  4.1782 +
  4.1783 +</section>
  4.1784 +<section anchor="implementation-status" title="Implementation Status">
  4.1785 +
  4.1786 +<section anchor="introduction-1" title="Introduction">
  4.1787 +
  4.1788 +<t>This section records the status of known implementations of the
  4.1789 +protocol defined by this specification at the time of posting of this
  4.1790 +Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>.
  4.1791 +The description of implementations in this section is intended to
  4.1792 +assist the IETF in its decision processes in progressing drafts to
  4.1793 +RFCs. Please note that the listing of any individual implementation
  4.1794 +here does not imply endorsement by the IETF. Furthermore, no effort
  4.1795 +has been spent to verify the information presented here that was
  4.1796 +supplied by IETF contributors.  This is not intended as, and must not
  4.1797 +be construed to be, a catalog of available implementations or their
  4.1798 +features. Readers are advised to note that other implementations may
  4.1799 +exist.</t>
  4.1800 +
  4.1801 +<t>According to <xref target="RFC7942"/>, “[…] this will allow reviewers and
  4.1802 +working groups to assign due consideration to documents that have the
  4.1803 +benefit of running code, which may serve as evidence of valuable
  4.1804 +experimentation and feedback that have made the implemented protocols
  4.1805 +more mature. It is up to the individual working groups to use this
  4.1806 +information as they see fit.”</t>
  4.1807 +
  4.1808 +</section>
  4.1809 +<section anchor="current-software-implementing-pep" title="Current software implementing pEp">
  4.1810 +
  4.1811 +<t>The following software implementing the pEp protocols (to varying
  4.1812 +degrees) already exists:</t>
  4.1813 +
  4.1814 +<t><list style="symbols">
  4.1815 +  <t>pEp for Outlook as add-on for Microsoft Outlook, release <xref target="SRC.pepforoutlook"/></t>
  4.1816 +  <t>pEp for Android (based on a fork of the K9 MUA), release <xref target="SRC.pepforandroid"/></t>
  4.1817 +  <t>Enigmail/pEp as add-on for Mozilla Thunderbird, release <xref target="SRC.enigmailpep"/></t>
  4.1818 +  <t>pEp for iOS (implemented in a new MUA), beta <xref target="SRC.pepforios"/></t>
  4.1819 +</list></t>
  4.1820 +
  4.1821 +<t>pEp for Android, iOS and Outlook are provided by pEp Security, a commercial
  4.1822 +entity specializing in end-user software implementing pEp while Enigmail/pEp
  4.1823 +is pursued as community project, supported by the pEp Foundation.</t>
  4.1824 +
  4.1825 +<t>All software is available as Free Software and published also in source form.</t>
  4.1826 +
  4.1827 +</section>
  4.1828 +<section anchor="reference-implementation-of-peps-core" title="Reference implementation of pEp’s core">
  4.1829 +
  4.1830 +<t>The pEp Foundation provides a reference implementation of pEp’s core
  4.1831 +principles and functionalities, which go beyond the documentation
  4.1832 +status of this Internet-Draft. <xref target="SRC.pepcore"/></t>
  4.1833 +
  4.1834 +<t>pEp’s reference implementation is composed of pEp Engine and pEp
  4.1835 +Adapters (or bindings), alongside with some libraries which pEp Engine
  4.1836 +relies on to function on certain platforms (like a NetPGP fork we
  4.1837 +maintain for the iOS platform).</t>
  4.1838 +
  4.1839 +<t>The pEp engine is a Free Software library encapsulating
  4.1840 +implementations of:</t>
  4.1841 +
  4.1842 +<t><list style="symbols">
  4.1843 +  <t>Key Management</t>
  4.1844 +</list></t>
  4.1845 +
  4.1846 +<t><list style='empty'>
  4.1847 +  <t>Key Management in pEp engine is based on GnuPG key chains (NetPGP
  4.1848 +  on iOS).  Keys are stored in an OpenPGP compatible format and
  4.1849 +  can be used for different crypto implementations.</t>
  4.1850 +</list></t>
  4.1851 +
  4.1852 +<t><list style="symbols">
  4.1853 +  <t>Trust Rating</t>
  4.1854 +</list></t>
  4.1855 +
  4.1856 +<t><list style='empty'>
  4.1857 +  <t>pEp engine is sporting a two phase trust rating system. In phase
  4.1858 +  one there is a rating based on channel, crypto and key security
  4.1859 +  named “comm_types”. In phase 2 these are mapped to user
  4.1860 +  representable values which have attached colors to present them
  4.1861 +  in traffic light semantics.</t>
  4.1862 +</list></t>
  4.1863 +
  4.1864 +<t><list style="symbols">
  4.1865 +  <t>Abstract Crypto API</t>
  4.1866 +</list></t>
  4.1867 +
  4.1868 +<t><list style='empty'>
  4.1869 +  <t>The Abstract Crypto API is providing functions to encrypt and
  4.1870 +  decrypt data or full messages without requiring an application
  4.1871 +  programmer to understand the different formats and standards.</t>
  4.1872 +</list></t>
  4.1873 +
  4.1874 +<t><list style="symbols">
  4.1875 +  <t>Message Transports</t>
  4.1876 +</list></t>
  4.1877 +
  4.1878 +<t><list style='empty'>
  4.1879 +  <t>pEp engine will support a growing list of Message Transports to
  4.1880 +  support any widespread text messaging system including email,
  4.1881 +  SMS, XMPP and many more.</t>
  4.1882 +</list></t>
  4.1883 +
  4.1884 +<t>pEp engine is written in C99 programming language. It is not meant to be used in
  4.1885 +application code directly. Instead, pEp engine is coming together with
  4.1886 +a list of software adapters for a variety of programming languages and
  4.1887 +development environments, which are:</t>
  4.1888 +
  4.1889 +<t><list style="symbols">
  4.1890 +  <t>pEp COM Server Adapter</t>
  4.1891 +  <t>pEp JNI Adapter</t>
  4.1892 +  <t>pEp JSON Adapter</t>
  4.1893 +  <t>pEp ObjC (and Swift) Adapter</t>
  4.1894 +  <t>pEp Python Adapter</t>
  4.1895 +  <t>pEp Qt Adapter</t>
  4.1896 +</list></t>
  4.1897 +
  4.1898 +</section>
  4.1899 +<section anchor="abstract-crypto-api-examples" title="Abstract Crypto API examples">
  4.1900 +
  4.1901 +<t>A selection of code excerpts from the pEp Engine reference
  4.1902 +implementation (encrypt message, decrypt message, and obtain
  4.1903 +trustwords) can be found in <xref target="abstract-crypto-api-examples-1"/>.</t>
  4.1904 +
  4.1905 +</section>
  4.1906 +</section>
  4.1907 +<section anchor="notes" title="Notes">
  4.1908 +
  4.1909 +<t>The pEp logo and “pretty Easy privacy” are registered trademarks owned
  4.1910 +by the non-profit pEp Foundation based in Switzerland.</t>
  4.1911 +
  4.1912 +<t>Primarily, we want to ensure the following:</t>
  4.1913 +
  4.1914 +<t><list style="symbols">
  4.1915 +  <t>Software using the trademarks MUST be backdoor-free.</t>
  4.1916 +  <t>Software using the trademarks MUST be accompanied by a serious (detailed) 
  4.1917 +code audit carried out by a reputable third-party, for any proper release.</t>
  4.1918 +</list></t>
  4.1919 +
  4.1920 +<t>The pEp Foundation will help to support any community-run
  4.1921 +(non-commercial) project with the latter, be it organizationally or
  4.1922 +financially.</t>
  4.1923 +
  4.1924 +<t>Through this, the foundation wants to make sure that software using
  4.1925 +the pEp trademarks is as safe as possible from a security and privacy
  4.1926 +point of view.</t>
  4.1927 +
  4.1928 +<!-- TODO: to be discussed:
  4.1929 +
  4.1930 +## Qualified Electronic Signatures 
  4.1931 +
  4.1932 +pEp uses cryptographic services to establish end-to-end transport
  4.1933 +security. The original message is transported unmodified, provided
  4.1934 +that message wrapping is used, so that additional features applied on
  4.1935 +the original message remain undamaged. The encryption and signature
  4.1936 +applied by pEp are discarded upon reception of the protected message.
  4.1937 +pEp signatures thus have no utility as a "qualified electronic
  4.1938 +signature" to later prove the authenticity of a message. This
  4.1939 +function must be provided by other means.
  4.1940 +
  4.1941 + * pEp User Agents MUST discard the signature and encryption of a
  4.1942 + protected message upon receipt, and eventually replace it with an
  4.1943 + "own" signature and encryption for the purpose of storing the
  4.1944 + message.
  4.1945 +
  4.1946 + * A symmetric key (session key) previously used to protect the
  4.1947 + message in transit MAY be reused, to avoid re-encrypting large
  4.1948 + quantities of data. \[\[ TODO: Double check that. \]\]
  4.1949 +
  4.1950 + * Qualified electronic signatures MUST be applied prior to
  4.1951 + protecting messages with pEp
  4.1952 +
  4.1953 + * The application of qualified electronic signatures MUST preceed
  4.1954 + the message processing through pEp, and the verification MUST be
  4.1955 + following the processing through pEp.
  4.1956 +
  4.1957 +-->
  4.1958 +
  4.1959 +</section>
  4.1960 +<section anchor="acknowledgments" title="Acknowledgments">
  4.1961 +
  4.1962 +<t>The authors would like to thank the following people who provided
  4.1963 +substantial contributions, helpful comments or suggestions for this
  4.1964 +document: Alexey Melnikov, Athena Schumacher, Ben Campbell, Brian
  4.1965 +Trammell, Bron Gondwana, Claudio Luck, Daniel Kahn Gillmor, Enrico
  4.1966 +Tomae, Eric Rescorla, Gabriele Lenzini, Hans-Peter Dittler, Iraklis
  4.1967 +Symeonidis, Kelly Bristol, Krista Bennett, Mirja Kuehlewind, Nana
  4.1968 +Kerlstetter, Neal Walfield, Pete Resnick, Russ Housley, S. Shelburn,
  4.1969 +and Stephen Farrel.</t>
  4.1970 +
  4.1971 +<t>This work was initially created by pEp Foundation, and then reviewed and
  4.1972 +extended with funding by the Internet Society’s Beyond the Net Programme on
  4.1973 +standardizing pEp. <xref target="ISOC.bnet"/></t>
  4.1974 +
  4.1975 +</section>
  4.1976 +
  4.1977 +
  4.1978 +  </middle>
  4.1979 +
  4.1980 +  <back>
  4.1981 +
  4.1982 +    <references title='Normative References'>
  4.1983 +
  4.1984 +
  4.1985 +
  4.1986 +
  4.1987 +
  4.1988 +<reference  anchor="RFC4949" target='https://www.rfc-editor.org/info/rfc4949'>
  4.1989 +<front>
  4.1990 +<title>Internet Security Glossary, Version 2</title>
  4.1991 +<author initials='R.' surname='Shirey' fullname='R. Shirey'><organization /></author>
  4.1992 +<date year='2007' month='August' />
  4.1993 +<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t></abstract>
  4.1994 +</front>
  4.1995 +<seriesInfo name='FYI' value='36'/>
  4.1996 +<seriesInfo name='RFC' value='4949'/>
  4.1997 +<seriesInfo name='DOI' value='10.17487/RFC4949'/>
  4.1998 +</reference>
  4.1999 +
  4.2000 +
  4.2001 +
  4.2002 +<reference  anchor="RFC7435" target='https://www.rfc-editor.org/info/rfc7435'>
  4.2003 +<front>
  4.2004 +<title>Opportunistic Security: Some Protection Most of the Time</title>
  4.2005 +<author initials='V.' surname='Dukhovni' fullname='V. Dukhovni'><organization /></author>
  4.2006 +<date year='2014' month='December' />
  4.2007 +<abstract><t>This document defines the concept &quot;Opportunistic Security&quot; in the context of communications protocols.  Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t></abstract>
  4.2008 +</front>
  4.2009 +<seriesInfo name='RFC' value='7435'/>
  4.2010 +<seriesInfo name='DOI' value='10.17487/RFC7435'/>
  4.2011 +</reference>
  4.2012 +
  4.2013 +
  4.2014 +
  4.2015 +<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
  4.2016 +<front>
  4.2017 +<title>Key words for use in RFCs to Indicate Requirement Levels</title>
  4.2018 +<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
  4.2019 +<date year='1997' month='March' />
  4.2020 +<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
  4.2021 +</front>
  4.2022 +<seriesInfo name='BCP' value='14'/>
  4.2023 +<seriesInfo name='RFC' value='2119'/>
  4.2024 +<seriesInfo name='DOI' value='10.17487/RFC2119'/>
  4.2025 +</reference>
  4.2026 +
  4.2027 +
  4.2028 +
  4.2029 +
  4.2030 +    </references>
  4.2031 +
  4.2032 +    <references title='Informative References'>
  4.2033 +
  4.2034 +
  4.2035 +
  4.2036 +
  4.2037 +
  4.2038 +<reference  anchor="RFC1122" target='https://www.rfc-editor.org/info/rfc1122'>
  4.2039 +<front>
  4.2040 +<title>Requirements for Internet Hosts - Communication Layers</title>
  4.2041 +<author initials='R.' surname='Braden' fullname='R. Braden' role='editor'><organization /></author>
  4.2042 +<date year='1989' month='October' />
  4.2043 +<abstract><t>This RFC is an official specification for the Internet community.  It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts.  [STANDARDS-TRACK]</t></abstract>
  4.2044 +</front>
  4.2045 +<seriesInfo name='STD' value='3'/>
  4.2046 +<seriesInfo name='RFC' value='1122'/>
  4.2047 +<seriesInfo name='DOI' value='10.17487/RFC1122'/>
  4.2048 +</reference>
  4.2049 +
  4.2050 +
  4.2051 +
  4.2052 +<reference  anchor="OpenPGP" target='https://www.rfc-editor.org/info/rfc4880'>
  4.2053 +<front>
  4.2054 +<title>OpenPGP Message Format</title>
  4.2055 +<author initials='J.' surname='Callas' fullname='J. Callas'><organization /></author>
  4.2056 +<author initials='L.' surname='Donnerhacke' fullname='L. Donnerhacke'><organization /></author>
  4.2057 +<author initials='H.' surname='Finney' fullname='H. Finney'><organization /></author>
  4.2058 +<author initials='D.' surname='Shaw' fullname='D. Shaw'><organization /></author>
  4.2059 +<author initials='R.' surname='Thayer' fullname='R. Thayer'><organization /></author>
  4.2060 +<date year='2007' month='November' />
  4.2061 +<abstract><t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format.  It is not a step-by-step cookbook for writing an application.  It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.  It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t><t>OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage.  These services include confidentiality, key management, authentication, and digital signatures.  This document specifies the message formats used in OpenPGP.  [STANDARDS-TRACK]</t></abstract>
  4.2062 +</front>
  4.2063 +<seriesInfo name='RFC' value='4880'/>
  4.2064 +<seriesInfo name='DOI' value='10.17487/RFC4880'/>
  4.2065 +</reference>
  4.2066 +
  4.2067 +
  4.2068 +
  4.2069 +<reference  anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
  4.2070 +<front>
  4.2071 +<title>Pervasive Monitoring Is an Attack</title>
  4.2072 +<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
  4.2073 +<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
  4.2074 +<date year='2014' month='May' />
  4.2075 +<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
  4.2076 +</front>
  4.2077 +<seriesInfo name='BCP' value='188'/>
  4.2078 +<seriesInfo name='RFC' value='7258'/>
  4.2079 +<seriesInfo name='DOI' value='10.17487/RFC7258'/>
  4.2080 +</reference>
  4.2081 +
  4.2082 +
  4.2083 +
  4.2084 +<reference  anchor="RFC7942" target='https://www.rfc-editor.org/info/rfc7942'>
  4.2085 +<front>
  4.2086 +<title>Improving Awareness of Running Code: The Implementation Status Section</title>
  4.2087 +<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
  4.2088 +<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
  4.2089 +<date year='2016' month='July' />
  4.2090 +<abstract><t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section.  This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t><t>This process is not mandatory.  Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.  This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t></abstract>
  4.2091 +</front>
  4.2092 +<seriesInfo name='BCP' value='205'/>
  4.2093 +<seriesInfo name='RFC' value='7942'/>
  4.2094 +<seriesInfo name='DOI' value='10.17487/RFC7942'/>
  4.2095 +</reference>
  4.2096 +
  4.2097 +
  4.2098 +
  4.2099 +<reference  anchor="RFC8280" target='https://www.rfc-editor.org/info/rfc8280'>
  4.2100 +<front>
  4.2101 +<title>Research into Human Rights Protocol Considerations</title>
  4.2102 +<author initials='N.' surname='ten Oever' fullname='N. ten Oever'><organization /></author>
  4.2103 +<author initials='C.' surname='Cath' fullname='C. Cath'><organization /></author>
  4.2104 +<date year='2017' month='October' />
  4.2105 +<abstract><t>This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973).  The other parts of this document explain the background of the guidelines and how they were developed.</t><t>This document is the first milestone in a longer-term research effort.  It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.</t></abstract>
  4.2106 +</front>
  4.2107 +<seriesInfo name='RFC' value='8280'/>
  4.2108 +<seriesInfo name='DOI' value='10.17487/RFC8280'/>
  4.2109 +</reference>
  4.2110 +
  4.2111 +
  4.2112 +
  4.2113 +<reference anchor="I-D.marques-pep-email">
  4.2114 +<front>
  4.2115 +<title>pretty Easy privacy (pEp): Email Formats and Protocols</title>
  4.2116 +
  4.2117 +<author initials='H' surname='Marques' fullname='Hernani Marques'>
  4.2118 +    <organization />
  4.2119 +</author>
  4.2120 +
  4.2121 +<date month='October' day='23' year='2018' />
  4.2122 +
  4.2123 +<abstract><t>The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (i.e., PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranging from key distribution to mechanisms of subject encryption.  The goal of pEp for email is to automatize operations in order to make email encryption usable by a wider range of Internet users, to achieve wide application of confidentiality and privacy practices in the real world.  This document defines basic operations of pEp's approach towards email and two PGP/MIME formats (pEp Email Format 1 and 2) to provide certain security guarantees.  The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).</t></abstract>
  4.2124 +
  4.2125 +</front>
  4.2126 +
  4.2127 +<seriesInfo name='Internet-Draft' value='draft-marques-pep-email-02' />
  4.2128 +<format type='TXT'
  4.2129 +        target='http://www.ietf.org/internet-drafts/draft-marques-pep-email-02.txt' />
  4.2130 +</reference>
  4.2131 +
  4.2132 +
  4.2133 +
  4.2134 +<reference anchor="I-D.birk-pep-trustwords">
  4.2135 +<front>
  4.2136 +<title>IANA Registration of Trustword Lists: Guide, Template and IANA Considerations</title>
  4.2137 +
  4.2138 +<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
  4.2139 +    <organization />
  4.2140 +</author>
  4.2141 +
  4.2142 +<author initials='H' surname='Marques' fullname='Hernani Marques'>
  4.2143 +    <organization />
  4.2144 +</author>
  4.2145 +
  4.2146 +<date month='July' day='8' year='2019' />
  4.2147 +
  4.2148 +<abstract><t>This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications.  Trustwords are common words in a natural language (e.g., English), which hexadecimal strings are mapped to.  Such a mapping makes verification processes like fingerprint comparisons more practical, and less prone to misunderstandings.</t></abstract>
  4.2149 +
  4.2150 +</front>
  4.2151 +
  4.2152 +<seriesInfo name='Internet-Draft' value='draft-birk-pep-trustwords-04' />
  4.2153 +<format type='TXT'
  4.2154 +        target='http://www.ietf.org/internet-drafts/draft-birk-pep-trustwords-04.txt' />
  4.2155 +</reference>
  4.2156 +
  4.2157 +
  4.2158 +
  4.2159 +<reference anchor="I-D.marques-pep-rating">
  4.2160 +<front>
  4.2161 +<title>pretty Easy privacy (pEp): Mapping of Privacy Rating</title>
  4.2162 +
  4.2163 +<author initials='H' surname='Marques' fullname='Hernani Marques'>
  4.2164 +    <organization />
  4.2165 +</author>
  4.2166 +
  4.2167 +<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
  4.2168 +    <organization />
  4.2169 +</author>
  4.2170 +
  4.2171 +<date month='July' day='7' year='2019' />
  4.2172 +
  4.2173 +<abstract><t>In many Opportunistic Security scenarios end-to-end encryption is automatized for Internet users.  In addition, it is often required to provide the users with easy means to carry out authentication.  Depending on several factors, each communication channel to different peers may have a different Privacy Status, e.g., unencrypted, encrypted and encrypted as well as authenticated.  Even each message from/to a single peer may have a different Privacy Status.  To display the actual Privacy Status to the user, this document defines a Privacy Rating scheme and its mapping to a traffic-light semantics.  A Privacy Status is defined on a per-message basis as well as on a per-identity basis.  The traffic-light semantics (as color rating) allows for a clear and easily understandable presentation to the user in order to optimize the User Experience (UX).  This rating system is most beneficial to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).</t></abstract>
  4.2174 +
  4.2175 +</front>
  4.2176 +
  4.2177 +<seriesInfo name='Internet-Draft' value='draft-marques-pep-rating-02' />
  4.2178 +<format type='TXT'
  4.2179 +        target='http://www.ietf.org/internet-drafts/draft-marques-pep-rating-02.txt' />
  4.2180 +</reference>
  4.2181 +
  4.2182 +
  4.2183 +
  4.2184 +<reference anchor="I-D.marques-pep-handshake">
  4.2185 +<front>
  4.2186 +<title>pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake</title>
  4.2187 +
  4.2188 +<author initials='H' surname='Marques' fullname='Hernani Marques'>
  4.2189 +    <organization />
  4.2190 +</author>
  4.2191 +
  4.2192 +<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
  4.2193 +    <organization />
  4.2194 +</author>
  4.2195 +
  4.2196 +<date month='July' day='7' year='2019' />
  4.2197 +
  4.2198 +<abstract><t>In interpersonal messaging end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks.  This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily authenticate their communication channel.  The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).</t></abstract>
  4.2199 +
  4.2200 +</front>
  4.2201 +
  4.2202 +<seriesInfo name='Internet-Draft' value='draft-marques-pep-handshake-03' />
  4.2203 +<format type='TXT'
  4.2204 +        target='http://www.ietf.org/internet-drafts/draft-marques-pep-handshake-03.txt' />
  4.2205 +</reference>
  4.2206 +
  4.2207 +
  4.2208 +
  4.2209 +<reference anchor="I-D.hoeneisen-pep-keysync">
  4.2210 +<front>
  4.2211 +<title>pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync)</title>
  4.2212 +
  4.2213 +<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
  4.2214 +    <organization />
  4.2215 +</author>
  4.2216 +
  4.2217 +<author initials='H' surname='Marques' fullname='Hernani Marques'>
  4.2218 +    <organization />
  4.2219 +</author>
  4.2220 +
  4.2221 +<author initials='K' surname='Bristol' fullname='Kelly Bristol'>
  4.2222 +    <organization />
  4.2223 +</author>
  4.2224 +
  4.2225 +<date month='October' day='31' year='2019' />
  4.2226 +
  4.2227 +<abstract><t>This document describes the pEp KeySync protocol, which is designed to perform secure peer-to-peer synchronization of private keys across devices belonging to the same user.  Modern users of messaging systems typically have multiple devices for communicating, and attempting to use encryption on all of these devices often leads to situations where messages cannot be decrypted on a given device due to missing private key data.  Current approaches to resolve key synchronicity issues are cumbersome and potentially unsecure.  The pEp KeySync protocol is designed to facilitate this personal key synchronization in a user-friendly manner.</t></abstract>
  4.2228 +
  4.2229 +</front>
  4.2230 +
  4.2231 +<seriesInfo name='Internet-Draft' value='draft-hoeneisen-pep-keysync-01' />
  4.2232 +<format type='TXT'
  4.2233 +        target='http://www.ietf.org/internet-drafts/draft-hoeneisen-pep-keysync-01.txt' />
  4.2234 +</reference>
  4.2235 +
  4.2236 +
  4.2237 +<reference anchor="SRC.pepcore" target="https://pep.foundation/dev/">
  4.2238 +  <front>
  4.2239 +    <title>Core source code and reference implementation of pEp (engine and adapters)</title>
  4.2240 +    <author >
  4.2241 +      <organization></organization>
  4.2242 +    </author>
  4.2243 +    <date year="2018" month="July"/>
  4.2244 +  </front>
  4.2245 +</reference>
  4.2246 +<reference anchor="ISOC.bnet" target="https://www.internetsociety.org/blog/2017/06/12-innovative-projects-selected-for-beyond-the-net-funding/">
  4.2247 +  <front>
  4.2248 +    <title>Beyond the Net. 12 Innovative Projects Selected for Beyond the Net Funding. Implementing Privacy via Mass Encryption: Standardizing pretty Easy privacy’s protocols</title>
  4.2249 +    <author initials="I." surname="Simao" fullname="Ilda Simao">
  4.2250 +      <organization></organization>
  4.2251 +    </author>
  4.2252 +    <date year="2017" month="June"/>
  4.2253 +  </front>
  4.2254 +</reference>
  4.2255 +<reference anchor="SRC.pepforandroid" target="https://pep-security.lu/gitlab/android/pep">
  4.2256 +  <front>
  4.2257 +    <title>Source code for pEp for Android</title>
  4.2258 +    <author >
  4.2259 +      <organization></organization>
  4.2260 +    </author>
  4.2261 +    <date year="2019" month="July"/>
  4.2262 +  </front>
  4.2263 +</reference>
  4.2264 +<reference anchor="SRC.pepforios" target="https://pep-security.ch/dev/repos/pEp_for_iOS/">
  4.2265 +  <front>
  4.2266 +    <title>Source code for pEp for iOS</title>
  4.2267 +    <author >
  4.2268 +      <organization></organization>
  4.2269 +    </author>
  4.2270 +    <date year="2019" month="July"/>
  4.2271 +  </front>
  4.2272 +</reference>
  4.2273 +<reference anchor="SRC.pepforoutlook" target="https://pep-security.lu/dev/repos/pEp_for_Outlook/">
  4.2274 +  <front>
  4.2275 +    <title>Source code for pEp for Outlook</title>
  4.2276 +    <author >
  4.2277 +      <organization></organization>
  4.2278 +    </author>
  4.2279 +    <date year="2019" month="July"/>
  4.2280 +  </front>
  4.2281 +</reference>
  4.2282 +<reference anchor="SRC.enigmailpep" target="https://enigmail.net/index.php/en/download/source-code">
  4.2283 +  <front>
  4.2284 +    <title>Source code for Enigmail/pEp</title>
  4.2285 +    <author >
  4.2286 +      <organization></organization>
  4.2287 +    </author>
  4.2288 +    <date year="2019" month="July"/>
  4.2289 +  </front>
  4.2290 +</reference>
  4.2291 +
  4.2292 +
  4.2293 +    </references>
  4.2294 +
  4.2295 +
  4.2296 +<section anchor="code-excerpts" title="Code Excerpts">
  4.2297 +
  4.2298 +<t>This section provides excerpts of the running code from the pEp
  4.2299 +reference implementation pEp engine (C99 programming language).</t>
  4.2300 +
  4.2301 +<section anchor="pep-identity" title="pEp Identity">
  4.2302 +
  4.2303 +<t>How the pEp identity is defined in the data structure
  4.2304 +(cf. src/pEpEngine.h):</t>
  4.2305 +
  4.2306 +<figure><artwork><![CDATA[
  4.2307 +typedef struct _pEp_identity {
  4.2308 +    char *address;            // C string with address UTF-8 encoded
  4.2309 +    char *fpr;                // C string with fingerprint UTF-8
  4.2310 +                              // encoded
  4.2311 +    char *user_id;            // C string with user ID UTF-8 encoded
  4.2312 +    char *username;           // C string with user name UTF-8
  4.2313 +                              // encoded
  4.2314 +    PEP_comm_type comm_type;  // type of communication with this ID
  4.2315 +    char lang[3];             // language of conversation
  4.2316 +                              // ISO 639-1 ALPHA-2, last byte is 0
  4.2317 +    bool me;                  // if this is the local user
  4.2318 +                              // herself/himself
  4.2319 +    identity_flags_t flags;   // identity_flag1 | identity_flag2
  4.2320 +                              // | ...
  4.2321 +} pEp_identity;
  4.2322 +]]></artwork></figure>
  4.2323 +
  4.2324 +<section anchor="corresponding-sql" title="Corresponding SQL">
  4.2325 +
  4.2326 +<t>Relational table scheme excerpts (in SQL) used in current pEp implementations,
  4.2327 +held locally for every pEp installation in a SQLite database:</t>
  4.2328 +
  4.2329 +<figure><artwork><![CDATA[
  4.2330 +CREATE TABLE person (
  4.2331 +   id text primary key,
  4.2332 +   username text not null,
  4.2333 +   main_key_id text
  4.2334 +       references pgp_keypair (fpr)
  4.2335 +       on delete set null,
  4.2336 +   lang text,
  4.2337 +   comment text,
  4.2338 +   device_group text,
  4.2339 +   is_pep_user integer default 0
  4.2340 +);
  4.2341 +
  4.2342 +CREATE TABLE identity (
  4.2343 +   address text,
  4.2344 +   user_id text
  4.2345 +       references person (id)
  4.2346 +       on delete cascade on update cascade,
  4.2347 +   main_key_id text
  4.2348 +       references pgp_keypair (fpr)
  4.2349 +       on delete set null,
  4.2350 +   comment text,
  4.2351 +   flags integer default 0,
  4.2352 +   is_own integer default 0,
  4.2353 +   timestamp integer default (datetime('now')),
  4.2354 +   primary key (address, user_id)
  4.2355 +);
  4.2356 +
  4.2357 +CREATE TABLE pgp_keypair (
  4.2358 +   fpr text primary key,
  4.2359 +   created integer,
  4.2360 +   expires integer,
  4.2361 +   comment text,
  4.2362 +   flags integer default 0
  4.2363 +);
  4.2364 +CREATE INDEX pgp_keypair_expires on pgp_keypair (
  4.2365 +   expires
  4.2366 +);
  4.2367 +]]></artwork></figure>
  4.2368 +
  4.2369 +</section>
  4.2370 +</section>
  4.2371 +<section anchor="pep-communication-type" title="pEp Communication Type">
  4.2372 +
  4.2373 +<t>In the following, is an example for the rating of communication types as
  4.2374 +defined by a data structure (cf. src/pEpEngine.h <xref target="SRC.pepcore"/>):</t>
  4.2375 +
  4.2376 +<figure><artwork><![CDATA[
  4.2377 +typedef enum _PEP_comm_type {
  4.2378 +    PEP_ct_unknown = 0,
  4.2379 +
  4.2380 +    // range 0x01 to 0x09: no encryption, 0x0a to 0x0e:
  4.2381 +    // nothing reasonable
  4.2382 +
  4.2383 +    PEP_ct_no_encryption = 0x01, // generic
  4.2384 +    PEP_ct_no_encrypted_channel = 0x02,
  4.2385 +    PEP_ct_key_not_found = 0x03,
  4.2386 +    PEP_ct_key_expired = 0x04,
  4.2387 +    PEP_ct_key_revoked = 0x05,
  4.2388 +    PEP_ct_key_b0rken = 0x06,
  4.2389 +    PEP_ct_my_key_not_included = 0x09,
  4.2390 +
  4.2391 +    PEP_ct_security_by_obscurity = 0x0a,
  4.2392 +    PEP_ct_b0rken_crypto = 0x0b,
  4.2393 +    PEP_ct_key_too_short = 0x0c,
  4.2394 +
  4.2395 +    PEP_ct_compromized = 0x0e, // known compromized connection
  4.2396 +    PEP_ct_mistrusted = 0x0f, // known mistrusted key
  4.2397 +
  4.2398 +    // range 0x10 to 0x3f: unconfirmed encryption
  4.2399 +
  4.2400 +    PEP_ct_unconfirmed_encryption = 0x10, // generic
  4.2401 +    PEP_ct_OpenPGP_weak_unconfirmed = 0x11, // RSA 1024 is weak
  4.2402 +
  4.2403 +    PEP_ct_to_be_checked = 0x20, // generic
  4.2404 +    PEP_ct_SMIME_unconfirmed = 0x21,
  4.2405 +    PEP_ct_CMS_unconfirmed = 0x22,
  4.2406 +
  4.2407 +    PEP_ct_strong_but_unconfirmed = 0x30, // generic
  4.2408 +    PEP_ct_OpenPGP_unconfirmed = 0x38, // key at least 2048 bit
  4.2409 +                                       // RSA or EC
  4.2410 +    PEP_ct_OTR_unconfirmed = 0x3a,
  4.2411 +
  4.2412 +    // range 0x40 to 0x7f: unconfirmed encryption and anonymization
  4.2413 +
  4.2414 +    PEP_ct_unconfirmed_enc_anon = 0x40, // generic
  4.2415 +    PEP_ct_pEp_unconfirmed = 0x7f,
  4.2416 +
  4.2417 +    PEP_ct_confirmed = 0x80, // this bit decides if trust
  4.2418 +                             // is confirmed
  4.2419 +
  4.2420 +    // range 0x81 to 0x8f: reserved
  4.2421 +    // range 0x90 to 0xbf: confirmed encryption
  4.2422 +
  4.2423 +    PEP_ct_confirmed_encryption = 0x90, // generic
  4.2424 +    PEP_ct_OpenPGP_weak = 0x91, // RSA 1024 is weak (unused)
  4.2425 +
  4.2426 +    PEP_ct_to_be_checked_confirmed = 0xa0, //generic
  4.2427 +    PEP_ct_SMIME = 0xa1,
  4.2428 +    PEP_ct_CMS = 0xa2,
  4.2429 +
  4.2430 +    PEP_ct_strong_encryption = 0xb0, // generic
  4.2431 +    PEP_ct_OpenPGP = 0xb8, // key at least 2048 bit RSA or EC
  4.2432 +    PEP_ct_OTR = 0xba,
  4.2433 +
  4.2434 +    // range 0xc0 to 0xff: confirmed encryption and anonymization
  4.2435 +
  4.2436 +    PEP_ct_confirmed_enc_anon = 0xc0, // generic
  4.2437 +    PEP_ct_pEp = 0xff
  4.2438 +} PEP_comm_type;
  4.2439 +]]></artwork></figure>
  4.2440 +
  4.2441 +</section>
  4.2442 +<section anchor="abstract-crypto-api-examples-1" title="Abstract Crypto API examples">
  4.2443 +
  4.2444 +<t>The following code excerpts are from the pEp Engine reference
  4.2445 +implementation, to be found in src/message_api.h.</t>
  4.2446 +
  4.2447 +<t>[[ Note: Just a selection; more functionality is available. ]]</t>
  4.2448 +
  4.2449 +<section anchor="encrypting-a-message" title="Encrypting a Message">
  4.2450 +
  4.2451 +<t>Cf. src/message_api.h <xref target="SRC.pepcore"/>:</t>
  4.2452 +
  4.2453 +<figure><artwork><![CDATA[
  4.2454 +// encrypt_message() - encrypt message in memory
  4.2455 +//
  4.2456 +//  parameters:
  4.2457 +//      session (in)     session handle
  4.2458 +//      src (in)         message to encrypt
  4.2459 +//      extra (in)       extra keys for encryption
  4.2460 +//      dst (out)        pointer to new encrypted message or NULL if
  4.2461 +//                       no encryption could take place
  4.2462 +//      enc_format (in)  encrypted format
  4.2463 +//      flags (in)       flags to set special encryption features
  4.2464 +//
  4.2465 +//  return value:
  4.2466 +//      PEP_STATUS_OK           on success
  4.2467 +//      PEP_KEY_HAS_AMBIG_NAME  at least one of the recipient
  4.2468 +//                              keys has an ambiguous name
  4.2469 +//      PEP_UNENCRYPTED         no recipients with usable key, 
  4.2470 +//                              message is left unencrypted,
  4.2471 +//                              and key is attached to it
  4.2472 +//
  4.2473 +//  caveat:
  4.2474 +//      the ownership of src remains with the caller
  4.2475 +//      the ownership of dst goes to the caller
  4.2476 +DYNAMIC_API PEP_STATUS encrypt_message(
  4.2477 +        PEP_SESSION session,
  4.2478 +        message *src,
  4.2479 +        stringlist_t *extra,
  4.2480 +        message **dst,
  4.2481 +        PEP_enc_format enc_format,
  4.2482 +        PEP_encrypt_flags_t flags
  4.2483 +);
  4.2484 +]]></artwork></figure>
  4.2485 +
  4.2486 +<t>Cf. src/message_api.h <xref target="SRC.pepcore"/>:</t>
  4.2487 +
  4.2488 +</section>
  4.2489 +<section anchor="decrypting-a-message" title="Decrypting a Message">
  4.2490 +
  4.2491 +<t>Cf. src/message_api.h <xref target="SRC.pepcore"/>:</t>
  4.2492 +
  4.2493 +<figure><artwork><![CDATA[
  4.2494 +// decrypt_message() - decrypt message in memory
  4.2495 +//
  4.2496 +//  parameters:
  4.2497 +//      session (in)   session handle
  4.2498 +//      src (in)       message to decrypt
  4.2499 +//      dst (out)      pointer to new decrypted message
  4.2500 +//                     or NULL on failure
  4.2501 +//      keylist (out)  stringlist with keyids
  4.2502 +//      rating (out)   rating for the message
  4.2503 +//      flags (out)    flags to signal special decryption features
  4.2504 +//
  4.2505 +//  return value:
  4.2506 +//      error status 
  4.2507 +//      or PEP_DECRYPTED if message decrypted but not verified
  4.2508 +//      or PEP_CANNOT_REENCRYPT if message was decrypted (and
  4.2509 +//         possibly verified) but a reencryption operation is
  4.2510 +//         expected by the caller and failed
  4.2511 +//      or PEP_STATUS_OK on success
  4.2512 +//
  4.2513 +//  flag values:
  4.2514 +//      in:
  4.2515 +//          PEP_decrypt_flag_untrusted_server
  4.2516 +//              used to signal that decrypt function should engage in 
  4.2517 +//              behaviour specified for when the server storing the 
  4.2518 +//              source is untrusted
  4.2519 +//      out:
  4.2520 +//          PEP_decrypt_flag_own_private_key
  4.2521 +//              private key was imported for one of our addresses
  4.2522 +//              (NOT trusted or set to be used - handshake/trust is
  4.2523 +//              required for that)
  4.2524 +//          PEP_decrypt_flag_src_modified
  4.2525 +//              indicates that the src object has been modified. At
  4.2526 +//              the moment, this is always as a direct result of the 
  4.2527 +//              behaviour driven by the input flags. This flag is the 
  4.2528 +//              ONLY value that should be relied upon to see if such 
  4.2529 +//              changes have taken place.
  4.2530 +//          PEP_decrypt_flag_consume
  4.2531 +//              used by sync 
  4.2532 +//          PEP_decrypt_flag_ignore
  4.2533 +//              used by sync 
  4.2534 +//
  4.2535 +//
  4.2536 +// caveat:
  4.2537 +//      the ownership of src remains with the caller - however, the
  4.2538 +//      contents might be modified (strings freed and allocated anew 
  4.2539 +//      or set to NULL, etc) intentionally; when this happens,
  4.2540 +//      PEP_decrypt_flag_src_modified is set.
  4.2541 +//      the ownership of dst goes to the caller
  4.2542 +//      the ownership of keylist goes to the caller
  4.2543 +//      if src is unencrypted this function returns PEP_UNENCRYPTED
  4.2544 +//      and sets
  4.2545 +//      dst to NULL
  4.2546 +DYNAMIC_API PEP_STATUS decrypt_message(
  4.2547 +        PEP_SESSION session,
  4.2548 +        message *src,
  4.2549 +        message **dst,
  4.2550 +        stringlist_t **keylist,
  4.2551 +        PEP_rating *rating,
  4.2552 +        PEP_decrypt_flags_t *flags
  4.2553 +);
  4.2554 +]]></artwork></figure>
  4.2555 +
  4.2556 +</section>
  4.2557 +<section anchor="obtain-common-trustwords" title="Obtain Common Trustwords">
  4.2558 +
  4.2559 +<t>Cf. src/message_api.h <xref target="SRC.pepcore"/>:</t>
  4.2560 +
  4.2561 +<figure><artwork><![CDATA[
  4.2562 +// get_trustwords() - get full trustwords string
  4.2563 +//                    for a *pair* of identities
  4.2564 +//
  4.2565 +//    parameters:
  4.2566 +//        session (in)  session handle
  4.2567 +//        id1 (in)      identity of first party in communication
  4.2568 +//                      - fpr can't be NULL  
  4.2569 +//        id2 (in)      identity of second party in communication
  4.2570 +//                      - fpr can't be NULL
  4.2571 +//        lang (in)     C string with ISO 639-1 language code
  4.2572 +//        words (out)   pointer to C string with all trustwords
  4.2573 +//                      UTF-8 encoded, separated by a blank each
  4.2574 +//                      NULL if language is not supported or
  4.2575 +//                      trustword wordlist is damaged or unavailable
  4.2576 +//        wsize (out)   length of full trustwords string
  4.2577 +//        full (in)     if true, generate ALL trustwords for these
  4.2578 +//                      identities.
  4.2579 +//                      else, generate a fixed-size subset.
  4.2580 +//                      (TODO: fixed-minimum-entropy subset
  4.2581 +//                      in next version)
  4.2582 +//
  4.2583 +//    return value:
  4.2584 +//        PEP_STATUS_OK            trustwords retrieved
  4.2585 +//        PEP_OUT_OF_MEMORY        out of memory
  4.2586 +//        PEP_TRUSTWORD_NOT_FOUND  at least one trustword not found
  4.2587 +//
  4.2588 +//    caveat:
  4.2589 +//        the word pointer goes to the ownership of the caller
  4.2590 +//        the caller is responsible to free() it
  4.2591 +//        (on Windoze use pEp_free())
  4.2592 +//
  4.2593 +DYNAMIC_API PEP_STATUS get_trustwords(
  4.2594 +  PEP_SESSION session, const pEp_identity* id1,
  4.2595 +  const pEp_identity* id2, const char* lang,
  4.2596 +  char **words, size_t *wsize, bool full
  4.2597 +);
  4.2598 +]]></artwork></figure>
  4.2599 +
  4.2600 +</section>
  4.2601 +</section>
  4.2602 +</section>
  4.2603 +<section anchor="document-changelog" title="Document Changelog">
  4.2604 +
  4.2605 +<t>[[ RFC Editor: This section is to be removed before publication ]]</t>
  4.2606 +
  4.2607 +<t><list style="symbols">
  4.2608 +  <t>draft-birk-pep-05:
  4.2609 +  <list style="symbols">
  4.2610 +      <t>Change authors</t>
  4.2611 +      <t>Minor changes, especially in identity system</t>
  4.2612 +    </list></t>
  4.2613 +  <t>draft-birk-pep-04:
  4.2614 +  <list style="symbols">
  4.2615 +      <t>Fix internal reference</t>
  4.2616 +      <t>Add IANA Considerations section</t>
  4.2617 +      <t>Add other use case of Extra Keys</t>
  4.2618 +      <t>Add Claudio Luck as author</t>
  4.2619 +      <t>Incorporate review changes by Kelly Bristol and Nana Karlstetter</t>
  4.2620 +    </list></t>
  4.2621 +  <t>draft-birk-pep-03:
  4.2622 +  <list style="symbols">
  4.2623 +      <t>Major restructure of the document</t>
  4.2624 +      <t>Adapt authors to the actual authors and extend Acknowledgments section</t>
  4.2625 +      <t>Added several new sections, e.g., Key Reset, Trust Revoke, Trust 
  4.2626 +Synchronization, Private Key Export / Import, Privacy Considerations
  4.2627 +(content yet mostly TODO)</t>
  4.2628 +      <t>Added reference to HRPC work / RFC8280
  4.2629 +      <list style="symbols">
  4.2630 +          <t>Added text and figure to better explain pEp’s automated Key
  4.2631 +Exchange and Trust management (basic message flow)</t>
  4.2632 +        </list></t>
  4.2633 +      <t>Lots of improvement in text and editorial changes</t>
  4.2634 +    </list></t>
  4.2635 +  <t>draft-birk-pep-02:
  4.2636 +  <list style="symbols">
  4.2637 +      <t>Move (updated) code to Appendix</t>
  4.2638 +      <t>Add Changelog to Appendix</t>
  4.2639 +      <t>Add Open Issue section to Appendix</t>
  4.2640 +      <t>Fix description of what Extra Keys are</t>
  4.2641 +      <t>Fix Passive Mode description</t>
  4.2642 +      <t>Better explain pEp’s identity system</t>
  4.2643 +    </list></t>
  4.2644 +  <t>draft-birk-pep-01:
  4.2645 +  <list style="symbols">
  4.2646 +      <t>Mostly editorial</t>
  4.2647 +    </list></t>
  4.2648 +  <t>draft-birk-pep-00:
  4.2649 +  <list style="symbols">
  4.2650 +      <t>Initial version</t>
  4.2651 +    </list></t>
  4.2652 +</list></t>
  4.2653 +
  4.2654 +</section>
  4.2655 +<section anchor="open-issues" title="Open Issues">
  4.2656 +
  4.2657 +<t>[[ RFC Editor: This section should be empty and is to be removed
  4.2658 +     before publication ]]</t>
  4.2659 +
  4.2660 +<t><list style="symbols">
  4.2661 +  <t>Shorten Introduction and Abstract</t>
  4.2662 +  <t>References to RFC6973 (Privacy Considerations)</t>
  4.2663 +  <t>Add references to prior work, and what differs here - PEM (cf. RFC1421-1424)</t>
  4.2664 +  <t>Better explain Passive Mode</t>
  4.2665 +  <t>Better explain / illustrate pEp’s identity system</t>
  4.2666 +  <t>Explain Concept of Key Mapping (e.g. to S/MIME, which is to be
  4.2667 +refined in pEp application docs auch as pEp email
  4.2668 +<xref target="I-D.marques-pep-email"/>)</t>
  4.2669 +  <t>Add more information to deal with organizational requirements</t>
  4.2670 +  <t>Add text to Key Reset (<xref target="key-reset"/>) as well as reference as soon as available</t>
  4.2671 +  <t>Add text to Trust Revoke (<xref target="trust-revoke"/>) as well as reference as
  4.2672 +soon as available</t>
  4.2673 +  <t>Add text to Trust Synchronization (<xref target="trust-synchronization"/>) as well
  4.2674 +as reference as soon as available</t>
  4.2675 +</list></t>
  4.2676 +
  4.2677 +<!-- TODO: Check relevance in pEp of that.
  4.2678 +
  4.2679 + * Add references to Private Key Export / Import
  4.2680 +  ({{private-key-export-import}}) as soon as reference available -->
  4.2681 +
  4.2682 +<t><list style="symbols">
  4.2683 +  <t>Add text to Privacy Considerations (<xref target="privacy-considerations"/>)</t>
  4.2684 +  <t>Scan for leftovers of email-specific stuff and move it to pEp email
  4.2685 +I-D <xref target="I-D.marques-pep-email"/>, while replacing it herein with
  4.2686 +generic descriptions.</t>
  4.2687 +</list></t>
  4.2688 +
  4.2689 +<!--
  4.2690 +LocalWords:  utf docname toc sortrefs symrefs SRC pepcore CryptoParty
  4.2691 +LocalWords:  interoperable fpr UUID USERID userId SMTP uid MUAs ons
  4.2692 +LocalWords:  keystore NetPGP iOS Crypto JNI JSON ObjC crypto api Bron
  4.2693 +LocalWords:  Shelburn Alexey Melnikov Trammell Gondwana Kahn Gillmor
  4.2694 +LocalWords:  Tomae Rescorla Dittler Iraklis Symeonidis Mirja Walfield
  4.2695 +LocalWords:  Kuehlewind Resnick Housley Farrel ISOC bnet src typedef
  4.2696 +LocalWords:  struct lang bool SQLite pgp keypair datetime enum rken
  4.2697 +LocalWords:  compromized RSA SMIME CMS OTR anonymization xbf xa xb xc
  4.2698 +LocalWords:  xba xff dst AMBIG stringlist keylist keyids REENCRYPT
  4.2699 +LocalWords:  reencryption untrusted trustword wordlist HRPC
  4.2700 +LocalWords:  wsize Windoze const Changelog PEM anonymize automatation
  4.2701 +LocalWords:  Keyservers Gabriele Lenzini interoperation correlatable
  4.2702 +-->
  4.2703 +
  4.2704 +</section>
  4.2705 +
  4.2706 +
  4.2707 +  </back>
  4.2708 +
  4.2709 +<!-- ##markdown-source:
  4.2710 +H4sIAICawF0AA9y963Yb15Uu+n89RTX9w6QagC62Y5va6Rxaomy2JVERqU4y
  4.2711 +kgyOAlAgKwKqkKoCKcTRGec1zuudJznzm5d1qQJ0Sbp799gc9hAJ1GVd5prX
  4.2712 +b845Ho/drJ6X1fVxtukW4++c68puWRxnB+um6Lptdpq322zdlLf5bJsdrk/X
  4.2713 +R8fZK/1zus2eFot8s+wOXD6dNsXtcbb3NjevZ1W+okfPm3zRjadl83a8Ltbj
  4.2714 +B9+4Wd4V13WzPc7abu5c2+XV/Cpf1hVdvS1aty6Psz929WyUtXXTNcWipd+2
  4.2715 +K/llVq9WRdW1f3Yu33Q3dXPsXJaN6f8sK6v2OPuPSfYDvYw/kBH8R718WzTh
  4.2716 +07qh+dMgs2f1pprnXVlX/HlL7yq64+x8WjR0/Y9NPi2q7Gv+blZ2NN4nP42/
  4.2717 ++/rBg+x3ZdUVTXezaeRLek6H+Vzcld3fimZJE+IvilVeLo+zWx7ABGvwf9Ea
  4.2718 +TBbpezcNTfim69bt8f376ff3e5P7aZK9yJu/bmiVwvx+Kpoqr8rkm//2Od7I
  4.2719 +ICYrGcQ/Oc8fJtlPdVEVZVtU0Ux/oJeURe+r//apTnkUkxsbxefPtaqbFf1+
  4.2720 +WxzTxa+fPfn6+6+/11+//fqrb4iky2rRu+bhw0ePjt0XWfbi7MXpMT559ODr
  4.2721 +b+i783VRvfrxFX/09XffPcA1F/6ib7795iE+oV9/9f23X9lbHn3znf36/deP
  4.2722 +9NfvHn33gF9x+fyCb/7u669/RV+djZ/avvIZlnXQL/zJ7ppN293Vzbw93nFP
  4.2723 +Q3MhvrPjmxta3vYmf1vYl35h+eu3xbbdVjM+5hevn0zos1nd8MVZ1uXNNfZ4
  4.2724 +z0rPi9v7cp2wuSd0IzGVTTMraJfnRUavzoivEIFU9FG5Wi8LcBe+O6sXTFaH
  4.2725 +RXVdVnJtPs/XRCrtET+V3kIPffTg4XfjB99ifGcX508m04pGtHN0d3d3EyY1
  4.2726 +uqKtZ2XRbSdEvfeny/r6Pj3m2/sPfnX/4aNxWVX1Le/9eN3UfylmXTtuiyX9
  4.2727 +W8zHRBfjabGtq/m4uynG9KjxgiZMi5tM9eAHviaja7KXRTfJHj7KzvxzianL
  4.2728 +c7MLfW5Gz83Se7Jn8txJdmYLQ395eXBb5sRy2jY7rWbNdo0loyMDZp438/Jv
  4.2729 +uHSHePj//p//t6Xfa+Lv9bI94CEbI8+ycNTPlvM8uyhXea0fM184m0Sf+eX/
  4.2730 +dvzgVzExf9GjlC8+lVS++K+hlS+GxOJHSMtOFzd1Od9L0bT3M+InRCzLzf1r
  4.2731 +Gl0+va/34Ot41y+i8WJDMSb8eyKXp8v2fX8gZd1+wiBmN7xYTbGu2/v0giu6
  4.2732 +86o8v7j/KQOh6z4yiHrTLev67aetxnAg53L7Jw1Gr907oKIqr8Hq6K27h2MX
  4.2733 +TOgU3i+refFusr5Z08f35/Vdtazz+X2hoDHe/aEhneqTMI8d43Hj8TjLpyTS
  4.2734 +8lnn3CUd0L2qV7aihy6ZBP05y+ZFO2vKKVFm1tLJJnKd1dUtTnRdtQ4jwKGn
  4.2735 +g1ivPEHX66LhP9qM3jsv8Wu+XG7pCSRI8zab5k1TEoVnXe1w+6YVyp8X62W9
  4.2736 +xeHAY3i/ipENklha0RbNLfhDASZWj+mfjPkivbDFO9yqaNv8mnkPzZUeW1az
  4.2737 +5WZOT5luuiynk1nVXbYsVyVYV1ePMhIT2Sqv8ms+lPy3m5ftrL4tmu1IV4MG
  4.2738 +0BV8KYTOEkM4lCcztyqKBsPBvxlkzk1TV+XfbD1cdH/LD6xp0g1m3WC78iyf
  4.2739 +NXWLtb4tZ0V7RDrMhoaUvS6vb4iDF1U+xSvxnGpWEvtoaQZvi+wp7n1RVjQb
  4.2740 +edmIyIEX5hRshP4/w+LwdkzLJZE+VsAV79bLkhQZ7G15XWXXdb5sJ6QFyV7i
  4.2741 +Tyz/pqXXFrb6IxA/aRddU883NMhsVeTY3zqjdSoXW9avN1U5k1lPi+4Om40l
  4.2742 +aY2k6LjRjXnmWOKrZKcFa7tihSfNC9qcQvc967ZrupoJLnqyPAzjplHScJ2R
  4.2743 +8LK4BfHe0lngcdMgcnp9M+Zl5hHQH0IfhVw9cRf0nHJBj666JU0R08cZD+Q/
  4.2744 +3ZTLOT9r2RT5fBu9wNiJE4VLBmbPJ7qv2jVZIS2x9sn1ZJSRpnUfylVGuuGN
  4.2745 +aIRHQl6gyjt6Ukd6KX+JYYCs6RjQqkzlD91GejFfY+O5K+nMbsdycoikZTVb
  4.2746 +2inSb+c0c3pCkeN8zWsWtfzKVAhNiC+URH71bCNnj9gbCaNWyIF0qobWWoll
  4.2747 +dlODRu1cGD2KGJsIv1mV8/mycCS+zpReWL11F7Kx8ZHq7y19fVt29DpwFjoD
  4.2748 +22xeLlh0do4mTIe8lUXDCSr4+nXedOVss8wbpjHSx0seet7t4BwubG1VMAfI
  4.2749 +Fpvlolwus3jFpkXbZbiFeVNDp+OscuFFo+yXX1Ttff+eWEKb0S4QS1yUhZw7
  4.2750 +W8qCl5rIgAgsPr7tZnYDRsinf5WcYKx5xN78TTxtVw4OdMvUcY0tiqZ/d1PS
  4.2751 +G5hz0CrNaMeY2cZ8hThkPc+3X9Kqr8EQdAuEoLJlPnvrxUO7WWMSsqi0SGWV
  4.2752 +N9vM8dJkdHhAYSXdxJoLc94PSJmwA0pay60jmYJThKXnMxgRltAi+Hy86Lwa
  4.2753 +I8weSznCINwin2FNQFYsk2KCJ32uIXUVTI1OpxcuMS26Hi12xeymqknD3k4+
  4.2754 +JjjDlJggmdOV+hSekTtT7d0Inp5D38yIpMHw6kV3hztZxyhEMHqZOuMVKkRX
  4.2755 +xrzrakvkUmSHd3wG6F1tSdus3ETZMb20hHTBthhzmZfXfLbSiU7IbMPxp//y
  4.2756 +2U1JjHEOlw1zPvDnzTqwP5IdZStcW/V14QRdzZMHM9NRQ0jT4+i6Yk2MmJkw
  4.2757 +ThyT4Yzk/xZbmxw6UoGxOfSRbk50DHT6xdwNBv9RHu5VmJv6jk6mKB1ly3wU
  4.2758 +YyDeSa9g5ZxmOqNjS0RJCwyaWzQ56U7EwGg8rdGBPB1mEPHxgjQ7MoKaesWv
  4.2759 +foJh1q+IVZBaQToEuMAke0qSgpgPn5+uXBUj5fFEJHlX034vi7wBlfMVdHgh
  4.2760 +X2jlxtPtmFfwekPHks+auymWayKZlbKmDy5bulijjIQ+TXxK+odbwUwpiLfO
  4.2761 +2K6TQwLNroQIMMXulqZPfPgvNSSdaAV4Z7nAt23hdg2SzwDvLW1qs6kqEAMr
  4.2762 +rIeLerms7/B37jeI6Ja5lVPSUbkjiwNirRbl9UYUSh6mSSR/lpk0amKBa3qO
  4.2763 +Y1oEc8sShkDzhmYzsu0TZWSovEL/6+mDWU8fxEd9Na+jPzbXxNQrGvl4Cl5N
  4.2764 +bLWpcQaEGcvc270MHtRVkzDoymuMmMZA9jyb6iJPs7zriCmTQvHi7PLFEc4o
  4.2765 +vSzX7ZvT8FriyiPHp1BeU1dLVm43tFq8Q8axo+OH62ZkVLS8lKJR6cnRwyRr
  4.2766 +Nc8uvZ+GOPEeD87796SCz0hJLtsV3kZiNqezQ+9f5tX1BhtGZhfEseoerDrQ
  4.2767 +vcL3vnQLIg7S52lRSHUCFcqQg54pjI3fiOETHeVl0+cLGYZQQcNTzi16wBSK
  4.2768 +EnuiYxEjqgJRRaTdgobLypHkpFnlYA1eM4OtsdZTM5BO8MKxdCKJTlROrIaW
  4.2769 +75aOBRlFEKE0QuKfM6882g7QesgGHPDJxhYUrDURE2k7JzvDrOMg4tfzuiJW
  4.2770 +QmyNmDYpJX6I7WZKxiKbPEH9MEVqVhiXgX6ucgzssCC1APrLdV5WrP7IEIUK
  4.2771 +RO9zuny8IXovj4ceTJtFgxloNCxXcO0KOgOOIHRT8XmwYnxTspihMTNHFc0T
  4.2772 +RHxDEgd7TxykgAKD+0ERrDs7r2HDwYMFlnOlYoKoYgszGkuam1Z+lDLwIKRF
  4.2773 +9s42oHIa8SEWLrUTjz4iRJV/3sLUMNZQb+is1osFZnTkzZm+msGWHE8Jp/au
  4.2774 +WPK/6TOq+BFQeBxdQiTe0YRoMl8Ka8NKQ3dtyjkdM683e1HNIg3jVJsB0+2P
  4.2775 +Rs+NaqhMJ0HLa1iip3ewVlyxTBBKBr36A1dU9LwZtvcu33pNhUb9v/6F7IQv
  4.2776 +steFLivp195QEGH65Plx9tML1pJuCtJF2SAgYQvb/h9xZHi2Q5+7nhOOBRfW
  4.2777 +mN8yhazGmGNt2d4wMML/eRUeqo+pVd5/kSjlA5XafUj/zGPiNpV6qIC6oICm
  4.2778 +9qVXR6GEQmZl6qMRPmyaqPsnNNGUWZsiFk2ZdBR4WBuyZSZ8Xuc11B+4Scbi
  4.2779 +JhEnQuS6GZAsrwWNqO2EQctAwj6yTRjUimjHvKcwe8NPanA+IdihjZCMgH8E
  4.2780 +bhR6RMtsXp6sTqggnES2kuVBjAoaZsenROylraMjMRJ9QUM2WApWFVpajuUc
  4.2781 +lj9uFTf7lG09mMQusdfow+hc/ZAv9cB5CeNNnBlLG5pL3Te8IwIqW7fPAM/2
  4.2782 +GOD0mL9uisj6dGp82zPp7dAfzbWf2OTy/qEt7j5oi2efZou7ni1O24Wv2FT2
  4.2783 +p7gp/rqBBiFsJ09OvYuFPQtMsaV10/2pGn3AoncfZAdZnx1Mst+x+n/IU8yX
  4.2784 +Rz1m1aqa1mIPSZivO6X0voOK+JDY9+4ftO8943dq3rPvs/gE+z5I1qGJH/So
  4.2785 +jxr5WE9aTNJ7iRJYckJNVaeZiijIpSlThhDQfh+A+wQfQO9YDF0ArCUOrLYP
  4.2786 +Wn8j+VpsHFWoY9txJMsuajqtMttzbDLFZg2fAHjeHEl51uvNRFsUd3Qk2LBb
  4.2787 +IswAlf+Dth0ppYlvgXht3SFCsFZVVBkHeF3xrpP1vsnpQTc4Gm32F2Jvjgzp
  4.2788 +XFi8Z+N0PqCI4ikgCoS85OYCAQOZXVNA7xAlhi4ZyxOwecw0iXnd1N7/cYPT
  4.2789 +CtQHMYaGfebBr9qbw+GK1NJyTPtPOxPfSyM7+j/TDPifZQX8J1mv/7DZyvEJ
  4.2790 +kzkj1oX/SeMVO/c/wnr9iLliKvROy2TkeP+ZPcCkKd5xPIyZpYShwJWHcRZa
  4.2791 +f/UBOnYAwrvPI2EjR3xIn2fqfL6lM3iCCdlZol9w1OHfnHNfwKBYysbclOsw
  4.2792 +RVEgRQ1o1fi4PH96nh3+9OLoOHsBPpzxM0T2dv9IOCS2DCQcMtLXNxhUETQR
  4.2793 +mjRxjpKdjKACsOsoukAzXDPEQgmbrRl6loZaIyVZwQOQb44fSbzYr4usd96a
  4.2794 +4+nYuYe8hRJQxBmP9QK1xvE8MbDlmAzgO+/fg53Sk34qlmuQz6aayRPMey0q
  4.2795 +TT4TY0idX0Euk15PBASbFAfMiXDRoKrOOJV80XIwe05tN7xVIxHRFH4ybFA2
  4.2796 +nIbHDX14KtEsWh/PFE82Gdz1XWXxWpvjNViZxbN1s4KJ12zE65Esel1F6rU+
  4.2797 +LoOPGOw7X+Fx7C02ws9xSNebDnx+VU9Bq+sbZv+gDuxqlyzDz8X2gs6X7uVO
  4.2798 +fJQsAqnU+Vwi9aNItQ8Uy8KCZD54yLyEHkU8WjznGbs/yXDggYDdmLDjw0I7
  4.2799 +GBYWir7IST4fMtKzk5cn7nVxXUIJMcL2DDt7Tp9/kGvT+P/0xz/9MXtZA/pw
  4.2800 +0sn5JRKDW9xzvi2MX2hs2A1iNogGsIEDxAIj+HqUNS86ovc2ssZwRnF5VdwB
  4.2801 +NCReH7Z96e67gpXRNl8UrOcsxHwxvdyb+HwjbG866hAJQjz4VB7S4Pa6mmR/
  4.2802 ++vOf/uw9JZcFuDR4lH7w0mB+QTYxB/sCmD0xaWTnnuvXIkzguxYxePDizcXl
  4.2803 +wUj+zV6e8++vT3/75uz16VP8fvHTyfPn/he5wtEf52+e6/f4Ldz55PzFi9OX
  4.2804 +T+XmFyd/OBDl7+D81eXZ+cuT5wcit4lQPGtVL4OFuGFUFKzbW8xGVap/AWrx
  4.2805 +4cPvea91BeI14VnznzLLEGfo+Bqm5WLBOprpze2MrC7hOBG3Jy7p7qUs5FgN
  4.2806 +npqjqKCWSo84NGRwCLhrKuH14gIElhOwHgksdSbQk3CXagSRYnJII4s1CHoI
  4.2807 +n/kFabhTUp6OVOdTmwd6H4IN4ncQ+SBBCLKYARlpSZGjZ9CLpn21wDv6Riom
  4.2808 +hI/Q1VCnJx/mmrRAYdR04GgpcyJmGLh8YFMdCSv28FfjKZ3EarOaMqN+AJU4
  4.2809 +y371zTdffXOExRjoWfxs2MJQbGqJGPkdGRmuhA8enc87eGZWU97faEHpzayn
  4.2810 +rDe0GjPB35TVbb28FQWIgREIeWTMV+k8tjh4H1IQmfic++PPr3/4c3a2yFaw
  4.2811 +nq+vacVFNZvWt8I635Jlnv3xjwkl/fnPxlyZJzlze7BxpbZXzf4noD9mkB9Q
  4.2812 +d/FNNHe4ODqE7TUmO4VgMh1DVeMg/5jsS4F5iJ6ku5edV9mzkiQxnFzZ4eX5
  4.2813 +szekC80Wk9SEUY8URDft9QEEBS1XULRxHxONSE34R9Z6ImgiZIxptM9vAREq
  4.2814 +1pu0XvXF5C0wrTx6gbYAI0bHi6fDF8H8UCehyxLjjv0wJJnkBkwyu9hMW+J/
  4.2815 +fOxSax4Xlm36BHrHxrtzZvkMto8MMh4ixIk6C8QuwkOq7EV5+UINmxFioiKm
  4.2816 +K/2I5OScJQ99PMNOzzkKrAR3u1lW6nANoc5ouJODSFElHRV7qeKL7TZBzfHq
  4.2817 +m//0cpLpBr8YmF9qdsnIom0GgnzHNp/QCNldg/iJur9IonSkvfB+ygRLc1iy
  4.2818 +rsOfmfrHjileJZDzUgxldk3MYe+30WSxMvCa0UFY5S3tXJPPWXEFf2NiYX+G
  4.2819 +6oZMD3iAP8hsR6VbbSSl66greb4RXCEY/7H7LZmX4no4xfAQy50xmACsqHDE
  4.2820 +16qsCN+09o06zedZD6ulznYwEni68SVZRCX0fDqd15ul6XxNttrAG0K01BQi
  4.2821 +pEe0meIfoSe0RQe7nV3NtPa4UqRYGA1fWrMbVIcRcJbZqiByAPO8hPtKL2af
  4.2822 +jLfpBNThtcwoftB6b7uqcuZ7ByGzhkt3rTLoTZHFAjAggy4/vKhDQVy8y6F0
  4.2823 +wR2A0VzclSRin9G5gzB4nt9lL5vs+6+/mjz4CtN9gjPu/U0X6hHz/ujs9A2p
  4.2824 +PrbSpCFl3z98AHz816QTnz09uYi+JaWXz4ocMVZBEOXftDCqD+ksL4sFTHR6
  4.2825 ++Bz+rkx99NU1MUl3/ubyx/Ozlz9mL04vLk5+PAW1eOyfHAngLArFstNKDemF
  4.2826 +0ae0BHe5Z+XM+IPZmoYOJqDf6zpEiQDCxIYq2rCU2NY8I91v9nYpqIWctI05
  4.2827 +v0YGkzezG9rEOVT+l6SwfeIcSN8vcJsfME3qtiSTnTVd+U7cnLtHflbRsUhG
  4.2828 +Li7ru5wkMvQXBGl0+OJDjAbPuEqZaBi+aH1IR2DKJXHIuPunYpa/8qY4q4bD
  4.2829 +TDSLm3K00nvH4jBqUbWbxvsMTbAvl3QK24LhJarAj/RR3u723jEhdgxIxPwq
  4.2830 +f1dyvIyVkl0BGvXWVObYJYnUMpqPDTJGZ2EV+X5min54WCNOPPBPFdcl3O4k
  4.2831 +eDuxB2c3NcNe4nvF+hNu0zL12Xw0auO1ONZ5PR5Y04e+bN3vium4XoxFqzj8
  4.2832 +XX15BHWk4KF79K34vASl20ReGoPIqYYwSU1RSAOGc9b2PtbiEA0i/W++rfKV
  4.2833 +MjgQzLJuVY+qme06diGMoIqbtuAN+ACwjSSRnNHgSoGWCZTwqgSXI95E2rBY
  4.2834 +cqzKM637FQ9clCU023ECnstcjCrTwKV4dcyyZ/XDszdYgbf1IDjHHj96sfv9
  4.2835 +q5/PssMLBhQfqfl77x40hXv3jkmre8fPu+NQznUvAYVmjNtHmdz+5z8LAYA8
  4.2836 +QvRZfQjsHRb96KfLF8+PJCagBzWKWzpvIuKU1lMynH1cRAOOyzqKWLLJRc8i
  4.2837 +rbnbAPGV+4j2lFEGCGUWs3wT3LtldSNuEruQlPW3HE+V8elrSF/4AIJvlO0I
  4.2838 +piUzH4FJ6AkeZdG8ZFL7FiCZKnTHaAx+5iO3c+pZb+qIb4qbtBMPP1GdEJ1g
  4.2839 +FnkrHC5oPZKCmNzzsnqLhXiSBpxpu5+ImZo9YbxmJPZYs+wJv8cs6dkFP013
  4.2840 +wKZ+X47rDS0sFkzSrDi9YtnW/Zts8jRSiaV3RaXMEIF71vymzCkktYQHGi+s
  4.2841 +mEB81FxfrFzg8IQn8O1lteP2ACIn1oKofaGHiTZ7l8SK1Foz9IExElf+tHC8
  4.2842 +UWY1sAqV3J8drutOTAdTBWM3H9Q+9m4nSM1qUaq5QcwEh/okIDFMOyTL/8tO
  4.2843 +I+1LRI3wTI0Gp0yVY3Q+LulnPclOOdGMcVX6UDoSTa0GKF2FsJhsXtk4P4Kp
  4.2844 +hH/ZSQu1ULEOwtDqt4V5kIk4L1/RbOq3xLaP2C+OVCncp46XVcZbpApBvG4z
  4.2845 +jlnDyyhAD/VRyLYvA1IDavFbwQExBYQwbXA9tGqHFau1ZFFgy3zEW0IZNjln
  4.2846 +HjA1dRCEXSGfQiEl/vGiEqvfS2H3KjSc0m4bI1JCrk9MkkKskLNAp/DrOJDs
  4.2847 +ZB8j2yWmQxykpYpT1RZXZCcx5qNVGUiCK3/LTKzsIrelJ+O7mzpMEStCDFRO
  4.2848 +FjvQvwzCHTxABKks0ShFpuDrHAZ0ucYCMNpV0bsW2/ccTXcKMiq7d49W+RQy
  4.2849 +6ia/FXF8Q0yJI5ps+rDk3Srjq2AeEDtg6wd+D8fqWnDpmVuXI7azzQy+Q/X+
  4.2850 +rklR7o7Nf1AWbGLRHEfRoRtlk4m5Wc2LOMipcu7pANL4tijWCvVo17lCCG4E
  4.2851 +/LxcCsHoljgGaeRLNfRjpI9Gyz16R4P4QAR5hTRK0eJMMs6x+eKLQWKXBbg1
  4.2852 +2pkC4NuieDvAmWgeUvAUet3fEppGcZiuD0YY6Dxqg5UNI0zaNUg062NXJonk
  4.2853 +eeMjQTYmcEmYlN1jdQt7sTTJaIp3tT91HA5EuKC4LtWcMCZdzJHz/XACYGiX
  4.2854 +8/C3KzKKG3MBCimz0419Z2sJ98+NuVQtsVVEZSVWFYG+DB8gGqt36e9eHOcx
  4.2855 +G4JC9dgF5nJkMreGPiF9o1ATNlCni5BCLuMJ3TXqfzEzaiRMlR+cQ7rA0rfX
  4.2856 +qHxasU/aEWUCqyQhgwCjAA8t8tUSru3dKXwSW4PfpMcL/N5yLIcDef5aVY17
  4.2857 +dyhX9UKz8AngAd7CexAdIEEgChqtZPmeyF0xKOiN0cKFx44yZu1ESNebnObc
  4.2858 +FWz68mG/rC3fxdhNekDEYuL7JZyQvSLuU8DUfF1PSbxWWDPnTc0hCgSVF96/
  4.2859 +55T6bFlO2afBLjNiUtt6o75SMXDBJxQPd1skV5E0m8OJ9cq7W5Y6Ng4lEnX5
  4.2860 +cXmCScO+Es9QtdO/47DFieiOBBQYBYw003mAO2MmJ2jQrY+OChvhKHTjVakV
  4.2861 +SQWwtB3HX8aiq4HtnQmErayQMsIKS1VX42GgVzNU1WE0YjOItWRZizvABiEP
  4.2862 +9DBjN1JniQhvvi49MM7gb/PCkyMRlFdRkLl59vL52ctT/yyeyLOSs5pHap5j
  4.2863 +FLqOJBtohZtrtrd4TjGf5QDgfFNE6BkVE02Iw/NdZvKm6I/We9CY0PQiOHEF
  4.2864 +7NbCbGEVZRqVG4ADyg5hfafxaQlU18whGkRsxfQ3D4ax688e0+Xzi/fvH6Mc
  4.2865 +yG8G9sZTYelmTrQWPk7NVCHDqnjXobQHzOGyFTOCQ73B2P252ELjE2XrZ4lp
  4.2866 +szg4uXg5eWi2PPxIbS2G+S0dqLoZx/G5WKrQSBTvGCSz6Ai9N3ez9XyzWkNG
  4.2867 +Ectn2Fm1raviN7FKwRN/TaMv7hhtMoIrawp+UL1NkN+gimOW7VEO9y9fBLb2
  4.2868 +fjCAV5p3jn8tH5uDIXwUoI2wjPPSz83ytTA34hqPoSN6z67CgkiJoXMJJ1vB
  4.2869 +jmoA98yWdaktTdYXIGqvHr2iXUJ47K2+7oCOE5L9MICDkWSq4Quzy2nqrdil
  4.2870 +07oOsEN9iMFfo0WIZ+b0Mo6BYuAalWc61FhAteVsA3oBq9UendkDEy00Qlwr
  4.2871 +ZDHELQrGrncQRwx2lbR5duwLP2q2gqqLI7yKxe3rk8ke/fJFXCqANvRFgPsb
  4.2872 +YD6CZM/EUNV0mb43kZcB83VJ/YFD2pEjGCGVgQEthKgBEyuvwNNdFfNSUPZO
  4.2873 +ksBtscHRvFkEzysc/qfrsfeN2W56wQ2B1das0irKw0pm9Bj5SPyXBuLLxVng
  4.2874 +ktlD1fKlA3yVCQmGBPFOg/7JYI+B0TXeq/Pi5A9ZAF72oD2+SoXYb3qd3PwB
  4.2875 +F5IxQ3YRs1ZvGD83cCRaXgA/lXaRbFhB2/G3wodg2L0lZnQU68bZuK//4rQ3
  4.2876 +N/mas7U5rVDUyhBwSaMso0z8MrEqFcxDBvGJ+wOs97F6pWAyiw/HcG68AqIF
  4.2877 +y/PoEo6233CNGg04iudXV5Cfer2sgTl4Enk0T7hYj8TudA25JlsDV637/eSb
  4.2878 +B99nT07aoyzxJUqlBwGFWCC+u9m6Q4lg7q4W9f79kYB8IlqIPJou3n/kJrEK
  4.2879 +oz4RfKCO1cgVKFYXPFhieuVa0qAPJXxKp2POqQICPMwbw/Fx/qnY/TchOI8a
  4.2880 +d7KGZ7vo1w5g8Q52XUCT+l01Yxjcg0QMnS1XKLiQg364yx9ZTvjxlspWoR8H
  4.2881 +sIkA2Yncz/gbuLqDGI5yYOkwCMZYERHEIdfduKwkclmYy4SpPJfCT7A/GevH
  4.2882 +WjzHcuUwkgyaFBOE2G4Brp5z6JOubPnkguuEZAZxuIo44ajIKFOHiZ1sjRFZ
  4.2883 +PgdbjJLey5DyabFUZR/h82Cj+hyBxIhIVgqoAVMGEOcP+UUQQT6BBCTnTdr0
  4.2884 +AZY2HKUWK5iHh7VQFK5EAYSxWh0WBsr5eFzIb3KMNis52qyYsUFexWJH6ItI
  4.2885 ++VyuFHX9hispsC5aWJqNN4FkprEgiGd7l5cdb2pqAHc5PPMW2cC0hZskIfKi
  4.2886 +g/WNpFELTWJxiYtuJIZTNpb8BGPFfBOzpU9PLzuvqGbrTYMDwq7z9oZN7MSC
  4.2887 +8ZPQqJ4k4qcATT6LIza3RqqLcmDTK/3IvLCQpS4VXckqEufDI4mDpadPOBXc
  4.2888 +CI13U/nM1NG+hILzJDPgwsfxLIt8T5KBRG+I71ejVNjunHMOiYIjtiFbJK7v
  4.2889 +w9CPDed/McpkiTptQvDq7QApqOj2tXXMYR85iqIqO06q7Aid55L97lkYEDut
  4.2890 +4shjl6EY9Cbyna2khfjjMCKUmE4jeZA7tGHlumSbQimL452SgcEb68ouWBDm
  4.2891 +ivydALZy9nNr2GLBfkc5a+Ilf/P71EqGSsj2pmJCob+j+KSpI0lhC2QqYBYr
  4.2892 +8fjGPMftLXah+YCcOxEcHuwqzW9ryZomoxm7qQBoRB3L9u0I6CBjd+DqCIpA
  4.2893 +00ZOG63LHVyuIlhx78D493vEZb+u65pxWPmIgwoCP2NvwqZRCxpIROYD6pke
  4.2894 +r+s140LYA1d1UWDR1MUE3soC9I/V2z/DWXEPv2RnEJkwkbwzF+ke4s9Ggc7q
  4.2895 +GhAuHCexpyAXOg7JQKgdZz9ss1CgK8fueRXOgGAwCH3qabVVtvRONJTaHLNq
  4.2896 +LnmKNJN5Bfm9osNE/wpoRtRBLYMymxVLsDxNG4iSCj1bw8BSpD9Lj+VWcKtR
  4.2897 +6pmkN8QxOwnHzYCXHcV8krR5uoelSi1kH6MBzdAAJlz1OeZ6LWTlKxFwWw/I
  4.2898 +lUQR2pLJ5D7dTTz/ft7OynIMpeZ+QEVetaSMcibWZPV2vufymzCEKxnkFREH
  4.2899 +k/7n3fXRe+AAQL2/K/xyhSfctPET5FbFj5wpvpCWBHWznDtFmQ8Az240KN/w
  4.2900 +nnEaOrAT4gGr4ZAopALZqi3IqvIwBlqS5Vz5pNOUGAkEcW5LSNtK/PyFelKZ
  4.2901 +sMTNma3bLb2TRgxFb+RIjeA4jwgnS/bxAa0TK4UEUozEtseWKseBnSIzESEb
  4.2902 +EJbKYre9+yIR6YfGyXZrOPh8fEWSldq48ED4MtEginfsiOZ4pkb2fF0zxyUG
  4.2903 +RDGJtO8s26GyCOIXNB3Cu9ErGbvASkgcdqGFf1vBgjHHsDr/gPoidpi35g08
  4.2904 +Cio/QrF87LmURYN9512WfEhVX8D9suum3qxxmqNvAH9aKMvMMwdxtCziCzha
  4.2905 +p5huGGrFXMOrk/jFUYUx5M7J52dPs0P8clXOjyQvV//KggeQmN+bs6f8Emdq
  4.2906 +NcnvZlqSRECar6RvwxvsSytggSTwTZcyJeT+yYIXJ2EfqhjKFLv4RvMsufRu
  4.2907 +xj9XthqtejPy7ABlOOnmK1x3Nj9gyUGiJCxBNBLT+kiznIgwF674Sk39hvRp
  4.2908 +2Cc+VlAOxc0A9yAJjOYtEG7P6hsJeK3r4P3MWjaBuKPiVzmsRPc4CP+tP1Pm
  4.2909 +FKVnZ/cgkjywBOv3ecdj4vz+snXkXbY8TF9+yCwpTnK2BJvpVlkNxL1/AY96
  4.2910 +Evspz8KI/uXX2QmOAxyFIhAadfACZ95I4REtr9AGwUi8gZ1uyamMZ8o5fQnU
  4.2911 +Qo4dyl4OHJxP+ZUWdAgeeVCZX+MVlJIpdKsO6G3H594YVPxqqHd6kfgEL+tR
  4.2912 +9mSWFd1s0nfZul+OjzOTgdlOOQMRU86vpOAihIo5aIW8/kPSO7h2VaGPd5a0
  4.2913 +klx5IgBTyWZBDjvfwqG9FdCqhdjMmyhayiFB/KgzucglC1nMY0tcIj4k5Qi4
  4.2914 +HIro/03iD5CH9KpBZjS2yIN5ItgRHETecvlTuJl5Y/VDozc6qhcvLl/5a9k1
  4.2915 +LkCDN1XJub7L7HWhRZLPjLM12eGb12eeDiSd64y0RxbBU/iIrQ5QV4c0bZ8c
  4.2916 +rq8DkbNKUoRzcXZ6+UziuOV043HYSDwDNtsnntkMguXISvbpOiqsA0tZ1duh
  4.2917 +WivmXFVnNJHW2fHX7afF/LnYYiFhE4sKoOGUcQiaxeHq1K7GXcgXpgX6WVJZ
  4.2918 +vGM4lQ5swWyIxUTum+xwsW6OfLK0T8cg1Y8zpqIrS1P+UyAfmyDe/burOIFg
  4.2919 +qpy6uJaiPzCXEY0VFWPYa9XLENKJ0HtJ9sKshE/Y3RTv8jm9bgV5i2X9W9HU
  4.2920 +4zXAoarHVrXxZzh4aEPbdT5jVeSLoNrRekfcQkV4P0EpV/OWTK983TJGnN4h
  4.2921 +jKc0FCuNLaf3cJFW9V7bAYjKTIWatqrr9d4GNxVHs7fsPXKIYLTFZo5iOkiC
  4.2922 +pieLH3cyGLnF2KbA/mgmhpfLsKkrOwMskKvaf0lmPas9VgLwelO07a4nVbkg
  4.2923 +caJHpcOI5DDAVXVjpULwGk5XI8E7K0hxhfW7oZuWWe5YaQqDER0sAE/zSFgY
  4.2924 +lUt+ANRBdd1KzVyYVuiz4BU4TcdgOg5+htwbashaKaud0sj8aubJM3krC6Op
  4.2925 +vFosxBvgGJ/Yukv5nB1PptVPySjVpA+QSKG59S6ArU+CDB/qM49lxn61dRow
  4.2926 +Rnbf4A7VC0LrSSqgJMxJcn4VrBvzntjs3shD+w8j7RS1bHCl3RqiwXwBL3qk
  4.2927 +ehT8qPSiiftMpewMDi14723aiGXj2SF3TQ4YM4mYEKfQ1DZAn7FDrQwm796C
  4.2928 ++8oexWAHFHLiPqQWSkhWAhyvi8WyUMf/pT5DZCufTVVmd1VOU4uLE5oMWhlp
  4.2929 +JocxAziSkilSXUqNNF8wYhcONjuEXSY5PkntqVXi1VUKhHh9LYWchIyr4NKA
  4.2930 +HMTtvecz/hMkJUIyX0ods8b+1FCwHhJ/URO9xR4tnJsWgrEZLkV/2pYalJBP
  4.2931 +IReeeMEThF8rfzvwzOf6JvUqblY4zN6f6IE/7OQIuu7TolMnjMFJnaJWybhT
  4.2932 +R5Ml9erzLfvaWal0Scb3QiSsvwSWRikmJI+0MaeMZzbbiI4nOrTpzm2QuCKX
  4.2933 +1FYHSCbkO7ne5eu8t3ezYrLDdzQE1n0hmgngBnJUWlQHeM8nUwIuO0sRmXhn
  4.2934 +XxqJYJ+LFwJJI2eVqGcMSLDMDmaPwSqf1UvrJiLzLpv5mOP6xKQdW5xtCG/y
  4.2935 +NXGyRB6FFkHSXQe8jcZ76WLnmYaWR59kp8Aql17/GmlxfgbkwUsESQynTxQT
  4.2936 +c1pHicXJIVBKjMk9ioa7jYbJGaEsVeip0Ma2DjY2KRGwB5lP+3f6YK/opwAg
  4.2937 +lLnnU1FiSb2TA4g9uXsY4o5cclpgzgRosSTXD14JDBxuT2jRgaaj/gUBUGdz
  4.2938 +CSDzWb3e9hPHIjSl6IAgl6kHLJcBUC8ITBxh5IsuxspNOReXzv6EzYEQuBHw
  4.2939 +H+pzarGGupAJARQXimNpYEgL+wo2aFULE4oxWVpTkP03ClaODdGVxren+ZRh
  4.2940 +92R5xKTBg6XpjrGaBQxirgkh0u3SRtuHoaozpilYa+5lCaQ1je3E0TH+01i/
  4.2941 +g4c4oz//bYIEj1vJl6Y9ECtbvDFNeV2qpY/XOR/Y50CUnllxJ3rSG5rhKMX5
  4.2942 +uz5ceSSasfiZ/vVfJVpbI/6PFC523nCdDJ5q8EZFr2fCxKoCL7rIoDFacpvj
  4.2943 +uwKC3fIieUs5UK9s5V1XJIGhWA9wwjSRms/AdF0UAM4rreQgKvydrugkO8fh
  4.2944 +uivbYLk4iJzCqw0kXbiqwOZaSjmyMwj3BqbIuwnnvIVHJkYIXl3uEcJhW8CT
  4.2945 +3x6NkpxYKxphpxHXjpxGub1pRjf4NdVUSRxLOUnY90Nw9hei5B8l7p6d8kDE
  4.2946 +AcuDazrhPZmAj4ZANJnfjyVCoZadXlSC2BMVHEFd4XbS6iSqMU3XykYTe9zM
  4.2947 +ZZnt5WbZozLGvLak97KzQNNvjjCWR3/6s/EWvottPHVrlsG5wNqONy/UEnIx
  4.2948 +iAtKZhVA7QEymCj/cclB9lmHUxtqUmWvfn5yMX74jZZGEICjFTmm6f2UtzeP
  4.2949 +g+PX0WWzzTKqR/C8nF4zaaG6L/1ytX57dV10VzbJwx3+MrQXOr6PVk+T62qz
  4.2950 +vuYmYbPrcjwtK3x6V0wn9Odv1r+Wr+mjx/mvp8t6+njxa7Jzqu4+PV7E8qR7
  4.2951 +1z2++fXXj2ZfTx8uHvxqkS8eTqfFtw8Xi3w+e7Qoigf0y6+mxez7h/n33z6+
  4.2952 +mf4ajRbvo2pze39Fqggted+rxpoGGx8RWUHDSX1nrJDWVlH1N9nPPxzzXROA
  4.2953 +oFqtKV0JjAvs7ekPbGnZQYu99ezNx05J3HtGe6RxlCzUTYkuI7LB/J335K+L
  4.2954 +GocxKmEoee/IfME+afWBir1a4icGqMUh3BySL4EkiMHIIgxJUTF/lNZSUjRs
  4.2955 +wdb6sphr5JsDoMixZRypiWUbR9WFJGmhRRFyLrqiTWzYeLxJlIE1mmWURyVK
  4.2956 +uAR+hzEHM6ChFDj1X1siblRiLh5HGqYwbcLOq5MwBB/OjwYrvLtR1odpBmHo
  4.2957 +AikzVnH8rYDVa9mlYYpWKMfF6BHURXVsbE4LrjsqTkoeUD+mQiv3spZczgY6
  4.2958 +oQJwbG6asmmqiCRwWXQONjupOdxYhmuxxu+0J6S3iiWggRHhVRraAcEMAz+D
  4.2959 +mMphjAb964Y0iPYTBILKA7XzFUSkjsxqG4IzUwsxCq4/xHZi/4HC9hIz471C
  4.2960 +H0mzeWFu++gehpSYlEVhQFZ6SJyK8zzJrAwvMlOyDYBZqV6e6lXSe8rHAIWi
  4.2961 +emPmNmtPnl6cjNiA5z+fPvrmm4ffS0Fv+/D1xQmfpfherw6H5CQxYo3waXRQ
  4.2962 +wgY3iqPFqyPe5QL5lFY+tT6M4nn5OSQ4wbCIVIO05OvWe7Xj4q++gGYSkWJ0
  4.2963 +fZvuSfK4TySi4I+KuL/3+VjxRZ+hH7kL88pHyCUTqAvpt76kBCNwE8cFZzGr
  4.2964 +p1bOkNa0FTShQN8D0Ja51sidpSEjAVHaeAMg1fKj+s4S6ejl4gxgsX6jCiCG
  4.2965 +ajqk8VRa4ZWUdeG3UY1bcxKjaw1pEJLCgk6HEnEe3GDmHF/tIgv7aOhMzonX
  4.2966 +TUm9PFwb8CPPUj8UvTkEnFmgQQT7M9qbOMa6sfoLbJ3h8aPgD3Odlb7yVaHh
  4.2967 +qKHjA+ATTpG5oqUSdzRccUiDIGgeL2z3QzuaUAM91IaVjY77P0ykUQVvT3fT
  4.2968 +FHHN8l724D0rIGshLHZY43MhCcPimkNVbRO7mo0RJBDeyxIVTRWiPW59LXct
  4.2969 +a+CDEgPfPjNRFzFR/RyMdOD2V7SD6rAMHoNSI8kFop84H72LHb8CgBEMGCCI
  4.2970 +JE9ppsuthQ4m2Y8bDbZFqktSMxoUoUkHXMhjK2GGcBJz7vfRdoqKbYYaLQ2N
  4.2971 +D/+7mxzeQ06NI+P7fofqIkho3sIo4Dpq+kC3lOocIaEHno2ikeLjBYrb+U04
  4.2972 ++68JavTmoGas4GF3PJ9j/rPlhpGBnZx0Y0Lbkd1ecgT04Jp0IQbCmsfsoHdF
  4.2973 +aFBI/JAZpdaiYk0s8DakPi9r0QvZaWH160Q/cOZAL0W/vp+dn6uzG2foI4v4
  4.2974 +CSI/iVS4z45U7AhUuH80UBFtVVHsUHRY5sC79a/wsEpezH3Vs7AYSXaYoUot
  4.2975 +ICSTYf8xqBUlRMQxsCs1xkUxrzTatTNCBr1Col++h9ZnRL8+EH7hxFPsJzEm
  4.2976 +SfrsBV/KJOEvppddHY7NkXlqAZeeRchIk1gpYEiI2oTYG4ufezRCcrGyv/ix
  4.2977 +5+r5OgaF/nOQBYTyfQH5mg6W72Fgi1AasgxS7jgbR0VnD6z0bb48GLm2Zt8F
  4.2978 +xygsyUqs1HpZzhmCjXrHNgQ5iVzHKRNgEdRfxwVoeRL3rVC4vHMJ0zuKggji
  4.2979 +Iyq2YWoHMWZnuOapCmpffdF6V/sF8jpsDrurThHDnAGUfQRY1d+DxqAfwTtj
  4.2980 +rwl6u9WExHx82h+beYt8pgkhoTzG4AJ+EusjAv2mh/jmrGIMRtqL1V4oSgGS
  4.2981 +7CIGpYMex+A0beGavneS1kpGqZYOqPiNr+Dlh0AbooGM3+xOLjWWLIAzVCYt
  4.2982 +jpmBgKowLbCHrj6+f5+5E4ZrcjzrPdI40v9BSJqEf/QyJ175pgnOpd9E7RQU
  4.2983 +5yfW+QBlY1EJEsu0p+jvGBcNCQFeb3oo1UZOIutr4fK4e+VEmFioznompT+t
  4.2984 +sIiVsxN2w3GSUFfOyk/wQeRlResBab0YUsp8dAd7VFYbLdInbRgFiHhm7MSo
  4.2985 +Ec2vOCFw1AMHeacR6/7qsq+2LlurdysqUxYH5DSb3Vdq0NvV6HVRGJCriOvb
  4.2986 +s0MEa6UbHKKOtPyFehSY5Dnty0W1oRmKmLowOhO7NVdpyX7/4vmj18+e0AKt
  4.2987 +14rbyNal5AFYlWjopFAazcQchEy7foksMxYkg5GNMHAAUQxf6KqecLFC8wH+
  4.2988 +O3E8Sbj4WAUuDRlxDdsZQ/qJNFe2FT2iAL4o76Q1Cr0MwfjPhPLf5ydeAc5o
  4.2989 +T72SVGimfSAbs72lMslo12Oab96VJLWb0E2Iw7bo8SJvzDTKwZmFxTvkfTKD
  4.2990 +8YgFj0tNw79hSzkvp0VsVxO8ez1gBI2a/VBPOVOwyxvDG4S+gLHnU7z3pHzM
  4.2991 +TCfhKZqolwVmM+iuFmQtSsq3x5C1Pqpf1WHgUsSCxsXv9mXv2VXJHocuk0R5
  4.2992 +Dgen7TMkv5E7h7Kd6gYjmDf53ZR7qMCLd31jIpOhLJqOWYSSGo/dAtWdRxlP
  4.2993 +kI2xru7Uu0uvBG1FfcG4FQiXg1auIH7skROiblmN5YQ4RdAhygo7nZb7sZb5
  4.2994 +RfFqTX24g/gj5s8J5jKsuJ+PhOYswlVLO5piK5vGO72n4++EM4S4+rZBcP6J
  4.2995 +rYqztP7ZPct2ko3ftLhDz2DbeNe8y5+GrVunevzH9k5WM9k9ZnVQTjhoqwaI
  4.2996 +AulkR3m9Lccx2dFOiyGkSXXa1S/ZZXGC8F5nh6LxeBVDfdlQfI6yzyGE+LDG
  4.2997 +BRuwpNPiesMlnX8A2JmmsRz51IqbzXVhAHgpcoCpQ/K/DVnewJ/BQ9EvBlEj
  4.2998 +oad5nNYP49CCpuwBYt3OmxoAVUYdaRE2pO8L+59kJywefVcjK4jNbsgbdiNw
  4.2999 +cqojmTOv7xDP8e2g1MnFt4CFG5EfPCUlteysyF9ETn10SLQIWtEvLIKfdm9J
  4.3000 +S43X7p1mNpxmKAcZtxlS1WAwd02jKhurGb577rwuyOfDDFtzKx9Y6tse2XPJ
  4.3001 +RbjgRRJHJ0sJ3xfWsMqcjBk3DIS5mup8wAc08HRodL2VojCZeAmD8Yzk34kU
  4.3002 +Fzuv4pJefNx8huE8aIZSFPGXX1BQgOxq1P6bK5JVUnL0jdMNANORi9hjNzw7
  4.3003 +ltqMPuaIA5srpS9IQeAMe8u8zR4o5HonTJsT+FfcXaML5czSawuSk0t0yCjT
  4.3004 +iXoEOESwze5CpnfE7z0JGK9Qp6BfsrqVcDmS+Xz5fa3v4b21Zv0fS6FP/4iA
  4.3005 +/I0GLHgi6C0orZPgMLWTIjM7SYKThp6tZ6oblKhvfQ6f53kTMTeeegK4JUss
  4.3006 +jqZKWWidEyMCtMh/mSr20vhVAxH1WgrtEyU9LxDfb+l+kdItGvhs1gyC4lYQ
  4.3007 +AkwaWQ8/yQ3hDFymFGDB2NlunplJVLWM5YHmKuUGxpnom0jYZOy13aydEN2d
  4.3008 +R9MrVgO+U4iwQjN25caYlbf8BMQGeLCRgQ0ljIXJDdeDudOnZIemHX8leeyI
  4.3009 +UT67esRBwJ/SS8E6rMKjdVocmif0IsZp6HPdV7uS7qVtA633E+klzKu4Rx3u
  4.3010 +6nl9JRO6kpGQOowYqiSOvlQfga1iw1OFK5jrszZx0w5NxFFFgpMA73KBqXmA
  4.3011 +WsTBRyKTBX6q5lvkvwglCZw/CnAnSlMIYu6y93e5lv0NdV1LHYJ95bsRJpnm
  4.3012 +g3qUP2j9f/m87WpUn+ESV4Kq9BCHSGVcIFhU1VoJQfAtX3aqXNnrSOvvxw+z
  4.3013 +e1LoArVhu8hNazSfR+X8Xp5fct0FYuWoQ8/YMPTUYF2JiW4wssyq/jSbtUl4
  4.3014 +bejDxO894Gwfa3KBFUKQkJ9CIZHzxw3GrQy1wEB0P92g7pwq6zs8R4XAKrz3
  4.3015 +ZW7PuqdvofHc8xnqXI7dMYK+Ep6iHvgl8weUdhXC54kPtHk7k7Vo+sEAd8Zh
  4.3016 +JLPRplyo+1Dok4fDIUPiGjZzTBn8pz/jzzhm1jvgSm+9wu5dbSph4VdhlHoS
  4.3017 +9QjSIDCXtijiYhuCJwQDebWZ/lxsr04eCTX4JUJ4mS0r37zA+Ird4XnWBG/4
  4.3018 +sjWPy7UY8grjolVwslecd42x4OXCEjhYITXVGMLvK76bou6ioO+20Mr8YMdW
  4.3019 +C5Gf82VrIoCZ9oXouiAx2VcbueKvpd1q4yMB+Iyf0yodMHhXggQ0KqkeUcdm
  4.3020 +n3WWk8P4TMrZRenhXq5YkHc4DmTAZnH1zQBgyHe0BJ1ZXIxGKdaVVmx1Gu00
  4.3021 +NYJBw/z46+RUw+99GctrASKFPHUM85ak8Bw6Jl1lXaGiQbdxGbellnjmk+xv
  4.3022 +jMowcR8fRQRoUF9f49tgaFbtjkBmBQRzuUizAvgt3n0t7f60+IUro6IXO/JL
  4.3023 +mFHGIO6dnmRzGuu+SE+6pRhP+naT9jl3eKmc1/Z+I09ModecnSeKDy0cM4ZO
  4.3024 +Ch+AivBlOysqUpRqDfIxHYpPxMMbTS0I/QzhYYAixeenKcZcnMm0hUcq6l1t
  4.3025 +eXd3iWrEgo+Xim+PdRTbaz7PLigPAd3pGVjQTfhZX96GttooFOyCH9eH96yS
  4.3026 +mlJBBMWQYGnU9EWCMOwQHhQnNSQCjarn3pywk3AIsDkNvuaVSXnBCWgVVqnQ
  4.3027 +Zm1DEcbksh9c8EPc0K8U1/9U9K1XeQnVlfPgefGFA3oJKsyip5e2NxJ+14Lm
  4.3028 +pZR4D2kf1wLNUTQ1BmDazgShWymgagwP4fVWgVOMCE79exyMRK4bTI+6UkIG
  4.3029 +dBwFB0xLfQPUC5mVvPvcnMX3mDVtnHQSbnIwI+vD/DqJPqKsnDmc89PjMsJc
  4.3030 +4c6n2+tim9doWK9LWj25tCG1lLIVvUzeJMXoCq2HlE7JUGYwD25ELW4N9GWG
  4.3031 +eF35SHEtRjdXgCrmMW5EbBYnQ443UKEe0gOv6CvZSVNjbannrFnpIUcitIW3
  4.3032 +rorCY5Iunq1gU1qB5tDCrtAvVKbr5ynFP3iUK9FHVjmYohX+gDwO4yJNWnE2
  4.3033 +Vq8L4SeGVmrJQg9FOqjvqgPDD+H8PKbzARVlhp4Gc+4w/lFlRY2BtRwTU0Vi
  4.3034 +zthzB/SoLvQ+0vSt9PIAKgqGriBgvVWWlO3maLhRbSYgfw9r/eULFOukVRqv
  4.3035 +rlfde8VwXqQjIuUx9nYxDwNAKN6U0FfH57tyTcuQEtS6Q1gE2LsjD7Pk7RpF
  4.3036 +WpHUa73bwVgCHfRO8ieBCoEIv83ZdfVMKluBrcr0F/4DWQCiRs+duQxS4dM5
  4.3037 +T+KuvEnIcuBmU+BHu5lCiyIxh9J78A9ovknkKlF3i9bUCs1G4h7AE19WpMft
  4.3038 +RKOLxywWP/qz+zZMnPRu9eYDmm1ipWWt05b2/+BoekCAiN++VyLDQ+HzzuXa
  4.3039 +sjMLmIO4l8ibNVduZ5NjNLxAgHYYvwfJJZ4kW34P+vEZWVajNnfqGX6cwCYl
  4.3040 +GFR5Fcx8UiIl9CyFcvsSgw3yssuvrw1uF5r/cL59NDyfnqVVULWza1ZzCock
  4.3041 +T3ERRMMgpHB7Kb0skS8o9pxIf5Y6IiXbh+NsUjWAxKM//IYvDXwBCETPK6U5
  4.3042 +opbTjIfEjtukqFN0aZx1jAuTO2M3FkOHlvk2gdiSXHQqbSxJqQ5dL5NnCWj3
  4.3043 +7MXJKyTvLqf1Ow/yZq4cawKiYKNBdlqTG8VOrBJ4khYvK8d+lKWUtE2ySWWn
  4.3044 +wCf+wnwNR7WQ1o+yHysZET1aoOTnEkC9gay0a5LZ1Nxv2+OpWWmxK501IBKX
  4.3045 +fGg9HGMQ18hJbUKRUi4JKBJa4KZG2n/dFBsWhYFcNZ7K+AnOA0GpZ57YIfvf
  4.3046 +2+5o5LTijXzMv8sXBq8F9z6cNnU+588t6K6NVZ0dWo7V4k2HS7p0PM2XtAVs
  4.3047 +c3Vm4TTCc1jAIgguTX40f0WtSj5/9Vp68rBdriqI9jCXWMQhGZg8mglWYMHd
  4.3048 +zHNBpYpjmW1bLlx0hCu0vRY7bubciZNmxVe/fvXkKBbGw6VXPpgFPJYo6I99
  4.3049 +hWngGsLpl0YZjE4IGQRTaKftpuyiTP6VtfSVdA9nhcCZ281JBw9dnO6IS3dF
  4.3050 +pW/TftGVVVIPI3MhZz2Luz+B3s20jdQtBZbSYWVG7W7LBpSjQl7kS2dd9NSX
  4.3051 +YxhpbQehmqvIFKc5evxcfiqrfb3HOp/MxS3GktiBdea0E6+RUTAcOr4o9WZW
  4.3052 +7cHZACyYPMrZow7EMOcGQJqS5TFiKlW1CSn8mwcpBvEgFK3ERRL3lfPtQfQ0
  4.3053 +PsAsOIwiXEF6vWiiTiiVH9BSeZQ72guxAFDmvI2f6oadNnw2F+eOLih8pKTW
  4.3054 +EzwWzAAh6wxMMi/0jzYOjMhWC1QKj3ABDCdCykplxU0hptt0eF+2u3OPEfEq
  4.3055 +euKRp+FLbe0uEqCVwkIVBJaFzPO6umdqRB9GRgd/CnIt17TNOH6FtP0rFM/j
  4.3056 +g15yHWN5jJxNR6XvonXWNbQ/7ejhqtDnd1CS31/GM+LFtHLpBrjGE/oRFzaL
  4.3057 +hX/d1txrPf5Q+Fs62EjxBXjvGLJGMpW4NwNAbBvfDcAwSNnVFdoEjblY+OCJ
  4.3058 +4ibzsM3sQK/K4+sOwsH8j9PXf5D8evZyIpvVffHwYXZ4fnJxdpFdKG0ecWlC
  4.3059 +X8ZSoOFjUsr5hCLekIwDS8Sl2mCoMO1Z9dulNUIOfaTA6rK/AMzDnAsOuBt1
  4.3060 +nrguLUuANDpOixsJILMExwKrDWkhrQIPwSAQ6aKD43ovzw64jDl9c6CKk/R8
  4.3061 +zLODQPezwlBuBxIFCc4/EX6kB9wocERpufWCsfChoN7njh1x7AEou5GE95ZL
  4.3062 +P9+sN98IIyHvcPEAPQ5P/KPiqJJUp5q7lWg/01q7DN0RKdUSBFQnDSquvPUO
  4.3063 +74RuIkBzlIvoDkwqA+jMbkQkcInS1NT1SnGmUce8fvssX+QA8AccZS0dkZKo
  4.3064 +GBGqCXAiABS0j5qKai+bg+9pETHTU+Osv3yhnGQMs2KG+idJ3y7vDBQsBzFW
  4.3065 +Xxl10yYVnCWtf2jnJ7lPUUqgrgwwAeyvurEQIMo6aPBYepmBEMSbAbIX8Yr6
  4.3066 +DJJir2UuuP5GDpkGOMbMMiaHAShNrDBcO47vsZADgnZa7BxZL2LfRNvAxwIq
  4.3067 +m0FyL3vFb3o9z3r5zVHMU4AjTksCcfmVbVv6CLuul8FNEOHuzeOcC+s6RR+T
  4.3068 +vokUdMNA+7oVqQyO08LsdLQbbtfOYYCMkyZd1HEiKv8pXk1+YsDdphMK6rtT
  4.3069 +1HEEFh7AFogP+tZuUCmJWk/Z3umsaj6N118hplVoX+JxKm0nfa4kyiMWkzku
  4.3070 +UaI7G1TJCqUge1a51JJwyTV7igCJKBYrhkeQPYQQ8uqKUPQAGqNJ2RWYLu3w
  4.3071 +gfNiPDzoET3ITzuX4CRbDr5NeSmFzg5qxBAOfBzamcKTb0VEW9meoGtYv6kd
  4.3072 ++GWGrzuTRFXcVJT1ED8MWVoyL1dQ7D0v7q2Uccz2cTS1r7LxDkIwWpFTnsxJ
  4.3073 +gmu9NrGKQATzsL/EJ8INQKNAkZWZCBsNuHUQa/41Rx9lpY+zuMNIr3gIN67D
  4.3074 +yp+Nn7bWMWYutZjZIIJcNPd3ONzaeyGKbre+OimDpXzfoR4j/52nDnrL5Qau
  4.3075 +Ig5h9FjEbzfl7C06tzQ1huEvzG7b4GCTkwuED7Cd5xWI4kKyH+SrF+W7quiU
  4.3076 +sbyuuU6T730VMm8ZT+cTPfKGTS9kr0HaKRxIc2skGMSaCpNpP/kmxJl89Sap
  4.3077 +qwS3h/q9pSmqPEQL83sCjbwiEw+2+eb9e0iYO6lg4wZAc073qlIk4CGbuBLu
  4.3078 +M9fZJZjO+DnDPN0Jmt1tj0b9oPyc1iQU9hJfsEIRZCat4NdIkYq//AwMQRgn
  4.3079 +aryX1RUTNVEZO+hPGL2bN6gSyOaCgpjaAPmNWW/ipHcyeOPKpnqQScy+GBTa
  4.3080 +4poRzCXZpvIB0KBtt46m06IrN9I+efcvTbPBomkLeg0AhaAkR0poGwCFcLHz
  4.3081 +k0fBBwc8WR8bUYxt869omy0+S1vKz0j2FO54hqbylqmbPoA6DTKL4bto+J+x
  4.3082 +NTXO0JXmq8t+uBAOkEpdHDq2HVA8IBwvQNNKryWcOXUDOK0m2QTOXku9E26B
  4.3083 +E+UPhXX41pM7r+t06+b1huvN79h38eEly8RE0opDlHQqxglyW2v8oj6HxSaq
  4.3084 +r+Yx1KHzZKktDiV07iVdOBNtdnbxSmk/IZbPWG0zxK9sYrvW/2XRmnYWQGS9
  4.3085 +ZgTqwtKyvIIH6cFdtRu0eCbbnchX1eukRpcYYdIoYqQZGaIfME6939c2ZAol
  4.3086 +FdQ/PAh/QLZrfT0M8ORT5/MLl9yYnlloconhmKPRJUEC59Gn1u6MO+gWRG6p
  4.3087 +8fA+892uPArW+UBFt7OXJcQjM5MO/aWTlYkwdhsDzDqTVfkUaXfMZr0tuxML
  4.3088 +wun04Fw5ax0KVfQvYTENtR7u0cgtowqylBLoN7e0jiR00TiucFGZ4nrA9UdJ
  4.3089 +kxmz+45zTtGdhM8US/fHXtgnyoS22gC4WeSqFHb+WH7VMKs732qcpBIHChnb
  4.3090 +9/8i15v58qmHTCPOV/TKq01lf8kM+6lSO8ur3dea7UnmmPb0DiGMH8AoBuFa
  4.3091 +KZCyE/jPrYAlvGfZvuo7mKVdcF2vG0YoQWrptGrj3OSalUMKLI62+6u0Ggwd
  4.3092 +GrXkHqugcHq1hTftCg+HCC1zUx+xx8YqGi6tY8KnMIqSjuRlrC/5MrXaMxiF
  4.3093 +HSxI5v1HPuIwreu3PE8u+4hTs7PwKJHWsygID1W0gGsYupi4wxnQC/6OUmN8
  4.3094 +QiDg1+wV4XCFe/EG7QtZULDvig38FmVgRv29VOu2TUqQoCSn5eUOmcM151VI
  4.3095 +dEvKgKn7Rj3ZwvZ8cK1FtoViVw4518i72KwOlhQ9HWWTyeRoz7F+BloAj8Cf
  4.3096 +hjpg4gypqoh9XZGFBOyIATnlQ7ipoZykn5JAALPyH8pDFYT0I+qutbsy/w2t
  4.3097 +9DP7M4ffW41mBvntfIAwtF33azegFETB4VqfHhZ6hRe+Nd+eLoLiVkwzjGSx
  4.3098 +48pjWvTeV0CzoscTaxSQ/ei75lnzhV5phUF7tx2ZzAtp49tsnU8fmEf1xZuo
  4.3099 +YggjdOLMeDCOpBw7Hx+711eowfHiMtySIJaX0QtIM1qUUgGxSDuNWVNpjE/6
  4.3100 +eDOwieF46JE3bO7Jl71/DyMjF9SijMyWUCqpxlU8UTjgbnihr4ql9pUGZcVW
  4.3101 +m+sAuHMZckNoJRxQZwkUXbooGkiGxR57yyWSZMV1pNO2znRVT0subcb3HBko
  4.3102 +zkXNETnRjxuLsd5QityronUGc1YHDrovauOdkpsTGjjT2jYqUsWqeHU1FwaV
  4.3103 +6smxnq+ZnrxFvW6NBpIPVeXSReJ3IiHtmi0siQr2jiojj7q64bP+Ko4GWN+H
  4.3104 +XqN53iZ1Pk6B2F7OzW2IHn4bK+SCdTxsj4739D3EvK0xZhIMCbWq4z6/6lNe
  4.3105 +1h6YI/0EWLK20ucRxIota2U6Vteh552XqK2KQcvpSryLS6nO2LbrmyZnKI3U
  4.3106 +n4hcwnl2W9bLEJvlxuzoti1RH+fbfCpUg6f5gb7F1jE36UD9/sh3Z4T3Qae6
  4.3107 +p2+z01ozohTHgCnBIAdQuS/hZkk/UgrirpiOJQGOJaV069xw0Q/u57qXFsx/
  4.3108 +yf4KgD+Da6uz0m7L7ZgJJXZSM+hM83Wm5ovQDGmpdYv8HfGlmEuU6LrlFr7o
  4.3109 +8DVoRQOsnAfwLLeR0STGZUN2pqRXjAdIMnQkzaIwPzeIqnnxNNAkca+UibM3
  4.3110 +Twqi0d3xBh/OlvVmfmQWL/NPtjItzBtTU+9eTca81b71BlnBzuI0z+u6aYHo
  4.3111 +ulYYhOMuQbk4Q3zPOVWdha5k3Rlz2EM+qi2UW3PxOoJGJlEF09Liko7CYOPi
  4.3112 +pT2cmYQiLJYnjc9VUXnlTxgxnnDatNY5e1o9qcZ0M+wNJ/USXTnoZL7p0uZd
  4.3113 +0C1ncoNvXncpIUnOjsrdDjkOYLMUqy2lFd6hMGTfGhQ4j6NBXL7beKTxBtOK
  4.3114 +GMoHDpPlfuWAUaNXz6ZCcq+Jo7iH6aIXxA7xK88GNGMgILPQesGPIxjLIi04
  4.3115 +Y1Vr32pb5qhWkbioZAUNAahLoAui5V+hZnB/S1uZaOZOQtjaaZUT5hmswVkD
  4.3116 +HswYmiQeTjme1y7NzXfE4PWlGfjsbS27ThhtVcd5KXEmVEBiO2Zn/BZNqqYP
  4.3117 +SzpnXN2cnZ6xEJ1uvRdPq+k4zg4dS5PbHCe0DUrhazIaukRHV9sy08bWJGtw
  4.3118 +hDdrMjWbwjcReyyeKzV+kP+xRVM5JFON2B17R+yDSGEzeyuBhGviS+yz0gwN
  4.3119 +3MryLPgokdbQOm3azbDrNd1a3E2sXeOCDuiNYhd8ApZkK3EGlmYvOaTmSB6F
  4.3120 +d57JHEZGlgbDwSgxIrqsbIu4Gg+yZWKovuZHq+vod+La0Gyp3vvsXUmN3+j+
  4.3121 +vlUkzgI2vtSf9Bb+MkU/7K+VciK0jtWWjjA81gMEl7oD6XQi+qjwScu/4wHr
  4.3122 +Kjt8LwHgcOYYWMIm/3IZYlssrsV3VLG5CLcX/C50o9NaX2+5BsTOGj5G1Ij+
  4.3123 +Ml94hqUSp/HI0OAuhXJrEmEdsq/w5jjnhhUmba1as15XcEctuo3XHAgZViNt
  4.3124 +zwQ8FBUe2TlYn5Ah0UZ1s7kUkU/mlRSWBlPizAKLqCf5YHlr45A4IprtYTh3
  4.3125 +/8hw0CaEBf+OUOvOIdXWyUdv0NS6vHVhdTIM5/XOVweNSbIJjcSRy2elrIVl
  4.3126 +e/1py3yqH96dNfAab43zhouh2zJa5UgHchkFJxRWal71PctjeQ0CrJxunT/l
  4.3127 +dhMUsh0FpVp95cmHiJbjwYqQCChuyc57zJWBgP2Bocu2kr/c26x82LwW1TXl
  4.3128 +9XXR+HU/03Ijia7OTbLR5VtAGPnMKo9KcDgarkt3q276ACleg5I4hSTF9Tq7
  4.3129 +uPRya4CljTexbPBRoYzAJLvAu6V3hCwDYtpa3dcTkQGX/DLEipCQDhNxb40k
  4.3130 +0VLXZt8a0jkGr5NE/jvPUVkERKUIWGIDcPKWs2CrbWflfSVnz1QQqVsTsFbB
  4.3131 +c2+FiEK8FFmPHEvB4dMyBcNyFJYMiWdW/b5XbFtbuFB6y+y8UOvi4Mhu5vTB
  4.3132 +cmsxIwB+1VhH7iIXIZCMK2Z4SLLmZGImIoXNTItZrlAehqyUq4Id4Az1cVj2
  4.3133 +f2E4j3/rl8I6JSog7HgOwILvTGtxkhvkYCp/ZsrV5NOJCKS8ErSDXKPoyCyg
  4.3134 +20iA+RAE1F4pTAi7cdc8Rv2J6KlmB4MoQeKsgde13lOmz2r7yJC0oFBXwwPA
  4.3135 +AfV4liPxlBimLiRWWukbruEphJc1AOkDFQR1Il9yBF34ct5YkfEkq9tKcqna
  4.3136 +wp4ZVpqk+IDlvUHJZ1QQk7Ngbrx2IZ5pGlzr5iVfcF2zz2tV190NIp4/8a20
  4.3137 +km03UJNCnqukBKO3snLbD7HaXl4jxsy7DE2JdqPnY8bXHuisNS34ULJdyWWW
  4.3138 +YfOx96kBDldSe7WuEanj8O9hK8gIWHJAQHhp58FhyCL13aw7YwHuhgTwXMNR
  4.3139 +QsPMAWnPUZlppCB9mKnIIF5HmWWao49JuSk6KQD+W8y9aI+S/fOZ9rp661uS
  4.3140 +8s7roWYxC7uYuwjnmmNkSozmpvqEadMZRplgAkXp3LRBYdxbQRDMmusbq4zQ
  4.3141 +ujeG1hu4u7NTwerez87Y3cDe4J6bg4tIq7HK3BC0p+4XULPCjJE16yz3QGsq
  4.3142 +ZF7RorX0ecLmLvqQWc/oX+GMvup03UjF+qK1tmK6LKGQ3zJvrrkQGKx1mXmt
  4.3143 +CVLWdDj46rOn1ppK/OBJ17nwWh0uhhnclzzCyC/o1PKDCvP69Ldvzl6fPuUg
  4.3144 +ZORCZ+kbml9G+aYo+qXkwTdxCc1B8YtgPvN0Vf+oFSFWLgS6XGhprIg6fQGB
  4.3145 +INYCytfHVaOobFKbc2JVI/FHOu5g0jDWJnrooKeXE2VP48DDOqBB9vIM4h2Y
  4.3146 +OCk9H6Hs0xu1QkN8zyiaQJKbHzJf0zo+7DJUh95MU67ER9vUOTCPvJFqOoWa
  4.3147 +srNlGYcc4H1UnBYnkCGUaFTitCHgkbnmmOlZykbqaJ5LbZ6oZYXMwEnFDhim
  4.3148 +0qysu9loQiB7CTSyWmeHCXc+skMKP/yOjZwwHrnzVaMVjJxrXD7O2PbtmiVN
  4.3149 +K0a7OsWme7EqHE3aKXPRkpKriPjebbF7i1MDAUSUkHCvmtymkiJaZiV4/T5h
  4.3150 +xFIUHmwI7eJoYC/OLl+oQ/JoYtH9QRRgeBZcSo2hfkBsb+ateIp8AlAyXafT
  4.3151 +VX/hm9+jlR7rRurydmdxWEHZx8VPJ8+fx6WHwNjXSJbEBTHCNLCLULIJRMiI
  4.3152 +IK3wrhq/BHiigKM+30mDnbpabFiTRx0UMkmjZY47jWyqnFPNuJ/endAtCsvp
  4.3153 +BF8G9xV3z6hCHWiDLyFzWH5T3wpqCWCkGWDVBdzCMUXQ4ySUEgKllRaodL1j
  4.3154 +ISp/KJzhzad4GHFwHgYNq5sIi7l8AfeTrJM63kKbCYHhShxcqnsDnMHdixGy
  4.3155 +b4pO8SjL/K41YYGvxquyKldBopFCKjWwV6x3dBYe1LdzRhVj9aYe++98IoN4
  4.3156 +FMU1JlWAstDHyzJlZRlpE4vlvA1rrCm+i8w4kCeRkfo7FV4RvVn5BWx7pre4
  4.3157 +gahBzjhekmvVdXVHJw/RcHxcXywhYimoBZPZI9wiiRI6J/nypur58aejLTyD
  4.3158 +5rRm1D53IXQeSDMOUETcTINt0CwadE0s6AhH/nXpecQAnDZ0Q/TVALUQTDwE
  4.3159 +9CWzzB7hHC4RlzjdMcOLffnq2BQFCmdr5E+vU6FlwLColuPaVD36bVxKHLEf
  4.3160 +bwST0GEJLMNOiDlT9qENmID87JzGKAMxSLQaixQ572F1WQtJbQZlUjJh+Gvk
  4.3161 +AWvufrV1h/GaHvFAOUE6zCLuMabH36rcSsJp1emOn2oKuTfiUVaLtZiQQ21p
  4.3162 +5mxgSTYuF8ex1H2rNGS9C7rtmoF2Wn4xeTbmMKdF53ZtlkelFd6Z+qW0tgCN
  4.3163 +AlDjeN+Y9o7FZ+7f1XqsyQ4QRwJLX1hZ9EnMNONxxWBfGTejfFCsphXVLNQM
  4.3164 +cN7bOy8El8Q+hDCRGHFiHl0p3AUblub20LwwNCIwK9wP+yB4YPCNeVDSanJc
  4.3165 +/UwMuCxTN89AD+ECjcJHQ74NK3YAvtF9iX7ntWdv3MUKeK+LmcnXCU9D6jCq
  4.3166 +a9Zuj4vDcd2MSBT9JHrU1GLoa0loQE07zVvwNbPCltBt5aeNyiQ7HuZv/kG9
  4.3167 +IjdSdScdErxkYeaNbzAZLx6eJic1E9JlfvalX8Iv1VGfQ5tBi8t1wSV5dQ8Q
  4.3168 +WtqwAMaDVG8RcbEtQOEmHJl6xjIGadHnKcUvsljq4slj2QVXgQfYC6ZAVxcE
  4.3169 +hDdamNa0ISMkHLGolKKESPz0Dvz0DvAQbmRo453Vy7o5wgTSPQ+KP9/yubMS
  4.3170 +ctCSK2ndIaO67KXfLrbBZX5SI3vHJCGFpQHVhycr8xrx4+jbaGtHH5rlYHYy
  4.3171 +Oe/DNM7DSblBv9xRl+8QGvmRquTIhMpE2ZwxbvtakreU6YVWFlI9SoVVicaZ
  4.3172 +Y5yHgrc91IGynfCZczDSfXVbhnJGxTk5U5Y0Hz5DaGZFu7WAF3DORndbj/Rt
  4.3173 +wfEs67qTeOxYxxXI0RdzJ21YaP3wze/HAJMd+Ryq+NyI2zXPrhvpBUi0SKYf
  4.3174 +bEJQvz00MGHblnRPZqFHgfAALUIoCr4VwU2GPYJ6zMaP7s8qu90sId71xO3a
  4.3175 +17IL+zpBfDIYMaVqekx1kDXSYXXXOPdRQFpCjDblM3de0qK36UYr1yrW/LSy
  4.3176 +tV5u2qykhCJlPK5PBa2SAWvpdPdBVBB4QAZR0bZe99tkd7MBN+lt7v9NPwJm
  4.3177 +558xfrJP++Fro3v/np3Q/5/28/fsh+zv/0nvzT75rXyt+9fxnp9/HVy8/1L3
  4.3178 +d5aj5r4rAupkOJj9lzq++LBkXxQ+poNztGdK+y/9T5rRf/6KDl+/fwBY0VeK
  4.3179 +ULkQsc/S5njnWHZee3JsK5rdexPUtHt7Z7T32v+kGQ3f9Wk/fx/ceaI6bazR
  4.3180 +ZoeR33nvnSb/j7L7ccdj8XYJ695zZ/wDA+v05ZPXf3h1efr0g6PdS2DDn3/7
  4.3181 +8Ds/9PN5d/7n7NB+mvu8p/DPvdOU5P63zCi5dtedPwzJ7mRAdjvvjMnOemuj
  4.3182 +ekVCQ707/9enk85/F7dK7/wcDtW/k3+Gu/5fONrkr49c/eE7T0Sl0uLXWv06
  4.3183 +VZ723BnpU1aRMF9yUyPWgKyTzo47NfqxvkFoECUzjj5ptERD2af9909xn/95
  4.3184 +Eo+I61Ly++59YEZ7r/3fLvFUFe0BRzniH+VstpqqJ1l/7xguYbED1GcWE7is
  4.3185 +QqVw39lxYdEimKmHURjiSLFIhhCPAuGviuYmX7e+aBX3TdL0K8ngihOwosFK
  4.3186 +8QbL5uptXVx+pg2bGbcQh+mi1sB8o1n0AQ+8MJjtJfur25ty0RmaMbeC96L/
  4.3187 +MyAfwF6rCtjFgAY2guQ1zpdbWWqkIk3U3BVDa6Pesh4jIamJKC/E3kTxODNy
  4.3188 +Ic7Zpl8rBU1HJagNDbjK54W7LSUPuxbPdzMOYVkGl9AnJpcYfDyytnu62k5W
  4.3189 +G7CurawGAhjb1bRealXj4l3nuw+LIz0uxc5VmbmsHVckUGyBc/c4YhOHEo2N
  4.3190 +qVuXEYsScwYwA87rDdqMCboA2fj3/FW+NszgQgFRe3uVC537krPsuGgE8yfu
  4.3191 +W4nd8rTqbLO+bmgJe3THMHvnK+6FckCRMRlwnDuT2iJrWAvEYvMiLi+3TMvm
  4.3192 +LV/f+W/ev9fqkIrF1+hT7eI63t7G1Yw9mVTsekaJt2tGZYY4rG6xRj2S4RhB
  4.3193 +hSqxaiuzu5sf/6XrlwwXiRZHlXanfk3SnEttXs3z6UoNWUkfN56G9MK13Jp+
  4.3194 +toNF+xG75DbiXG6DPpc8XX6OxtoG91oUI6pfbmC0ABxRfLZLUs84TdcHdCXe
  4.3195 +X2thE5ShkFLXsk5JaXUXqqlJYxjNBpJ6u2EgQsWa7cpuDitVyV0+uTJL9KVV
  4.3196 +DpRO1fS3fgy6fsIM7Uk9Z0eZ04Yl8Yk30cgIAj5/deORBENi9q7HyMUp2XDa
  4.3197 +Y9q3226zg8hIPBi5g9PwR3agwhS/vmEIwwnTJf1ddDN5em+EpSRpMlu0skKc
  4.3198 +Gl62UScW4a5Njlw80oGINUACrnKcEKnY5iJ30oC1HaUAdim7JYzQu23ZV+Qk
  4.3199 +mjr39SaU7Wuh2f5SQn/idqmSyhmxzLKaWzUWEI96lnlAoTaZlZrb+DSmI5TO
  4.3200 +TjjqDr4ZQvATldFnleTiwSNyqFWejvorrVNCOkjT6JzkPNaNhzlwIpAIzEMr
  4.3201 +9tTkW/PW+wyrG0BXZLFs2Z1IEVS2E6DowaZiiMsBJkB/NMWyhJfzgK9JHjXJ
  4.3202 +RJm41BoJu06CyBSS7GUn8ZCi7Y/AMzUfmhWktQIQS27OvuTg6U6mHrngJXXw
  4.3203 +JFTMtihcKJOXbhTn8YuMj7rL1wIc4/C7T+r00Bqa6SnigYhicObcrOixVidO
  4.3204 +dQlMS+c1Gmfy5jHezGOOsukB2v1HlUZGIJXdRnHv+DFkWcEALrQEYHiO5Gf6
  4.3205 +bg7CI8qFj88bkrHUmmJRBpDpmLu6G8RFbRaFVHUNXbShAkrH4MCuay5DzhjB
  4.3206 +KMEVHQoGOYkBuoEoG+eDWapU65O92dhSBgKSRdEFpyhDTmZEFJb5WaNIVybI
  4.3207 +JJEpSpachzIWYUAuNEzo4UYHK2LHgr68SCqwq0MbdHxTE/ekla2YkrUgqGI9
  4.3208 +84xelsA0mnpdt6V2kIPGY8oQqCFk2WGvAzpFRNuuzE+RecP8z9KSiseJ096n
  4.3209 +e2oS8xJlnkwPknpN8sRQlcgX86BPrX5OaLQiaDGXK7yKa8CochqVbfM7nytE
  4.3210 +x5qvxGdnsPiffoh8XRWBmTBWGG0OQBo4yDso4rOXzB+bsx6kSbSJvFwZ/UWY
  4.3211 +p2W/dGuSBh6VSndFxVd7oJYcaYM2cfeN+2ga6lFOWDr6Xjtw8BlkZbCLl0pS
  4.3212 +UYp3N2STiYT2PSToXNd2d2B1siHy2OzgleZjviCN5yDVcCO0pDraWpYPUdxX
  4.3213 +IDADxK9PrOcrGSgdQ28EU4aS+cYJrWpAbi/ktoyuh0PmIvMBTdCmeFwpnenL
  4.3214 +ozHzkrKfN76tRSoAUOgqnn9iGcYw3njBnpYtb+Mrn5JBy/am9ZWBa+3zFpX8
  4.3215 +Ue1gLnfOIzgWtw1YioRFz8dd0Mo0Q7ky5NSugYDK+MSbvdnV9tZ+qW+QpQbb
  4.3216 +BfGSL5ep1OVPQ6VTLZCTfur71QgbjQFqnAqj/tlRhIP1408pTylGvhxrlvAY
  4.3217 +/QiMz2KR+LQOZEWyP6fA7nGZjYNQjv9JrpXRz5vr3NhPK04EPssQVexQ6Nj2
  4.3218 +4NLFtyXxEyvBzanZwt9ZtMESBwhSsdBOJQDjsSRoLW3KjcmylquFtljpZDa2
  4.3219 +LK65rFiD9jLiajGhNyzgcfKHmAziidqa+lKjuYuART2YsAd4cypOlLkdoaov
  4.3220 +2bUT17whdkOmJ749JEMRIsC3Q1eRzGo4B4efnF2cgzMvFlB/tb/PrgX0+bTR
  4.3221 +rtBuhmx7qQBCql3JzUZ155OpmxKTIHA9raC0ofYUMDujVyvBu6F68wknjc16
  4.3222 +ZjyAecdj9SVYo4ZBI8O0ZL7Nd7qS+n4X9QSq5iYtNQdn5wzT2jWR16yLClEn
  4.3223 +A7E3jEBx9gbjDdKVHnkO3AiN9eOOMzps9SY7DtBeHWrnkBnxAVgIg21rIASl
  4.3224 +F7TPrEl0rhZ1Bqx6TNrssg2OHVaopfNBiBkhU01STFuQIDdk47IkLPZv6yXS
  4.3225 +SPTlkr90XXdlWtFnkWaeul5yzyR7Gu4Ph+oQ0U1f9+4oGcrIphiw7oZeYX/G
  4.3226 +jmwWy9YTnSVq+wvsvsO7eFH99dHXvhVdNpi5ApB7M3IhyyjioD9Yyphx0ZPB
  4.3227 +Z3Y0+vBe9TDn81vkc8yl/pzztVQ6LRlrMsnGbCkhlk8dTCBDZsHfTGaltseM
  4.3228 +nMNJcpE+MYErz0m+SpqMppSzaELLBd8IgZ7PTS221gRDaGudSwvY2BXNYxQq
  4.3229 +ZK/4W+lsSpaWdhwbZEv8YPqKUc6ufCTAoPv9L9XFSCfTPWN0Ks7h4eX5szcs
  4.3230 +D72XNoGIWj4Z7UjFE4MH03l4U68pDUvqzRQwcS19GKUg+C5y7kWo1XH4Cmip
  4.3231 +uGb6L7+8fvbk20fffCcuLm6LJ68zcJh5U+cj6/LgyVItoSTIN/TusW3gZLvE
  4.3232 +4ZkoaiTMSl/ByDY02Fll6BcWdX9JNUHGBC44khH7VeHVitym3BbK9HV++BFI
  4.3233 +NfIEq6ZnuX1s2MvsrHcSPXFrVWaU6CQZzHvY9rWZtDlHyVYTn/ynWcVR0Zc+
  4.3234 +N/MdL+hwSpkQtYrgRFmRFgqcp4oYad1g+iJXMPMerz59exNOrSeYTycvTwbX
  4.3235 +sX03r2cbjnEpMNo4NsaKu+RVvQZIFs/ieqDSaMjETmQHWStjPmLeQyt5YH1X
  4.3236 +tnb99Ka+VtQV31GIT6j3yTpZIsEZa1z7csHsmjSLY/xUKrarOiFVvSSsxB4B
  4.3237 +1HT3fWzZ3YSD8/3Xj+Bfurwx8LxPYugPuuwZfqnK4iK/zdnp5TNt08TcrI2E
  4.3238 +nFjB3NlJC/JxoXl2dtN46LC9kizlKmnjuSz9pLkFNsko4vhIVO351KQoum8M
  4.3239 +tQJimMZYN60A7tU9hyH28oqQKLlAn1q219BcGPsg7D86KXE2VIAkqtaAaj95
  4.3240 +65CCw8oRvY0XA9YLW58IaGZJAxi/hrmqglzkAolw6g4mwW5K4YgrZHT5spaV
  4.3241 +8Km2AwJr1J+jihC99LWkimnvST6CUj3Jlln05P6TyMaQZCqc9SHfZfIZZQd/
  4.3242 ++uNkMkEW+o0WRBTPD1Lgy+JOg3YOeiduv+aKoubtu644/DuLDyxLaT2scfoW
  4.3243 +js2UzNdFyVHVZlOxFYkA8ChqMMG5R5wmB70AqiW6peXLDVbLSSHZcMA5k53s
  4.3244 +KFQFiN7FzJ23PEov9aqiW0l/Riyv1QrcrH2xkECgw0lL8BpRhYiWvH+rQDZI
  4.3245 +N2HrMXuyadiD5BvWDcrX9TJhdl9oHmk/emR7wteG+uxkoSBAArNK81elb94x
  4.3246 +osC4iw3XTbdE2V64MriSHn/6ooTvjl5p3yP1Xs7vL79cvH4yWRdruq6WL9+/
  4.3247 +jx54Us0bJJseRoxqAbtI05N//h5JwUe7H5jLzfzA06q8hrfqPvvI0uHVfyNS
  4.3248 +RFsEDnNPy2bef16hd9Nzk+GV5xfZYbzx7LuD/iejmhZdngyprFt6gOtNb8QP
  4.3249 +AoH5BWwifVXTvEx5G6lfs2hgcDqFL2jQp/ybpp4Y6mA/UWhZr3hlONiwadoN
  4.3250 +c5rQugdjQY7mKK2sZwTzDJVszC4+QYEU/8441Z+e+Axxtwv7lrELG9UPxWJA
  4.3251 +lR/ppAGi17Kkr/fERkJ9zRn3krocjMcWUdIoP+kpvj6nmLxx2cfSN+lBBZBp
  4.3252 +sa21ZrUxIZEuQbAzo0tF7yTQA16n1MB5K3uGp6XcuLWvets0ZqSFRdzJnFvG
  4.3253 +txyxm5ZsmiHk6auGaSVTdKtcltMm584mMpHwOIfwXCGNnuqoM7rUJcmlCmCH
  4.3254 +baEXcdAzz14WHdRMPpJ3pERrk0vvMwFd211Hk7BDhUyAIxMpTcj4uFFavm5R
  4.3255 +AQ/MZ6gbMd/p133+t347bUUrhNd5PvJjtXn1o1ThuKER05RkLi7DtzTuIxLB
  4.3256 +P5tJHyrPku5syrWp4RIbXOXS8CuL9WteiODil1JdO8AT93q4gH/rDbu1RrK5
  4.3257 +oDVuuGZ73LVLYqRcZ4G/5XkUUdUBX6fIVkChOiMbVS79z0Jb6iyr8hVdewA+
  4.3258 +cMXhzYPwguyR5QizhOMSxSK2kIUXArFYHghVT3HSu8xy7TQIL3lNrWYer1C2
  4.3259 +tErj/SHcz+t1oq0T1FjMTl6dYdlAYDu+CqEFdidbYyepISKeUNk784tyvJb2
  4.3260 +DgDPuEqeoEukHrZW34pCKfQAa0cqfu0IOJWE/pRghMX4fqE8MeuSEPqH98hB
  4.3261 +SlAJH+YUF5Hp1j1zeL80afB3VNs4IzlqyxWF2gWTwkmznMlO91+8uBhlv3/x
  4.3262 +6pXm7lfSm0HbhAZStWa5tH9Pvv8+ac+6zKvrDWdTiibEfXELdZ7YiSkrF62o
  4.3263 +oPasAHDULjJ9qXZO6OrrghVUNoJzvyZeHuXGKaUGKuKIheKrdoxTmwkBUVdL
  4.3264 +v4DU365ubG48IUrBk/MX3PIGwBd5lX7x7y/P+p9cnL/sfXQ+/csTgYRc3JWL
  4.3265 +7qj39astUV/V+/C3nf8AonIX7SuAoYWPLIm78doW74i9o++xLz6yC5XQ48DZ
  4.3266 +oR0bX1rMTo7/IDTidAH7Zsl4ofrdL79YF5SxMKJxvi7HNubxQwE2cCXnNggQ
  4.3267 +Mm6EYx0QGXe0hadwWWjU8oB5kvQVZC9RBwggqjRyL/Zi7lR54SKPTQ07oac3
  4.3268 +CJek4dFOdH8rGiIJODJekUVANANc6F3h/X4+/Bfp2EwSXqr51i/xUMxXYoWb
  4.3269 +xwuShJNPvw8eLpJAVWnZbsR6OSx+KD064OeFOGLcK53mrl++FjrReiMsOipV
  4.3270 +OApoJ+n9rMrwZKeGJf1Oi+VaqiYGJuO1xzEZYO4Qax3U1iNTKYOPeMn9vkfs
  4.3271 +PeqSaItGIYFORFdzroiGscTV22Txw6jySno/rZDgGKKzbbKyzsg9Wt2SC4m2
  4.3272 ++YIVVu9+1YqKJhxF91J0rXRv51bbxd1kf/0w7hlPh/S30pCFNuIUpxGu7ll2
  4.3273 +Yf2L20xYKpeG3tO7sYsAsHH/Ul+j1NlAJVRDlsc1tz6JIm5xR8FNtarnPKSR
  4.3274 +tztcVIypSLpYiufQiglHIRBzJPi4D4nEbtfrtdEKtmuFjsIyyh3RX36ey4On
  4.3275 +xMqAYUlJZnJVOXGsFd4pxbvqq/hbCj8vahtWORR3qkhQd+JM5SD8wV/9BhV+
  4.3276 +g5y/FRFsUCvXs6lvd+N181A6gB3DXp+28qSxeRf6oLdS9RhDjaGvfOR1ygrP
  4.3277 +irtdRwuHV7vh7MMqleuu3+rUCnxK+2LuzOm0Luje95iGr2FhlrLqfof7Jay6
  4.3278 +lH1tt3Tyu0ZdxoeI5mmlsaO4lpqFzqJ+mi7QbJVpi8BQHVad2CQLuChVU4xt
  4.3279 +jCzHGzT+ot3UaCNGCc1OW9HKEX0qXeVmXBuau1Wpk5gG/tsdhBDTkGfFSqDE
  4.3280 +EWqudOmRFXFJS0FAwx2j1XdjRYeGtovsBm9D7cwCKfFdVG4kal1iRS0Zjm6K
  4.3281 +Z9IO3fdoCw4hPTE7nuFr+2UnM6uJxOqPCAOrBi/F2wUKy3yhepvKw2ytrcVv
  4.3282 +6sBh2s2Uu7WU+TJ4PyUkCYmC7nyab8LeynZzfY02eOaMZ/eY2d7H2cmyeAfz
  4.3283 +r1hW5dv6dpSd4Ejm6AW6WcHaIOHyA2mmT0i1mBZLsnx+aEoi9UvW1+VvWIZk
  4.3284 +1ZP4yEfZkyXEZp0938zejrKnkLTL7Of8hq4hoUfa74j0JKLp2l3Wq5xUnlMQ
  4.3285 ++OuiJct+Sff/mE9J3NKknxfV38qqHCGHoR2/QsWX7CnXpqdHnDU5gpbuYrsq
  4.3286 +aMfnJQdkcSxpeHSmaFw/45ccg69I2RllL8rmL3n286a4WRa0uHQCXtKA3c+k
  4.3287 +p5DGI2L0JeCcv8uXXK9qlOGlGBqRFM3lNapZ/oQzh1prF5PsgtZ7umkq6Wx6
  4.3288 +0RVrxIWekb5QLK0AKwMSAEfWIj3IfNPOIsqYg1rgSa8y7640Juamgr7GEjFF
  4.3289 +NjLM3+67RtYz6OVftjRl72Qh+xwwIrGuMvGzsN0kPi+uwv7LL2cX508mU3oI
  4.3290 +PCtjksPQrkC+QMtnp6rs9sIy3kvklWErfxi5jhMF2e1110SGyeE+A+hIYtm4
  4.3291 +9EyThRhQ4tVvn5VUtj7uoyHCFEkskKS2mcF9J0r75OboWFLI5MfBcqeH6E3Z
  4.3292 +Fdpr+hf8wsDc2U3eZPcUivE4Tke7fz97gjtLaytq3TveXD4bf6ddi+fRQxbr
  4.3293 +5nHW+xk8JIoZyoNc/5bBA4ZvgquBJvLh4bIP9Ozp3uHie7g5Hn/0IbjqHxns
  4.3294 +q9NXV96DkvnfHvOF/NkASh5yyc6ehrGCev741Z8f919mVCXPQev5NkJuf2iY
  4.3295 +gED96qvvxw+zk+evfjoZPxrRw6CebDtWER/wI6Z1Dc1tsKv8iHLhw/msxKOl
  4.3296 +jzmBPvJ2YshoDXH/pkRkd8E3GF1eLZb5dXvVZfzvY31X/OXD7O/pB48+/sa/
  4.3297 +o2Wee5/FJ+BxfFQYSvQkQUJd/Pa5c6+16i8AXrnviBoZz4cwFX/7/Mh8GNlM
  4.3298 +YzI7kqVGjhseafej0OhNrkX/sqXWGOZwAj0WFZtx7mGVpmf7yevTk8vT7PLk
  4.3299 +h+enilnLDrngirp21myxbgWYQ58bvcu3XCh1s2QHTwaV/Iquu9J7bT09qyNz
  4.3300 +6HqNK7hkxyGd9CO7BkB7xrBwJzj/SJAmP4v/stxR/4EE96846BU+LdurdbG+
  4.3301 +0sKaXXHNJY8FQPTAHT126aw9K+N5G3vyT1MusXdGumblfMdcZjlp3HPOu9ys
  4.3302 +53n45L9qvQYrxOQ/XAVbJ8YN7PwSQACipNV68P0hJoKvD78kfe7LoyO+PqKT
  4.3303 +7NCjDnXxjoarnsyMR7pudlOc6Qg6Dv5M8o/b5LNPnTvGokM5e/n09PfxUK7s
  4.3304 +wRDE/RHqd7g/PfLiuks48CX4suLYIy12pD2XPysnCD1AIvBG3k8G2iXC+1Gi
  4.3305 +PSK9qDar7CqVML8EqdNdaQZW9muQhVM22HCa84N3Dx5CWad/vz9OK0CP8GGu
  4.3306 +XxLH0fusvKAgjjhKHr+rqq8iA/HX/IIR7tOm57uvLeZXljTMtzwaxdfheNFr
  4.3307 +r8RdyBd8NbjAstn5668HX1tfEv76m8HX0wfN20LH+6vk29XWv1+TNPUh34+S
  4.3308 +iZuv5Wq6vaqnrXqI+Mo8eaC86koDLnzBdDCerq6vpCw/XzBL32UZVH+zsRS8
  4.3309 +xLLL8Zfantf0AJuS9uC1uxfR3dF3AJb2qeXhAyGIrxbH2abS2l9F7BRwKeX5
  4.3310 +S/pk8fDBPrLQ0NrVXZG/jZ8gtwk1vb44yR4+ePQ1BxvouuStXX01La7Ylte7
  4.3311 +Hu192QXyWAZvefQw2ZEnLy6Glzzq7T9M9esrsl0Hl3710akO7vhOtoQLFioI
  4.3312 +/tGDr7/LpqWXMB/70VUi5nT6JHnn5evh+/IhY/hat/rbvVut7dbRlMYDrPdv
  4.3313 +/hWu5Ld9vXc9oJP1x/btok/88bffybNY/aTFYRQZjLhSO1x/eLWgT7aZf+Jg
  4.3314 +Db5T5vgdrQEik82t6vPRNd/rOk3pmo8eiL3H4ftPOg5y6e4jkB1uKiieR/vP
  4.3315 +Qm/tcn7nvkMhlwwOgny8m/h7c5p+bE5y1QdofS8Fy507qHamu7HYsxsfodk9
  4.3316 +FDv7EMXyFYsFmRSJDB4oGB8Oy6XgrDQqB1/350TmRj7nWeNrUCzUTXiVr8vJ
  4.3317 +Tdob9d85ZTHEBR9LC+O022nSLyILnblPg68194FnaSw6eG1fo0kVGrGZ8TBr
  4.3318 +L354lI2zXpQR81kVNMAt3YB7kENAxgxCusf8N37MuUw22VHygZTUD9c1s3AN
  4.3319 +fqLaXvpify0XW4+vlg/e+k7d4czbLXNa2MN60/nnc5hIcAGAiIW0CnsvPefl
  4.3320 +G5ReWfiHDH7STh3SUog7T7MHP4yXSFhBKTLo8Db52F8pWnY0M/mAS/92BitL
  4.3321 +PP8a5LEtaAr6sxKMR9gEnIeLy5PLNxdX5z9H468rq52VXPrz6R+ufjq5uDp5
  4.3322 +8cPZj1cvT4gHpTlg/X4k+1dIf3hrbiTXN19Ny+sNQqMwfZMXv3k5LOZX1eE9
  4.3323 +rXmALBdklH301VGQbVkskkYoo4/ebDCcMmlDkZWdrfcsv6UdCCvNAbY74k7t
  4.3324 +TbnmOAzRtQTY2hBd5ZK+zf6bQK3XdeEb2en1T/9Ae3H25AoMK2zp4Kx6UcvX
  4.3325 +nF5cnJ2/tGM38l/autyjEYZPxdEGqMZVl93jc7Xjlns0wFHymojEw6+DS3iY
  4.3326 +iTOpb/99KrcCw3taDBneP8rvFDCR8LseiOIf4nefxu0iXqcv3ce4emxLrw5s
  4.3327 +ax9FGzcDyyDZAWe1XUn0zdAcfUugAKFX+rqcB/6gxrUNKSrAHYXA+vzMxh+4
  4.3328 +GeJoS8/QdBqfztCKpkEISrCd/lP6CIT29NR4CCmfoaemrRQS4uBqkzAc6ZG9
  4.3329 +25+cvHx5fnn1+lR5UfwUBFzCk7jSTbTgik/Y+kcf8cuA7IiDwmtDzJdtfDcw
  4.3330 +7rMIzCuHXnCvDCDpDzRw9ISP82VYaUX6hVUrq+OEPvAQI3zccOVzEq+kFciA
  4.3331 +miwkrPvHkAM7Jj6oTvYyBGEocT14zLS4yRFlbqK6XiChO+sVJ6+Pg9jDhyg0
  4.3332 +GRAIG3ZYoU33kakSv73SXCcY+oOnx63hOMy2sr5wSMUWGYgJ+IzZwRMOkU5o
  4.3333 +Njyn7SfQunGoc3ZfwKPl8BmCbdS3YrWPPjwr4itXBh4ZPEyrIBUhb5L5UC0d
  4.3334 +f3wKjd0/yU6Ggp0PeQ0FN2QOanspRmsIOFC75Jie8IH9nzdcbm5qmTpocc5c
  4.3335 +QnscMR1rOGPwmPOXz/8gRK54IiE8xiIwAoBxFtperNQmL4OnWJF7yVbJ4X6S
  4.3336 +DusfXmokv2xWQ4ZrzW6QOJt9+BF0iOrm40/QM/3PqBqgtijp1T8DcX7WqyS1
  4.3337 +G/mRuvvZoQgCQBGLQku9L7lDDf9FwifmR0rckDFcXexIsqQMMPbYjnaJdV6T
  4.3338 +1dkG5euDVCx9TrrJ/mnvUZb2Xm/y7gP3lLKYzFqCri7l/Y3LiWBq+3qrfwaD
  4.3339 +poounGmMU5donybX10L+GU1uj7KWKnj3dDFSTU2F+j1tQpt8F28UtLh7O9U4
  4.3340 +qGfn0obpST859x9V0a4LGrJ/Cmto9JGAwsPnOsE9epAgje8hDHGPMyZ97QMT
  4.3341 +nLu1ur5et0etQ6TvYaTY+WgYiqNyRjZjOjMpxxgVTtlnh4w5kjPL0eeWDier
  4.3342 +cFnyukd7XtcWM2A1/vn3RddyANG/Lo3Kh+i1j4DDdxLdre0rVBeMFNkepCHZ
  4.3343 +zr0jTSAEI5ouZ0xbUGe6BOapQDfLfQ9Q4z4MVzHwIamqHuo/9uMHyLNidgJw
  4.3344 +iOAnwQ83lffRxEvQln8r/BIsSUOiCYM2PkbDfIFfefGpoge9tW5A9YLoflXH
  4.3345 +273mQET4k73XFMs2fkdOJPyumI95DgCLxVy5/3MocD65g7sDblZjFLyp11u9
  4.3346 +ef/Y0Fj5HSvoOGRH4WjuNgb2+zfiNdGud4lehPvO31xenT+7enH64vz1H+wL
  4.3347 +YLLrRTD34hsuX7+5uPzd+eunVzATnp2/efm05x4J1AGCYudfmENfjIuE4qvt
  4.3348 +TMSSKRFdO0RVFkt57roCsIQvagDhTayyjFf7kBjX70gZrP8mVQDg7JfreKn3
  4.3349 +yKYe+3W7hZLkPyeYjntgiiPGvu/66pHdA1jNPT6OfDEDgu7xy+h4E81B2PAB
  4.3350 +GgkIBmdiIHeyp1Yv4Amrdf9/Y1fT00YMRO/8Ch8DSsRnC+XWRkGNSiSUgHoO
  4.3351 +bIK2AhKxSZsK8d/r92bGXywpFyKy3onttWdtz3tvHhb3esI6vui7QQVVikI5
  4.3352 +rjaJNuQShMSEpMtWVQXZqckp654w33tBRvjgE8Kxe/pbhr/kV6P6CeIQsrb0
  4.3353 +SyLd6lKMNDpqYfi0WT4Ryxf1JspNxWNmXPpaVW26CdauUEbwzHjQUCXFMIq6
  4.3354 +O6FQiq7kSp5N4eWh97HP3iXCBwh8MCyZva/NwJFc9AD96H5MA/qxrXXH0rrR
  4.3355 +9BdzOMbwuw5yw5Fq/abLVQC36rzQdN/2LQHRhDOW0NiyPyABiIWwvxmLWL1q
  4.3356 +euxR5L2bqXfaf1wLFWpG3W1pxrvvyWBwJur6m4mpILrruxKOczepbMQ2+pZ/
  4.3357 +H1/1Bfq5jwF9dnQmqDArTMwHTwzqe9IsmEcRPsWkEYXfqrn2/B2+yrq+G6RZ
  4.3358 +HK/LtIcdSYeYplSUWl4uBKFZPxJ/b0zPUJMZ5xxBxTJq2sbDkY4HAPg7gu6p
  4.3359 +diX4ggANNgyVnwlxuNrkTi+Hq4hquWHTrGdhkpfFMK8K9Yw/2ELGqYFgTyia
  4.3360 +af4l97HAt7Ye/sAUP7RG87mHfmorenCuU1EScuqbUcQera3N/xxd3B7PHpfK
  4.3361 +mimdn4yFLR5wAjDE7CnTVaEli6qh0DiCrrx1X6HPX06PXad9JuySQVpVKVSL
  4.3362 +rAOg9zHWBb7MxyOczUbEO3r+DTQSwI7/icOTo8Oe/3NCe8UzSZ9fy+V9Vz88
  4.3363 +rDVz6LvPb6Cl+1A+W3KBIAxn4eJQ8gc1F03ORLyePbxDLJqBhwtxXDg8zEqV
  4.3364 +wgVqGVRPf89bWWReeX0N3cYQYapLkckH59QtO1BS0oAY4FT1NwXX5zovL1Dg
  4.3365 +RKR9xfxyUZ8uuiMQsxYigxHXuoXJ1IXCqmYH5P9bDIMh+zHThSuOv1HoliU/
  4.3366 +5o1/oB0JbaxPMgp4d9Qos8fHV9V0paSaN+N3yzvB18DXU08YqXU6Y4GeHDJq
  4.3367 +Xa1SSU2DegNYIH4jmPdI+/QKP3X3t5cJtjQ6hiYggWLHgPDY4rfqiHKURbXC
  4.3368 +ZrWez4VsDB9dr0wxy8apH6Xvj9WuylsItYnEtRXncC3wan+/hvRT59ooe2/n
  4.3369 +EuDcn1gJnju3Xs0xWwQ2u/A18z3muwh6vo/8nIz7Tk8RNMJ/hU1wbiWX48Wm
  4.3370 +9+YGwPTJYDykmtXzsHKT0fWVW9cVBESAYmxyGyFvswovQF9BIQVgGJNTTBax
  4.3371 +cfqXNUktuRUje5SMGWdMmMCBydguuRFSXgLZxegsxmZxkc2ibBWjouRWIofF
  4.3372 +yClGS1HyCXb5fQdCB8/HFPiYG1FiA88KuE5XyPTyfukMAWqgV4FMAoaX20ih
  4.3373 +c0CeCA4GoBdATjLUiNvczt1m6j/c5i63srn1X8/lgJCh7DS2ZaeAEt5yIdqT
  4.3374 +m8gCNyHM0Lb9x8osv1c2+7bRkj1OXLfg1WUNmdl6TA5n8mcS07KXDKZkECv+
  4.3375 +4Jki13Rg8BD/ABHLeaZyXgEA
  4.3376 +
  4.3377 +-->
  4.3378 +
  4.3379 +</rfc>
  4.3380 +
     5.1 --- a/pep/draft-birk-pep.mkd	Mon Nov 04 22:53:17 2019 +0100
     5.2 +++ b/pep/draft-birk-pep.mkd	Mon Nov 04 22:57:49 2019 +0100
     5.3 @@ -3,7 +3,7 @@
     5.4  
     5.5  title: "pretty Easy privacy (pEp): Privacy by Default"
     5.6  abbrev: pretty Easy privacy (pEp)
     5.7 -docname: draft-birk-pep-05
     5.8 +docname: draft-birk-pep-06
     5.9  category: std
    5.10  
    5.11  stand_alone: yes
    5.12 @@ -32,7 +32,7 @@
    5.13    I-D.birk-pep-trustwords:
    5.14    I-D.marques-pep-rating:
    5.15    I-D.marques-pep-handshake:
    5.16 -  I-D.pep-keysync:
    5.17 +  I-D.hoeneisen-pep-keysync:
    5.18  
    5.19    SRC.pepcore:
    5.20      target: https://pep.foundation/dev/
    5.21 @@ -201,7 +201,7 @@
    5.22  1. Helper functions for interactions between a user's own devices, which give 
    5.23  the user the ability to run pEp applications on different devices at the same 
    5.24  time, such as a computer, mobile phone, or tablets (e.g., pEp KeySync
    5.25 -{{I-D.pep-keysync}}).
    5.26 +{{I-D.hoeneisen-pep-keysync}}).
    5.27  
    5.28  In addition, there are documents that do not directly depend on this
    5.29  one, but provide generic functions needed in pEp, e.g., IANA
    5.30 @@ -1531,7 +1531,7 @@
    5.31  
    5.32  ## Private Key Synchronization
    5.33  
    5.34 -The pEp KeySync protocol (cf. {{I-D.pep-keysync}}) is a 
    5.35 +The pEp KeySync protocol (cf. {{I-D.hoeneisen-pep-keysync}}) is a 
    5.36  decentralized proposition which defines how pEp users can distribute their
    5.37  private keys among their different devices in a user-authenticated manner.
    5.38  This allows users to read their messages across their various devices, as long