Hi Sune-- On Sat 2025-05-17 20:01:48 +0200, Sune Stolborg Vuorela wrote: > What is - to you - the purpose of the reserved packet space around > 61-63 in any of the pgp related standards?
It's not really up to me, for what it's worth. I'm basing my answers on: https://www.rfc-editor.org/rfc/rfc9580.html#section-12.10 which references: https://www.rfc-editor.org/rfc/rfc8126.html#section-4.1 (Private use) https://www.rfc-editor.org/rfc/rfc8126.html#section-4.2 (Experimental use) (or, if you prefer the obsoleted RFC 4880, https://datatracker.ietf.org/doc/html/rfc4880#section-13.10 which references: https://datatracker.ietf.org/doc/html/rfc2434#page-5 ) But if you want my short paraphrase, it's this: - Private means "i will use this only when talking to other people within the same administrative domain, and i don't care about interoperability." - Experimental means "i might at some point want to bother with interoperability, but i need to experiment with some functionality without burning a finite codepoint; i don't intend these generated objects to have any permanence or persistence." For example, the OpenPGP WG made good use of the experimental range in the OpenPGP Pubkey Algorithms registry over the past year when developing draft-ietf-openpgp-pqc (just now coming out of WGLC, yay!) Once development branches of multiple implementations could confirm that they were able to interoperate using the experimental codepoints for new algorithms, the specification was adjusted to use non-experimental codepoints so that the experimental codepoints could be reused for the next wave of experimentation. All the participating implementers needed to do was to adjust one constant in their development branches before moving to production. Poppler wants to create interoperable OpenPGP signatures for PDF documents, right? If that's the case, I don't think Poppler's proposed use here falls into either of these two categories. > What's the purpose of X-foo headers in emails? of X-foo http headers? This seems like an entirely different question to me, because the X-foo style MIME or HTTP headers represent an open-ended string-based registry, while the reserved codepoint ranges in OpenPGP are a very limited fixed set of numeric identifiers (typically constrained to a single octet; with packet types, constrained to only 6 bits!) By the way, using an X- header is deprecated in open-ended namespaces, for a variety of reasons that i won't re-hash in this message, but i do recommend anyone read if they're interested in helping to evolve protocols used on the open Internet: https://www.rfc-editor.org/rfc/rfc6648 At any rate, i don't think questions about the X-header are relevant to https://bugs.debian.org/1105820. > This is not about poppler or rfc9580 or any other things. This is about GnuPG- > in-debian adding a patch that was rejected upstream for likely breaking > things. This isn't how i see it (and by the way, it's not just Debian who has adopted these patches in the face of upstream delay). This situation was apparently triggered by poppler, some few months ago, starting to emit what are ostensibly OpenPGP signatures. But they include packets assigned to private or experimental codepoints. This suggests that there is no expectation of interoperability with any OpenPGP implementation, including non-GnuPG implementations, and potentially any future versions of GnuPG that decide to limit exposure to their message parser in a detached signature context. I don't think poppler's choice of private or experimental use packets is a good idea, as i've noted in https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595 > I consider this in the same family as if an email server started to reject > emails with a X-foo header, a http client refusing to continue downloading > after a X-foo header. I don't think this is the same situation at all. I'd be happy to help you fix poppler to not emit experimental codepoints, if you would find that useful. Let's follow up over on https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595 Regards, --dkg
signature.asc
Description: PGP signature
