From: Mike C. <tu...@gm...> - 2008-06-10 19:45:48
|
I agree with your points. As far as I can see, the checksum within the mzML file is not good for anything other than as an additional check that (say) Windows hasn't flipped any bits in the file. Arguably, this kind of checksumming is barely worth doing, unless you're also checksumming the other parts of the system regularly. Who among us periodically checksums our instrument software or configuration files, for example? If you're concerned about instrument operators faking results, it seems like the only meaningful bar would be to have the instrument software cryptographically sign the result file. This would entail all kinds of key management problems that would rule this out in practice (I would think). If you're concerned about downstream people faking the results, my thought would be that you'd checksum (SHA1, etc.) the file at creation or "publication" (the point at which others have access to the file), and then publish that checksum in a "read only" location. As you say, this is pretty much the method used by thousands currently for file verification. If you already have a decent backup regime, just backing up the checksums might qualify. Or you could publish a grand-checksum in the newspaper occasionally, or whatever. Note, though, that for these latter scenarios you specifically *must ignore* the checksum within the file itself, as it is (as you and Jim say) not trustworthy. Rather, the checksum must be recalculated. I'm not familiar with 21 CFR Part 11, but it would seem that the mzML file itself ought to simply include all of the useful details about what it contains. Any further audit trail should happen outside of mzML, though--once the file comes off of the instrument, it should never change, in my opinion. Mike |