----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Friday, March 11, 2005 11:00 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
(3 comment) Perhaps we should try and determine why that distinction was made: i.e. why one role present on the host computer can access data files, but the cardholder cannot so access their contents, by policy formulation. What's in those files? one naturally asks.
(3 discussion) We know that the files subject to the policy comment (3 comment) distinguish the TL and the V of BER-encoder TLVs. I.e. the tags and lengths of the PDV stream are in one file, under one TDEA key obligation, and the Vs are in another, under a distinct TDEA presentment obligation. We also know, that there can be multiple[le instances of the file manager applet, each with different TDEA key presentment(s), requirements. This suggests that there can be more than instance of the AO, surely? We should investigate the background to this, to apply to musclecards, if appropriate.
In 4.5.2 of the cited PDF, we learn that each PKI applet instance, in the ActiveCard policy world, holds one and only one RSA key; there is a GC applet instance in tow, which presumably holds the associated certificate. We know each GC instance has two files, with separate XAUT access rules, and they split TLs from Vs.
One basis for separating the TL(s) a from the V(s) of the cert stream would be to ease loading the parameters into the Java API. Rather than walk the BER stream, which most folks have difficulty doing because of BERs many rule variants) the applet code can now have preconfigured offsets in the code, for the cert fields it needs to access - to configure the ICC's crypto co-processor.. It can walk the list of TLs, to the required index, adding up lengths and len(TL) as it goes, to located the index of the V in the corresponding V file.
Presumably, a XAUT-enabled application, such as an authorized SSL engine, that needed to present the certificate to its peer for creating its own security association, would reconstruct the PDV stream of the cert from the two views of the object.
If we were to be consistent with the card management/PKI systems for ActiveCard, we would need to have the same basic policy re files stored in the musclecard objectstore. Rather than, as per PKCS#11 today, storing a list of certs in the user's cert hierarchy each in a well-named object files, as a complete PDV, each cert would get two files.
Now, why bother will all this (if its even correct), is my final question. What did it buy them, and what would it buy us, if we adopted the practice in the PKCS#11 and opensc drivers?
Peter. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
