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

On 05/11/2025 16:14, Simon Josefsson wrote:
> Hi.  I think this document is a great initiative -- media types for many
> old protocols and applications are often under-specified, and PGP isn't
> any exception.  I'm happy to review the document.

Thanks!

> Re section 5 that introduces new media type parameters, is this
> documenting any existing deployment, or is this a purely new idea [that
> is open for discussion]?

There is no existing deployment, but at some point when we implement 
HKPv2 we'll need to make a decision about what content-type to use, and 
I'd like to do it the right way first time. ;-)

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

> text/pgp-secret-keys
> application/pgp-secret-keys
> 
> although text/* is often complicated due to i18n concerns, and I suppose
> we use application/pgp-* for armored PGP blobs already so this would be
> a strange pattern.

Yes, I think it's best to avoid text/* because ASCII armor isn't meant 
to be human-readable, any more than Base64 is in other contexts.

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

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, more wrong than defaulting a parameter to true.

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

A

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