Here are the answers from one of the coolkey developers ... followups to
coolkey-devel(a)redhat.com
------------------------------------------------------------------------
Subject:
[Fedora-directory-devel] coolkey information and license
From:
Andreas Jellinghaus <aj(a)dungeon.inka.de>
Date:
Wed, 27 Aug 2008 09:03:25 +0200
To:
fedora-directory-devel(a)redhat.com
To:
fedora-directory-devel(a)redhat.com
Hi,
first some question about coolkey:
is the windows CSP coolkey specific, or is it (as it looks from many
miles away) a
generic CSP to PKCS#11 bridge?
It's a geneeric PKCS #11 bridge.
> the csp code mentions Identity alliance all over the place - is this the
> ID Ally CSP now open sourced? (it worked always fine for me, so an
> open source release labed as coolkey would be great).
yes, we got permission from ID Ally to release it under GPL.
> The fedora directory server wiki page on coolkey doesn't have too many
> details on what each component exactly does / how it is implemented.
>
> For example:
> - the windows CSP: generic or tied to the coolkey pkcs#11 module?
Generic.
> - the java card applet: generic or only working on cyberflex cards?
> how is it uploaded? with gpshell? maybe include instructions for
> doing this, or refer to some tutorial?
Tied to javacard/global platform, however your mileage may
vary. I
number of cards we tested all required tweaks to the applet to get working.
> - the java card applet: what API does it implement? I guess not a
> filesystem with pkcs#15 structures, but some proprietory simple api?
No it's not a filesystem card, it's a java card.
It's currently a
modified muscle API. We'd love to add PIV and CAC as interfaces as well.
> - is the source code of the java card applet open source too? where
> can people find it?
yes, it's there on the website:
CVSROOT=:pserver:anonymous@cvs.fedora.redhat.com:/cvs/dirsec ; export
CVSROOT
cvs login
cvs checkout coolkey/applet
Build instructions are at:
http://directory.fedoraproject.org/wiki/BuildCoolKeyApplet .
> - how is the card managed with this applet? e.g. does it implement
> a single user or a security officer plus normal user combo?
> or is it flexible to do both?
Neither. It's currently managed by a back end TPS system.
We would like
to add user managed as well. The system that manages it is available at
dogtag (
http://pki.fedoraproject.org/wiki/PKI_Main_Page). The relevant
subsystems are TPS and TKS. Stand alone versions of those would be an
excellent addition (so much work, so little time).
- the windows makefile: what build environment for windows does it
expect? (oops, found the wiki page with the windows build
instructions,
thanks, solved)
- what is the job of the "cspres.dll"?
- what is the job of th "regcerts.exe"? when/how does a user need to
start it?
- does the pk11install.c work with all versions of mozilla firefox,
thunderbird and netscape? if so, it would be very interesting for
other projects with pkcs#11 modules too. what does it exactly?
(modify config file? databases? ...) is it important to have
firefox etc.
> running? or to have it not running? etc.
all current versions, as well as older mozilla and seamonkey.
Longer
term we are looking at shared database as a better solution.
- the ChangeLog file is mentioned in the spec file - thus I guess it
gets
included in the rpm? this is not needed (the file is empty)
- the coolkey.spec sets the license to LGPL which is not 100% correct
(see below)
- the coolkey.spec file uses "PKCS#11" without mentioning "RSA
Security Inc. Public-Key Cryptography Standards (PKCS)"
which could be a license violation (see below)
- the pkcs11.h file has a different license clause than the usual file.
I wonder where you got this, did RSA ever released a file with the
spelling error "In.c"?
last the license: some web sites assume the software is LGPL. but the
PKCS#11 header files used - even the copy from mozilla source - is
not, it includes the RSA disclaimour, which is similar to the BSD
advertising
clause, but worse because of its very vague formulation ("all
material" etc.).
Scute has a PKCS#11 header file written from scratch by using public
information
thus not tainted by any RSA license. opensc and a number
of other open source projects switched to using this header file
(released
> as public domain). maybe this is a viable solution for coolkey too?
I believe Mozilla cleared the Mozila copies with RSA for
distribution
under the GPL, LGPL, and the MPL. Coolkey's copies come directly from
Mozilla. 'Scratch rewrites' still technically have a problem in that
they are still derived from the PKCS #11 spec which as the same license
clause. BTW in PKCS #11 v2.3 RSA is removing offending clause! This
should free up all the various copies floating around.
bob
> (same pkcs#11 header files in coolkey and the windows/csp directory.)
yes, we prefer the Mozilla versions since we know we have
clearance for
GPL, LGPL, and MPL.
> Regards, Andreas
>
> --
> Fedora-directory-devel mailing list
> Fedora-directory-devel(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-devel