A note on vendor reaction speed to the e=3 problem

[Leichter, Jerry]

| > *That* is the Right Way To Do It. If there are variable parts (like
| > hash OID, perhaps), parse them out, then regenerate the signature data
| > and compare it byte-for-byte with the decrypted signature.
| 
| You know, this sort of reminds me of a problem with signatures on
| tar.gz files.  Basically, you have to keep them around so you can
| check the signature, but you can't delete them because you can't
| reconstruct the original tar file from an untarred copy because it's
| full of metadata that won't necessarily be replicated on your system.
| For example, uids and gids.  Unfortunately, cpio appears to be worse.
| From a tape backup standpoint, tar doesn't store enough (extended
| attributes, hard links, etc.) and so it appears to store both too much
| and too little at once.
VMS has for years had a simple CHECKSUM command, which had a variant,
CHECKSUM/IMAGE, applicable only to executable image files.  It knew
enough about the syntax of executables to skip over irrelevant metadata
like link date and time.  (The checksums computed weren't cryptographic
- at least the last time I used it, many years ago.  The command was
created to use in patches to provide a quick verification that the file
being patched was "the right one".)  I've always found it surprising
that no one seems to have developed similar tools for Unix - with the
Gnu libraries for portable access to object/ executable files, it could
be done relatively easily.

The general issue here is how to checksum the information, rather than
the raw data.  XML signatures have horrendous problems with this
because XML has many equivalent ways to "say the same thing", and
there is enough information in an XML file for intermediate nodes to
be able to change representation without changing semantics - and for
various reasons, they do so.  (The XML guys try to deal with this by
defining a "canonical representation" for data, and sign *that*.
Unfortunately, there are two competing standards for the "canonical
representation.")
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com