Re: [openpgp] Version 1 image header bits that MUST be 0

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2023-04-19 18:33:03 -0400, Paul Wouters wrote:
> Current text states:
>
>  	The fourth octet of a version 1 image header designates the encoding format of the image.
>  	The only currently defined encoding format is the value 1 to indicate JPEG.
>  	Image format types 100 through 110 are reserved for private or experimental use.
>  	The rest of the version 1 image header is made up of 12 reserved octets, all of which MUST be set to 0.
>
> Where possibly, I'd like to extend claims of "MUST be x" with "and MUST
> be ignored if not x". In general, this allows forward compatibility
> without old clients dying because of reserved bits now being in use.
>
> I just wanted to run this by the WG to ensure this can be done here as
> well. I don't think this would be a security issue, unless we would
> want the entire image to fail upon seeing a single unknown bit.

I have no data to show that making this change would be a problem, but i
also don't know how well it would work in practice.  Do you have data
that suggests existing implementations wouldn't choke on this?  I don't
see anything in the interoperability test suite that indicates what
would happen if these bits of an image attribute subpacket are actually
set.  For example, if including such an image attribute in a certificate
would cause an existing implementation to be unable to encrypt to that
cert, or to verify a signature from it, that would be bad news.

As an alternate approach, i expect it would be more straightforward to
deprecate these bits (and much of this flexibility) entirely.  The root
of the issue is that there is too much unused extensibility here.  A
simplifying approach might be:

 - drop the Image Attribute Version registry
 
 - drop the Image Attribute Encoding Format registry
 
 - redefine the "1" row of the User Attribute type registry to be "JPEG"
   (and define that format with a wire image that matches the current
   common use)

Then we still have a lot of flexibility (maybe even too much still: user
attribute packets can still have an arbitrary sequence of attribute
subpackets), but we've moved the flexibility into a single table that
describes those subpackets, the User Attribute type registry.  "Have one
joint and keep it well-oiled" is the way i've heard this philosophy
expressed elsewhere in the IETF.

At any rate, i don't think my simplifying proposal above is in-scope for
the current WG charter, but maybe a future incarnation of the WG can
consider it.  I've opened
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/167 to track it.

            --dkg