Re: [kmip] Suggestion regarding v1.4 errata

[Tim Hudson <tjh@cryptsoft.com>]

There is no "valid" interpretation as such John - we have conflicting information.Â

One is an omission (and hence very easy to see as simply a mistake) and the other is a clear statement (removing the possibility of arguing what the TC's intent was).

It would be different if there was a clear statement that said Opaque Objects do not have State and elsewhere Opaque Objects do have State (which is in essence what your argument is predicated on).Â

I don't think there is any disagreement inside the TC about what the TC intended - at least I haven't seen any emails on that topic nor heard any conversations suggesting otherwise to date.

When we hit an even clearer issue in the PKCS#11 technical committee where we had directly clashing definitions for constant values that required an errata that was inherently material non-interoperable changes we still were able to make changes because it was clearly a mistake impacting interoperability - in essence if we let things stand as they were the specification fails to serve its purpose - and that common sense position is what drove the decision making. In PKCS#11 that errata effectively invalidated almost all vendor implementations that supported that specific feature.

The OASIS rules did not prevent that change from being made as ultimately it comes down to a vote of the technical committee. This is a more clear cut context than we had in the PKCS#11 technical committee as we are dealing with a simple omission requiring reading meaning into an omission as overriding the text elsewhere in the specification.Â

OASIS as a group is about handling things in manner to generate sensible outcomes. We do have rules to govern how we interaction - but we also have a decision making mechanism that allows forward progress even if a minority disagree.

Thanks,

Tim.

On Fri, Jan 25, 2019 at 10:50 AM John Leiseboer <JL@quintessencelabs.com> wrote:

I think the question we need to answer is whether the change to the specification is âNon-Materialâ. The OASIS rules at first glance are pretty clear on the definition of Errata (https://www.oasis-open.org/policies-guidelines/oasis-defined-terms-2018-05-22):

Â

"Errata" is a set of Non-Material corrections to an OASIS Standard that have not yet been approved by an OASIS Technical Committee or Project Governing Board as an Approved Errata.

Â

But this definition depends on the definition on âNon-Materialâ:

Â

"Non-Material Change" is any change to the content of a Work Product that does not add or remove any feature of the Work Product and that: (a) constitutes only error corrections, editorial changes, or formatting changes; or (b) is a pro forma change to content required by TC Administration.

Â

I think we all agree that the 1.4 specification can be interpreted to a) require support for the State Attribute and therefore state-changing related Operations for Opaque Objects, or b) it can be interpreted to mean that Opaque Objects do not have a State Attribute, and therefore related state-changing Operations are not relevant. I think we all agree that either interpretation is possible, and valid. Given that some vendors have implemented Cryptographic Objects with State, and some others have not (and the number of vendors for each case is greater than one), it is a fact that we do not all agree on a single, âcorrectâ interpretation.

Â

So, we are in the position now where an error in the specification has resulted in different server implementations that MAY cause interoperability issues. It is possible to develop client applications that do not have interoperability issues if operations are not requested by a client when different server implementations may behave differently; e.g. if a client never attempts to Activate or Revoke an Opaque Object, the client will not run into interop issues due to these operations. It would be perfectly possible to develop profiles for âstatelessâ Opaque Objects, and âstatefulâ Opaque objects. But more importantly it is possible to create a profile that works for both stateless and stateful Opaque Objects. This means that even with different server implementations it is possible to specify and implement profiles that are fully interoperable with both interpretations.

Â

Getting back to material vs. non-material change. By changing the specification through errata for Opaque Objects to require support for state, existing server implementations that do not support state for Opaque Objects would be materially impacted. Pre-errata these server vendors can claim that the server implementation is in accordance with a valid interpretation of the specification. Post-errata, these vendors cannot make this claim. In my opinion this is a material change. I would argue that to require support for State by Opaque Objects adds a feature that was not present in a currently valid interpretation of the 1.4 standard. Similarly, removing support for State by Opaque Objects is a material change due to the fact that it removes a feature that was not present in another currently valid interpretation of the 1.4 standard.

Â

The result of correcting the error by editing text to add state to an Opaque Object would be equivalent to adding a feature to the Work Product, and by OASISâ definition, this is a material change.

Â

Would it make more sense to go down the path of simply describing how to remain interoperable with 1.x servers that have been implemented with different interpretations of Opaque Object requirements? I think this would be the least disruptive approach.

Â

John

Â

From: kmip@lists.oasis-open.org <kmip@lists.oasis-open.org> On Behalf Of Tim Hudson
Sent: Friday, 25 January 2019 9:36 AM
To: kmip@lists.oasis-open.org
Cc: John Major <jmajor@quintessencelabs.com>
Subject: Re: [kmip] Suggestion regarding v1.4 errata

Â

The challenge in this context is we have statements in the specification which are effectively technically contradictory but in reality are actually quite clear from context.

In one location we are simply missing an object type in the list of applies-to in a table - a very simple act of omission.

In multiple other locations there are clear statements which show that opaque objects change state and have state change impacts on attributes.

Â

There isn't actually anything within the specification beyond the simple omission error to indicate the technical committee ever had the intent to actually preclude opaque objects from having state.

Â

In the past when we have hit issues where there is a non-interoperable context we have explored options but ultimately gone with the majority view point based on the impact of the change in terms of impacted vendors.

Leaving this non-interoperable context as-is really isn't something that is consistent with the whole purpose of the technical committee (and OASIS) - which is interoperable results.Â

Â

In terms of conformance - you have to actually go to the profiles document itself - the specification text explicitly passes all conformance across to the profiles.Â

So no one can actually claim conformance to the base specification (that has no meaning) - you have to specify which profiles you conform to (which in turn specify the items in the specification).Â

There is only one profile that covers Opaque Objects - theÂOpaque Managed Object Store - and it covers only a simple register with a Name - and does not address State one way or the other.

Â

We have a simple decision making process in the TC - and based on the call this week we will end up with clear change documents for consideration on next weeks call.Â

Â

Tim.

Â

Â

On Fri, Jan 25, 2019 at 9:00 AM John Major <jmajor@quintessencelabs.com> wrote:

Hi,

Â

I have a suggestion for this errata that may be a little outside the box at this point.

Â

First, my understanding of the oasis errata rules, quoted in the recent call, is that they aim to prevent a compliant instance in the field from becoming non-compliant by a documentation change. There are server implementations, in the wild, that claim 1.4 compliance and they differ from each other in some aspects. There are clients, in the wild, expecting different behaviours depending on their interpretation of the spec. All of these are currently considered compliant. None of these should be made non-compliant by an errata.

Â

With this in mind, I suggest that any errata should

• Clarify the original intent.
• Document the existing discrepancies found in the wild.

Â

Any new test case that changes the compliance of deployed software would, I feel, hit the spirit of the Oasis definition of material change, if not the letter.

Â

Regards

John Major

Â

John MajorÂ| Software DeveloperÂ| QuintessenceLabs | W: quintessencelabs.comÂ

Unit 1 Lower Ground |15 Denison St | Deakin ACT 2600 | P: +61 2 6260 4922Â

Check out our new website: quintessencelabs.com

ÂÂ

Â

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
______________________________________________________________________