The following table is derived from the X.500 Conformance Specifications taken from Section 13 of X.519 (2008). 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.

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,directoryOperationalBindingManagementACdap-ip,dsp-ipdop-ip, or a combination of these. A DSA that claims conformance to thedirectoryOperationalBindingManagementAC 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 ordsp-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,specificHierarchicalBindingIDnon-specificHierarchicalBindingID, or a combination of these. A DSA that claims conformance to theshadowOperationalBindingID 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.

UniversalStringBMPString and UTF8String are all supported
All of the attributes specified in X.520(2005) are supported, with the exception of: uUIDPair; all “Notification” attributes.

The following matching rules are supported:

bitString
boolean
caseExact
caseExactOrdering
caseExactSubstrings
caseIgnore
caseIgnoreList
caseIgnoreOrdering
caseIgnoreSubstrings
facsimileNumber
generalizedTime
generalizedTimeOrdering
integer
integerOrdering
numericString
numericStringSubstrings
octetString
protocolInformation
telephoneNumber
telephoneNumberSubstrings
uniqueMember
uTCTime
uTCTimeOrdering

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, anddisp-ip.
A DSA implementation claiming conformance as a shadow supplier and not supporting disp-ip shall, at a minimum, support either theshadowSupplierInitiatedAC or theshadowConsumerInitiatedAC. If the DSA supports theshadowSupplierInitiatedAC, it may optionally support the shadowSupplierInitiatedAsynchronousAC. If the DSA supports the shadowConsumerInitiatedAC, it may optionally support theshadowConsumerInitiatedAsynchronousAC. If claiming conformance to disp-ip, it shall be stated whether the implementation is capable of invoking therequestShadowUpdate operation, responding to acoordinateShadowUpdate, or both.
shadowSupplierInitiatedAC andshadowConsumerInitiatedAC (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, anddisp-ip.
A DSA implementation claiming conformance as a shadow consumer and not supporting disp-ip shall, at a minimum, support either theshadowSupplierInitiatedAC or theshadowConsumerInitiatedAC. If the DSA supports theshadowSupplierInitiatedAC, it may optionally support the shadowSupplierInitiatedAsynchronousAC. If the DSA supports the shadowConsumerInitiatedAC it may optionally support theshadowConsumerInitiatedAsynchronousAC. If claiming conformance to disp-ip, it shall be stated whether the implementation is capable of responding to the requestShadowUpdate operation, requesting acoordinateShadowUpdate, or both;
shadowSupplierInitiatedAC andshadowConsumerInitiatedAC (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.