161
edits
m |
m |
||
Line 14: | Line 14: | ||
A public key can be changed for | A public key can be changed for | ||
* Adding or removing UIDs | * Adding or removing UIDs - No need to have a version, just need the current public key | ||
* Adding or removing (revoke) Subkeys | * Adding or removing (revoke) Subkeys - No need to have a version, just need the current public key | ||
* Change the expiration date | * Change the expiration date - No need to have a version, just need the current public key | ||
* Adding Key signatures | * 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. | I think there is no need to provide a history. | ||
Other use cases which we should check? | |||
== Key-lookup / GnuPG's Keyring / Homedir == | == Key-lookup / GnuPG's Keyring / Homedir == | ||
Line 33: | Line 35: | ||
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`). | 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 | 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. | 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. | ||
Line 49: | Line 51: | ||
There are two [E] subkeys. | There are two [E] subkeys. | ||
* We shouldn't care how the user receives the public key. This should be via Keyserver, WKD, E-Mail or XMPP PEP. | * 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 be | 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 | 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 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 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 | * 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 | * 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 | I think it will be better to use the same keyring and homedir like GnuPG is using. | ||
= XEP Review = | = XEP Review = |
edits