RE: OpenPGP Card
David Picon Alvarez wrote: > Options 4 and 5 are much preferable to option 0 (GnuPG implements PKCS#11 and people use non-free drivers) and not implementing > PKCS#11 might put some optimizing pressure in this direction. Again, you are wrong. There is not point in writing a low level code in each application to support each card it is NxN situation, not wise. Had you written that if vendors would have published their low-level interface, which is expected to be different since every one offers a different set of features, and someone would have written a GPLed PKCS#11 provider for each card, I could almost agree with you that this is the right way to go... Why almost? Since the software you are communicating with, which runs on the smartcard device, is proprietary... And I am completely not agree with you that there is a difference between sending proprietary APDUs or using an API. I think you reach the same state no matter how you look on it. I am still waiting for FSF response, does anyone knows someone there how can help in resolving this issue? Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP global directory cruft in keyservers
On Tue, Sep 06, 2005 at 01:36:37PM -0500, John Clizbe wrote: > Kurt Fitzner wrote: > > This isn't GnuPG-related really, but recently downloaded my own public > > key from a keyserver and found on it about a billion of those silly PGP > > global directory signatures on it. Either someone has been downloading > > my key from PGP a whole bunch and then submitting it to keyservers, or > > the mainstream keyservers are syncing with PGP's global directory. > > > > I'm wondering if this is a widespread problem. Have other people > > noticed this with their keys? > > > > I am now very sorry I went throught that email process with PGP. I'm > > actually hoping this is a widespread problem so that keyserver operators > > will start deleting those stupid signatures. If not, I am stuck with my > > key having a billion useless signatures on it. > > > > I'm so glad there is GnuPG with no corporate agenda!!! > > Thanks Werner et al. > > gpg --edit-key clean > > And setting the clean-sigs and clean-uids options on import-options, > export-options, and keyserver-options are our only defense until then. > > Like you, I refreshed from a SKS server and found 120 new sigs on my key, > ALL PGP Universal Keyserver. To my knowledge, the PGP GD doesn't sync with anyone. It would be interesting to know how/where these signatures are leaking into the keyserver net. > Over on PGP-Basics, someone asked what was the purpose of the 'clean' > command in GnuPG. A good friend of mine replied, "It undoes the damage > caused by the PGP Universal key server." > > Like you, I regret ever submitting my key to that nightmare. I ignored all > the renewal emails. > > I can't say if the PGP signatures were always the problem, but importing my > full keyring to clean it in the process reduced a 750 key ring from ~8MB to > ~6MB, just under 1/3 (32%) reduction. > > Maybe --clean-keys could be added as a command to GnuPG, like --check-sigs. Do you think this is that useful? I had expected people to treat clean-* as a "set it and forget it" feature and let GnuPG handle the keyring. Note that if clean-* is set, doing a --refresh-keys, as many people do every now and then, effectively runs clean on each key. > Perhaps autocleaning keys is something the SKS keyserver folks will > introduce. They seem to have the only active development taking place. Would be difficult to do in SKS. You need to be able to verify signatures (so cleaning doesn't remove the wrong signature), and right now SKS doesn't verify signatures. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Alon, First, I might have written to you directly instead of to the list. If so I'm sorry, I screwed up with my mail agent. > There is no sense in turning Linux environment to be less > attractive for free software development, since smart card are > hardware based, they will never be free and as such every > program that need to use hardware will have to use proprietary > code. This is really, really wrong. Just because a piece of hardware is proprietary it needs not have proprietary drivers. There are plenty of free drivers for hardware in the Linux kernel, for example, thanks to either reverse engineering or to companies who make the hardware being smart (and doing the write thing) and releasing the necessary specifications of the hardware so that a free driver is possible. In addition, with ever-cheaper FPGAs and so on, hardware and software might converge quite a lot (a lot of hardware these days is more written (VHDL or VeriLog code) than designed). But this is a bit OT. The fact is that, even though I mostly agree with you that it is a hard fight to convince smart card manufacturers to provide ISO compliance or specs for their cards and that using PKCS#11 would make GnuPG more capable this does not matter, because the things you're able to express with a licence are limited, and GPL is written as it is. So nothing there is to be done. > From your position there are three options: There are a few more. > 1. Linux will not be able to use many hardware devices > available in the market. So there will be less application for > Linux, more application for Windows. This already happens today to an extent. Winmodems, winprinters. Fortunately there are pervasive reverse engineering efforts together with pressure to manufacturers to yield specs. > 2. Vendors will develop NONE FREE software and sell it to > people who insist to use these hardware devices and Linux. For > example, I will write a PKCS#11 gpg-agent and sale it for > enterprises... If they insist of using gpg... But I don't > believe they will... Again, this happens today. See proprietary nVidia drivers (which probably violate the GPL). > 3. Application in Linux environment will invent standards like > the OpenPGP card, and be left out with some early adapters > individuals. 4. Hardware manufacturing companies will follow standards about smart cards like the cited ISO standard. 5. Hardware manufacturing companies will provide specifications that will allow the creation of free drivers. Options 4 and 5 are much preferable to option 0 (GnuPG implements PKCS#11 and people use non-free drivers) and not implementing PKCS#11 might put some optimizing pressure in this direction. Best, --David. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
David Picon Alvarez wrote: I dropped all stuff regarding the differences using API and communication... I think you are wrong, there is exception for the rules... I try now to contact FSF for a formal position. The lawyer who wrote GPL wrote it with the explicit intent to incentive programmers to write free software and keep software free. Allowing linkage to or from NON-GPL code is generally considered to be counterproductive for the purposes stated. Here is what you imply... And it is so sad that I want to cry :-( On Microsoft platform, there is an API called CryptoAPI which is provided as part of the operating system. This API uses CSPs (Cryptographic Service Providers) that is provided by the smart card vendors. So GPLed program can execute on Windows platform which is TOTALLY NOT A FREE software and use vendor provided smart card interface. On the other hand, in Linux environment, the flag ship of the free software, a GPLed software cannot use vendor provided smart card interface since (As you claim) every shared library that is used must be also GPLed. Microsoft environment turns to be the best environment for GPLed software, since it provides all features as part of the operating system... This is how they use their monopoly... And you and all people who think like you fall into their trap. Your arguments should not be if the code is run here or run there or how technically you use a piece of code, your argument should be around the ability to spread free software, and this ability is provided if the free software uses as many standards as it can, PKCS#11 is one of them. There is no sense in turning Linux environment to be less attractive for free software development, since smart card are hardware based, they will never be free and as such every program that need to use hardware will have to use proprietary code. From your position there are three options: 1. Linux will not be able to use many hardware devices available in the market. So there will be less application for Linux, more application for Windows. 2. Vendors will develop NONE FREE software and sell it to people who insist to use these hardware devices and Linux. For example, I will write a PKCS#11 gpg-agent and sale it for enterprises... If they insist of using gpg... But I don't believe they will... 3. Application in Linux environment will invent standards like the OpenPGP card, and be left out with some early adapters individuals. When I read the GPL and the GPL FAQ I don't understand that this was the wish of the authors. Exactly because of that they allowed exceptions. People should understand when a situation occurs that satisfied an exception. Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
> But this is the opposite the GPL program uses a none GPLed library with
out
> linkage to it!!!
> I don't understand why we always turn the facts around.
It's the same, combination and derivation trigger the copyright, and the GPL
_requires_ the combined whole work to be covered by the GPL.
So if I link to non-GPL library the linking against non-GPL code taints
mine, and if someone links to my GPLed library my GPL requirement has to be
obeyed.
> Let's say my Api is as follows:
>
> int do_work (int argc, void *argv[]);
>
> Now I load a shared library, get the do_work address and call it by:
>
> int (*do_work)(int argc, void *argv[]) = get_do_work_address ();
>
> char *args[] = {
> "ls",
> "-l"
> );
>
> do_work (2, argv);
>
> What is the difference between calling this shared library or executing a
> none GPLed "ls"?!?!?!?
The difference is in the copying. Copyright is triggered by copying, not
use. When you call a program and it executes independently you do not create
or combine or derive in the meaning of copyright, because you are not
engaging in copying and aggregating onto your own code. When you link a
library you do.
> Again... I am sorry but I must disagree... WHERE THE CODE RUN IS NOT AN
> ISSUE.
> The issue is how tightly your code is with another code.
Part of the issue is that, since, as I said later, API itself can have some
degree of copyright protection. But it is generally believed by FSF that
sharing an address space implies creating a combined and/or derived work.
> In your view I can write a PKCS#11 daemon that exposes SOAP as protocol...
> And this way to use PKCS#11 in GPLed application.
> But I cannot use the PKCS#11 directly...
Correct, if you write a daemon no copy occurs, thus no triggering of
copyright.
> This is CRAZY!!! You are fooling your-self if you think there is a
> difference between the two...
> If the usage of PKCS#11 caused your application to violate the GPL
license,
> then the usage of the same API through SOAP will cause the same affect!
See above.
> I cannot imagine that the lower who wrote the GPL meant that the open
source
> community's programmers should work so hard in order to implement their
> software... I think this is your interpretation... I've written FSF and I
> hope they will address this issue.
The lawyer who wrote GPL wrote it with the explicit intent to incentive
programmers to write free software and keep software free. Allowing linkage
to or from NON-GPL code is generally considered to be counterproductive for
the purposes stated.
--David.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
Werner Koch wrote: >> As Alon did remark earlier, the general movement in the industry is >> towards multi-purpose smart-cards. OpenPGP card currently doesn't fall >> into this category. > Not true. The OpenPGP card specification is a card application and you may put as many other applications on a card as you like and the > EEPROM allows to. With 6k (and even less possible) it is actually a pretty small application. Werner, you fail to understand the user requirements... The low level specifications of the cards is not important, programmers (except of you guys...) do not program low-level code in order to access devices. There is PKCS#11 which is high-level SOFTWARE API that is cross-platform, cross-device, and easy to use. This is the only specification to which I can write software and make sure that the user will be free to choose his hardware. Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP global directory cruft in keyservers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Fitzner wrote: > This isn't GnuPG-related really, but recently downloaded my own public > key from a keyserver and found on it about a billion of those silly PGP > global directory signatures on it. Either someone has been downloading > my key from PGP a whole bunch and then submitting it to keyservers, or > the mainstream keyservers are syncing with PGP's global directory. > > I'm wondering if this is a widespread problem. Have other people > noticed this with their keys? > > I am now very sorry I went throught that email process with PGP. I'm > actually hoping this is a widespread problem so that keyserver operators > will start deleting those stupid signatures. If not, I am stuck with my > key having a billion useless signatures on it. > > I'm so glad there is GnuPG with no corporate agenda!!! > Thanks Werner et al. gpg --edit-key clean And setting the clean-sigs and clean-uids options on import-options, export-options, and keyserver-options are our only defense until then. Like you, I refreshed from a SKS server and found 120 new sigs on my key, ALL PGP Universal Keyserver. Over on PGP-Basics, someone asked what was the purpose of the 'clean' command in GnuPG. A good friend of mine replied, "It undoes the damage caused by the PGP Universal key server." Like you, I regret ever submitting my key to that nightmare. I ignored all the renewal emails. I can't say if the PGP signatures were always the problem, but importing my full keyring to clean it in the process reduced a 750 key ring from ~8MB to ~6MB, just under 1/3 (32%) reduction. Maybe --clean-keys could be added as a command to GnuPG, like --check-sigs. Perhaps autocleaning keys is something the SKS keyserver folks will introduce. They seem to have the only active development taking place. And I second the thanks to Werner, David, Timo, and the rest of the GnuPG development community. - -- John P. Clizbe PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3-cvs-2005-09-04 (Windows 2000 SP4) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the £33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDHeG0HQSsSmCNKhARAqyJAKD1xF5/xYoV2m2CSqC3BQ1t2mX6jwCeNxc/ bgXl+nXUPBTIuAk0+rGJQ6k= =DTUD -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, 06 Sep 2005 16:04:28 +0200, Zeljko Vrba said: > Anyway, the "right" way, as I've understood Alon, is to make gpg use > gpg-agent. They communicate via a well defined _protocol_ and are not > _linked_ together. Just for the record: Linking is only one indication that the whole is a derived work. There is no one to one relation ship and in particular even two separate processes might make up a derived work. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, 06 Sep 2005 19:35:34 +0200, Zeljko Vrba said: > As Alon did remark earlier, the general movement in the industry is > towards multi-purpose smart-cards. OpenPGP card currently doesn't fall > into this category. Not true. The OpenPGP card specification is a card application and you may put as many other applications on a card as you like and the EEPROM allows to. With 6k (and even less possible) it is actually a pretty small application. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 04:52:55PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >> 1) Pointers being passed >>By copying the whole address space back and forth at each call and >>return? "Morally" that's not running in separate address spaces! > "Morally" I don't care, even in the case of copying. "Morally" is what a judge will look at. So it is the crux of the matter. -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Alon Bar-Lev wrote: When you raise this issue... It seems that PKCS#11 is not implemented not because of licensing problems... But because if PKCS#11 will be implemented then there will be no work to be done for each specific card... But this strategy can, and will backfire :) From personal experience, companies are much more likely to choose a standard, interoperable solution (-> PKCS#11 -> X.509) than paying for a proprietary[1] solution. [1] In a sense that I can't describe exactly, OpenPGP card + GnuPG feels more proprietary than any closed-source smart card with PKCS#11 driver provided. The metric of 'proprietary-ness' would be in this case: the number of different smart-cards and interfaces supported by GnuPG. IMHO, the overall situation would get better for GnuPG and OpenPGP card if someone wrote a GPL-compatible PKCS#11 driver for the OpenPGP card. Then: a) OpenPGP cards can be used by other applications, not just GnuPG. (OK, they can be used in other applications even now, but noone sane will write card-specific code when they can use a high-level, universal API like PKCS#11). b) GnuPG switches to PKCS#11 and uses the GPL-compatible PKCS#11 for the OpenPGP card. It doesn't even have to dynamically link to it. As Alon did remark earlier, the general movement in the industry is towards multi-purpose smart-cards. OpenPGP card currently doesn't fall into this category. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
'Lionel Elie Mamane' wrote: > I find the following argument very reasonable: I have no interest in implementing PKCS#11 and nobody has stepped up to pay me to do it. When I started this discussion, I wanted to ask whether implementing a feature of gpg-agent to access PKCS#11 token is in the roadmap... I will gladly get the answer, yes... If someone will pay for the implementation... When you raise this issue... It seems that PKCS#11 is not implemented not because of licensing problems... But because if PKCS#11 will be implemented then there will be no work to be done for each specific card... Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Alon Bar-Lev wrote: Again... I am sorry but I must disagree... WHERE THE CODE RUN IS NOT AN ISSUE. The issue is how tightly your code is with another code. A protocol and API specification are the same, since they can replace one another... I would agree with this. Why does the actual _mechanism_ of DATA sharing matter? Can somebody explain, what is the difference between calling PKCS#11 as a shared library and passing a message to some daemon to pefrorm the work and return the result? The amount of sharing and coupling between the two modules is EXACTLY THE SAME, the only difference is the MECHANISM used to accomplish that sharing (i.e. shared address space in the case of dynamic library or UNIX sockets in the case of stand-alone daemon). What's more, UNIX sockets can be implemented via shared memory. What would GPL say in _that_ case? And I would try again to emphasize DATA sharing, not CODE sharing. You use PKCS#11 API to share DATA with the library[1]. In my opinion, data sharing does not and cannot (in any common-sense interpretation) constitute a "derivative work". Then again, I'm not a lawyer. The application calling PKCS#11 one way or another shares ONLY data with it, not its code! And I don't think that GPL says anything about data sharing. So it would be (maybe) legal and GPL-compliant to link in proprietary PKCS#11 .so into GnuPG. [1] There are some cases when you can register a callback to be called by PKCS#11 into you application. This is again a moot point, since even Windows do that: call app callback from the kernel (e.g. the ubiquitous "WndProc"). Paradoxically, it seems that GnuPG would be allowed to used closed-source MS CAPI because it is delivered as a "part of the operating system". The way CAPI works is: your application -> CAPI -> back-end driver So your application interacts with CAPI (delivered as a part of the operating system - an exception permitted by the GPL, as someone quoted in this thread), and CAPI interacts with the back-end driver for the particular hardware device. In your view I can write a PKCS#11 daemon that exposes SOAP as protocol... And this way to use PKCS#11 in GPLed application. But I cannot use the PKCS#11 directly... This is CRAZY!!! You are fooling your-self if you think there is a difference between the two... > Yes, I agree with this viewpoint. The only difference is in the MECHANISM to accomplish the sharing. BTW, let us know when you get the reply from the FSF. I'm really curious.. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 04:52:55PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >>Please do so. I'm curious how you will handle: >> >> 1) Pointers being passed >> >>By copying the whole address space back and forth at each call and >>return? "Morally" that's not running in separate address spaces! > Make the programs share their _data_ segments, but NOT their _code_ > segments. GPL is about _code_, not about the _data_ created and used by > the code. The pointer may point to code. It can be a pointer to a function. For a callback, for example. > I don't have all details worked-out, but none of them seem really > unsurmountable. In the extreme case, nothing that couldn't be solved > with little kernel-side work and support. >> By all means, please follow through on this plan. It will be very fun >> to watch! > In what way "fun"? :) 1) Scientifically, see interesting problems tackled. 2) From a slightly more "Schadenfreude" perspective, watch the legal discussions and / or flamewars it will create. White papers flying around! Eben Moglen saying your mechanism doesn't circumvent the GPL, you disagreeing and arguing back, a new GPL revision coming out to address the "loophole" you have demonstrated (if it gets settled that it _is_ a loophole), etc. You saying that the revised GPL version doesn't count, because not derivative work and thus legally cannot enforce limitations. Fun to watch from the sidelines, cheering on, etc ;-) > In any case, Werner will run out of his only reasonable argument > (IMHO) for not supporting PKCS#11 and users will (hopefully) profit > ;) I find the following argument very reasonable: I have no interest in implementing PKCS#11 and nobody has stepped up to pay me to do it. He won't run out of *this* argument ;-) -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Wed, Sep 07, 2005 at 01:02:52AM +0930, Alphax wrote: > Is it possible to arbitrarily make an OpenPGP key with whatever keypair? There is no software that would do this right now, but assuming this is a actual RSA keypair, yes. Why not? Alex -- mors ab alto 0x46399138 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Janusz A. Urbanowicz wrote: > On Tue, Sep 06, 2005 at 11:48:45PM +0930, Alphax wrote: > >>>The application is free to do whatever it wants with these objects, >>>given sufficient authentication to the card (PIN). Technically, there is >>>nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. >> >>I think I might have seen something like that with a Thawte Freemail >>root certificate or something... it wasn't pretty :( > > > When Thawte signed PGP keys as a part of Web Of Trust program, they used the > same key in both OpenPGP and X.509 form. > > Why you say it wasnt pretty? An actual RSA modulus is well hidden within the > stuff so it doesn't really matter. > They converted the same key several times, so there were 3 or so keys with the same long fingerprint, but different creation times - multiple copies of the same key. Is it possible to arbitrarily make an OpenPGP key with whatever keypair? -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 |X Against HTML email & vCards http://tinyurl.com/cc9up| / \ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] GnuPG Explorer Extension (GPGee) version 1.2.0 released
Version 1.2.0 of GPGee has been released - head to the homepage at http://gpgee.excelcia.org to download it. New features include: - Support for creating signatures with more than one key at once. - Support for verifying multi-signed documents. - Automated new version checking (this was actually added in 1.1.3 but that version was unannounced) - Can automatically change the status of source files to read-only after they are signed. Useful for cases where a certain type of file's reader (MS Excel with spreadsheets is one) changes the file when it is opened even if it isn't edited. Since this would invalidate a signature, you can now have GPGee set the file read-only. In addition to that, there are a few bug fixes incorporated for good measure. For those that aren't familliar with GPGee, it is a Windows shell extension that adds GnuPG support to explorer's right-click menu. You can sign, sign+encrypt, encrypt, verify, and decrypt files right from within the Windows explorer. ___ Gnupg-announce mailing list [EMAIL PROTECTED] http://lists.gnupg.org/mailman/listinfo/gnupg-announce ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 11:48:45PM +0930, Alphax wrote: > > The application is free to do whatever it wants with these objects, > > given sufficient authentication to the card (PIN). Technically, there is > > nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. > > I think I might have seen something like that with a Thawte Freemail > root certificate or something... it wasn't pretty :( When Thawte signed PGP keys as a part of Web Of Trust program, they used the same key in both OpenPGP and X.509 form. Why you say it wasnt pretty? An actual RSA modulus is well hidden within the stuff so it doesn't really matter. Alex -- mors ab alto 0x46399138 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
David Picon Alvarez wrote:
> If a library runs on a shared addressable space, FSF (which is GnuPG's
Copyright holder, I assume?) considers the combined result
> a derived work in the meaning of copyright law. This is the whole point of
the LGPL, to have a licence that allows linking libraries into
> non-free software, but which ensures distribution of the library will
always be on free terms and so on.
But this is the opposite the GPL program uses a none GPLed library with out
linkage to it!!!
I don't understand why we always turn the facts around.
> You are wrong. The GPL does not talk of standards in the meaning you
propose. If a work links to a shared library and invokes its functions
> it is making use of the library in a manner similar to copying pages from
another book into your own book. This process creates a derived work of
> the library.
> Whether the library implements a patent-protected standard, a Trade Secret
or an open, non-patent-encumbered standard is for the purposes
> of the linking issue, irrelevant. Linking creates derivation.
No... You are wrong.
Let's say my Api is as follows:
int do_work (int argc, void *argv[]);
Now I load a shared library, get the do_work address and call it by:
int (*do_work)(int argc, void *argv[]) = get_do_work_address ();
char *args[] = {
"ls",
"-l"
);
do_work (2, argv);
What is the difference between calling this shared library or executing a
none GPLed "ls"?!?!?!?
There is an exception in the FAQ page... "If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program."
Please note the word _ALMOST_, you tend to forget that every rule has an
exception.
The above implementation and PKCS#11 do not fall this category.
>> Hence... HTTP is a standard (RFCXXX, protocol), PKCS#11 is a standard
(RSA,
>> API), S/MIME is a standard (RFC, format) etc... There is not
>> difference between them in term of implementing a compliance software.
> The difference is that when I write onto a socket to talk to an HTTP
server I do not copy its code onto my memory segment, I am making use
> of the server but not copying anything from its internals, which is why
HTTP does not lead to a derived work being created. Whereas when I link
> in a library I copy its code onto my memory segment, and I invoke its
functions in a manner equivalent to writing those functions onto my own
> code, which makes a derived work.
Again... I am sorry but I must disagree... WHERE THE CODE RUN IS NOT AN
ISSUE.
The issue is how tightly your code is with another code.
A protocol and API specification are the same, since they can replace one
another...
In your view I can write a PKCS#11 daemon that exposes SOAP as protocol...
And this way to use PKCS#11 in GPLed application.
But I cannot use the PKCS#11 directly...
This is CRAZY!!! You are fooling your-self if you think there is a
difference between the two...
If the usage of PKCS#11 caused your application to violate the GPL license,
then the usage of the same API through SOAP will cause the same affect!
I cannot imagine that the lower who wrote the GPL meant that the open source
community's programmers should work so hard in order to implement their
software... I think this is your interpretation... I've written FSF and I
hope they will address this issue.
Best Regards,
Alon Bar-Lev.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to select a subkey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Henk M. de Bruijn wrote the following on 9/6/05 8:48 AM: | Hi all, | | Forgive my ignorance but how do I select a subkey? | | TIA I take it that you mean an additional subkey. $ gpg --edit-key [key ID] Command> addkey Key is protected. You need a passphrase to unlock the secret key for user: [you and the key you have selected] [type the passphrase for that key] Please select what kind of key you want: ~ (2) DSA (sign only) ~ (4) Elgamal (encrypt only) ~ (5) RSA (sign only) ~ (6) RSA (encrypt only) Your selection? If you want the additional subkey for sign only, your choice of DSA or RSA may be conditioned to the fact that if you want or need a "large" size (>1024) then you have to go for RSA. If you generate a RSA subkey of e.g. 2048, then you can use, if you want SHA256 i/o SHA1. Etc... Charly -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQx2w5m69XHxycyfPAQj0qg//cps0LAn/ftiXfqBlxJvrqQxqS56H3Q1B Q7QBorwIz3BpoqPNpX9OmSICmvDZ19reBfRhOjberVa6Ut6hbSfR1xtIztEExIjM y0OGcVplFq1wuxJHQKoOra/iSWPZkrIJkwaYV18LWG9qw1r4cMtv6fH8KNfAXMhJ WrXU/jKHxEluZa2N1xnTzlKWCCh6tMnFPdCOocMVpdrCEgPgEjf0GnskNOtW8+Re 9KXH9jmchNgzGnYECFSEc7zUWiLnqAqZBc2ad1rrxI2T2GWbES5jMWuMYMTwarkB D/bgwDDzIUUJoQplcEXeyzVWS8KeiMXgKcyoH84UjNwTzIsQW5/QzYOfcWmsGN+R nuyq5DIz0mQRK+p6nyliQ6fWJPU7RovAYbyQJLGAqkAOw/vhBUhWKou8fpgx32Aj vXEnASTmw5hI1s0uzPNG1qWxOstx/gEXJ97yg/necA+3U9VLlSEY1iMkbSN+dJgA R70yqRBOijtkFB0j6136HyNXNBfTMeUqT3rnpBoq1AA7Orph8LbejHBbkN3QFRAU OKpNZUxxRYnHirpiGAkGpJaVidUo76udQsu0iuKdHPL9AVVRrPExLLds3JiYcN2O IxlJiXEXCBMe1LVu0AN/YHFkklPWtG/5ycqjthH4LnoJhohZe2W2EHi7ugh6lLQK iRbaYrqYlc8= =qOfn -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certification-only key
On Tue, Sep 06, 2005 at 01:03:00AM +0200, Lionel Elie Mamane wrote: > >> I would obviously have at least one data-signing subkey. I presume > >> these people would take a signature from such as subkey. Or > >> decryption of a nonce they sent me encrypted to an encryption > >> subkey. > > > They might, but really shouldn't (I wouldn't). When you make a > > certification signature on someone elses key, you're signing the > > primary key plus the user ID in question. There is no benefit in > > receiving a signed challenge from any key other than the primary. > > But that subkey is attached to the primary key by a signature of the > primary key. Isn't then control of that subkey enough to "prove" > control of the primary key? > > Unless: > > 1) Signature scheme cryptographically broken. We have a bigger > problem. > > 2) Primary key owner has done stupid things, like sharing subkeys > with others. But if we assume he has done that, we might as well > assume he would sign the challenge a man-in-the-middle attacker > has forwarded him or shared his primary key or ... > > Where's the flaw in the reasoning? The flaw is that #2 is not necessarily a stupid thing to do. There are useful things that can be done by having two different keys that happen to share subkeys. It's not illegal in OpenPGP to do so. In addition, given the current design of signing subkeys, it's possible to steal a subkey from someone elses key and pretend that their signature is from you. (GnuPG has a fix for this from a recent OpenPGP draft, but I'm waiting for PGP to implement it before I turn it on). The real flaw here is accepting a signature from something other than the object you are signing. That's one step removed, and therefore dangerous. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
'Lionel Elie Mamane' wrote: Please do so. I'm curious how you will handle: 1) Pointers being passed By copying the whole address space back and forth at each call and return? "Morally" that's not running in separate address spaces! Make the programs share their _data_ segments, but NOT their _code_ segments. GPL is about _code_, not about the _data_ created and used by the code. The first pointer-sharing reference will trigger a fault which will be handled by the ld.so and it will create an appropriate data-sharing mapping. "Morally" I don't care, even in the case of copying. Technically, making the programs share their data segments is, IMHO, not a violation of GPL since no code is shared between the programs. But then again, I'm not a lawyer. I'm always interested in other opinions. 2) A library that calls exec() or fork() or setuid() such a "process state changing" syscall. I don't think you can keep the semantics of all libraries in this way. By providing the support for few such critical things within ld.so, so it can change the state of the 'right' process. I don't have all details worked-out, but none of them seem really unsurmountable. In the extreme case, nothing that couldn't be solved with little kernel-side work and support. It would certainly be a fun legal challenge. I don't believe however, you would win it. But I'm not a lawyer, he. Neither am I. By all means, please follow through on this plan. It will be very fun to watch! In what way "fun"? :) I don't have the time currently, sadly. But, the biggest journey begins with the first step, so I just might start to write some design paper in my spare time :) Either I'll be the first one to do it, or someone will get ahead of me. In any case, Werner will run out of his only reasonable argument (IMHO) for not supporting PKCS#11 and users will (hopefully) profit ;) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to select a subkey
On Tue, Sep 06, 2005 at 02:48:33PM +0200, Henk M. de Bruijn wrote: > Forgive my ignorance but how do I select a subkey? I'm not sure what you mean. In the "--edit-key" menu, you type "key n", replacing "n" by a number. From the command line, you "just" use the KeyID of the key. -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 04:26:05PM +0200, Zeljko Vrba wrote: >> PKCS#11 IS a library API. But really, how is API different from a >> protocol? Is the only difference linking in the same address space? > BTW, I can imagine writing a version of ld.so (BSD licensed!) that > will execute different shared libraries as separate processes, Please do so. I'm curious how you will handle: 1) Pointers being passed By copying the whole address space back and forth at each call and return? "Morally" that's not running in separate address spaces! 2) A library that calls exec() or fork() or setuid() such a "process state changing" syscall. I don't think you can keep the semantics of all libraries in this way. > and will NOT link them in the same address space with the > application in question (i.e. GnuPG). > So the "procedure call" will call to a stub in the BSD licensed > ld.so which will just "pass a message" to the real shared library > and return a result code to the application. > Thing like this would forever end this GPL madness about what is > "derivative work". It would certainly be a fun legal challenge. I don't believe however, you would win it. But I'm not a lawyer, he. By all means, please follow through on this plan. It will be very fun to watch! -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
List wrote: So the "procedure call" will call to a stub in the BSD licensed ld.so which will just "pass a message" to the real shared library and return a result code to the application. That might not be enough. In order to ensure that copyright does not trigger you need to exclude derivation, which is caused by copying (but not copying only). The API could be (and has sometimes been) considered to be subject to copyright insofar as it is an original non-functional (id est, it could be done some other way) work. However for this case the API is explicitly licence, so if the licence of the API is GPL-compatible your library might indeed solve the problem. Many libraries however could not be used in such a way. --David. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 04:04:28PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >>I had understood that it was not a _protocol_ but a library API. HTTP >>is a _protocol_ for data interchange over the network. I thought >>PKCS#11 was a _library_ API and that you linked (dynamically at >>run-time) a particular "implementation" of it (the card driver) into >>your program to use it. If that's not the case, my previous messages >>are void and meaningless. > PKCS#11 IS a library API. But really, how is API different from a > protocol? Is the only difference linking in the same address space? The fact that they have to run in the same address space suggests that they exchange "complex data structures" and that the intercoupling (interdependency?) between them is quite tight. I suppose this is the FSF's reasoning. -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Zeljko Vrba wrote: > PKCS#11 IS a library API. But really, how is API different from a protocol? Is the only difference linking in the same address space? BTW, I can imagine writing a version of ld.so (BSD licensed!) that will execute different shared libraries as separate processes, and will NOT link them in the same address space with the application in question (i.e. GnuPG). So the "procedure call" will call to a stub in the BSD licensed ld.so which will just "pass a message" to the real shared library and return a result code to the application. Thing like this would forever end this GPL madness about what is "derivative work". signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Zeljko Vrba wrote: > Alphax wrote: > >> Zeljko Vrba wrote: >> >>> Joe Smith wrote: >>> >>> For example, your CA can revoke your key leaving you with one key that is invalid X.509, but valid OpenPGP? Yuck! >>> >>> Using the X.509 cert and OpenPGP public key (having the same private >>> key) could be useful in the following scenario: >>> >> >> Is that even allowed?? >> > In what sense allowed? PKCS#11 know nothing about policies.. It just > exposes a set of objects on the card (certificate, public and private > keys and maybe some other data objects along with certificates). > It terms of using the same generic public/private keypair... how does that work? > The application is free to do whatever it wants with these objects, > given sufficient authentication to the card (PIN). Technically, there is > nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. I think I might have seen something like that with a Thawte Freemail root certificate or something... it wasn't pretty :( (eh, I think I just answered my own question, but I still don't "get it"...) -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 |X Against HTML email & vCards http://tinyurl.com/cc9up| / \ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Alphax wrote: Zeljko Vrba wrote: Joe Smith wrote: For example, your CA can revoke your key leaving you with one key that is invalid X.509, but valid OpenPGP? Yuck! Using the X.509 cert and OpenPGP public key (having the same private key) could be useful in the following scenario: Is that even allowed?? In what sense allowed? PKCS#11 know nothing about policies.. It just exposes a set of objects on the card (certificate, public and private keys and maybe some other data objects along with certificates). The application is free to do whatever it wants with these objects, given sufficient authentication to the card (PIN). Technically, there is nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG Explorer Extension (GPGee) version 1.2.0 released
Version 1.2.0 of GPGee has been released - head to the homepage at http://gpgee.excelcia.org to download it. New features include: - Support for creating signatures with more than one key at once. - Support for verifying multi-signed documents. - Automated new version checking (this was actually added in 1.1.3 but that version was unannounced) - Can automatically change the status of source files to read-only after they are signed. Useful for cases where a certain type of file's reader (MS Excel with spreadsheets is one) changes the file when it is opened even if it isn't edited. Since this would invalidate a signature, you can now have GPGee set the file read-only. In addition to that, there are a few bug fixes incorporated for good measure. To my knowledge, GPGee is the only GUI for GnuPG that supports multi-key signing. I actually got a first. :) For those that aren't familliar with GPGee, it is a Windows shell extension that adds GnuPG support to explorer's right-click menu. You can sign, sign+encrypt, encrypt, verify, and decrypt files right from within the Windows explorer. p.s. A very grateful thank-you goes to Werner Koch. In addition to a very nice compliment about GPGee's source code, he has offered hosting for GPGee at gnupg.org. Recently I began to experience a lot of downloads of GPGee (up to 500/week - which is a whole lot for me) and it was threatening to overwhelm my modest self hosting ability. Actually, now that I think about it, it was partially his fault to begin with. He added a link to GPGee on the GnuPG web site's list of frontends, and it was then that was when I started to see all the downloads. I should mention, before people think I'm actually blaming him, that I requested the link... Werner was simply gracious enough to say yes and put it there. Thanks for both the link and the hosting. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
'Lionel Elie Mamane' wrote: I had understood that it was not a _protocol_ but a library API. HTTP is a _protocol_ for data interchange over the network. I thought PKCS#11 was a _library_ API and that you linked (dynamically at run-time) a particular "implementation" of it (the card driver) into your program to use it. If that's not the case, my previous messages are void and meaningless. PKCS#11 IS a library API. But really, how is API different from a protocol? Is the only difference linking in the same address space? Anyway, the "right" way, as I've understood Alon, is to make gpg use gpg-agent. They communicate via a well defined _protocol_ and are not _linked_ together. So actually, the PKCS#11 licensing issue can be solved by independently writing a BSD-licensed version of the gpg-agent. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Zeljko Vrba wrote: > Joe Smith wrote: > >> >> For example, your CA can revoke your key leaving you with one key that >> is invalid X.509, but valid OpenPGP? Yuck! >> > Using the X.509 cert and OpenPGP public key (having the same private > key) could be useful in the following scenario: > Is that even allowed?? -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 |X Against HTML email & vCards http://tinyurl.com/cc9up| / \ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Joe Smith wrote: For example, your CA can revoke your key leaving you with one key that is invalid X.509, but valid OpenPGP? Yuck! Using the X.509 cert and OpenPGP public key (having the same private key) could be useful in the following scenario: 1. You must periodically pay to your CA to renew your certificate 2. OpenPGP trust model isn't as 'strong' as X.509 (i.e. there aren't many trusted introducers) So, you pay ONCE to some CA to issue you short-lived, widely-trusted certificate. It will expire after a year or so, but.. you can continue to use your OpenPGP key as long as you deem it's OK. The point is that your _identity_ doesn't change when the X.509 cert expires. So, continuing to use the X.509 (expired) private key solves problem 1. Having X.509 cert in the first place, solves problem 2. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
how to select a subkey
Hi all, Forgive my ignorance but how do I select a subkey? TIA -- Henk M. de Bruijn __ The Bat! Natural E-Mail System™ version 3.5 Pro on Windows XP SP2 Request-PGP: http://www.biglumber.com/x/web?qs=0x6C9F6CE78C32408B Gossamer Spider Web of Trust http://www.gswot.org A progressive and innovative Web of Trust pgpcqPgLR1dGX.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
> NOTICE: Since the application does not know which cryptographic token is > used by the user, the usage of the library MUST be done at runtime. There is > stick interface for these libraries which is described in PKCS#11 standard. In such a case the DLL or .so or whatever MUST be GPL-compatible (GPL or less restrictive) per the meaning of FSF in order to be GPL-linkable, or be covered by the "standard OS component" exception. > We need a definite answer here... So the licensing argument will be out of > the way... If a library runs on a shared addressable space, FSF (which is GnuPG's Copyright holder, I assume?) considers the combined result a derived work in the meaning of copyright law. This is the whole point of the LGPL, to have a licence that allows linking libraries into non-free software, but which ensures distribution of the library will always be on free terms and so on. > A standard is a standard... And it is not matter if it describers an API, a > protocol, a command-line, a format or any other interface. > As long as there is no intellectual rights claims for the implementation of > the standard, it can be used by GPL. You are wrong. The GPL does not talk of standards in the meaning you propose. If a work links to a shared library and invokes its functions it is making use of the library in a manner similar to copying pages from another book into your own book. This process creates a derived work of the library. Whether the library implements a patent-protected standard, a Trade Secret or an open, non-patent-encumbered standard is for the purposes of the linking issue, irrelevant. Linking creates derivation. > Hence... HTTP is a standard (RFCXXX, protocol), PKCS#11 is a standard (RSA, > API), S/MIME is a standard (RFC, format) etc... There is not difference > between them in term of implementing a compliance software. The difference is that when I write onto a socket to talk to an HTTP server I do not copy its code onto my memory segment, I am making use of the server but not copying anything from its internals, which is why HTTP does not lead to a derived work being created. Whereas when I link in a library I copy its code onto my memory segment, and I invoke its functions in a manner equivalent to writing those functions onto my own code, which makes a derived work. IANAL (yet), but a gifted amateur :-) HTH, --David. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
Lionel Elie Mamane wrote: > I thought we were talking about PKCS#11 "drivers" for specific cards, and that you had to link this driver into your program (dynamically > at run-time) in order to use it. That _driver_ would be gpl-incompatible. PKCS#11 is a standard it is not vendor specific, please refer to http://www.rsasecurity.com/rsalabs/node.asp?id=2133 so that your answers will be correct. So if PKCS#11 is an API specification that every smartcard/HSM/Software who manages cryptographic keys supports, by means of developing a shared library/DLL that implement the standard, is it OK for GPLed program to load and interact with this library. NOTICE: Since the application does not know which cryptographic token is used by the user, the usage of the library MUST be done at runtime. There is stick interface for these libraries which is described in PKCS#11 standard. We need a definite answer here... So the licensing argument will be out of the way... [[[ Some of my thoughts... And comments for your position. A standard is a standard... And it is not matter if it describers an API, a protocol, a command-line, a format or any other interface. As long as there is no intellectual rights claims for the implementation of the standard, it can be used by GPL. Hence... HTTP is a standard (RFCXXX, protocol), PKCS#11 is a standard (RSA, API), S/MIME is a standard (RFC, format) etc... There is not difference between them in term of implementing a compliance software. ]]] Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Linux-gnupg and win-pgp
> > In the message composition window, in the toolbar, there is a choice > list between "Inline OpenPGP", "OpenPGP/MIME" and a few others. Choose > "Inline OpenPGP". "inline OpenPGP" works!!! thank you !!! :-) stefan pgpstGJGpfQRp.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP global directory cruft in keyservers
Kurt Fitzner wrote: > This isn't GnuPG-related really, but recently downloaded my own public > key from a keyserver and found on it about a billion of those silly PGP > global directory signatures on it. Either someone has been downloading > my key from PGP a whole bunch and then submitting it to keyservers, or > the mainstream keyservers are syncing with PGP's global directory. > > I'm wondering if this is a widespread problem. Have other people > noticed this with their keys? > > I am now very sorry I went throught that email process with PGP. I'm > actually hoping this is a widespread problem so that keyserver operators > will start deleting those stupid signatures. If not, I am stuck with my > key having a billion useless signatures on it. > If you have gpg 1.4.2 you can edit your key and clean it. You can also set your import and export options to clean these signatures automatically. -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 |X Against HTML email & vCards http://tinyurl.com/cc9up| / \ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Tue, Sep 06, 2005 at 10:09:25AM +0200, Alon Bar-Lev wrote: > Lionel Elie Mamane wrote: >> But there is indeed a case to be made that if the library >> implements a well-known, standard ABI, then linking to it is not a >> GPL violation. Legally it depends whether the linked >> program is a "derived work" from the program or not. > But PKCS#11 is not a library you link against! > It is an API specification. > There is no proprietary code you link into your program in order to > implement this standard. I thought we were talking about PKCS#11 "drivers" for specific cards, and that you had to link this driver into your program (dynamically at run-time) in order to use it. That _driver_ would be gpl-incompatible. >> GnuPG doesn't *link* to RAID drivers or video drivers. They don't >> end up "running linked together in a shared address space". They >> communicate over syscalls or sockets; mechanisms that are >> well-known as to be "GPL-safe" (as long as the coupling between >> them isn't too tight). > I think you should read PKCS#11 specification... You cannot call it > "combining two parts into a program" PKCS#11 is a specification, you > don't provide the implementation along with your program, the > specification is EXACTLY the same as protocol or command line > specification. I had understood that it was not a _protocol_ but a library API. HTTP is a _protocol_ for data interchange over the network. I thought PKCS#11 was a _library_ API and that you linked (dynamically at run-time) a particular "implementation" of it (the card driver) into your program to use it. If that's not the case, my previous messages are void and meaningless. > Since you don't provide the PKCS#11 provider implementation along > with your GPLed distribution and that there is a complete API > specification of the interface, it does not fall into the "combined > program". Again assuming that the provider implementation is a library you link against: That may or may not be true. I don't think that's legally clearly established yet. >> On the other hand, some people interpret the GPL in a way saying >> that if a library implements a "standard" ABI, then one can link >> GPL software to it. I think it is a good idea to stick to >> the copyright holder's interpretation. > I don't understand this statement... There are two statements: First: >> On the other hand, some people interpret the GPL in a way saying >> that if a library implements a "standard" ABI, then one can link >> GPL software to it. This one says essentially the same thing as what you quoted before. Some say standard ABI -> not combined program, but I don't think this has been "proven" by case-law yet. It may be found true by courts, or not. Second: >> I think it is a good idea to stick to the copyright holder's >> interpretation. A license means what the licensor means by it. If the licensor has clearly told you that by *his* reading of the GPL that-and-that is forbidden then you'd be in a tricky situation in front of a judge explaining "I know that the licensor meant to forbid that, but the text he gave me permits it, so he has permitted it.". >>> I can show you that it GPLed program loads these drivers... >> Yes, show me, I'm curious. I had misundertood what you meant by "these drivers". I thought you meant the display and printing drivers. > Examples: > opensc from www.opensc.org - LGPL uses PKCS#11 > pkcs11_login from www.opensc.org - LGPL uses PKCS#11 LGPL is not GPL. The difference is exactly that it permits linking to non-(L)GPL code. > openCryptoki from http://sourceforge.net/projects/opencryptoki - GPL uses > PKCS#11 I downloaded opencryptoki-2.2.0.tar.gz . It is not GPL, it is under the "Common Public License Version 0.5". -- Lionel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
PGP global directory cruft in keyservers
This isn't GnuPG-related really, but recently downloaded my own public key from a keyserver and found on it about a billion of those silly PGP global directory signatures on it. Either someone has been downloading my key from PGP a whole bunch and then submitting it to keyservers, or the mainstream keyservers are syncing with PGP's global directory. I'm wondering if this is a widespread problem. Have other people noticed this with their keys? I am now very sorry I went throught that email process with PGP. I'm actually hoping this is a widespread problem so that keyserver operators will start deleting those stupid signatures. If not, I am stuck with my key having a billion useless signatures on it. I'm so glad there is GnuPG with no corporate agenda!!! Thanks Werner et al. Kurt. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Zeljko Vrba <[EMAIL PROTECTED]> writes: >Yes, these devices are expensive for individuals. Although they're less expensive on ebay :-). Keep an eye on that long enough and you'll find almost anything turning up, for example there's almost always some Spyrus Lynks cards on sale by someone. Some of the stuff even has previous CA's keys still in the HW. >PKCS#11 is not limited to smart-cards. Yup, and that's an important point. If you want big-iron style crypto HW support, your choice is either PKCS #11, CryptoAPI, or a per-hardware-device custom API. I know which one I'd want... Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
"Alon Bar-Lev" <[EMAIL PROTECTED]> writes: >The conclusion of my discussion with people here is that the need of using >PKCS#11 for accessing various smartcards is not clear. I've tried to >highlight the advantages of using standard software API to access external >devices, but I've failed. Users of crypto tokens tend to fall into two classes, hobbyists/enthusiasts (who don't mind hacking their own glue code, so PKCS #11 isn't too important), and commercial/business users (who really need PKCS #11 but who probably wouldn't use GPG). The result is, as you've found, something of a lack of a market for PKCS #11 combined with GPG. Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: > Let's say you use GPLed licensed program on windows... It loads > kernel32.dll, right? > Since your GPLed program does not contain any other licensed code it is > still GPLed... Note that the GPL has a specific exception in it for libraries like kernel32.dll that are shipped as part of the operating system. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
"Alon Bar-Lev" <[EMAIL PROTECTED]> writes: >I use Athena smartcard www.athena-scs.com which works perfectly in term of >Linux and PKCS#11. I enjoy using it with Java JCE, Mozilla, Tunderbird, >PAM_PKCS11, I've encrypted my disk using aes-loop and then required gpg to >support PKCS#11... And here we are... Oh, that's the old Aladdin stuff. Well, they've certainly come a *long* way since I last looked at them - in the 1999-2000 time frame they had the worst PKCS #11 driver I've ever seen, and their "support" consisted of telling you to buy more copies of their $700 SDK to see whether they'd fixed any of the bugs in the version you already had. I still have some of their hardware lying around as a paperweight somewhere. (Disclaimer: I have no idea what it's like now (it certainly sounds a lot better than it used to be), I'm just saying that at one point it was really bad). Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Lionel Elie Mamane <[EMAIL PROTECTED]> writes: >On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: >> Since your GPLed program does not contain any other licensed code it is >> still GPLed... >> The same goes with GPLed licensed program that loads PKCS#11 >> module... > >Not unless that PKCS#11 module "is normally distributed with the major >components of the operating system". (Assuming here that the PKCS#11 module >would is a library that GnuPG would be dlopen.) PKCS #11 is a device driver without which it's impossible to use critical (to the application) hardware. If you take this interpretation then GPG already violates it because it ends up using all manner of components (RAID drivers, ATI/nVidia video drivers, PC/SC drivers, etc) that aren't distributed as part of the OS. In fact if you wanted to go reductio ad absurdum even kernel32.dll is excluded because the hotfixes that are constantly applied to it aren't "normally distributed with the system components" - they're a special download. On the other hand using a particular interpretation of the GPL in order to make it impossible for GPG to be able to support widespread smart cards and crypto hardware is a great example of cutting off your nose to spite your face. I guess you can always tell people who want to use crypto devices with PGP to go with the commercial PGP instead. Or cryptlib :-). Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
I wrote: >Oh, that's the old Aladdin stuff. Well, they've certainly come a *long* way >since I last looked at them - in the 1999-2000 time frame they had the worst >PKCS #11 driver I've ever seen, and their "support" consisted of telling you >to buy more copies of their $700 SDK to see whether they'd fixed any of the >bugs in the version you already had. Argh, sorry, wrong driver, it's the ActivCard drivers (and support) that were that bad, not Aladdin. Aladdin (and by extension ASECard and Athena Cards, and eTokens as well) work just fine. Just to repeat that: Nothing wrong with Aladdin's PKCS #11. Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Linux-gnupg and win-pgp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Fuhrmann wrote: > okay, most of the win users have outlookso what? Outlook and many other mailers do not support MIME very well. You have to use different methods to communicate with them unfortunately. >>> 2.) Is there a way to sent this mail so that win users have the >>> mail in the mail body and not as attachment? >>> >> I dunno if KMail can do that. Look for a "old method" option or >> "plain text" option or something like that. > > Cant find something like that. In KMail, you want to use Inline OpenPGP, from the Composer window (http://docs.kde.org/development/en/kdepim/kmail/the-composer-window.html#encrypt-sign). - -- ToddOpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp == When buying and selling are controlled by legislation, the first things to be bought and sold are legislators. -- P.J. O'Rourke, Parliament of Whores -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkMc8F4mGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1rg3gCdEFuO4QZSr9BOCgEHlAGSpjPIz18AoNdKP9or n4fol8Ou2QqwmXZonvgR =rkm3 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGG Card
Zeljko Vrba <[EMAIL PROTECTED]> writes: >Peter Gutmann wrote: >> I'd already offered the use of my PKCS #11 interface code from cryptlib for >> GPG use some time ago. This should do everything you need and has had years >> of tuning to work with all the bugs in various PKCS #11 drivers, it's vastly >> easier than going through the entire learning curve yourself. > >That's correct, it was my proposal in question. The problem is that, under >Linux, I couldn't find a smart-card + PKCS#11 combination that works >correctly enough (out of the box) to be usable with cryptlib. I think the problem is more a generalisation of that, it's "under Linux, I couldn't find a smart-card + PKCS#11 combination that works correctly". I've heard of (from memory) four PKCS #11-for-Linux projects by commercial vendors that either ended up as pre-alpha quality releases/abandonware or were shelved beause the vendor couldn't find a business model for them (this was a few years ago, it may be better now). The one PKCS #11-under-Linux driver that I know of that was completed, the nCipher one, works fine with cryptlib. Everything else is Windows only... actually Eracom have Solaris and some other OS support (PHUX?), and there's some OEM'd Cryptoswift supported under Solaris. (Which other Linux PKCS #11 drivers are there?). Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP Card
Werner Koch <[EMAIL PROTECTED]> writes: >On Tue, 06 Sep 2005 01:23:51 +1200, Peter Gutmann said: >> and commercial/business users (who really need PKCS #11 but who probably >> wouldn't use GPG). The result is, as you've found, something of a lack of a > >I won't agree to this because there is at least one large company in Germany >using Smartcards along with gpgsm. Well OK, so there's always exceptions, but I don't think there's enough to drive significant demand for this - all the commercial users I've seen who want smart cards/PKCS #11/whatever want to use it with standard commercial software and, you know, that stuff with the 'X' and some digits in it :-). Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: OpenPGP Card
Lionel Elie Mamane wrote: > But there is indeed a case to be made that if the library implements a well-known, standard ABI, then linking to it is not a GPL violation. > Legally it depends whether the linked program is a "derived work" from the program or not. But PKCS#11 is not a library you link against! It is an API specification. There is no proprietary code you link into your program in order to implement this standard. > GnuPG doesn't *link* to RAID drivers or video drivers. They don't end up "running linked together in a shared address space". > They communicate over syscalls or sockets; mechanisms that are well-known as to be "GPL-safe" (as long as the coupling between them isn't > too tight). See http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation . I think you should read PKCS#11 specification... You cannot call it "combining two parts into a program" PKCS#11 is a specification, you don't provide the implementation along with your program, the specification is EXACTLY the same as protocol or command line specification. Like you can use HTTP protocol, since you have RFC that state how, you use cryptographic token since you have PKCS#11 that tells you how. Since you don't provide the PKCS#11 provider implementation along with your GPLed distribution and that there is a complete API specification of the interface, it does not fall into the "combined program". > On the other hand, some people interpret the GPL in a way saying that if a library implements a "standard" ABI, then one can link GPL software > to it. I think it is a good idea to stick to the copyright holder's interpretation. I don't understand this statement... >> I can show you that it GPLed program loads these drivers... > Yes, show me, I'm curious. Examples: opensc from www.opensc.org - LGPL uses PKCS#11 pkcs11_login from www.opensc.org - LGPL uses PKCS#11 openCryptoki from http://sourceforge.net/projects/opencryptoki - GPL uses PKCS#11 Best Regards, Alon Bar-Lev. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
