Setting up wks/ error parsing submission email
Fabian A. Santiago
fsantiago at deviltracks.net
Wed Dec 26 16:12:44 CET 2018
On 2018-12-23 05:59, Werner Koch wrote:
> On Fri, 21 Dec 2018 15:18, fsantiago at deviltracks.net said:
>> webkey at mail:/var/vmail/procmail$ /usr/lib/gnupg/gpg-wks-client
>> --verbose --debug crypto --receive --send < sample2.txt
>> gpg-wks-client: gpg: Good signature from
>> "key-submission at deviltracks.net" [unknown]
> The signature from the server. The server signs the confirmation
> request to allow the client to detect malicious requests before
> the user with a request to decrypt the challenge. All good here.
>> gpg-wks-client: DBG: gpg status: ENC_TO FAD6496868B818DD 1 0
>> gpg-wks-client: gpg: encrypted with RSA key, ID FAD6496868B818DD
> The encrypted challenge. The client must be able to decrypt this to
> confirm the publication requests he sent.
>> gpg-wks-client: DBG: gpg status: NO_SECKEY FAD6496868B818DD
> But for whatever reason the client does now own that private key.
>> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
> Sure that this is the same gpg version you used to create the
>> that key id mentioned as missing, "FAD6496868B818DD", is that of my
>> test123 address from my client testbed. i would have assumed it would
>> be encrypted to the key-submission address' key. am i wrong? is it so
> No. You encrypt your publication request to the submission address
> key. This is not required for the protocol but we want to encrypt as
> traffic as possible.
> The server then encrypts to the key you want to have published.
>> that i could also read the message in my sent folder so it's encrypted
>> to both of us? i'm just thinking aloud. let me know what you
> The server does not need to decrypt its own challenge again.
yes, confirmed same gpg version between both ends. thanks for the
More information about the Gnupg-devel