Le 01/04/2011 17:23, Douglas E. Engert a écrit : > > 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. IAS/ECC 20 20 Unique 10 10 there is no UUID RutokenECP 20 20 Unique 8 8 there is no UUID AuthentIC 20 20 Unique 4 4 there is no UUID Oberthur 20 20 Unique 4 4 there is no UUID WestCOS* 20 20 Unique 8 8 there is no UUID * if it used default pkcs15.profile settings
> (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.) Why do you think they truncate the serial, and not the 'cardid' ? Can you compare CP_CARD_GUID and CP_CARD_SERIAL_NO properties returned by PIV-W7 ? Minidriver compatible card must have (or emulate) the 'cardid' file. 'Serial number' is optional in the minidriver specification . The 'cardid' file contains the 16 bytes of GUID. According to wikipedia a GUID has at least 15.25 pseudo-random bytes . PIV-W7 replaces 3 bytes by the cert-role tags to construct the UID of key-container . There are still 12.25 random bytes in the key-container identifier. Do you think we need to consider seriously the probability of collision for the very limited number of the cards present in system ? And for that purpose to break the commonly used GUID format ? -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
