Browse Source

Merge commit 'refs/pull/620/head' of https://github.com/xsf/xeps

Jonas Wielicki 11 months ago
parent
commit
fdc2f5691e
1 changed files with 120 additions and 45 deletions
  1. 120
    45
      xep-0373.xml

+ 120
- 45
xep-0373.xml View File

@@ -46,6 +46,14 @@
46 46
     <email>look@my.amazin.horse</email>
47 47
     <jid>valodim@stratum0.org</jid>
48 48
   </author>
49
+  <revision>
50
+    <version>0.3.0</version>
51
+    <date>2018-04-16</date>
52
+    <initials>fs</initials>
53
+    <remark>
54
+      Split public keys into metadata and data nodes.
55
+    </remark>
56
+  </revision>
49 57
   <revision>
50 58
     <version>0.2.1</version>
51 59
     <date>2017-11-13</date>
@@ -125,9 +133,11 @@
125 133
   <dl>
126 134
     <di><dt>OpenPGP element</dt><dd>An XMPP extension element: &openpgp; qualified by the 'urn:xmpp:openpgp:0' namespace</dd></di>
127 135
     <di><dt>OpenPGP content element</dt><dd>An element embedded via OpenPGP in a &openpgp; element. Either one of &signcrypt;, &sign; or &crypt;, qualified by the 'urn:xmpp:openpgp:0' namespace.</dd></di>
128
-    <di><dt>PEP</dt><dd>Personal Eventing Protocol (<cite>XEP-0163</cite>)</dd></di>
129
-    <di><dt>Public key PEP node</dt><dd>A PEP node containing an entity's public OpenPGP key.</dd></di>
130
-    <di><dt>Secret key PEP node</dt><dd>A PEP node containing an entity's encrypted secret OpenPGP key.</dd></di>
136
+    <di><dt>PEP</dt><dd>&xep0163;</dd></di>
137
+    <di><dt>Public-Key metadata node ("metadata node")</dt><dd>A PEP node containing metadata of the entity's public OpenPGP key.</dd></di>
138
+    <di><dt>Public-Key data node ("data node")</dt><dd>A PEP node containing an entity's public OpenPGP key.</dd></di>
139
+    <di><dt>Secret-Key node</dt><dd>A PEP node containing an entity's encrypted secret OpenPGP key.</dd></di>
140
+    <di><dt>OpenPGP v4 Fingerprint String</dt><dd>A String representing the OpenPGP v4 fingerprint of a key.</dd></di>
131 141
   </dl>
132 142
 
133 143
 </section1>
@@ -261,48 +271,90 @@
261 271
 
262 272
 </section1>
263 273
 
264
-<section1 topic='Announcing and Discovering the Public Key via PEP' anchor='announcing-discover-pubkey'>
274
+<section1 topic='Announcing and Discovering Public Keys via PEP' anchor='announcing-discover-pubkey'>
265 275
 
266 276
   <p>Parties interested in exchanging encrypted data between each
267 277
   other via OpenPGP need to know the public key(s) of the
268 278
   recipients. The following section specifies a mechanism to announce
269 279
   and discover public keys.</p>
270 280
 
