Anders Rundgren wrote:
> Jean-Michel Pouré - GOOZE wrote:
>> On Mon, 2010-04-19 at 06:51 +0200, Anders Rundgren wrote:
>>> I'm still quite uncertain on what to emulate in order to get a
>>> middleware-free token. CCID yes, but above that level things
>>> looks much more unclear.
>> Before working on a new token, we recommend that you use OpenSC and
>> learn about X.509 standards and authentication tools. There is no need
>> to reinvent the wheel if everything is already there.
>
> I work with X.509 on a daily basis so that's not a problem. Using OpenSC
> may be the solution but I still have to investigate alternatives such
> as emulating PIV/FIPS201 tokens since (as the subject line alludes)
Others have also seen that the PIV standards might work in other the the US
Government. The PIV/FIPS201 was designed to have government agencies
issue millions of cards, with photo, fingerprints and other objects digitally
signed on the card as well the process used to vet the individuals.
Search for the terms: "PIV Interoperable PIV compatible"
Interoperable (PIV-I) implies cards issued by others but could be trusted by
government agencies to some extent. Compatible (PIV-C) implies the card
works work with readers and drivers but says nothing about vetting or
what subset of objects are needed on the card.
When you say emulating PIV/FIPS201 I would consider that PIV-C. I think
you are saying you want to create your own cards with an applet that
responds to the commands defined in NIST 800-73-2. This might be helpful:
>> We are happy to release some open source PIV-II like applets produced
>> by Michigan State University Computer Science Students under the
>> direction of Identity Alliance. They can be downloaded under a BSD
>> license at the following link:
>>
>> http://www.identityalliance.com/downloads/PIV-II-MSU.zip
>>
>> There are some subtle differences between these applets and the final
>> PIV specification as they were working on this early in the semester
>> while PIV-II was still in transition. Nevertheless you will hopefully
>> find these to be of use as you are looking at PIV-II implementations ....
>>
> I'm interested getting away from middleware.
As are any others. Windows 7 has a PIV driver that I have tried with login.
All that is needed on the card is a auth key, cert and a CHUID. The key was
generated on the card, and the cert was issued by our Windows Enterprise CA
good for login, The CHUID object was made up and not signed. So this would be
considered a PIV-C card, accepted locally. Windows 7 (and XP with other drivers)
and the 2003/2008 AD controllers are also setup to use government issued PIV
cards as well.
But the big question is who will trust your emulated PIV/FIPS201 tokens
with your applet?
> That every EU eID
> card needs some specific feature in some of the layers is an
> indication that at least PKCS #15 is unlikely to be the "my" way.
>
> Regarding what is ready and what's not, it is entirely clear that
> card initialization is NOT READY for mass-market adoption.
This comes down to what Martin said:
> a) centralized - like eID rollouts, where the actual RA has requirements
other than purely technical
> b) "home user" - like people using pkcs15-init to store "their" keys
> a) has already solutions that work and don't really depend on what is
available on the "edge" of the network (client computers) for initialization
part
> b) works with whatever is possible with the card at hand, like OpenSC.
I am interested in (a) Where centralized is both the US government, and our
local Windows Domain for those users who don't have the government issued cards.
In either caes we would want "approved" cards, and a robust card management
system.
> OpenSC
> does currently not support end-to-end security initialization so IMO
> it is not suitable as is and I also believe that the symmetric key
> card solutions that you can buy are useless on the Internet.
>
>> Kind regards,
>
> U2!
>
> Anders
> _______________________________________________
> 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
