[openpgp] Re: Fwd: New Version Notification for draft-gall agher-openpgp-media-types-00.txt

On Wed 2025-11-19 12:14:16 +0000, Andrew Gallagher wrote:
> Well, we do have a matrix - the grammar defines messages, detached 
> signatures, TPK/certificate(bundle)s and TSK(bundle)s; and each has a 
> raw and an ascii-armored form. So our options are:
>
> * four types each with two variants
> * four types with no variants, armor is part of the content-encoding
> * four types with no variants, implementations MUST auto-detect
> * eight types with no variants, armor is part of the type

I'm leaning toward the last option.  Possibly ten instead of eight,
because working on sop has convinced me that while INLINESIGNED and
CIPHERTEXT are both "OpenPGP messages" they have rather different
semantics and handling properties; conflating the two becaus there
happens to be an ABNF construction that describes them both leads to
some amount of risk.  (e.g. using "decrypt" functionality on an
INLINESIGNED message often yields the message, even though it wasn't
encrypted -- there are probably bugs lurking in applications out there
that will render a signed message as though it was encrypted; clearer
typing might help to avoid that)

> I don't follow your argument. Are you now suggesting that all future 
> OpenPGP tooling should auto-detect armor, or that they should not? I'm 
> arguing that they should not.

The only common OpenPGP API that i'm aware of is sop, and by definition,
a sop implementation always auto-detects armor.

Other interfaces that i'm aware of have mixed results in detecting
armor.  For example, GnuPG can only handle "keyrings" in unarmored form,
but it auto-detects armor for messages and detached signatures, and
during import it auto-detects armor for secret key and certificate
bundles.

But regardless of what tooling does for operation, three of the four
types you identify are trivially concatenatable (only "message" is not).
But concatenation within a category only works for sure if everything is
in dearmored form. It *might* work for some implementations if
everything is in armored form, but it definitely won't work if the
concatenated objects are a mix of armored and dearmored form.

Since concatenation is a thing that people sometimes do with these
objects, and we're not going to be able to convince /bin/cat to be
OpenPGP-armor-aware, i think we need to explicitly represent the armor
status.

> We *can* use content-encoding to denote plain base64. We can't use it to 
> denote ascii-armor, unless we define a novel content-encoding that is 
> used only for OpenPGP data. But this still doesn't address the problem 
> that "application/pgp-*" currently defaults to "armored".

I do not think we should introduce a novel content-encoding.  I'm
suggesting that if the application uses MIME and they have a need for
a 7-bit-clean encoding, they have a way to do that already, without
using OpenPGP armor.

If we have three things defined already, and they're already
armored-only, then it seems simplest to just define the other 7 to
complete the zoo.

This way, if some new top-level OpenPGP object appears (persistent
symmetric keys?) we don't have to automatically support a pointless
armored form for it as well.

    --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

wr0EARYKAG8Fgmkd6d0JEHgLhU7ZwrSWRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z
LnNlcXVvaWEtcGdwLm9yZ+iYZMA62qWbzlH9YpossMs71p6iO/iS6HkppTWpy8IK
FiEEY6wRjlsuXWbIioWneAuFTtnCtJYAAPytAQDQbz+QLXAJib/MjZHQh/QS7q3C
JKNXiuKXr6pHkSnBtAEA4utf5mX8RyxGt2M+NDccKvJ4RX49jjnCAViNfAgAyQM=
=qWx/
-----END PGP SIGNATURE-----