Anders Rundgren wrote:
> > your third question I did not understand.
>
> ATRs identify the card's type, right?
Sort of, it has characteristics of the card. Google for:
parsing an ATR.
So if you don't want
> to write a card profile but have full freedom on the token side
> the token would need to use an ATR that belongs to some other
> vendor or community.
>
> Does all FIPS201 cards share an ATR or need middleware to recognize
> different vendors?
"FIPS PUB 201-1: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION
Personal Identity Verification (PIV)
of
Federal Employees and Contractors"
The OpenSC PIV driver is for the FIPS201 cards.
http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV
So I am not sure what your are tring to do.
NIST 800-73 states that the different Application IDs.
See the Opensc src/libopensc/card-piv.c and look for piv_aids[].
The card-piv will do a piv_select_aid to see if the card has the
PIV application as the default.
The various vendors have different ATRs (The application ID may be
in the ATR too, for example: an Obether card has:
3b:db:96:00:81:b1:fe:45:1f:03:80:f9:a0:00:00:03:08:00:00:10:00:18
^^^^^^^^^^^^^^^^^^^^^^^^^^
P.S. I am getting ready to update the driver to NIST 800-73-3.
>
> Assuming the above is not completely BS (may not be the case...),
> how about exchanging non-standard objects as well over the very same
> CCID+PCSC interface?
>
> Anders
>
> Jan Just Keijser wrote:
>> Hi Anders,
>>
>> Anders Rundgren wrote:
>>> If you wanted to provide a USB PKI token that would give the user maximum
>>> flexibility it seems that the device should support CCID.
>>>
>>> 1. As I understand,CCID only provides the basic communication and does
>>> not
>>> address higher level issues such as PKI, right?
>>>
>>> 2. Would a token that emulates FIPS201 and CCID be usable in most
>>> systems as is or is there another emulation that would be better?
>>>
>>> 3. You would need to "hijack" somebody else ATR in order to emulate
>>> in a (for the user) hassle-free way?
>>>
>>> 4. Other question: CCID allows you to exchange arbitrary data between
>>> the token and the host, right?
>>>
>>>
>> most of this information can easily be found using
>> YourFavouriteSearchEngine, e.g.
>>
>> http://www.smartcardalliance.org/newsletter/february_2005/feature_0205.html
>>
>> CCID:
>> The Chip Card Interface Device (CCID) specification is an approach to
>> smart card reader communication that is gaining in popularity. The
>> specification defines a standard communication protocol for smart card
>> readers that connect to a computer via USB, allowing the same host-side
>> driver to communicate with any CCID-compliant smart card reader.
>> Microsoft provides a CCID driver through the Windows Update system. All
>> new smart card reader deployments should seriously consider using
>> CCID-compliant readers, both to reduce driver installation issues and to
>> ensure that, in the future, the installed smart card readers can be
>> easily and transparently replaced with any other CCID-compliant reader.
>>
>> PC/SC:
>> The basic technology for communication between personal computers and
>> smart cards is PC/SC, defined by the PC/SC Workgroup
>> (www.pcscworkgroup.com). PC/SC defines an application program interface
>> (API) that provides software developers with a standard set of tools for
>> managing smart card readers and communicating with readers and cards.
>> The PC/SC interface defines standard interfaces for a variety of smart
>> card related-operations. The most common are:
>>
>> * Enumerating and describing attached smart card readers
>> * Requesting information about card and reader states
>> * Exchanging commands with cards
>>
>> Microsoft has implemented the PC/SC API as part of the Win32® API, which
>> is the fundamental toolset for building Windows applications. Microsoft
>> is also a member of the PC/SC Workgroup.
>>
>>
>> your third question I did not understand.
>>
>> cheers,
>>
>> JJK
>>
>>
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
--
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