271
-  <section2 topic='Announcing the Public Key via PEP' anchor='annoucning-pubkey'>
272
-
273
-    <p>In order to announce the public key, the client needs to store
274
-    it in a PEP node. The public key data, as specified in <cite>RFC
275
-    4880</cite>, is stored within a &lt;pubkey/&gt; element which is a
276
-    child element of the &lt;pubkeys/&gt; element qualified by the
277
-    'urn:xmpp:openpgp:0' namespace. Note that OpenPGP's ASCII Armor is
278
-    not used, instead the XMPP client MUST encode the public key using
279
-    Base64. Clients MAY only try to store the public key if the
280
-    Personal Eventing Protocol service supports persistent-items, thus
281
-    they possibly check if the service reports the
282
-    'http://jabber.org/protocol/pubsub#persistent-items' feature.</p>
283
-
284
-    <example caption='Saving the public key in the PEP node.'><![CDATA[
285
-<iq from='juliet@example.org/balcony' type='set' id='1'>
281
+  <p>Two PEP node types are invovled: A "medatata node" is used to store meta information about
282
+  OpenPGP keys used by an entity while the actual public keys are stored in "data nodes".</p>
283
+
284
+  <section2 topic='The OpenPGP Public-Key Data Node' anchor='annoucning-pubkey'>
285
+
286
+    <p>The public key data, as specified in <cite>RFC 4880</cite>, is stored in a PEP data
287
+    node. Note that OpenPGP's ASCII Armor is not used, instead the XMPP client MUST encode the
288
+    public key using Base64. The id of the node MUST be "urn:xmpp:openpgp:0:public-keys:" followed
289
+    by the fingerprint string of the OpenPGP public-key contained in the data node.</p>
290
+
291
+    <p>The <em>OpenPGP v4 fingerprint string</em> is obtained as follows: First the raw bytes of the
292
+    fingerprint are computed as specified in <cite>RFC 4880 § 12.2.</cite>. Then the bytes are
293
+    encoded as a hexadecimal string using upper case characters<note>This matches the representation
294
+    used by GnuPG minus the SPACE separation.</note>.</p>
295
+
296
+    <p>The data node MUST contain an &lt;pubkey/&gt; element qualified by the 'urn:xmpp:openpgp:0'
297
+    namespace. An optional 'date' attribute holds the information about the last modification of the
298
+    key as DateTime format of <cite>XEP-0082</cite>. The element MUST include a &lt;data/&gt;
299
+    element which contains the data of the key Base64 encoded.</p>
300
+
301
+    <example caption='Saving the public key in the data node.'><![CDATA[
302
+<iq type='set' from='juliet@example.org/balcony' id='publish1'>
286 303
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
287
-     <publish node='urn:xmpp:openpgp:0'>
288
-        <item>
289
-          <pubkeys xmlns='urn:xmpp:openpgp:0'>
290
-            <pubkey>
291
-              BASE64_OPENPGP_PUBLIC_KEY
292
-            </pubkey>
293
-          </pubkeys>
294
-         </item>
295
-      </publish>
296
-    </pubsub>
304
+    <publish node='urn:xmpp:openpgp:0:public-keys:1357B01865B2503C18453D208CAC2A9678548E35'>
305
+      <item>
306
+        <pubkey xmlns='urn:xmpp:openpgp:0' date='2018-01-21T10:46:21Z'>
307
+           <data>
308
+             BASE64_OPENPGP_PUBLIC_KEY
309
+           </data>
310
+        </pubkey>
311
+      </item>
312
+    </publish>
313
+  </pubsub>
297 314
 </iq>]]></example>
298 315
 
299 316
   </section2>
300 317
 
301
-  <section2 topic='Discovering the Public Key via PEP' anchor='discover-pubkey'>
318
+  <section2 topic='The OpenPGP Public Key Metadata Node' anchor='announcing-pubkey-list'>
319
+
320
+    <p>To update the public keys used by an entity, the metadata node is updated. Before adding a
321
+    OpenPGP key ID to the metadata node, the publisher MUST ensure that the public key is available
322
+    at the corresponding data node.</p>
302 323
 
303
-    <p>In order to discover the public key of an XMPP entity, clients
304
-    send a PubSub &IQ; request to the entity's bare JID of which it
305
-    wants to know the public key.</p>
324
+    <p> The ID of the metadata node is 'urn:xmpp:openpgp:0:public-keys'. It contains a
325
+    &lt;public-keys-list/&gt; element qualified by the 'urn:xmpp:openpgp:0' namespace containing one
326
+    or more &lt;pubkey-metadata/&gt; elements. Every pubkey-metadata element MUST have a
327
+    'v4-fingerprint' attribute, containing the OpenPGP v4 fingerprint string, and a 'date'
328
+    attribute, containing the time the key was published or updated in DateTime format of
329
+    <cite>XEP-0082</cite>. An OpenPGP V4 fingerprint MUST NOT occur in the list more than once.</p>
330
+
331
+    <example caption='Publishing a public key to the metadata node.'><![CDATA[
332
+<iq type='set' from='juliet@example.org/balcony' id='publish1'>
333
+  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
334
+    <publish node='urn:xmpp:openpgp:0:public-keys'>
335
+      <item>
336
+        <public-keys-list xmlns='urn:xmpp:openpgp:0'>
337
+          <pubkey-metadata
338
+            v4-fingerprint='1357B01865B2503C18453D208CAC2A9678548E35'
339
+            date='2018-03-01T15:26:12Z'
340
+            />
341
+          <pubkey-metadata
342
+            v4-fingerprint='67819B343B2AB70DED9320872C6464AF2A8E4C02'
343
+            date='1953-05-16T12:00:00Z'
344
+            />
345
+        </public-keys-list>
346
+      </item>
347
+    </publish>
348
+  </pubsub>
349
+</iq>]]></example>
350
+
351
+  </section2>
352
+
353
+  <section2 topic='Discovering Public Keys' anchor='discover-pubkey'>
354
+
355
+    <p>In order to discover the OpenPGP public keys, the interested entity first queries a remote
356
+    entities metadata note to learn about its currently annouced OpenPGP keys. Then the public
357
+    OpenPGP key(s) can be retrieved by querying the data node for a specific fingerprint.</p>
306 358
 
307 359
     <example caption='Requesting an OpenPGP public key from an XMPP entity.'><![CDATA[
308 360
 <iq from='romeo@example.org/orchard'
@@ -310,27 +362,28 @@
310 362
     type='get'
311 363
     id='getpub'>
312 364
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
313
-    <items node='urn:xmpp:openpgp:0'
365
+    <items node='urn:xmpp:openpgp:0:public-keys:1357B01865B2503C18453D208CAC2A9678548E35'
314 366
            max_items='1'/>
315 367
   </pubsub>
316 368
 </iq>]]></example>
369
+
317 370
     <example caption='Personal Eventing Protocol result containing the requested public key.'><![CDATA[
318 371
 <iq from='juliet@example.org'
319 372
     to='romeo@example.org/orchard'
320 373
     type='result'
321 374
     id='getpub'>
322 375
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
323
-    <items node='urn:xmpp:openpgp:0'>
376
+    <items node='urn:xmpp:openpgp:0:public-keys:1357B01865B2503C18453D208CAC2A9678548E35'>
324 377
       <item>
325
-        <pubkeys xmlns='urn:xmpp:openpgp:0'>
326
-          <pubkey>
378
+        <pubkey xmlns='urn:xmpp:openpgp:0'>
379
+          <data>
327 380
             BASE64_OPENPGP_PUBLIC_KEY
328
-          </pubkey>
329
-        </pubkeys>
381
+          </data>
382
+        </pubkey>
330 383
       </item>
331 384
     </items>
332 385
   </pubsub>
333
-  </iq>]]></example>
386
+</iq>]]></example>
334 387
 
