Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

MDS Schema Definition

Module Directory Services standardize a set of schemas and programming interfaces that enable any software object to locate information about any other software object. A set of CDSA-specific schemas are also defined to support CDSA components discover the properties of other CDSA components.

Object Directory Database and the Object Relation

The root MDS Object Directory is a single relation in an MDS database named MDS Object Directory. The database location is registered at MDS installation time with the host platform registry services (for example, Windows registry or UNIX configuration file). The database contains a single relation identified by a relation ID.

The schema for the Object Directory relation is defined in the following table:

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying a collection of software objects (module)
  Manifest BLOB Signed-manifest describing the module
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  Path STRING Module search path in platform-specific format.
  ProductVersion STRING Product version string (in dotted high/low format - e.g. 2.0)

* Indicates the primary database key.

The Object relation contains one record for each instance of a CSSM. Each instance of a CSSM must create entries in the Object relation when CSSM is installed. Any new CDSA applications that have a manifest and need CSSM to do bilateral authentication must insert entries in the Object relation. The primary purpose of the object relation is to support bi-lateral authentication between applications and CSSM. Any other CDSA components added to the platform overtime (such as service providers and Elective Module Managers) are not required to add a record to the Object Relation. These CDSA components must add records to other CDSA-specific relations defined later in this specification. The additional information stored in the CDSA-specific relations is required by other CDSA components for successful cross-check and use of CDSA service provider, EMMs, and applications. These records are added to CDSA-specific relations as part of the installation process for that CDSA component.

Typically each CDSA module has exactly one record in the Object Relation. If a third party redistributes a module, and the redistributed manifest signature differs but the object itself is unchanged, the signatures of the redistributed objects are appended to the manifest structure and the augmented manifest is inserted into the existing MDS record by the installation program for the module. The ModuleID remains the same and there is a single record for this module. If an object module changes such that the hash of that module changes, then a new ModuleID must be generated and a new additional record containing the new ModuleID and the new signed manifest must be added to the Object Directory relation by the module's installation program.

The Object Directory contains also relations defining its schema, namely MDS_SCHEMA_RELATIONS, MDS_SCHEMA_ATTRIBUTES, MDS_SCHEMA_INDEXES, which have the same form as those described at MDS Schema Relation. The schema relations can be queried by users and applications, but cannot be modified by users or applications.

CDSA Directory Database

MDS supports a CDSA-specific set of schemas in a database called MDS CDSA Directory. The database location is registered at MDS installation time with the platform specific registry service (for example, Windows registry, UNIX config file, etc.) The CDSA directory database file contains relations that are identified by relation Ids. The implemented CDSA relation Ids are registered with the platform-specific registry service.

The information stored in the CDSAA Directory database is provided to:

The CDSA schemas focus on CDSA security service provider modules and CDSA Elective Module Managers. Each module type has one or more corresponding relations containing module-specific information. The CDSA-specific schemas are defined in the following sections.

CSSM Relation

This relation defines attributes of an instance of CSSM.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying a CSSM module.
  CDSAVersion STRING CSSM Version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING CSSM Vendor name in ASCII text.
  Desc STRING CSSM description in ASCII text.
  NativeServices** uint32 Set of service managers which are native to CSSM. This information is a CSSM_SERVICE_MASK.

*
Indicates the primary database key.

**
In the NativeServices, CSSM can describe all services that are implemented natively. If a module service type is set in the Native services, then CSSM implements the service type. If not set, the module may be implemented as an EMM.

KRMM Relation

This relation defines attributes of an instance of KRMM.

  Field Name Field Data Type Comment
* CSSMGuid STRING GUID (in string format) uniquely identifying a CSSM module.
* PolicyType unit32 Flag identifying the KR policy type.
  PolicyName STRING Human readable name of the module containing the policy information.
  PolicyPath STRING Module search path in platform-specific format.
  PolicyInfo BLOB Additional policy information, used by CSSM.
  PolicyManifest BLOB Signed maifest describing the module

EMM Relation

