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

Hi, Daniel.

On 19/11/2025 16:01, Daniel Kahn Gillmor wrote:
> 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.

The ABNF also includes "compressed message" and "literal message" as 
distinct options, so I fear this is a can of worms. And that's before we 
get into the combinatorics of message nesting.

On the other hand, we might need a distinct type for cleartext-signed 
messages. We would only need one variant though - there's no such thing 
as a "raw" cleartext-signed message, as it is only defined for armor 
(and is the reason armor exists in the first place).

> (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)

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

This is a good point - although both the "separate types" and 
"parameterised types" models would do this in principle.

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

I agree.

A

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