Hello, On Feb 16, 2011, at 5:19 PM, Viktor TARASOV wrote: > On 16.02.2011 13:34, Martin Paljak wrote: >> On Feb 16, 2011, at 1:01 PM, webmas...@opensc-project.org wrote: >>> Revision: 5199 >>> Author: vtarasov >>> Date: 2011-02-16 11:01:46 +0000 (Wed, 16 Feb 2011) >>> >>> Log Message: >>> ----------- >>> IAS/ECC: for the IAS/ECC cards include into the OpenSC configuration the >>> 'card_atr' sections >> >> Why are these needed? card-iasecc.c also uses internal ATR table to match >> those ATR-s. > > It's not needed for the basic usage. > In IAS/ECC branch I use it to indicate the configuration section of Secure > Messaging used with particular card. > 'Local' version of SM module looks for the keysets values in the opensc.conf > file. I'll assume that there will be a set of default keys and the option to specify arbitrary keys. If there are *any* keys that are default to a set of cards (which could be identified by an ATR for example, or by some other programmatic means) then those keys should be built into OpenSC if technically possible. Unless there's some stupid intellectual property law forbidding this (and if this law can't be cheated somehow; or if the keys are otherwise confidential), it would still be required to be able to *build* such an "unlawful" binary. But of course what must remain is the possibility to specify random keys through the configuration file or some environment variable or command line option or whatever gets implemented.
Codebase of OpenSC should strive for complete code based solution, not for a "configurable toolset" (which should of course not be made totally impossible, if reasonable). The default, if possible, should be a static binary, not a set of modules and configuration files. Yes, eventually the system will depend on modules and configuration files to complete the interaction with the card, but having static code blobs gives several (security related) advantages in various situations. This is one more motivation to provide again the libopensc interface in the future, for direct linking into security-concious applications. >> As a general rule, OpenSC should be usable without a configuration file. A >> programmatic approach that could be statically compiled should be the >> default, with the configuration file as a solution to "fix and tune" things >> that don't work out of the box or otherwise can't be put into the default >> open source distributable package (think: vendor/setup specific secure >> messaging, which you want to put into opensc.conf) > Ok, I see. > What about the options from the 'pkcs15' and 'pkcs11' sections of opensc.conf > ? Should we still have possibility to tune them? Sure. Always. But code should not rely on external configuration for any use *if possible*. A missing configuration file should result in a normally functioning card (or reasonably failing tools and interfaces). Tuning the configuration file should be the result of knowledgeable actions *by the end user* and *only if needed*, not by a public distro packager or be present by default. End user here means a home user or an integrator at some company. >> Right now the only uncommented lines are for forcing the protocol selection >> onto otherwise broken cards. Which should also be changed to a flag in the >> ATR table and ATR tables of card drivers exposed to core. >> The same (ATR-s and masks) is needed to be flushed programmatically to >> Windows registry for Minidriver use. > >> Ideally packagers should be bugged to stop distributing opensc.conf >> installed into /etc(/opensc). > But still, there will be the possibility for OpenSC to read from somewhere > the pkcs15 and pkcs11 configuration options, isn't it ? Yes, through the configuration file. Which should be installed (or comments removed) *if necessary* not by default. Distributing opensc.conf in public RPM/DEB builds could be OK if it had 0 lines without comments. For more food for thought, see SecurityConsiderations [1] on OpenSC wiki (I'm sure I've missed something as well) [1] http://www.opensc-project.org/opensc/wiki/SecurityConsiderations -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