This relation defines attributes of a CDSA Elective Module Manager. This relation contains information that allows the CSSM to perform cross-check operations before loading the EMM. There is a single entry for each EMM installed on the system. The Version string is used by CSSM to identify interoperable EMMs.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) identifying EMM modules
  Manifest BLOB Signed-manifest describing the EMM module
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  Path STRING Library search path. Contains locations where EMM modules and EMM service provider modules are installed. Path is in platform specific format (Windows, UNIX, Mac).
  CDSAVersion STRING Highest compatible CDSA Version (in dotted high/low format - e.g. 2.0).
  EMMSpecVersion STRING Highest compatible EMM spec Version (in dotted high/low format - e.g. 2.0).
  Desc STRING Module description
  PolicyStmt BLOB Any policy statement defined and managed by this EMM.
  EmmVersion STRING EMM manufacturer version string (in dotted high/low format - e.g. 2.0).
  EmmVendor STRING EMM manufacturer/vendor name in ASCII text.
  EmmType UINT32 Module service type supported by the EMM.

* Indicates the primary database key.

As new EMMs are defined, additional information can be required. New relations can be created in MDS to store this information. To add update existing relations or add new relations, the CDSA Directory database is closed for general use and re-opened for administrative use. A unique CDSA RelationType value must be defined and associated with each new MDS relation.

Primary EMM Service Provider Relation

This relation contains credentials that are introduced to the system by dynamic EMM service providers. CSSM queries this table at module-load time to locate and verify credentials for the EMM service provider module.

  Field Name Field Data Type Comment
* ModuleID STRING identifying the service provider module
* SSID UINT32 4 byte Subservice ID
* ServiceType UINT32 Flag identifying the CSSM_SERVICE_TYPE of the service provider module. The integer corresponds to symbols of type CSSM_SERVICE_TYPE.
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider.
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  Version STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  SampleTypes MULTIUINT32 An array of 4-byte integers representing the sample types accepted by the service provider. The integers correspond to symbols of type CSSM_SAMPLE_TYPE
  Acl SubjectTypes MULTIUINT32 An array of 4-byte integers representing the ACL subject types accepted by the service provider. The integers correspond to symbols of type CSSM_ACL_SUBJECT_TYPE
  AuthTags MULTIUINT32 An array of 4-byte integers representing the Authorization tag values defined by the service provider. The integers correspond to symbols of type CSSM_ACL_AUTHORIZATION_TAG
  EMMSpecVersion STRING Highest compatible EMM spec Version (in dotted high/low format - e.g. 2.0)

* Indicates the primary database key.

Common Relation

The Common Relation contains information common to all CDSA service provider modules. Information in this table uses the module GUID as a unique key. The Manifest element describes the library that performs event notification and exports CDSA interfaces. The ModuleName element is the name of the library file. Path is the search path used to find installed modules. Path also describes manifests that may be introduced to the system by dynamic service providers. See also the Primary Relation schema defines in this specification.

This relation will be updated during service provider installation and deinstallation.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
  Manifest BLOB Signed-manifest describing the module
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  Path STRING Module installation path in platform specific format (Windows, UNIX, Mac).
  CDSAVersion STRING Highest compatible CDSA Version (in dotted high/low format - e.g. 2.0).
  Desc STRING Module description
  DynamicFlag UINT32 Module supports dynamic subservices
  MultiThreadFlag UINT32 Module requires CSSM to serialize access. This flag will be deprecated in future, as it cannot be enforced in an environment with multiple CSSMs in the same process space (two independent CSSMs using the same addin will be unaware of the other's threadsafe mutex)
  ServiceMask UINT32 Service Mask of all supported service types. The integer corresponds to symbols of type CSSM_SERVICE_MASK.

* Indicates the primary database key.

CSP Primary Relation

The CSP Primary Relation describes attributes of a cryptographic service provider. The ModuleID and sub-service ID (SSID) uniquely identify the CSP. The information in this relation can change each time a CSP is inserted or removed from the running system.

Dynamic cryptographic service providers may produce a secondary manifest describing new components introduced to the system and the use exemption (USEE) privileges supported by the service provider. The Manifest field will be empty if no new components or privileges are made available at token insertion.

The USEE tag values in this table must be verified against the actual values in the module manifest before granting security-critical privileges.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) for service provider module
* SSID UINT32 4 byte Subservice ID
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  ProductVersion STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  CspType UINT32 Implementation type, e.g. software/hardware (4 bytes). The integers correspond to symbols of type CSSM_SERVICE_MASK.
  CspFlags UINT32 Flags (4 bytes). The integers correspond to symbols of type CSSM_CSP_FLAGS.
  CspCustomFlags UINT32 More Flags (4 bytes)
  UseeTags MULTIUINT32 Array of 4-byte INTEGERS containing the USEE tag values supported by the Service provider module. The integers correspond to symbols of type CSSM_USEE_TAG
  SampleTypes MULTIUINT32 An array of 4-byte integers representing the sample types accepted by the service provider. The integers correspond to symbols of type CSSM_SAMPLE_TYPE
  Acl SubjectTypes MULTIUINT32 An array of 4-byte integers representing the ACL subject types accepted by the service provider. The integers correspond to symbols of type CSSM_ACL_SUBJECT_TYPE
  AuthTags MULTIUINT32 An array of 4-byte integers representing the Authorization tag values defined by the service provider. The integers correspond to symbols of type CSSM_ACL_AUTHORIZATION_TAG

