Le 30/03/2011 20:16, Douglas E. Engert a écrit :
> On 3/30/2011 11:38 AM, Viktor TARASOV wrote:
>> Le 28/03/2011 18:29, Douglas E. Engert a écrit :
>>> On 3/28/2011 7:06 AM, Viktor TARASOV wrote:
>>>> Le 25/03/2011 20:51, Douglas E. Engert a écrit :
>> ...
>>>>> Do we really need the GUID format? "{" and "}" and 4 "-" take up 6
>>>>> characters that could be used for more serial number and ID.
>>>> Not really.
>>>> I'm get used to this GUID format in the Windows world.
>>>> and so it seemed to me quite natural to use it for the Windows containers.
>>> The { - - - - } characters dont add any uniqueness, but do take 6 characters
>>> of the 39. leaving only 32, to stuff a serial number and ID.
>> What would you say if we accept the 'classic' GUID form as a default one,
>> and give the possibility to define its own format to the pkcs15 card driver ?
> This is not a card driver issue. Its a cardmod issue. This is only used by the
> cardmod which wants a unique string for each cert.

Cardmod is promoted by Microsoft and is used (afaik) exclusively by Microsoft .
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.)

That's why it seemed to me quite natural to give to the card driver owner
the possibility to have the standard GUID form.

> I would rather see an approach if you can not combine the serial number and 
> the
> ID into a string that will fit in 39 characters, then drop the "{", "}" and 4 
> "-"
> and see if that will fit.

Sure 19 bytes for the unique ID is better then 16, but is it so crucial ?

Anyway it's not always possible to put entire cert ID into 39 characters.
As an example the 'intrinsic' identifiers calculated like SHA1(modulus).

> The intent is to have a unique string for each certificate that can
> be obtained from the card and the certificate, and the same card and cert
> will always return the same value.

As far as I understood your explanations
'cert ID' for Microsoft and for PIV is in fact a certificate role (tree bytes 
of tag).
In this case the unique ID is obtained not for 'serial & cert' but for 'serial 
& cert-role'.

In OpenSC/PKCS#15 we have (can have) the unique ID derived from the certificate 
itself (ex. SHA1(modulus)).
For me it's fine as a binary source of GUID.

> By using the serial number and dropping some of the trailing bytes,
> there is a good chance that the string will not be unique and could cause
> issues if many cards are used on the same machine.
>
> In the OpenSC PIV case, the last byte is dropped. which means 256 
> consecutively
> issued cards would have the same containerID. (Windows 7 built-in driver 
> drops 3
> bytes from the serial number, and thus 16Million cards may have the same
> containerID!)
If Windows do like this, it means that the other 13 bytes of the serial number 
are really random .


> With 16 byte serial numbers, there is not room to add the cert ID to this.
I guess the intrinsic ID can be used without serial number.


> If you want to drop some bytes from a serial number, drop then from the
> first bytes of the  serial number, not the last. This would have a better
> chance of not having problems.
GemaltoAccess cards have 'running counter' in the middle of its serial number .


> As side question is how big are serial numbers and how are they generated
> on other cards?

GUID is not always the same as serial.

Serial length can be different .
Oberthur used the 4 bytes of sequential 'serial-number' from CPLC data .
For some Gemalto cards it's the 8 bytes of 
'serial-number,batch-identifier,module-fabricator' from the same CPLC data .
Other cards, like IAS/ECC, use PAN format: 
industry+country+issuer+serial-number, 10 bytes in total .
Some uses partial result of MD5 over the part of 'cardid' ...


> Another approach is to use md5 or sha-1 hash of the serial number and the 
> cert ID
> so as to keep as much uniqueness as possible as defined here:
>    http://en.wikipedia.org/wiki/Universally_unique_identifier
>
>    http://msdn.microsoft.com/en-us/library/aa373931(v=vs.85).aspx
>
>    GUIDs are the Microsoft implementation of the distributed computing 
> environment
>    (DCE) universally unique identifier ( UUID).
>
> Note that the cardmod is not asked to return a GUID  but rather to return
> a string that looks like a GUID.


I still think that we should give a possibility of the standard GUID, default 
or not, to the driver owner .

-- 
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

Reply via email to