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

Simon Josefsson <[email protected]> Wed, 05 Nov 2025 20:05:06 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Andrew Gallagher <[email protected]> writes:

>> What do you think about not doing parametrization but instead define two
>> separate self-contained media types for each format?  For example:
>> application/pgp-secret-keys
>> application/pgp-secret-keys-unarmored
>
> ASCII armor falls in a strange place somewhere between a type and an
> encoding. It's *almost* a Base64 encoding of the "raw" OpenPGP media
> type, but because of the armor headers you can't roundtrip it.

I'd argue that from a MIME media type point of view, these are two
different kind of data formats even if they carry (almost) the same
information.

The ASCII armor used in PGP is PGP-specific (e.g., the CRC) and not used
by anything else, IIRC.  You could see PGP armor as a generic encoding
to be applicable for any kind of data, but I think that is stretching
the purpose because PGP armoring was never intended to encode non-PGP
stuff.

>> My experience with parametrized media types is that it creates
>> implementation complexity and I've rarely seen this paramtrization
>> contribute to anything over having two separate media types for each
>> specific format.
>> I may be missing some context here, maybe using a parameter is the
>> only
>> feasible approach because of some concern that I'm not seeing.
>
> Another thing to consider is the future possibility of "+json" suffix
> types for OpenPGP material - hockeypuck already uses such an encoding
> internally, and I know Sequoia were also working on it.

I think JSON is just a third data format from the point of view of MIME
media types.

Couldn't your document specify the JSON media types too?  Then you can
control the definition and meaning of them.  Is there a PGP JSON spec to
reference?

> If armor is denoted by a parameter, then any +json suffix would apply
> to the underlying type, which feels to me like the most natural place
> to insert it in the stack. By contrast, if armor-ness is hardcoded in
> the definition of the type, then you would have to use
> application/pgp-keys-unarmored+json, because application/pgp-keys+json
> would imply a JSON representation of an armored certificate block -
> this feels really wrong to me

Why would it be wrong?  The +json isn't any magic pattern, is it?  There
has to be a specification describing what foo+json means, and you can
make that mean anything you want.

> I don't think there is any solution to this that is both backwards
> compatible and elegant, so we're really trying to minimise badness...

Yes, probably, but I think breaking RFC 3156 media types ought to be
avoided (if possible), so I'm hoping these media types will be a strict
superset of the old ones.  My experience with media type parameters
suggests it is better to avoid them if there is no strong reason to use
them.  Often parameters are used for non-critical aspects that does not
influence how you would parse the data, but that is not the case here.

/Simon

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 1.2 KB)