This is a long email, but it goes direct to the source, namely RSA Labs. PKCS #11 is the definition, in the C++ programming language, of an API for use by an application requiring cryptographic services. The API provides a common way for the application to connect to a device that holds cryptographic information and performs cryptographic functions. Typically, an application within a PC obtains services from a smart card (the token) inserted in a reader/writer connected to the PC, but PKCS #11 is written in a general manner, so that, for example, the cryptographic service could be provided by a remote server.
Cryptographic tokens, such as Integrated Circuit Cards (or IC cards), are intrinsically secure computing platforms ideally suited to providing enhanced security and privacy functionality to applications. As noted by Matthias, PKCS #11 is implemented as a library in a PC. This library can included drivers for a specific combination of card reader and card, or, as noted above, it can connect to a network on which is a secure server. PKCS #15 is intended at establishing a standard which ensure that users in fact will be able to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application's cryptoki (or other token interface) provider. Thus PKCS #15 defines the file structure within the token (usually a smart card), and therefore also the skeleton of the 'card edge' interface (the commands used to access the token). Newly published is information about profiling the card edge and the card file structure to suit different applications. >From the RSA Labs Security web site: PKCS #15: Cryptographic Token Information Format Standard Background It is widely recognized that cryptographic tokens such as Integrated Circuit Cards (ICCs or Smart Cards) offer a great potential for secure identification of users of information systems. But if this potential is ever going to be fully realized, and users are to receive full benefit of these tokens, there is an obvious requirement of credential portability and interoperability. Interoperability demands standardization, and this document, PKCS #15, is intended at establishing a standard which ensure that users in fact will be able to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application's cryptoki (or other token interface) provider. Why is PKCS #11 not sufficient? The PKCS #11 specification alone can not offer this functionality since it is an API specification aimed at offering applications a uniform interface to cryptographic tokens. This means that different tokens requires different PKCS #11 drivers, and unless a user's desktop has the 'right' PKCS #11 driver installed, the user will be unable to use the token on that desktop. What does 'Information Format for Cryptographic Tokens' mean? This means that we need to agree on the syntax for storing digital credentials (keys, certificates, etc) on these tokens, and how this information are to be accessed. If such an agreement can be met, we have a very good platform to achieve the goals of this work. Objectives Some important objectives of PKCS#15 are: ? Enable interoperability among components running on various platforms (platform neutral). ? Enable applications to take advantage of products and components from multiple manufacturers (vendor neutral). ? Enable the use of advances in technology without rewriting application-level software (application neutral). ? Maintain consistency with existing, related standards while expanding upon them only where necessary and practical. Users should be able to use their tokens for identification purposes in all applications where this is necessary To download the PKCS standards and PKCS #15 profile specification, start at: http://www.rsasecurity.com/rsalabs/pkcs/index.html and select the PKCS # that you require. > > ----- Original Message ----- > From: Matthias Bruestle <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, October 17, 2001 3:57 PM > Subject: Re: MUSCLE SC architecture, puzzled > > > > Mahlzeit > > > > > > On Wed, Oct 17, 2001 at 04:11:39PM +0200, Radovan Semancik wrote: > > > 1) PCKS#11 - I've understood that this is an application-level API, that > > > means API between application (netscape) and some kind of driver. What > > > is that 'driver', is it resource manager or what? > > > > It is a library implementing the PKCS#11 API. > > > > > Is it specific to a > > > smartcard type or may I use the same 'driver' for gemplus and > > > schlumberger cards? > > > > It is specific to a smart card type. > > > > > 2) How can a card provide PKCS#11 interface? > > > > The smart card does not provide a PKCS#11 API. A library on the host, > > which communicatates with the card, does this. > > > > > If that is the case, what protocol do they communicate? A proprietary > > > one or some standard? > > > > The library can use protocols what ever the smard card understands. > > So in most cases the commands are exchanged via T=0 or T=1 and the > > data is put on the card into files, etc.. The data layout of these > > files could be according to PKCS#15. > > > > > > Mahlzeit > > endergone Zwiebeltuete > > > > *************************************************************** > > Unix Smart Card Developers - M.U.S.C.L.E. > > (Movement for the Use of Smart Cards in a Linux Environment) > > http://www.linuxnet.com/ > > To unsubscribe send an email to [EMAIL PROTECTED] with > > unsubscribe sclinux > > *************************************************************** > > > *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
