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

On 05/11/2025 19:05, Simon Josefsson wrote:
> Andrew Gallagher <[email protected]> writes:
>
> 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.
With 20-20 hindsight PGP/MIME is really oddly designed, because MIME 
defines message subpart delimiters and metadata headers, and the 
non-base64 decoration of ASCII armor is... message subpart delimiters 
and metadata headers (plus a metadata footer). It makes sense in a 
PEM-like context such as clearsigned messages, so ASCII armor is 
probably better thought of as an alternative protocol to MIME, not a 
content type within MIME.

There's no need for the PEM-like decoration in PGP/MIME at all, except 
that because PGP command line tools automatically generate it and expect 
it, it's easier for the MUA to stuff it all into the multipart verbatim 
and not have to re-parse. So you get the MIME delimiters and inside that 
the (redundant) armor delimiters. If we were doing it again, we would 
apply Content-Encoding: Base64 to the raw OpenPGP bytestream. But it's 
too late now.

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

No, there's no spec and definitely no interop yet. I would like to do it 
at some point, but this draft is not the place.

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

Sure, we could specify it any way we want. But I'd still like it to be 
intuitive, and not spread the type vs encoding confusion to new pastures...

> 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.
Are you aware of any prior art that we could use for refererence? 
Particularly any cases where legacy media types had to be grandfathered 
into a more general scheme of types?

A

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