* Indicates the primary database key.

CSP Capabilities Relation

The Cryptographic Service Provider (CSP) Capabilities relation contains attribute information for cryptographic services. Each CSP can have multiple entries. All fields except AttributeValue and Description form the concatenated primary database key. The description string is a short (about 64 bytes) description of the algorithm identified by the AlgType field.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying the CSP module
* SSID UINT32 4 byte Subservice ID
* UseeTag UINT32 4-byte USEE tag associated with the attribute values. The integer correspond to symbols of type CSSM_USEE_TAG.
* ContextType UINT32 Class of cryptographic information (4 bytes) The integers correspond to symbols of type CSSM_CONTEXT_TYPE
* AlgType UINT32 Cryptographic algorithm supported by CSP (4 bytes). The integers correspond to symbols of type CSSM_ALGORITHMS.
* GroupId UINT32 4-byte identifier grouping all of the attributes associated with a single AlgType
* AttributeType UINT32 CSP attribute tag to identify the attribute value. The integers correspond to symbols of type CSSM_ATTRIBUTE_TYPE.
  AttributeValue MULTIUINT32 Array of 4-byte values having the same AttributeType.
  Description STRING Human readable description of the algorithm (AlgType)

* Indicates the primary database key.

The AttributeValue field contains a list of the attributes expressed as 4-byte scalars corresponding to namespace as controlled by the CDSA specification. Each array of values is relative to the fields comprising the database key.

The use exemption (USEE) tag value of none (0) is used to describe the base capabilities of the CSP. All non-restricted algorithms and attributes are populated under USEE tag none. Restricted algorithms and appropriate key sizes have entries suitable for other USEE tag values.

Several attribute types defined by CDSA do not describe capabilities of a cryptographic service provider. These attribute types are not recorded with MDS. They are:

Conventions for expressing attribute values as a MULTIUINT32 data type are described in terms of the attribute data type tag:

The CSSM_ATTRIBUTE_CUSTOM type can be specified. The service provider vendor is responsible for defining conventions for interpreting each member of the MULTIUINT32 element.

CSP Encapsulated Products Relation

This relation defines the attributes describing an third party, encapsulated product that is used in the implementation of the Cryptographic Service Provider. Information in the CSP Encapsulated Products relation is optional. It is provided at installation time by the CSP vendor. There are three classes of information:

  1. A software product used in the implementation of the CSP.

  2. A standard to which the implementation complies.

  3. A reader device used for removable tokens/smartcards.

CSP vendors define the format of STRING fields. The format for flags fields is specific to the encapsulated product.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  ProductDesc STRING ASCII text description of the product encapsulated by the implementation.
  ProductVendor STRING ASCII text description of a software product encapsulated by the implementation.
  ProductVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ProductFlags UINT32 Flags (4 bytes)
  CustomFlags UINT32 More flags (4 bytes)
  StandardDesc STRING String describing the standards complied to by the implementation (e.g. PKCS11)
  StandardVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ReaderDesc STRING ASCII text description of the token reader device.
  ReaderVendor STRING ASCII text description of the reader device vendor.
  ReaderVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ReaderFirmwareVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ReaderFlags UINT32 Flags (4 bytes). Currently valid values include:
