[ts-gen] Test.rb

R P Herrold herrold at owlriver.com
Thu Jul 8 09:57:09 EDT 2010

On Wed, 7 Jul 2010, Bill Pippin wrote:

> In addition, if you want to add to the code in the release, 
> please discuss guidelines for code submission with Russ.

I do not want to be coy here, as the 'hurtle' needed for code 
to be considered for formal inclusion to the shim have minimal 
 	1. be under a 'GPLv3 or later' license
 	2. have on file an 'assignment of copyright' to 'trading-shim,

see: http://www.trading-shim.com/copyright/

This link has been here (looking at the timestamp) since 2006, 
with minor wordsmithing since then

Ask for an assignment URL if interested (I am re-working it, 
based on some changes in intellectual property and e-commerce 
law to be more accessible [of which more below] and less 
restrictive).  It seems that the methods to perform an 
electronic 'signing' are easier than they were in days past, 
after the necessities of an 'authentication' step.

Particularly I want to commend to consideration the identity 
verification (viz., 'authentication of identity) services of:

and its owner, Eddy Nigg, and am figuring out how to graft 
accepting his personal identity certificates.  These 
certiticates are similar to pass-phrase protected keypairs, 
countersigned by a third-party CA [here, startssl].  They are 
held in the 'security device store of a web browser or 
exported to a PKCS12 file for backup of transport to another 
certificate store in, say, another browser.  When to be used, 
they are locally 'unlocked' for use to acess the 'private key' 
part which may be validated against time based, and also 
CA maintained revocation list management

Once unlocked, that credential can assert to the counterparty 
its 'fingerprint', serial, expiration and confirming CA during 
the D-H key exchange phase, and may be remotely validated for 
validity and a countersign by a known and trusted CA.  Then 
the two parties to the connection can proceed to a temporary 
session key for establishing a SSL protected connection 
between two known and authenticated (by a third-party CA) 
parties, and be comfortable that a 'Man in the Middle' is not 
immediately able to 'see' or tamper with the content [One must 
assume with endless time and resources, that all possible 
interpertations of the conversation with this functional 'one 
time password' from the D-H negotiation, may be 'broken' ... 
but not soon, if ever]

Tricky stuff, and I want to get it right, and document it into 
a security policy and implementatation outline, so I can then 
forget about the touchy details

-- Russ herrold

More information about the ts-general mailing list