Public Member Functions | |
virtual | ~X509Certificate (void) |
X509Certificate (unsigned char *dataToSearch, int dataLen) | |
X509Certificate (const char *certPath) | |
string | getOid () |
string | getSerialNumber () |
virtual const char * | getDescription ()=0 |
virtual CK_OBJECT_CLASS | getClass () |
Protected Member Functions | |
X509Certificate (const char *oid, const char *desc, Token *thisToken, Session *session) | |
Protected Attributes | |
Key * | privKey |
X509 * | myData |
int | cka_id |
Static Protected Attributes | |
CK_KEY_TYPE | CERT_TYPE = CKC_X_509 |
CK_OBJECT_CLASS | CLASS = CKO_CERTIFICATE |
int | _CKA_ID = 1 |
|
Cleans up private members |
|
This constructor attempts to create 'this' object based on dataToSearch. Because the start position of the X509 object from the card has not shown itself to be in the same position everytime the byte stream is scanned and the X509 data is 'aligned' |
|
Lods this X509 cert from a file path #
|
|
Constructs this object from subclasses. The oid is essential to loading the object from the card. Any failure to load the card results in a Pkcs11Exception
|
|
In order to access an object on the card you must have the OID. As a result, it is required by all subclasses.
Implements PivObject. |
|
|
|
returns the description of this certificate -- distinguishing it from other X509 instances Implements CryptoObject. Implemented in X509ForCardAuth, X509ForDigitalSig, X509ForKeyMan, and X509ForPivAuth. |
|
returns the object class type as defined by Cryptoki. In the case it's CKO_CERTIFICATE
Reimplemented from GenericCryptoObject. |
|
a constant defining our certType for Cryptoki which is always CKC_X_509 |
|
a constant defining our class type for Cryptoki. This is always CKO_CERTIFICATE |
|
a handle to the private key. Hey, you never know if you're gonna need it |
|
a handle to the X509 data structure as represented on the card. It IS the model behind 'this' object |
|
Cryptoki doesn't require, but strongly recommends, that you have a CKA_ID that can tie a pubkey/privkey/X509 cert together, while still allowing for a serial number that may nor may not be the same In our case, we do implement it, and I have thought about making it equal to the serial number for consistency sake. But I never got around to it. This object is incremented with every construction. Think of it as a unique id that ties the 3 parts of the cert together |
|
The member value of the CKA_ID. This is the one that will be saved as an attribute |