- CSSM_CSP_RDR_EXISTS (0x00000002):
  Device is a reader with removable token
- CSSM_CSP_RDR_HW (0x00000004):
  Reader is a physical device
  ReaderCustomFlags UINT32 More flags (4 bytes)
  ReaderSerialNumber STRING Text representation of the token reader device serial number.

* Indicates the primary database key.

CSP SmartcardInfo Relation

The information in the CSP Smartcard relation is updated each time a smartcard is inserted or removed from a reader device. The information is optional. CSP vendors define the format for STRING fields. The format for flags fields are specific to the smartcard.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  ScDesc STRING ASCII text description of the smartcard.
  ScVendor STRING ASCII text description of a smartcard.
  ScVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ScFirmwareVersion STRING Version string (in dotted high/low format - e.g. 2.0).
  ScFlags UINT32 Flags (4 bytes). Currently valid values include:
- CSSM_CSP_TOK_RNG (0x00000001)
  Device has a hardware random number generator
- CSSM_CSP_TOK_CLOCK_EXISTS (0x00000040)
  Device has built-in real-time clock
  ScCustomFlags UINT32 More flags (4 bytes)
  ScSerialNumber STRING Text representation of the smartcard serial number.

* Indicates the primary database key.

DL Primary Relation

The DL Primary relation describes capabilities of Data Library modules. If the DL is a dynamic module and new objects are introduced to the system as a result of Insert event notification, the Manifest field will contain integrity credentials for these objects. This table may be updated in conjunction with CSSM Insert and Remove events.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider.
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  ProductVersion STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  DLType UINT32 Flag describing the backend implementation approach. The integer correspond to symbols of type CSSM_DLTYPE.
  QueryLimitsFlag UINT32 Flag indicating query limits will be performed. Valid values include CSSM_QUERY_TIMELIMIT_NONE and CSSM_QUERY_SIZELIMIT_NONE.
  SampleTypes MULTIUINT32 An array of 4-byte integers representing the sample types accepted by the service provider. The integers correspond to symbols of type CSSM_SAMPLE_TYPE
  Acl SubjectTypes MULTIUINT32 An array of 4-byte integers representing the ACL subject types accepted by the service provider. The integers correspond to symbols of type CSSM_ACL_SUBJECT_TYPE
  AuthTags MULTIUINT32 An array of 4-byte integers representing the Authorization tag values defined by the service provider. The integers correspond to symbols of type CSSM_ACL_AUTHORIZATION_TAG
  ConjunctiveOps MULTIUINT32 Array of 4-byte integers describing the supported conjunctive operators.
  RelationalOps MULTIUINT32 Array of 4-byte integers describing the supported relational operators.

* Indicates the primary database key.

DL Encapsulated Products Relation

The DL Encapsulated Products Relation provides information about third party products that are used in the implementation of the DL services. This information is optional, but it can be useful to users of the DL service provider.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying a service provider module
* SSID UINT32 4 byte Subservice ID
  ProductDesc STRING ASCII text description of the commercial product encapsulated by the implementation. This string is typically a product name. Examples include "Oracle RDBMS*", "GemStone*", "Microsoft Access"
  ProductVendor STRING ASCII text providing the name of the vendor of the encapsulated product. This string is the commercial business name of the vendor who markets the encapsulated product.
  ProductVersion STRING ASCII string providing a version number for the product named in the Product Description. The version number is formatted in dotted high/low format - e.g. 2.0.
  ProductFlags UINT32 Flags describing product-specific features provided by the encapsulated product and used by the DL service provider to provide service to users. Examples include:
- support for and use of stored data base queries
- support for and use of audit trails
- support for and use of virtual data views (4 bytes).
  StandardDesc STRING ASCII string describing an industry standard supported by the encapsulated product. Examples include:
