Based on the thread supprot, Im doing better, using what turns out to be an
IBM JCOP31 engineering sample card (not a JCOP21, as previously inaccurately
reported).
Using the profile manager, I can perform remote loading of the applet load
file, using the JCOP21 load option. I had to disable my symantec commodity,
client-side stateful firewall, however, to communicate with the remote
server.
Similarly, using the profile manager, I can perform remote installation of
an applet, using the JCOP21 reinstall option. This nicely appears to detect
the existing load file, in the GP registry. One can easily imagine there
being multiple profiles (for a card name), creating multiple instances of
the applet, and thus multiple object stores, each with their own default
acls and principals.
Using Muscletool-IDA, I performed a conventional format operation, citing
the 3030303030303030 transport code. For object size, I used 2048, suited to
the JCOP31 apparent free resources.
Using File->Get Digital ID(VeriSign TM), the server apparently issued me a
self signed cert, which appears in the IDAlly tool. A glance at the APDU
log on my system show a BER-encoded (cert) stream is indeed being written.
Using the view option, windows reports that "this CA root cert"... has not
been installed into one of the root stores. On inspecting the cert, it has
only end-entity authority, not CA authority. Regardless of this fact, if one
uses the "let windows select the cert store into which to insert the cert",
it appears to be treated post-install as a CAcert, and windows indeed warns
one that now cert's issued by the "CA" will automatically be recognized.
Using regedit, I confirmed that the cert currently exists in (in my SID):
HKEY_USERS\S-1-5-21-1830548265-4081794962-2048613730-1006\Software\Microsoft\SystemCertificates\Root\Certificates\16BBF457DEA5A24F747DE32F4C8D973BB4A1F651
Using Outlook, the Tools->Options->Security->Settings allows one to bind
this cert to signing and encryption privileges for S/MIME v3. Depennding on
the account I use, the binding options change: encryption cert was
automatically chosen in one (and all alg.options were greyed out) , and in
another I could change the encryption algorithm.
On attempting to send a signed message, using my normal hotmail transport
provider, I could not get passed a dialog which said "error in underlying
security system." (No pin was ever demanded.)
So, im summary, good progress.
I think we need a simpler test case for signing, using the CSP and the
self-signed cert, than outlook. We need to seperate the fun of making
outlook and PKI work, versus show a simple working unit test of signing,
with the CSP.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
