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). 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,
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
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,
but retaining the ability to check if they are absolutely unique or not.
Bye,
Tommaso.
[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
