On 2021-01-21 at 18:49 +0100, Neal H. Walfield wrote: > 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.
We do have a bit of leeway here. This is not a "general TPK", as we are defining it inside a protocol. That's the context in which I considered it would be permissible to ignore trailing NULs. My main consideration was that this allowed the admin to simply do¹ truncate -s 4096 /var/www/html/.well-known/openpgpkey/hu/* and get all the keys padded to 4096 (or whatever value he may want. He would only need not to have real keys already larger than that). I don't think we can expect most users to manually calculate a complex padding. Now, if the operators can't disable compression, that's a problem. > 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. The right™ way would be to append a valid PGP key with an UID not matching the hash. All implementations should already had considered that possibility. One could use a public key with e.g. a Public-Key Algorithm of 0, and define that as a "null key" that should be skipped, but I'm not keen on that since, it isn't really a public key. It is overloading a packet to mean something different, for backwards compatibility. I don't think we are at a point requiring such level of backwards compatibility. There is only a handful of wkd implementations. The spec is just a rfc, and we are finding cases where the implementations differ, and will need to be changed, anyway. It would be a bad choice to fossilize a hack like that. dkg suggested an OpenPGP literal data packet. I suspect it may have been an error, and rather than a Literal Data Packet (Tag 11), he may have intended an _Obsolete_ Literal Packet, now Marker Packet (Tag 10). If it wasn't, consider this a formal proposal to use it. Tag 10 was never used by an official release, and 4880 says: > Such a packet MUST be ignored when received. A new no-op packet could be made, but Marker seems already a perfect fit. Instead of putting "PGP", it would contain the padding data. The content could start with e.g. "PADDING:" to make the intent even more obvious, but the whole packet should have been ignored. I have added several new test keys: alice.nulpadd...@wkdtest.pgp.16bits.net The same padding with nuls alice.lite...@wkdtest.pgp.16bits.net Padding with a literal packet alice.mar...@wkdtest.pgp.16bits.net Padding with a marker packet alice.sec...@wkdtest.pgp.16bits.net Padding with a secret key packet alice.experimen...@wkdtest.pgp.16bits.net Padding with an unknown packet GnuPG imports without issues the key with a literal or secret packet, but not with a marker, as it verifies (parse_marker) that it strictly contains "PGP" :-/ 4880 mentions that such is the content of a marker packet, but I was expecting a more lenient parsing, given that there might be packets generated from that unreleased version. It would be possible to pad with a number of these (see alice.pgppgp...@wkdtest.pgp.16bits.net), but it has the same issue of being compressible. I also prepared dynamic.k...@wkdtest.pgp.16bits.net which is simply padded with other different, varying keys. However note that gnupg only looks at the first 5 keys returned. > > 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. Do you mean to compress the returned file with AES? That would be a big change from existing protocol. And you still need a way to separate the padding from the key. Regards Ángel ¹ or, if you prefer truncate -s 4096 /var/www/html/.well- known/openpgpkey/hu/???????????????????????????????? _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
