WKD proper behavior on fetch error

[Daniel Kahn Gillmor]

On Thu 2021-01-21 18:49:19 +0100, Neal H. Walfield wrote:
> 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.

fair enough. It also doesn't allow arbitrary trailing NUL octets to
follow it, so i was just trying to at least make the subsequent octets
parseable.  But i agree that perhaps there are still potential failures.

> 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.

i think many implementations would treat a signature from an unknown
party as something worth keeping.  that is, they wouldn't be able to
distinguish a bad signature from an unknown signature.  so another
approach would be to create a bad signature that claims to be from the
primary key itself -- that is a *known bad* signature, so it should be
possible to discard it.

> We could append a public key packet with fixed creation time and MPIs,
> and a direct key signature, which is filled with junk.

Interesting.  this would likely be interpreted as the start of another
OpenPGP certificate, if i understand correctly.  at the moment, i think
wkd instructs client to expect at most two certificates (one expired and
one active), but i don't know whether clients are strict about this
check.  this would show up as a third certificate.

> Implementations would detect this as an invalid key for several
> different reasons (no valid self signature, for instance).

The risk with this approach is that an implementation that isn't strict
about requiring a valid self-signature might see this as a usable key
for the address they're looking up in WKD.  What if the public key
packet was instead using a reserved algorithm?  then it would be
unparseable and unusable by the client even if they mistakenly thought
it was the right one?

> And, implementations in the know could recognize the public key packet
> as being padding and no even emit a warning about an invalid
> certificate.

That would definitely be a nice outcome.  a dedicated/dummy key type
would facilitate this kind of discarding too.  what do you think?

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

this is a non-backward-compatible change to the format, so i think
that's probably not a great outcome.

       --dkg