Re: [openpgp] Modernizing the OpenPGP Format draft

ianG <iang@iang.org> Mon, 02 November 2015 23:40 UTC

To: openpgp@ietf.org
References: <CALq76CJiL6r1RFvcW3P5UE2buH181bCMsTR4MCbQNVDuJotTfg@mail.gmail.com> <5637DE40.4080109@iang.org> <64F3E0AF-DAAE-4EBD-8568-8C387A297001@gmail.com>
From: ianG <iang@iang.org>
Message-ID: <5637F46B.2010200@iang.org>
Date: Mon, 02 Nov 2015 23:40:27 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <64F3E0AF-DAAE-4EBD-8568-8C387A297001@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/B7KtaGC26iQGXvvecmSZMl5o2lM>
Subject: Re: [openpgp] Modernizing the OpenPGP Format draft
Precedence: list

On 2/11/2015 23:30 pm, Bryan Ford wrote:

>> 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is likely to signal which tool was used, unless we can convince other packages to do that (pretty unlikely).
>
> Great.  My hope is that if we were to specify the padding/bucket-expansion mechanism in a separate document in an application-neutral way and with the relevant theory spelled out, we might eventually be able to convince other applications to use or migrate to such a scheme too.  But that would be a long-term goal, and whether or not it happens it would have to start somewhere, and to me OpenPGP seems like a reasonable place for it to start. ;)


Right that's what I was thinking - write a separate draft listing an 
algorithm to determine next padded length to aim for.

I'd actually suggest slightly table driven:

512
1024
1500 (ethernet or the old UDP packet length)
4096
16k
64k (jumbo packet)
...




iang

[openpgp] Modernizing the OpenPGP Format draft Bryan Ford
Re: [openpgp] Modernizing the OpenPGP Format draft ianG
Re: [openpgp] Modernizing the OpenPGP Format draft Bryan Ford
Re: [openpgp] Modernizing the OpenPGP Format draft ianG