- an encapsulated RDBMS can support industry standard SQL
- an encapsulated OODBMS can support industry standard O-SQL.
Multiple standards can be listed in a semicolon-separated list.
  StandardVersion STRING ASCII string providing a version number for the industry standard named in the Standard Description. The version number is formatted in dotted high/low format - e.g. 2.0.
  Protocol UINT32 Identifies the CSSM_NET_PROTOCOL supported by the encapsulated product (if any). Examples include CSSM_NET_PROTO_LDAP, CSSM_NET_PROTO_NDS, CSSM_NET_PROTO_HTTP
  RetrievalMode UINT32 Retrieval modes supported by the service provider. The integer corresponds to the symbols of type CSSM_DB_RETRIEVAL_MODES.

* Indicates the primary database key.

CL Primary Relation

The CL Primary relation describes capabilities of Certificate Library modules. If the CL is a dynamic module and new objects are introduced to the system as a result of CSSM event notification, the Manifest field will contain integrity credentials for these objects. This relation can be updated in conjunction with CSSM Insert and Remove events.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  ProductVersion STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  CertTypeFormat UINT32 Certificate standard (e.g. X.509) & format (e.g. BER/DER). High word (2 bytes) is type, low word (2 bytes) is format. The high word (type) corresponds to symbols of type CSSM_CERT_TYPE and low word (format) corresponds to symbols of type CSSM_CERT_ENCODING.
  CrlTypeFormat UINT32 Certificate revocation record format. The standard (e.g. X.509) & encoding format (e.g. BER/DER) are in high word low word. High word (2 bytes) is type, low word (2 bytes) is format. The high word (type) corresponds to symbols of type CSSM_CERT_TYPE and low word (format) corresponds to symbols of type CSSM_CERT_ENCODING.
  CertFieldNames BLOB Encapsulated array of OIDs in <length> <OID> format. Length is a 4-byte length followed by OID. The length byte order is in platform specific format.
  BundleTypeFormat MULTIUINT32 Encapsulated array of the supported standards for importing collections of certificates into CertGroups. Certificate collection standard (e.g. PKCS7) & encoding format (e.g. BER/DER) where high word (2 bytes) is Type, low word (2 bytes) is Format. The high word (type) corresponds to symbols of type CSSM_CERT_TYPE and low word (format) corresponds to symbols of type CSSM_CERT_ENCODING.
  XlationTypeFormat MULTIUINT32 Encapsulated array of supported standards for translating certificate formats. The certificate standard is the high word (2 bytes) as Type (e.g. X.509) & the low word (2 bytes) as encoding format (e.g. BER/DER).
  DefaultTemplateType UINT32 An integer identifying the default template type
  TemplateFieldNames BLOB Encapsulated array of OIDs in <length> <OID> format. Length is a 4-byte length followed by OID. The length byte order is in platform specific format.

* Indicates the primary database key.

CL Encapsulated Products Relation

This relation provides implementation-specific information that may be useful to callers of the CL service provider. This relation can be used to describe a commercial product that is used to implement the CL module. Examples include third party Certification Authorities, Registration Authorities, and Authorization Servers.

  Field Name Field Data Type Comment
* ModuleID STRING GUID in string form describing service provider modules
* SSID UINT32 4 byte Subservice ID
  ProductDesc STRING ASCII text description of the commercial certificate services product or a certificate encode-decode product encapsulated by the implementation. This string is typically a product name. An example is "Snappy-soft ASN.1 Compiler"
  ProductVendor STRING ASCII text providing the name of the vendor of the encapsulated product. This string is the commercial business name of the vendor who markets the encapsulated product.
  ProductVersion STRING ASCII string providing a version number for the product named in the Product Description. The version number is formatted in dotted high/low format - e.g. 2.0.
  ProductFlags UINT32 Flags describing product-specific features provided by the encapsulated product and used by the CL service provider to provide service to users. Examples include BER encoding only, BER/DER encoding, S-expression parsing.
  StandardDesc STRING ASCII string describing an industry standard supported by the encapsulated product. Examples include:
- ASN.1 standard RFC 209
- SPKI S-expression IETF Draft spki-cert-theory-04 (November 1998)
Multiple standards can be listed in a semicolon-separated list.
  StandardVersion STRING ASCII string providing a version number for the industry standard named in the Standard Description. The version number is formatted in dotted high/low format - e.g. 2.0.

* Indicates the primary database key.

TP Primary Relation

