Re: [openpgp] Unuploadable Keys
On Tue 2015-07-21 23:36:45 +0200, ved...@nym.hush.com wrote: There could be a workaround, where the key is uploaded to the keyservers, but functionally unusable except to individuals whom the key-creator wants to use it: [1] Encrypt part of the public key symmetrically, the same way that the private key is symmetrically encrypted. [2] Send the passphrase to whomever you want to send the public key, encrypted to their public key. [3] Upload the key to keyservers. It will be usable only by those whom you choose to give the passphrase. (* Unless* you misjudged someone to whom you sent the passphrase, and he turns maliciously on you, and uploads the decrypted form ) If such a key-type were implemented, would it need a change in 4880, other than a notice to allow it? if we were to have a cryptographically-validating keyserver, there's no way that the certificate could be verified. I'm not clear what the use case for this is. people who want their public key to be not-public probably actually care more about: * avoiding publication of their User ID, and * avoiding publication of a persistent identifier that can link communications together both of these things would probably fail if the key (even obscured) was published to the public key servers. I don't see how this proposal solves the identified concern (though it's possible that i'm misunderstanding the identified concern). --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [openpgp] Unuploadable Keys
Hi On Tuesday 21 July 2015 at 10:36:45 PM, in mid:20150721213645.979d941...@smtp.hushmail.com, ved...@nym.hush.com wrote: (* Unless* you misjudged someone to whom you sent the passphrase, and he turns maliciously on you, and uploads the decrypted form It could easily be accidental rather than malicious. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-gro...@riseup.net Coffee doesn't need a menu, it needs a cup. pgp3RD4dNCShc.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [openpgp] Unuploadable Keys
On 7/21/2015 at 5:11 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Concretely, it should be possible to mark a key as not exportable to a keyserver or to provide a list of key servers (perhaps described using regular expressions as per Section 8 of RFC 4880) to which it may be exported. This could be implemented as a new signature subpacket. . However, this arrangement (or your signature subpacket proposal) has a set of problems that make it far from ideal protection, especially in the face of potentially adversarial users: 0) Any existing key (one with a self-sig that does *not* have this feature set) can't add this feature in a reliable way -- a new self-sig can just be stripped out of the certificate and the remaining certificate (with the previous self-sig) will be back to being exportable. 1) The keyservers would need to respect the value and decline to accept or propagate such keys. SKS currently doesn't even respect the non-exportable flag for non-self-sigs (https://bitbucket.org/skskeyserver/sks-keyserver/pull- request/20), let alone verify the cryptographic validity of signatures. = There could be a workaround, where the key is uploaded to the keyservers, but functionally unusable except to individuals whom the key-creator wants to use it: [1] Encrypt part of the public key symmetrically, the same way that the private key is symmetrically encrypted. [2] Send the passphrase to whomever you want to send the public key, encrypted to their public key. [3] Upload the key to keyservers. It will be usable only by those whom you choose to give the passphrase. (* Unless* you misjudged someone to whom you sent the passphrase, and he turns maliciously on you, and uploads the decrypted form ) If such a key-type were implemented, would it need a change in 4880, other than a notice to allow it? vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
