On 3/29/19 3:19 AM, Jon Callas wrote:
I wrote a point-by-point reply and decided that that’s not productive. I’m
going to try to cut to the chase on this, so forgive me if I have dodged an
important point. I’m happy to come back to it later.
Like some interim replies, particularly Bart Butler, I thought we had a rough
consensus and that it was approximately:
* MUST support 16KB chunks.
* SHOULD support 256K chunks, as these are common (Protonmail).
* MAY support larger up to the present very large size.
* MAY reject or error out on chunks larger than 16KB, but repeating
ourselves, SHOULD support 256K.
I think it’s also reasonable to just simplify it by making be MUST support up
to 256K. I don’t like getting rid of the SHOULD clause, thus making it be
either 16K or off in squishy land, but I wouldn’t wring my wrists, I’d merely
be a bit unhappy.
I could also get behind a hard limit of 2^30 on the grounds that that’s what
we had for partial body lengths, but I understand the comment that there are
things like multi-terabyte S3 buckets and out and out forbidding those to be
single-chunk is a bit churlish, but only a bit.
If we really want to tie a bow around everything, then define some notation
or other marker so that an implementation can mark in a key what the max
chunk size is.
How’s that?
FWIW, I think that's reasonable. It is very similar to the original
OpenPGP AEAD proposal by Brian M. Carlson, which just had "MUST support
up to 64KB chunks" and "MAY support larger chunks". That original
proposal is simpler than yours, but given that Protonmail already uses
larger chunk sizes, that's ok. From the perspective of mobile and
desktop devices, 64KB and 256KB are similarly reasonable.
There is a little bit of tension here, because any increase in the MUST
area may give trouble to constraint devices, who should be able to hold
a single chunk in memory if they are interested in non-malleability.
The difference between 16KB and 256KB can matter here. So, I guess I
understand why you introduced the SHOULD requirement, although it makes
things more complicated.
Thanks,
Marcus
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp