> > ------------------------------------------------------------------------ > > Subject: > [Fedora-directory-devel] coolkey information and license > From: > Andreas Jellinghaus <aj@xxxxxxxxxxxxxxx> > Date: > Wed, 27 Aug 2008 09:03:25 +0200 > To: > fedora-directory-devel@xxxxxxxxxx > > To: > fedora-directory-devel@xxxxxxxxxx > > > 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@xxxxxxxxxxxxxxxxxxxxx:/cvs/dirsec ; export CVSROOT
cvs login cvs checkout coolkey/appletBuild 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-devel>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
