On Fri, Sep 27, 2019 at 3:44 PM Derek Atkins <derek(_at_)ihtfp(_dot_)com> wrote:
Justus Winter <justuswinter(_at_)gmail(_dot_)com> writes:
On Wed, Sep 25, 2019 at 4:32 PM Derek Atkins <derek(_at_)ihtfp(_dot_)com>
wrote:
Why not just have multiple literal packets inside the encryption? I.e.:
ENC{ Lit1{realData} | Lit2{pad} }
Because that is not a well-formed OpenPGP message.
Neither is anything else you are currently proposing.
That is incorrect. Please do go back to my original message and
re-read it carefully.
If you're going
to extend the spec to add a new packet type you might as well extend the
spec to allow this, which is easier.
I was explicitly *not* proposing a new packet type. And I do not
believe that extending the spec is as easy as you make it seem to be,
and extending the spec doesn't help existing implementations.
And honestly many parsers (at
least the parser I wrote in 1995 which AFAIK is still in use by at least
one implementation) will actually parse this structure properly.
I bet that your parser from 1995 will correctly handle the padding
mechanism I proposed, as long as it is able to deflate compressed data
packets. Please do actually try that, I'd be very happy to get some
feedback.
Cheers,
Justus
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp