It occurred to me recently that the current obsession with one pass
processing has resulted in rather an irritating side effect.
Unless I'm wrong the current implementations of PGP do not permit
businesses who want to rely on after-the-fact verification of digital
signatures to do so without much nonsense on the senders side.
As an example, suppose bob the stockbroker is accepting PGP based orders,
using PGP signature and encryption to secure and authenticate customer
security orders.
If a dispute arises, surely bob would want to be able to find and present
the actual order along with its digital signature to defend his actions,
the same way most brokerages record order calls today.
Unless I'm mistaken its currently impossible for bob to do this effectively
with PGP. He can maintain an archive all of the encrypted messages from
clients, but keyword searching of the archive is impossible. And
decrypting all the messages is likewise difficult (though I suppose filing
them by date might help). There is, as far as I can tell, no way to detach
cleartext signatures from a signed and encrypted PGP message.
Suggestions?
At 02:08 AM 7/25/98 , dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
headers is the proper one. Someone check the syntax again.
The nesting is important. For a one-pass implementation, it makes it hard
if you have to check every onepass to see if it was NESTED - see the
discussion of the nested octed in 1pass sig header packets. That is the
major headache since only nonnested signatures could be moved around
anyway. The moment the signatures are nested (i.e this signature includes
the following one-pass packet through the signature at the end), order is
critical.
Syntactically, it is similar to a do { ... } while(...); in C - the do
says to look for a while.
And if you do a onepass implementation like I do (the whole reason for
having 1pass sig headers), it works better if you can create a stack and
simply note the nesting level, then pop each context off the stack as its
corresponding signature appears.
Further, you might have to test more than one signature - keyids aren't
guarnteed to be unique.
--- reply to tzeruch - at - ceddec - dot - com ---