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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
