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

Hi, Daniel.

On 18/11/2025 21:16, Daniel Kahn Gillmor wrote:
> On Mon 2025-11-17 22:23:18 +0000, Andrew Gallagher wrote:
>> I think the fundamental question here is “how many things do we need to name?”
> 
> Why is that a fundamental question?  I mean, we want to name all the
> things that people are likely to want to interoperably share.  right?

It's a fundamental question because it defines the scope of the problem. 
I want to name all the things that already exist. How useful or wanted 
each of them may be in the future is IMO a separate task.

> So let's write down the list.  if it's not too long, just make one entry
> in the list for each item, rather than an N dimensional matrix where
> each dimension can have K values ;)

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

>>> The fact that some OpenPGP tooling can ingest an armored object the same
>>> way as a non-armored object is cute: application code that knows its
>>> OpenPGP tooling has that capacity can check the non-parameterized name
>>> and ignore the parameters in that case.
>>
>> Right, but if the same media type represents both armored and
>> non-armored formats, then we’re effectively mandating that cuteness
>> into the future.
> 
> do we want to mandate this future cuteness? 

No, definitely not.

> If we can all agree that
> armored forms are kind of redundant today, given that b64 encoding is
> already well-understood and widely implemented, and the OpenPGP armored
> headers are basically an attractive nuisance, maybe having separate media
> types helps to segregate the cuteness into its own media type.

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.

>> And if we can’t use either content-encoding or parameters to denote
>> armor, we leave an important metadata detail untepresentable (within
>> an HTTP API context).
> 
> But why can't you use content-encoding if you need to b64 it?  it won't
> be formal OpenPGP ascii armor, but just let the transport layer handle
> the encoding.

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

A

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