The TP Primary relation describes capabilities of Trust Policy Library modules. If the TP is a dynamic module and new objects are introduced to the system as a result of CSSM event notification, the Manifest field will contain integrity credentials for these objects. This relation can be updated in conjunction with CSSM Insert and Remove events.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  ProductVersion STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  CertTypeFormat UINT32 Certificate standard (e.g. X.509) & format (e.g. BER/DER). High word (2 bytes) is type, low word (2 bytes) is format. The high word (type) corresponds to symbols of type CSSM_CERT_TYPE and low word (format) corresponds to symbols of type CSSM_CERT_ENCODING.
  SampleTypes MULTIUINT32 An array of 4-byte integers representing the sample types accepted by the servic e provider. The integers correspond to symbols of type CSSM_SAMPLE_TYPE
  Acl SubjectTypes MULTIUINT32 An array of 4-byte integers representing the ACL subject types accepted by the s ervice provider. The integers correspond to symbols of type CSSM_ACL_SUBJECT_TYP E
  AuthTags MULTIUINT32 An array of 4-byte integers representing the Authorization tag values defined by the service provider. The integers correspond to symbols of type CSSM_ACL_AUTHO RIZATION_TAG

* Indicates the primary database key.

TP Policy-OIDS Relation

The Policy OIDS relation lists the policy object identifiers recognized by the service provider. Information in the table can change in conjunction with CSSM Insert and Remove events. The policy objects implemented by the service provider are contained in this relation. There is an entry for each OID and Value. The ModuleID, SSID and OID fields identify a unique record.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
* OID BLOB Policy object identifier interpreted by module
  Value BLOB Accompanying information. Uses OID to interpret contents.

* Indicates the primary database key.

TP Encapsulated Products Relation

This relation provided information about any third party products used in the implementation of the Trust Policy services. This information is optional, but can be useful to users of the trust policy services.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying a service provider module
* SSID UINT32 4 byte Subservice ID
  ProductDesc STRING ASCII text description of the commercial certificate services product or a certificate encode-decode product encapsulated by the implementation. This string is typically a product name. Examples include World-authority Certificate Service, Corporate CA, Mini-server CA.
  ProductVendor STRING ASCII text providing the name of the vendor of the encapsulated product. This string is the commercial business name of the vendor who markets the encapsulated product.
  ProductVersion STRING ASCII string providing a version number for the product named in the Product Description. The version number is formatted in dotted high/low format - e.g. 2.0.
  ProductFlags UINT32 Flags describing product-specific features provided by the encapsulated product and used by the CL service provider to provide service to users. Examples include:
- Key archive and recovery service
- Support for Registration Authorities
- Online Certificate Revocation Services
- Online verification services (4 bytes)
  AuthorityRequestType MULTIUINT32 Encapsulated array of supported certification authority (TP) requests this service provider can submit to a TP process. Example request type values include:
CSSM_TP_AUTHORITY_REQUEST_CERTISSUE
CSSM_TP_AUTHORITY_REQUEST_CERTREVOKE
CSSM_TP_AUTHORITY_REQUEST_CERTVERIFY
CSSM_TP_AUTHORITY_REQUEST_CRLISSUE
  StandardDesc STRING ASCII string describing an industry standard supported by the encapsulated product. Examples include:
- IETF's OCSP for certificate revocation
- IETF's PKIX-3 for certificate requests and recovery
- PKCS#10 for certificate requests
Multiple standards can be listed in a semicolon-separated list.
  StandardVersion STRING ASCII string providing a version number for the industry standard named in the Standard Description. The version number is formatted in dotted high/low format - e.g. 2.0.
  ProtocolDesc STRING ASCII string describing the protocol used to perform certificate request. (e.g. CMP)
  ProtocolFlags UINT32 Flags describing protocol-specific features provided by the encapsulated product and used by the CL service provider to provide service to users(4 bytes)
  CertClassName STRING ASCII string naming a class or category of certificates managed by the encapsulated product. A certificate authority can issue multiple classes of certificates.
  RootCertificate BLOB The certificate of the encapsulated product. For a CA product, this is the CA's certificate. The certificate contains the trusted public key of the encapsulated product. The public key can be used for verification. The certificate is encoded as specified by RootCertTypeFormat
  RootCertType Format UINT32 Specifies the certificate form (e.g. X.509) & encoding (e.g. BER/DER). High word (2 bytes) is Type/Form, low word (2 bytes) is Encoding.

