Hi,
I cannot speak for the Openswan project (though the smartcard code
was originally contributed by me but hasn't been maintained by
the Openswan team for more than two years) but I can explain the
current smartcard selection policy employed by strongSwan's
much improved PKCS#11 interface:
There are two ways to select a certificate:
a) by CKA_ID and optionally by slot
leftcert=%smartcard<optional slot nr>:<key id>
probably certs belonging to the same private key
will go into the same slot. Thus specification of the
slot won't help in differentiating multiple certs
having the same CKA_ID
b) by enumeration (positional parameter)
leftcert=%smartcard#<position>
During startup strongSwan queries the card[s] for all
certicates and and lists them in the order they were
found.
Example of my egate Token configured using pkcs15-init:
List of Smartcard Objects:
Feb 08 11:30:35 2006, #1, count: 4
slot: 0, session closed, logged out, has valid pin
id: 45
label: '/C=CH/O=strongSec GmbH/CN=bonsai.strongsec.com'
subject: 'C=CH, O=strongSec GmbH, CN=bonsai.strongsec.com'
Feb 08 11:30:35 2006, #2, count: 1
slot: 0, session closed, logged out, has no pin
id: 00
label: '/C=CH/O=strongSec GmbH/CN=strongSec Root CA'
subject: 'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
Feb 08 11:30:35 2006, #3, count: 5
slot: 1, session closed, logged out, has valid pin
id: 47
label: '/C=CH/O=HSR/OU=IntSec/CN=intsec.hsr.ch'
subject: 'C=CH, O=HSR, OU=IntSec, CN=intsec.hsr.ch'
Feb 08 11:30:35 2006, #4, count: 1
slot: 1, session closed, logged out, has no pin
id: 00
label: '/C=CH/O=HSR/OU=IntSec/CN=HSR IntSec Root CA'
subject: 'C=CH, O=HSR, OU=IntSec, CN=HSR IntSec Root CA'
strongSwan can now select one of the certs using the position
#1, #2, #3, #4. Currently in order to retrieve the desired certificate
and to use the private key, the 'slot' and the CKA_ID is used
for the actual query.
If according to your proposal all certs belonging to a common private
key must have the same CKA_ID then additionally I would have to
include either the 'subject' or 'the label in the PKCS#11 query
in order to achieve a unique resolution to a single cert.
Regards
Andreas
Peter Koch wrote:
Hi!
Before I programmed the PKCS#15 emulations routine for TCOS-cards
I downloaded the PKCS15-spec but it was too long and I was too lazy
to read it. So I just used my common sense. One consequence was
that I chosed unique IDs for certificates. I still believe that
a non-unique identifier does not fulfill its only purpose namely to
(uniquely) identify something. But read on. We all believe that
the ID of a certificate is an identifier of the certificate itself.
It's not :-)
Here's what I read in the PKCS11# and PKCS15# specification:
=====================================================================
PKCS#11, section 10.7.2: Common Key Attributes
"The CKA_ID field is intended to distinguish among multiple keys.
In the case of public and private keys, this field assists in
handling multiple keys held by the same subject; the key identifier
for a public key and its corresponding private key should be the
same. The key identifier should also be the same as for the
corresponding certificate, if one exists. Cryptoki does not enforce
these associations, however."
=====================================================================
PKCS#11, section 10.9: Private Key Attributes
"It is intended in the interests of interoperability that the subject
name and key identifier for a private key will be the same as those
for the corresponding certificate and public key. However, this is
not enforced by Cryptoki, and it is not required that the certificate
and public key also be stored on the token."
=====================================================================
PKCS#11, section 12.3.2: X509 Certificate Attributes
In Table 30:
Attribute=CKA_ID, Type=Byte array, Meaning=Key identifier for
public/private key pair (default empty)
"The CKA_ID attribute is intended as a means of distinguishing
multiple public-key/private-key pairs held by the same subject
(whether stored in the same token or not). (Since the keys are
distinguished by subject name as well as identifier, it is possible
that keys for different subjects may have the same CKA_ID value
without introducing any ambiguity.)"
Here's how I interpret PKCS#11. Keys are identified by a CKA_ID
value which must be unique for each object type. Corrensponding
private and public keys should have the same ID.
Certificates are NOT identified by a CKA_ID value, but the CKA_ID
value of a certificate is not an identifier of the certificate itself
but it references the id of the corresponding public/private key.
So the CKA_ID value should better be named CKA_KEY_ID.
=====================================================================
PKCS#15, section 5.5.3: Public Key Directory Files (PuKDFs)
"..... When the private key corresponding to a public key also resides
on the card, the keys must share the same identifier. ....
NOTE – When a certificate object on the card contains the public key,
the public key object and the certificate object shall share the same
identifier. This means that in some cases three objects (a private key,
a public key and a certificate) will share the same identifier."
=====================================================================
PKCS#15, section 5.5.5: Certificate Directory Files (CDFs)
"..... When a certificate contains a public key whose private key
also resides on the card, the certificate and the private key must
share the same identifier. ...."
So while PKCS#11 only recommends to use identical identifiers for
certificates and their corresponding keys, PKCS#15 makes this a MUST.
So I should change my TCOS-card emulation if I want to fulfill the
PKCS#15 spec.
On the other hand OpenSwan (and most likely other applications too)
use the ID of a certificate (which does not identify the certificate
itself, but the corresponding key) as a way to specify which certificate
they want to use.
This will not work (and according to PKCS#15 this is not supposed to
work) for cards that have more than one cert per key.
So OpenSwan should change change its way to select a certificate.
But maybe OpenSwan does not care about which certificate is used if
only the public key has the correct id.
Peter
=======================================================================
Andreas Steffen e-mail: [EMAIL PROTECTED]
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
