v3.2.4

This version doubles the speed of inserting new entries by caching
subschema subentries between invocations of the addEntry operation.

v3.2.2

This version dramatically improves the performance of the DSA for search
and list operations and for addEntry when performed in rapid succession, as
well as for a few other use cases. In general, you should see a 400% to 1000%
increase in performance.

v3.2.1

This release fixes a severe bug where the length of IDM frames was given an incorrect value in some cases.

v3.2.0

Version 3.2.0

This new version introduces new features around authentication and chaining.

New Features / Improvements

• Support for SPKM authentication
• Support for externalProcedure authentication
• Mutual binding: Meerkat DSA will now send strong credentials or SPKM
  credentials back to the client.
• Verifying credentials returned by DSAs during chaining.
• Added the MEERKAT_TLS_REQUEST_CERT
  option to enable the DSA to request the TLS client certificate, even when
  client certificate authentication is not enforced.

Bug Fixes

• Fixed incorrect object identifier for the Simple Security Policy.

Upgrading

You do not have to do anything to upgrade to this version. Just update the
Meerkat DSA version.

v3.1.0

Version 3.1.0

This version introduces support for Rule-Based Access Control (RBAC), thereby
enabling Meerkat DSA to enforce the rule-based-access-control,
rule-and-basic-access-control and rule-and-simple-access-control access
control schemes defined in
ITU Recommendation X.501 (2019).

New Features / Improvements

• Support for Rule-Based Access Control
• Slight performance improvement when creating a new entry

Bug Fixes

• Fix invalid OCSP requests
  • OCSP requests were made using the subject's subjectPublicKeyInfo rather than the issuer's.
• Fix invalid OCSP verification
  • Verification would occur using the same issuer certificate over and over again
• Fix invalid invalid remote CRL signature validation

v3.0.0

Version 3.0.0 🎉

The defining aspect of this version is support for cross references. Cross
references allow a DSA to "bookmark" the DSAs that were involved in servicing
a previous request, so that, in chaining subsequent requests, the correct DSA
can be used directly, rather than routing the request through a first-level DSA.

New Features / Improvements

• Using cross references for routing purposes
• Returning cross references
• Requesting cross references from other DSAs
• More performant and correct namingContexts attribute
• More resilient and performant updating of superior DSAs
• Better logging surrounding name resolution
• Signature verification is faster and more resilient
• Chained results get verified
• Chained results returned from other DSAs get re-signed if they need it

Bug Fixes

• Log invalid DSP signatures received from chained results.
• Wrong error code returned to DOP associations
  • The operationalBindingError was being coded as a securityError.
• Bug where results received from chaining could get cross-wired
  • Meaning that a request might receive a result that belongs to another
    different request.
• Time-related signatures verification issues
  • Signatures on certificates could be wrongfully rejected if verified at
    certain times of the year (due to a bizarre, undocumented behavior in
    ECMAScript).

Upgrading

This is a breaking change, because the database schema had to be changed in a
breaking manner. If you upgrade to this version, you will need to repopulate
a new Meerkat DSA database.

v2.7.0

The defining aspect of this version is support for shadowing, which allows you
to replicate entries across multiple DSAs. It also includes many very serious
bug fixes.

New Features / Improvements

• Support shadowing
  • Shadow operational binding management via DOP
    • This includes relayed DOP
  • All DISP operations: consumer-initiated and supplier-initiated
  • Total and incremental refreshes
• Significant performance enhancements when inserting entries
• Improvements to the web admin console
• The moddn command in the X.500 CLI has been separated into two different
  move and rename commands, making it clearer what the syntax of the
  arguments should be.
• DAP / DSP operations can now be chained with signing when using bulk insert mode.
• Signatures on requests, results, and errors are ignored when using bulk insert mode.
• Connections between DSAs retained and reused, greatly improving performance for
  distributed operations.
  • This means that the TCP connections and TLS do not need to be re-established
    each time the DSA performs a distributed operation directed at a DSA that
    it has had prior contact with.

Bug Fixes

• Fix display of operational binding expiration times in the
  web admin console
• Fix non-use of shadow context prefix knowledge in Find DSE procedure
• Do not enforce access controls when moving an entry to the top level if open
  top level is configured.
• Fix a bug with getting context assertion defaults
• Fix logging unbinds at warning level
• Fix StartTLS establishment
• Fix OSI application association rejection when encountering an unsupported application context
• Fix OSI transmission of errors
• Fix handling of malformed TPDUs in the OSI transport layer
• Fix negotiation of TPDU size in OSI transport layer
• Use timeout supplied to X.500 client function to determine the TCP socket timeout
• Do not include the valuesWithContext in an attribute if there are no contexts
• Fix establishment of governing structure rule in a context prefix established
  by a hierarchical operational binding
• Chained operations will not be retried if they are modification operations and
  the outcome was an abort or reject, except with certain reason / problem codes.
  • This is because these outcomes could indicate an internal error, in which
    case, the modification might have been half-completed. If the error was
    caused by the user, we also do not want to propagate requests that were
    already determined to be invalid.
• Fix back-propagation of rejects, aborts, and timeouts received from chained
  operations.
• Fix crash when encountering a malformed Invoke ID

Upgrading

You do not need to do anything for this to work other than apply migrations.

v2.5.0

• Support Non-Specific Hierarchical Operational Bindings (NHOBs), which allow
  entries in multiple directories to share / compete for the same namespace.
• Fixed bugs in operational binding management
• Fix issues with validating some self-signed certificates

v2.4.4

Changes

SECURITY UPDATE

• Fix use of prescriptiveACI to regulate subentries in simplified access
  control.

This security bug was introduced as a result of version 2.4.2. You were
unaffected if you did not use versions 2.4.2 or 2.4.3, or if you never used
simplified access control.

v2.4.3

Summary

Summary: small deviation introduced in which searches recurse one entry into
other service administrative areas for the sake of DIT discoverability.

Changes

The X.500 specifications mandate that searches are not to recurse into other
service administrative areas, but this means that service admin points will not
be discoverable at all via search operations. Since LDAP has no list
operation, it also means that LDAP users will never be able to find any entry
that lies in a different service administrative area (except by "guessing" that
it exists).

For example, if C=US,ST=FL is a service admin point, and a user performs a
one-level search at C=US, the ST=FL subordinate will be hidden from the
results entirely. The user will have no way of even finding ST=FL except for
performing a list operation and noticing that this subordinate differs from
the results obtained by a one-level search (since list is not governed by
service administration).

This version of Meerkat DSA onwards will deviate from the specification by
recursing one entry into other service administrative areas so that the DIT is
traversible to users. Continuing on the previous example, this means that, if a
user performs a one-level search at C=US, the ST=FL subordinate will be
returned. If a subtree search at C=US is performed, ST=FL will be returned
as well, but none of its subordinates (the latter of which is technically
correct behavior).

If this is undesirable, meaning that you want Meerkat DSA to behave exactly as
the specifications specify, fear not: this version of Meerkat DSA also
introduces a new option, MEERKAT_PRINCIPLED_SERVICE_ADMIN, which, if set to
1, disables this deviation. Meerkat DSA will thereby adhere strictly to the
specifications and service admin points will be hidden from search results.

The above issue will be reported to the ITU working group that authors the X.500
specifications, so it may be resolved in a future version.

Updating

You do not have to do anything to upgrade to this version. Just update the
Meerkat DSA version.