* Indicates the primary database key.

MDS Schema Relation

The following relations provide information about the schema definition of all the relations managed under MDS. Applications can query the relation to learn about the schema of the CDSA relations. Administrative application can update the relation when creating new relations in MDS or adding new attributes to existing relations in MDS.

The schema relations can be queried by users and applications, but cannot be modified by users or applications.

MDS_SCHEMA_RELATIONS is a relation containing one record for each relation defined for the database. All fields are searchable. RelationID is the primary database key for this relation.

  Field Name Field Data Type Comment
* RelationID UINT32 A unique integer value identifying a relation stored and managed by MDS. The CDSA relations are identified by integers in the range [CSSM_DB_RELATIONID_MDS_START, CSSM_DB_RELATIONID_MDS_END].
  RelationName STRING The relation name in ASCII text.

* Indicates the primary database key.

MDS_SCHEMA_ATTRIBUTES is a relation containing one record for each attribute defined for the MDS database. All fields are searchable. The starred(*) fields form the primary database key for this relation.

  Field Name Field Data Type Comment
* RelationID UINT32 A unique integer value identifying a relation stored and managed by MDS. The CDSA relations are identified by integers in the range [CSSM_DB_RELATIONID_MDS_START, CSSM_DB_RELATIONID_MDS_END].
* AttributeID UINT32 A number identifying an attribute in the relation identified by RelationId
  AttributeNameFormat UINT32 Format of AttributeName
  AttributeName STRING Name of attribute
  AttributeNameID BLOB Name of attribute expressed as an infinite precision number (aka OID).
  AttributeFormat UINT32 Data type of values associated with the attribute

* Indicates the primary database key.

MDS_SCHEMA_INDEXES is a relation containing one record for each index defined for the MDS database. All fields are searchable. The starred(*) fields form the primary database key for this relation.

  Field Name Field Data Type Comment
* RelationID UINT32 A unique integer value identifying a relation stored and managed by MDS. The CDSA relations are identified by integers in the range [CSSM_DB_RELATIONID_MDS_START, CSSM_DB_RELATIONID_MDS_END].
* IndexID UINT32 A number uniquely identifying an index. Unique indexes will use the same IndexID for each attribute (AttributeID) comprising the concatenated key of the unique index.
* AttributeID UINT32 An integer value uniquely identifying an attribute within the relation identified by RelationID.
  IndexType UINT32 Type of index (part of the unique index or a non-unique index).
  IndexedDataLocation UINT32 Source of the information used to create the index

* Indicates the primary database key.

AC Primary Relation

The AC Primary relation describes capabilities of Authorization Computation service provider modules. If the AC is a dynamic module and new objects are introduced to the system as a result of CSSM event notification, the Manifest field will contain integrity credentials for these objects. This relation can be updated in conjunction with CSSM Insert and Remove events.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider
  ModuleName STRING Human readable name. This is the filename of the library that performs cross-check operations.
  ProductVersion STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.

* Indicates the primary database key.

KR Primary Relation

The KR Primary relation describes capabilities of Key Recovery modules. If the KR is a dynamic module and new objects are introduced to the system as a result of CSSM event notification, the Manifest field of this relation contains integrity credentials for these dynamic objects. This relation can be updated in conjunction with CSSM Insert and Remove events to add or remove records as appropriate.

  Field Name Field Data Type Comment
* ModuleID STRING GUID (in string format) uniquely identifying service provider modules
* SSID UINT32 4 byte Subservice ID A subservice can be used to support different KR mechanisms. Examples include Encapsulation, Escrow.
  Manifest BLOB Signed-manifest describing the dynamic components of a service provider
  ModuleName STRING Manifest Section Name.
  CompatCSSMVersion STRING Lowest compatible CSSM version
  Version STRING Service provider version string (in dotted high/low format - e.g. 2.0).
  Vendor STRING Service provider vendor name in ASCII text.
  Description STRING Human-readable description of this KR subservice.
  ConfigFileLocation STRING Search path in platform-specific format for KR configuration files

* Indicates the primary database key.


Click here to return to the publication details.

Contents Next section Index