[langsec-discuss] delimited base64 file specification

Grawrock, David david.grawrock at intel.com
Wed Mar 20 16:00:00 UTC 2013

On the compression side, I agree that we shouldn't really be too worried about the size and that the complexity is not worth the gain.

The argument doesn't hold on the integrity side. One of the points of delimited base64 is to avoid weird machines and other such gotcha's. Well having the data change is a big gotcha. Passing off integrity means that NOBODY can ever trust the file. It's what we have today. Few, if any, file formats include their integrity metrics. Now I admit a bit of a bias towards trusted solutions, but I think that it is critical to make this type of definition to include integrity checks.

At a minimum, there should be a provision to include an integrity check at the end. Result of a hash maybe? That would give those who care the ability to provision their files with checks that all can validate regardless of the transport or storage mechanism. 

David Grawrock
Security Architect
503 264 3642

-----Original Message-----
From: langsec-discuss-bounces at mail.langsec.org [mailto:langsec-discuss-bounces at mail.langsec.org] On Behalf Of Michael Ossmann
Sent: Wednesday, March 20, 2013 8:38 AM
To: Felix 'FX' Lindner
Cc: langsec-discuss at mail.langsec.org
Subject: Re: [langsec-discuss] delimited base64 file specification

On Wed, Mar 20, 2013 at 04:12:42PM +0100, Felix 'FX' Lindner wrote:
> It's hard enough to get one thing right. And by the way, wouldn't the 
> compressed data form another language?

Clearly.  My point is not that I want to recommend archival/compression.
(I certainly do not want to include any such function or recommendation in the delimited base64 file format specification!)  However, files will be stored/packaged/encapsulated in various ways with various benefits and risks.  People who are concerned about the base64 expansion or who want features like integrity checking have several archive format choices available to them.  While these things may be problematic in practice, I don't have a problem with them in theory, and I consider them to be out of the scope of the file format specification.

> The cost of bandwidth and storage decreases constantly, so why bother 
> with the past when designing for the future?

You make an excellent point, but I'm afraid there will always be people with a need to push the limits.
langsec-discuss mailing list
langsec-discuss at mail.langsec.org

More information about the langsec-discuss mailing list