335 388
     <p>Note that the result may contain multiple pubkey elements. Only
336 389
     the public keys found in the most recent item MUST be used. Requesters
@@ -347,10 +400,24 @@
347 400
 
348 401
   </section2>
349 402
 
403
+  <section2 topic='Receiving notifications about key changes' anchor='pubsub-notifications'>
404
+
405
+    <p>Entities which are subscribed to the metadata node or advertise the
406
+    "urn:xmpp:openpgp:0:public-keys+notify" feature via &xep0115; (see <cite>XEP-0060 § 9.2</cite>)
407
+    receive a notification upon a node update.</p>
408
+
409
+  </section2>
410
+
350 411
 </section1>
351 412
 
352 413
 <section1 topic='Synchronizing the Secret Key with a Private PEP Node' anchor='synchro-pep'>
353 414
 
415
+  <!--
416
+  TODO: Also split in metadata and data node? Probably not, because it could cause stale secret
417
+  keys on the service (since it is not possible to list all PEP nodes starting with
418
+  e.g. urn:xmpp:openpgp:0:secret-keys and delete old ones. We could split later anyways.
419
+  -->
420
+
354 421
     <p>A private PEP node is used to allow XMPP clients to synchronize
355 422
     the user's secret OpenPGP key. Where private PEP node is defined: A
356 423
     PEP node in whitelist mode where only the bare JID of the key
@@ -572,14 +639,22 @@
572 639
 
573 640
   <section2 topic='PubSub Node Configuration' anchor='pubsub-node-configuration'>
574 641
 
575
-    <p>The PubSub nodes specified by herein SHOULD be configured to either never send the latest
576
-    item, or to send the latest item only when a new entity subscribed. Thus the nodes
577
-    'send_last_published_item' configuration option SHOULD be set to either 'never' or 'on_sub' (see
578
-    <cite>XEP-0060</cite> <link
642
+    <p>The Public-Key <em>metadata</em> node and the Secret-Key node SHOULD be configured to either
643
+    never send the latest item, or to send the latest item only when a new entity subscribed. Thus
644
+    the nodes 'send_last_published_item' configuration option SHOULD be set to either 'never' or
645
+    'on_sub' (see <cite>XEP-0060</cite> <link
579 646
     url='https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config'>§ 16.4.4</link>).</p>
580 647
 
581 648
   </section2>
582 649
 
650
+  <section2 topic='Key Enforcement' anchor='key-enforcement'>
651
+
652
+    <p>Whenever an entity becomes aware that the metadata node has changed (e.g., by receiving a PEP
653
+    update from their own account), it SHOULD check that the list contains the key they use. If the
654
+    key has been removed, the entity SHOULD reannounce it.</p>
655
+
656
+  </section2>
657
+
583 658
 </section1>
584 659
 
585 660
 <section1 topic='Implementors Advice' anchor='implementors-advice'>
@@ -793,7 +868,7 @@
793 868
 <section1 topic='Acknowledgements' anchor='acknowledgements'>
794 869
 
795 870
   <p>Thanks to Emmanuel Gil Peyrot, Sergei Golovan, Marc Laporte, Georg
796
-  Lukas, Adithya Abraham Philip and Brian Cully for their feedback.</p>
871
+  Lukas, Adithya Abraham Philip, Brian Cully and fiaxh for their feedback.</p>
797 872
 
798 873
   <p>The first draft of this specification was worked out and written
799 874
   on the wall of the 'Kymera' room in one of Google's buildings by the

Loading…
Cancel
Save