Tommaso Cucinotta wrote: > Karsten Ohme wrote: > >> But for the CardEdge applet this does bot matter, this is only used for >> >> Unix libraries to detect if they are compatible with each other. So, >> 1.0.1 is a beautiful number and does fit in the above scheme. >> >> Your above scheme would say >> So 1.10.0 would be the result. >> >> > Actually, any number is usually reset to 0 as soon as some other number > on the left is incremented, > so I would propose 1.0.0 to underline that some internals changed. I'm > sure David loves tagging > the Applet to 1.x.x because this gives people the feeling of a stable > software component, as opposed > to 0.9.11 which recalls something in experimentation. Please, note that > the Applet > version is not important at all for compatibility issues, because the > only thing that is important is the > *protocol version*, as output by the GetStatus APDU. On the basis of > this version, the host-side > plugin should decide what set of APDUs to use to talk to the card (if > it's a new plugin), or to > not talk to the card (if it's an old plugin and sees an increment in the > leftmost number).
The old MCardPlugin does not care for the protocol version. But the applet recognizes form the expected response size, which version is talking from the client side. > So, the > real question here is: what is the new protocol version, that could be > reformulated as "do the old > MuscleCard plugin APDUs still work the same ?". Current document [1] is > versioned as 1.2.1, Yes. You should also be able to talk from old MuscleCard plug-ins to the applet. I always (?) checked the expected response length and responded accordingly. > thus a Yes would imply 1.3.0, a No would imply 2.0.0. And I would like > to update the protocol > specification reflecting the new APDUs. Actually, I can't remember if > the Applet is really compliant > with [1] or if it has deviated from it in the last four years. > >> What is the difference between the usual ACL read parameter and the read >> >> only flag? At the moment 0xFFFF 0x0020 0x0020 would mean that it cannot >> be read (exported) (0xFFFF) and only used (0x0020) and deleted (0x0020) >> by PIN#1. Please explain. >> >> > The difference is quite important: if the key were injected from the > outside world with the Read > ACW inhibited, then an outsider could potentially have that same key. > If, instead, we added the OK. Got it. So I would proposed a bit mask (a short) and one bit means that the key was generated on the card. (Makes such a bit mask also sense for objects?) What other flags could it be interesting for such a bit mask?. It is reported with a ListKeys command depending on the expected length it is reported or not. > information that the key is a private key of a keypair that was > generated on the card with Read > ACW inhibited, then we would be sure that the card is the only entity > that knows the key. This > flag could be checked by a software before trusting that key or before > granting auhtorizations. > I know, I could write a modified Applet that cheats on that flag and > always says "never exported". > So, in order to have a CA that has absolute certainty of the > non-cloneability of the private keys, > I (CA) would at least need to control the process of card format. > Though, I could inject into the > Applet a generic authentication key, leaving to the user the ability to > self-generate keys by himself, I do not get this point. What is the job of the generic authentication key? > but retaining the ability to check if they are absolutely unique or not. > > Bye, > > Tommaso. Bye, Karsten > > [1] http://www.musclecard.com/musclecard/files/mcardprot-1.2.1.pdf > -- > Tommaso Cucinotta, Computer Engineer PhD > Scuola Superiore Sant'Anna, Pisa, Italy > Tel +39 050 883 093, Fax +39 050 883 452 > http://feanor.sssup.it/~tommaso > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
