WKD proper behavior on fetch error

[Neal H. Walfield]

On Thu, 21 Jan 2021 17:10:31 +0100,
Daniel Kahn Gillmor wrote:
> For WKD services which cannot control their webserver to disable
> compression, and automate padding, a better approach would be to pad
> each published key with an OpenPGP literal data packet, whose content is
> filled with a high-entropy (uncompressable) stream.
> 
> Implementations that can parse OpenPGP packets will identify and discard
> this packet (it is not part of any legitimate OpenPGP certificate); it
> can't be easily compressed (due to the high entropy); and there won't be
> any confusion about where the certificate ends, if the actual
> certificate itself happens to end with any trailing nul octets.

Please don't do this.  This is the format of a TPK:

  https://tools.ietf.org/html/rfc4880#section-11.1

It doesn't allow arbitrary packets to follow it, as far as I can see.

Let's stick to it.

Now, there are few things we could do: we could inject a bad
signature.  Some implementations won't discard bad signatures, so this
is probably a bad idea.  We could append a public key packet with
fixed creation time and MPIs, and a direct key signature, which is
filled with junk.  Implementations would detect this as an invalid key
for several different reasons (no valid self signature, for instance).
And, implementations in the know could recognize the public key packet
as being padding and no even emit a warning about an invalid
certificate.

>    If the Literal Data packet padding mechanism is used, it SHOULD be
>    filled with high-entropy randomness, in case some HTTPS server,
>    reverse proxy, or other element in the data transmission chain tries
>    to compress the certificate.

Another approach to make the data uncompressable would be to encrypt
the keyring with, say, AES and include the key.