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 -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
