Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
isode.com / support / deployment notes /Isode Statement of X.500 (2005) Conformance for Directory Products
The following table is derived from the X.500 Conformance Specifications taken from Section 13 of X.519 (2005). This conformance requirement sets out a number of "statement requirements", where a product should specify the elements of service in X.500 to which conformance are claimed. It then sets out what a product claiming conformance to a given element of service should do. This document provides conformance statements for the Isode directory products.
This document applies to Isode M-Vault R14.2.
| X.500 Conformance Statement Requirement | Isode DUA Conformance Statement |
|---|---|
13.1.1 Statement requirements for DUAs The following shall be stated: |
This section applies to Isode’s Directory Client API and to Sodium, Isode’s Administrative DUA. |
| a) the operations of the directoryAccessAC application-context and/or dap-ip protocol that the DUA is capable of invoking for which conformance is claimed | directoryAccessAC |
| b) the bind security level(s) for which conformance is claimed (none, simple, strong – and if simple, then whether without password, with password or with protected-password); and whether the DUA can generate signed arguments or validate signed results; | None; simple with/without password; strong; Signed arguments and signed results |
| c) the extensions listed Table 1 of ITU-T Rec. X.511 | ISO/IEC 9594-3, that the DUA is capable of initiating for which conformance is claimed; | subentries, copyShallDo, attributeSizeLimit, extraAttributes,
modifyRightsRequest, matchedValuesOnly, targetSystem, useAliasOnUpdate,
newSuperior, replaceValues. Partial support for ManageDSAIT, but conformance not claimed. |
| d) whether conformance is claimed to Rule-based Access Control; and | no |
| e) if conformance is claimed for strong authentication, or signed operations, identification of the Certificate and CRL extensions for which conformance is claimed. | The following certificate extensions: are supported: keyUsage,
basicConstraints, nameConstraints, cRLDistributionPoints. pathLenConstraint is supported, but follows RFC 3280, which differs slightly from X.509. The following CRL extensions are supported: cRLNumber, crlScope (deprecated), issuingDistributionPoint, deltaCRLIndicator |
13.2.1 Statement requirements for DSAs The following shall be stated: |
The following sections apply to Isode's DSA, M-Vault. |
| a) The application-contexts and IDM protocols for which conformance
is claimed: directoryAccessAC, directorySystemAC,
directoryOperationalBindingManagementAC, dap-ip,
dsp-ip, dop-ip, or a combination
of these. A DSA that claims conformance to the directoryOperationalBindingManagementAC
or to the dop-ip in support of hierarchical operational bindings
shall also support the directorySystemAC or dsp-ip.
If a DSA is such that knowledge of it has been disseminated, causing
knowledge references to the DSA to be held in other DSAs outside
of its own DMD, then it shall claim conformance to the directorySystemAC
or dsp-ip. NOTE 1 – An application context
shall not be divided except as stated herein; in particular, conformance
shall not be claimed to particular operations. |
directoryAccessAC and directorySystemAC |
| b) The operational binding types for which conformance is claimed: shadowOperationalBindingID, specificHierarchicalBindingID, non-specificHierarchicalBindingID, or a combination of these. A DSA that claims conformance to the shadowOperationalBindingID shall support one or more of the application contexts for shadow suppliers and/or shadow consumers indicated in 13.3 and 13.4. | shadowOperationalBindingID |
| c) Whether or not the DSA is capable of acting as a first level DSA, as defined in ITU-T Rec. X.518 | ISO/IEC 9594-4. | Can act as first level DSA |
| d) If conformance is claimed to the application-context specified by directorySystemAC and/or associated with the dap-ip protocol, whether or not the chained mode of operation is supported, as defined in ITU-T Rec. X.518 | ISO/IEC 9594-4. | Chained mode is supported |
| e) If conformance is claimed to the application-context specified by directoryAccessAC and/or associated with the dap-ip protocol, the bind security level(s) for which conformance is claimed (none, simple, strong – and if simple, then whether without password, with password, or with protected password); whether the DSA can perform originator authentication as defined in 22.1 of ITU-T Rec. X.518 | ISO/IEC 9594-4 and if so, whether identity-based or signature-based; and whether the DSA can perform result authentication as defined in 22.2 of ITU-T Rec. X.518 | ISO/IEC 9594-4. | None, simple with/without password, and strong are supported. Signature-based originator authentication is performed. Result authentication is performed. |
| f) If conformance is claimed to the application-context specified by directorySystemAC and/or associated with the dsp-ip protocol, the bind security level(s) for which conformance is claimed (none, simple, strong – and if simple, then whether without password, with password, or with protected password); whether the DSA can perform originator authentication as defined in 22.1 of ITU-T Rec. X.518 | ISO/IEC 9594-4 and if so, whether identity-based or signature-based; and whether the DSA can perform result authentication as defined in 22.2 of ITU-T Rec. X.518 | ISO/IEC 9594-4. | None, simple with/without password, and strong are supported. Signature-based originator authentication is performed. Result authentication is performed. |
| g) The selected attribute types defined in ITU-T Rec. X.520 | ISO/IEC 9594-6, and any other attribute types, for which conformance is claimed and whether for attributes based on the syntax DirectoryString, conformance is claimed for the UniversalString, BMPString, or UTF8String choices. | UniversalString, BMPString and
UTF8String are all supported All of the attributes specified in X.520(2005) are supported, with the exception of: uUIDPair; all “Notification” attributes. Support for other attributes is set out in the M-Vault Conformance Web Page. |
| h) The selected object classes defined in ITU-T Rec. X.521 | ISO/IEC 9594-7, and any other object classes, for which conformance is claimed. | All of the object classes of X.521(2005) are supported. Support for other object classes is set out in the M-Vault Conformance Web Page. |
| i) The extensions listed in Table 1 of ITU-T Rec. X.511 | ISO/IEC 9594-3, that the DSA is capable of responding to for which conformance is claimed. | Supported: subentries, copyShallDo, attributeSizeLimit, extraAttributes,
modifyRightsRequest, pagedResultsRequest, matchedValuesOnly, targetSystem,
useAliasOnUpdate, newSuperior, replaceValues.
Partial support for ManageDSAIT, but conformance not claimed. |
| j) Whether conformance is claimed for collective attributes as defined in 8.9 of ITU-T Rec. X.501 | ISO/IEC 9594-2 and 7.6, 7.8.2 and 9.2.2 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | Partial support, but conformance not claimed. |
| k) Whether conformance is claimed for hierarchical attributes as defined in 7.6, 7.8.2 and 9.2.2 of ITU-T Rec. X.511 | ISO/IEC 9594-3 | Yes. |
| l) The operational attribute types defined in ITU-T Rec. X.501 | ISO/IEC 9594-2 and any other operational attribute types for which conformance is claimed. | All of the operational attribute types defined in X.501(2005) are supported, except for: ServiceAdminSubentry; subschemaSubentryList; accessControlSubentryList; collectiveAttributeSubentryList; contextDefaultSubentryList; serviceAdminSubentryList; contextAssertionDefaults; searchRules; hierarchyLevel; hierarchyParent; hierarchyTop; structuralObjectClass; governingStructureRule; contextTypes; dITContextUse; friends; dITStructureRules; dITContentRules; nameForms; matchingRuleUse |
| m) Whether conformance is claimed for return of alias names as described in 7.7.1 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | Yes. |
| n) Whether conformance is claimed for indicating that returned entry information is complete, as described in 7.7.1 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | Yes. |
| o) Whether conformance is claimed for modifying the object class attribute to add and/or remove values identifying auxiliary object classes, as described in 11.3.2 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | Yes. |
| p) Whether conformance is claimed to Basic Access Control. | Yes, apart from import/export, and under 'protectedItems' the following are not supported: rangeOfValues; maxValueCount; maxImmSub; restrictedBy; contexts; classes. |
| q) Whether conformance is claimed to Simplified Access Control. | Yes, subject to the same constraints as Basic Access Control. |
| r) Whether the DSA is capable of administering the subschema for
its portion of the DIT, as defined in ITU-T Rec. X.501 | ISO/IEC
9594-2. NOTE 2 – The capability to administer a subschema shall not be divided; specifically, the capability to administer particular subschema definitions shall not be claimed. |
No. |
| s) The selected name bindings defined in ITU-T Rec. X.521 | ISO/IEC 9594-7 and any other name bindings, for which conformance is claimed. | None. |
| t) Whether the DSA is capable of administering collective attributes, as defined in ITU-T Rec. X.501 | ISO/IEC 9594-2. | Yes, apart from refinements. |
| u) The selected context types defined in ITU-T Rec. X.520 | ISO/IEC 9594-6, and any other context types, for which conformance is claimed. | None. |
| v) Whether conformance is claimed for contexts as defined in 8.8, 8.9 and 12.8 of ITU-T Rec. X.501 | ISO/IEC 9594-2, and in 7.3 and 7.6 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | No. |
| w) Whether conformance is claimed for the use of contexts in RDNs, as defined in 8.5 and 9.3 of ITU-T Rec. X.501 | ISO/IEC 9594-2, 7.7 of ITU-T Rec. X.511 | ISO/IEC 9594-3, and ITU-T Rec. X.518 | ISO/IEC 9594-4. | No. |
| x) Whether conformance is claimed for the management of the DSA Information Tree, as defined in 7.13 of ITU-T Rec. X.511 | ISO/IEC 9594-3. | No. |
| y) Whether conformance is claimed for the use of systems management for administration of the Directory, as defined in ITU-T Rec. X.530 | ISO/IEC 9594-10. | No. |
| z) The selected managed objects and management attribute types defined in ITU-T Rec. X.530 | ISO/IEC 9594-10, and any other managed objects and attributes, for which conformance is claimed. | None. |
| aa) Whether conformance is claimed to Rule-based Access Control. NOTE 3 – The support of security labels requires the following minimal support of contexts: Context lists as per 8.8 of ITU-T Rec. X.501 | ISO/IEC 9594-2 and returnContexts per 7.6 of ITU-T Rec. X.511 | ISO/IEC 9594-3. |
No. |
| bb) Whether conformance is claimed to integrity of Directory operations. | Yes. |
| cc) Whether conformance is claimed that the DSA can hold and provide access to encrypted and digitally signed information. | Yes. |
| dd) If conformance is claimed for strong authentication, signed operations, or protected operations, identification of the Certificate and CRL extensions for which conformance is claimed. | Supported certificate extensions: keyUsage, basicConstraints,
nameConstraints, cRLDistributionPoints. pathLenConstraint is supported, but follows RFC 3280, which differs slightly from X.509. Supported CRL extensions: cRLNumber, crlScope (deprecated), issuingDistributionPoint, deltaCRLIndicator |
13.3 Conformance by a shadow supplier 13.3.1 Statement requirements The following shall be stated: |
|
| a) The application context(s) for which conformance is claimed
as a shadow supplier: shadowSupplierInitiatedAC,
shadowConsumerInitiatedAC, shadowSupplierInitiatedAsynchronousAC,
shadowConsumerInitiatedAsynchronousAC, and disp-ip. A DSA implementation claiming conformance as a shadow supplier and not supporting disp-ip shall, at a minimum, support either the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If the DSA supports the shadowSupplierInitiatedAC, it may optionally support the shadowSupplierInitiatedAsynchronousAC. If the DSA supports the shadowConsumerInitiatedAC, it may optionally support the shadowConsumerInitiatedAsynchronousAC. If claiming conformance to disp-ip, it shall be stated whether the implementation is capable of invoking the requestShadowUpdate operation, responding to a coordinateShadowUpdate, or both. |
shadowSupplierInitiatedAC and shadowConsumerInitiatedAC (synchronous only). |
| b) The security-level(s) for which conformance is claimed (none, simple, strong). | None, simple and strong |
| c) To which degree the UnitOfReplication is supported. Specifically, which (if any) of the following optional features are supported: | |
| – entry filtering on objectClass; | Yes. |
| – – selection/Exclusion of attributes via AttributeSelection; | Yes. |
| – the inclusion of subordinate knowledge in the replicated area; | Yes. |
| – the inclusion of extended knowledge in addition to subordinate knowledge; | Yes. |
| – selection/Exclusion of attribute values based on contexts. | No. |
13.4 Conformance by a shadow consumer 13.4.1 Statement requirements The following shall be stated: |
|
| a) The application context(s) for which conformance is claimed
as a shadow consumer: shadowSupplierInitiatedAC,
shadowConsumerInitiatedAC, shadowSupplierInitiatedAsynchronousAC,
shadowConsumerInitiatedAsynchronousAC, and disp-ip. A DSA implementation claiming conformance as a shadow consumer and not supporting disp-ip shall, at a minimum, support either the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If the DSA supports the shadowSupplierInitiatedAC, it may optionally support the shadowSupplierInitiatedAsynchronousAC. If the DSA supports the shadowConsumerInitiatedAC it may optionally support the shadowConsumerInitiatedAsynchronousAC. If claiming conformance to disp-ip, it shall be stated whether the implementation is capable of responding to the requestShadowUpdate operation, requesting a coordinateShadowUpdate, or both; |
shadowSupplierInitiatedAC and shadowConsumerInitiatedAC (synchronous only). |
| b) The security-level(s) for which conformance is claimed (none, simple, strong); | Simple and strong. |
| c) Whether the DSA can act as a secondary shadow supplier (i.e., participate in secondary shadowing as an intermediate DSA); | Yes. |
| d) Whether the DSA supports shadowing of overlapping units of replication | No. |
