Tech pages/OX
This page should be used to discuses the XEP's and implementation of XEP-0373: OpenPGP for XMPP
Discussion
History of version of public key
Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used. Requesters may want to limit the results to the most recent item using the 'max_items' attribute set to '1'.
Is it required to have a versions for the public key?
A public key can be changed for
- Adding or removing UIDs - No need to have a version, just need the current public key
- Adding or removing (revoke) Subkeys - No need to have a version, just need the current public key
- Change the expiration date - No need to have a version, just need the current public key
- Adding Key signatures - No need to have a version, just need the current public key
I think there is no need to provide a history.
Other use cases which we should check?
Key-lookup / GnuPG's Keyring / Homedir
How should the Sender fetch the public key and where should it be stored?
- The key-lookup can be done via a lookup of all known keys with the XMPP-URI as UID.
sec rsa3072 2020-05-01 [SC] [verfällt: 2022-05-01]
7FA1EB8644BAC07E7F18E7C9F121E6A6F3A0C7A5
uid [ ultimativ ] Doctor Snuggles <doctor.snuggles@domain.tld>
uid [ ultimativ ] xmpp:doctor.snuggles@domain.tld
ssb rsa3072 2020-05-01 [E] [verfällt: 2022-05-01]
In this example there is a UID for the E-Mail and an additional UID with the XMPP-URI as Name (`gpg --quick-add-uid`). I guess, most of the time the user has just one key per account. It could be, that a user has one key for his Desktop and one key for his laptop. There is also the possibility - I didn't try yet - to create two subkeys [E] and have one key stored on the Desktop and one on the laptop.
gpg --quick-add-key 7FA1EB8644BAC07E7F18E7C9F121E6A6F3A0C7A5 rsa3072 encr 2y
sec rsa3072 2020-05-01 [SC] [verfällt: 2022-05-01]
7FA1 EB86 44BA C07E 7F18 E7C9 F121 E6A6 F3A0 C7A5
uid [ ultimativ ] Doctor Snuggles <doctor.snuggles@domain.tld>
uid [ ultimativ ] xmpp:doctor.snuggles@domain.tld
ssb rsa3072 2020-05-01 [E] [verfällt: 2022-05-01]
AFBB 126C DC71 912E F5C0 F47D FC18 A7DA 7495 5B8A
ssb rsa3072 2020-06-02 [E] [verfällt: 2022-06-02]
6C88 E0E5 3F69 A137 2F0F A36A 3AED DD36 93E7 8BCE
There are two [E] subkeys.
- We shouldn't care how the user receives the public key. This should be done via Keyserver, WKD, E-Mail or XMPP PEP.
If I read a Mail via Mailinglist and get the public key via WKD, it would also be possible to use those key for XMPP. Also, if I'm going to update the public keys. This is important for the WoT and to make sure that a key is valid, because of new signatures of the public key.
- The user should be able to use his own key. For instance, if the user would like to use his OpenPGP Smartcard / Token for E-Mail and XMPP.
- The user should be able to manage his public keys like all other keys GnuPG's `--update-trustdb`and `refresh-keys`
- The user should be able to use WoT pgp or tofu or tofu+pgp mode
- The WoT is important for messages which has been signed or signcypted
I think it will be better to use the same keyring and homedir like GnuPG is using.
XEP Review
XEP-0373: OpenPGP for XMPP
Date of a public key
In Section The OpenPGP Public-Key Data Node Example 3 is a date attribute in the pubkey tag. In Section Requesting Public Keys Example 8. is no date attribute in the response. The Text "Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used." may reference to the date attribute.
"Requesters may want to limit the results to the most recent item using the 'max_items' attribute set to '1'." Does this constrain guarantee that the response is always the most recent item?
I think there is no need to have more than one version of a public key on the PEP. Within OpenPGP (local Keyring, Keyserver, Web Key Directory, doesn't support a version of public key AFAIK). The user should be able to update the item with his current version of the key.
XEP-0420: Stanza Content Encryption
rpad
In Section Affix Elements rpad is defined like
"Prevent known ciphertext and message length correlation attacks. The content of this element is a randomly generated sequence of base64 characters of random length between 0 and 200 characters. TODO: sane boundaries?"
In Example 1 is rpad
<rpad>C1DHN9HK-9A25tSmwK4hU!Jji9%GKYK^syIlHJT9TnI4</rpad>
This is not the The RFC-4648 - The Base 64 Alphabet defined in: https://tools.ietf.org/html/rfc4648#section-4 (!%^).
static const char rfc_4648_base64_alphabet[] = {
'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P',
'Q','R','S','T','V','V','W','X','Y','Z','a','b','c','d','e','f',
'g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v',
'w','x','y','z','0','1','2','3','4','5','6','7','8','9','+','/',
};
static const char* rfc_4648_base64_pad = '=';
Example:
rpad: 6mWBrmp77XWx/srrjVNwS32eXf5 rpad: B1LXIxB9xPZwzD5mXr6jiIiPyr0FpworMt5GpniK8JnyRVVVnWJzYbyS6kVMEbTmxDsgmwCOV7dpczyl1SiBO1DhzKhdxHCW6gsMH1nyAOC9dHW/JJM2L/fklEge4d+ktrC0 rpad: ebeJpeWb4KLt rpad: P7ZgMDX6b4gFN4TN0/VSl6315bgvXxnHz2+AVmSVZVzl57ztMVQ5NtRZb2yVEZA rpad: BQCJ/1e8iY2nJTW0RdP8bhg9NOaNZr/O/xvgTYCY+t0zFpEJMBaCY9sKWKfFePtB3BLva2HQ17zw2kFVDn50Kp8n+VKhctSfwofda51NQq8Giug+A5057Ma9NSjMZt rpad: PyOyTdHT2WiXeTuevJdS5yQLzLtxrf3g6GbN4qKrzPKLgQMGOo8cd3bayBO9o1yZHy341KoCtDMhyhwhDl/aMTXNh2bPrjIpeAJ6xDLjL6Ph/OB32GMTvMqtpy9vbygXo3
Verification
Table 1: Overview about different crypto property elements
Receiving clients MUST check, if the JID matches the to attribute of the enclosing stanza and otherwise alert the user/reject the message
This could be full JID or bare JID, depends on the Envelope Element? Should be a plain string compare?
Receiving clients MUST check whether the difference between the timestamp and the sending time derived from the stanza itself lays within a reasonable margin.
???