|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Eric Perlin (ericperl
MICROSOFT.COM)Date: Thu Jul 12 2001 - 21:07:01 CDT
I am not really sure why you would need to duplicate any information
between the 2 databases.
All the entries maintained in Calais\SmartCards would be used by the
Scardxxx APIs and your software would use additional keys in its own DB.
I am not preventing you to add more keys in there. I am just telling you
it could move without notice.
What the code in autoreg.cpp does is add fallback code in case the Scard
DB calls fail.
Nothing in there is supposed to work forever.
It looks like you have feedback about the PC/SC specifications.
Maybe you want to join the workgroup...
-----Original Message-----
From: Pavel Hrdina [mailto:paul
COMPELSON.COM]
Sent: Thursday, July 12, 2001 6:08 AM
To: SmartCardSDK
DISCUSS.MICROSOFT.COM
Subject: Re: Rules for using the registry
Importance: High
Very thanks to your answer, Eric.
So it means that i must hold the other database of smart card types with
only some subset of standard information ("CardTypeName", ATR, ATRMask,
and some custom information). It's very complicated to hold some
consistency between information in "HKLM\...\Calais\SmartCards" and in
the private database. Also I can't know such links like "Crypto
Provider" etc.
But, if you look into CSPDK, file \csp\autoreg.cpp, routine
DllRegisterServer, part between #ifdef SCARD_CSP and #endif, you'll find
some assumption about the registry key. The case 0 tries to use the W2K
routine SCardSetCardTypePrividerName (which is the preferred way),
*BUT* cases 1 and 2 do that by direct access to the ".....\SmartCards"
key. How those assumptions can be made ? Or should I understand it like
"this is for old systems only, where the key is well known, so it
considered as OK" ?
Anyway, the reason I want to add some information under some smart card
types is that the Primary Provider (and its interfaces) is "more than
unusable". There are only few implementations, but very limited and
really unusable. Also the interface SCardVerify, for example, is not
generic, you must know something about its implementation to
successfully use it. And so on ... and so on. So I'm trying to design
some interface(s) which will be really *GENERIC*, so the application
don't care about the card type, its specific features, but is able to
work with all cards (supporting at least what the application
needs)
in very generic way. That's really something what is still missing.
And what do you think it can be the best place to put the link between
smart card type and the information about the generic interface which
knows this card type ? (I think it is the same place as for "Primary
Provider", "Crypto Provider", etc. So the information I can put to that
place should be named for example "Generic Provider" :-)))
Best regards,
Paul
-----Original Message-----
From: SmartCardSDK [mailto:SmartCardSDK
DISCUSS.MICROSOFT.COM]On Behalf
Of Eric Perlin
Sent: Wednesday, July 11, 2001 6:34 PM
To: SmartCardSDK
DISCUSS.MICROSOFT.COM
Subject: Re: Rules for using the registry
You cannot assume that. That's why there are APIs to read and write to
those keys. I recommend that you store your info in a separate location
that your software would know.
Like HKLM\Software\Compelson\SmartCards
-----Original Message-----
From: Pavel Hrdina [mailto:paul
COMPELSON.COM]
Sent: Wednesday, July 11, 2001 1:31 AM
To: SmartCardSDK
DISCUSS.MICROSOFT.COM
Subject: Rules for using the registry
I have one question mostly related to someone from Microsoft, the only
instance which can answer responsibly to this kind of questions.
The question is related to using the registry key
HKLM\Software\Microsoft\Cryptography\Calais\SmartCards.
As I know this key is used for storing information about introduced
smart cards in all MS OSs I've ever seen (from Win95 and WinNT4). And
the information under it is very standard in all those systems. Right
under that key there are subkeys fo every introduced card. And under
every such key are some standard values:
ATR, REG_BINARY
ATRMask, REG_BINARY
Primary Provider, REG_BINARY
Supported Interfaces, REG_BINARY
Crypto Provider, REG_SZ
And now the question:
Can I assume the key name will remain the same in the fututre, can I add
some custom value (with custom name) uder some card keys to provide the
link between smart card type and some custom generic library ? (If it is
possible but with some restrictions like the name of the custom value
must be approved by MS, it's still OK)
Thanks a lot for any answer
Paul
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]