On 4/1/2011 2:08 AM, Viktor TARASOV wrote:
> Le 31/03/2011 21:28, Martin Paljak a écrit :
>> Hello,
>>
>> On Mar 31, 2011, at 20:36 , Viktor TARASOV wrote:
>>> Cardmod is promoted by Microsoft and is used (afaik) exclusively by
>>> Microsoft .
>> For the sake of terminology - the concept is called a mini(-)driver and most
>> Miicrosoft originating documentation talks about "a minidriver", not a
>> cardmod.
> Sorry, 'cardmod' should be read as 'minidriver'.
>
>
>>> In the minidriver documentation it's going about GUID, and GUID has its
>>> well known form in the world of Microsoft .
>>> As far as I've seen, the minidrivers of the card producers have also
>>> adopted this serialized form of GUID .
>>> (From my little experience with CSP I retain also this kind of key
>>> container identifier.)
>> The representation of GUID-s is not a must have. Take any random data and
>> you can format it in a fixed form unique ID (like hashing) or use something
>> else that does the work.
>>
>> One thing I personally dislike is a ultra-verbose XML with a bunch of
>> meaningless (but things that need to match) GUID-s all over the place, like
>> Wix config :). I mean if 1, 2 and 3 guarantee uniqueness in a specific
>> context, GUID-s should not be used. The fact that GUIs that autogenerate
>> such XML find it easy to toss around GUID-s for simplicity doesn't mean we
>> need to copy it.
>>
>> But that's pure demagogy. The thing is: GUID-s are supposed to be
>> machine-parsed. Like PKCS#11 URI-s. If a user needs to deal with GUID-s in
>> real life situations, something else is broken. I don't think that the
>> *user* should be given a knob to tweak the internal format of some technical
>> machine parsed field. I mean - who cares if my partition table is big or
>> little endian if it works ?
>
> These debates have little of technical substance, it concerns rather the
> 'visual effect' for the curious user eager for the details .
> But, we have made a minidriver, let it behave as minidriver .
>
>
>> I'll re-read the e-mails one more time to make sure that I've not
>> misunderstood something. We just need to make sure that whatever we
>> concatenate for the unique ID satisfy the requirements for the uniqueness of
>> the ID. Everything else is pure formatting.
I agree.
The format is not important. Its the uniqueness that counts.
This can be a problem if many cards of the same type are used
on a single machine.
The containerID from a newly inserted card is compared with
the containerID saved in the store from some previous time.
Thus the card must be able to produce the same containerID,
and be as unique as possible so there is less confusion if
two cards produce the same container ID and are used on the
same machine.
We have:
#define SC_PKCS15_MAX_ID_SIZE 255
#define SC_MAX_SERIALNR 32
The objection I have with the method chosen of taking the
sc_pkcs15_cert_info id.value concatenated with the serial number,
and truncating this to 16 bytes, may not produce unique values in
many cases. It may may drop part or all of serial and part of the
ID bytes losing most of the uniqueness.
Your suggestion of a new function to generate the string based
on the card might be needed, or some other approach to using these
two values.
I do not have a lot of examples of card to know what is typical
for the ID and serial. So I would like to hear more about supported
cards to see if this is a general problem.
If we could fill in this chart it would help show the problems and
help address the situation.
Card - type of card supported by OpenSC
ID Min Max - ranges of sc_pkcs15_cert_info id.len
Meaning - Same - the same id.value is used on every card
For example PIV Auth=1, Email=2, Encryption=3
Unique - Is a unique value in its own right.
For example, based on some value in the certificate.
UUID - Is the serial number a true UUID?
Card ID Serial
Min Max Meaning Min Max UUID?
PIV 1 1 Same 16 16 Usually no, issuer will sequence.
PIV-W7 3 3 Same 16 16 Usually no, issuer will sequence.
(PIV-W7 shows what the Microsoft mini-driver does, but they truncate the serial
number, then concatenate the id value, and have a worse problem.)
>>
>> Cheers,
>>
>> Martin
>
> Kind wishes,
> Viktor.
>
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
