Re: [openpgp] padding packet as first packet in a packet sequence

[Ángel <[e-mail]>]

On 2022-12-01 at 11:23 +0100, Neal H. Walfield wrote:
> I think the draft should be changed to forbid the padding packet from
> being the first packet in a packet sequence.  Something like:
> 
>   the padding packet MUST NOT occur as the first packet in a packet
>   sequence.

Just no. What if the point where it makes sense to have the padding is
*precisely* at the beginning?
For example, a keyserver that encrypted the connection with RC4 might
want to add a random padding at the beginning of the content to counter
the cipher bias. (Had this packet existed then)

As we don't know what will be needed in the future, I think the current
text («An implementation MUST be able to process padding packets
anywhere else in an OpenPGP stream, so that future revisions of this
document may specify further locations for padding.») is the right one.


> Alternative, I propose fixing the first few (4? 8?) bytes of the
> padding packet to some value specified by the standard.

However, I am fine with the goal of keeping the files libmgic-friendly. 
I think the best aproach would be to say that if the padding packet is
going to be added at the beginning it SHOULD be prepended by a Marker
packet.

The Marker packet clearly points out to the type of content, it is
already defined (thus old libmagic versions should understand it) and
it doesn't require adding extra bytes to the padding packet unneeded in
other locations.