LC-2561 proposed resolution - import of schema for extension points

Makoto

This mail relates to LC-2561 recorded against Generic Hybrid Ciphers, on the issue "to validate this ECKeyValue element, we need the schema for Signature 1.1" (I entered a new issue when this concern was raised) [1].

Note that dsig11:ECKeyValue is one of a variety of values that can be placed in ds:KeyValue, which is essentially an extension point to XML Signature 1.0 (and also 1.1). We agree that Signature 1.1 schema would be needed to validate the dsig11:ECKeyValue element, but do not agree that XML Signature 1.1 schema should be imported into XML Signature 1.0  schema or into the XML Encryption 1.1 schema.

After the XML Security WG discussed the issue it resolved that there is no schema change to make. 

The rationale is as follows:

1. Implementors should not be relying on schema import statements in order to validate the use of other schemas  for within extension points of a given schema. Instead they should build knowledge of relevant schemas within their code to allow validation. 

I add that it doesn't make sense to change the 1.0 schema to allow use of 1.1 elements in an extension point - existing 1.0 implementations should not need to be 1.1 aware if those extensions are not used - this is a general point of extension points, the schema need not anticipate all uses.

We agree validation is important but implementations need to understand how to validate without relying on schema imports to indicate all possibilities. That does not mean they cannot use schema validation, but that import statements need not  drive it.

2. Implementors should cache needed schema definitions, and not load them repeatedly from the URL associated with the schema definition

Repeated schema definition fetching puts unnecessary load on the server and is not necessary. It is better for the implementation to store a local copy of the schema definition, as it should not be changing. The same can be said for schemas that are used in extension points - those schema definitions can also be locally stored if use is anticipated, and extension points can be validated based on normative text statements in the document.

3. What is allowed in the extension point can be defined in normative text within a specification and this may be hard to mirror in the schema definition itself.

Do you accept this resolution and the reasons for it?

Note,  gh-example.xml is not an XML Encryption 1.1 file but related to the generic hybrid ciphers specification [1]

Thanks very much for your review and comments. 

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/2006/02/lc-comments-tracker/42458/CR-xmlsec-generic-hybrid-20110303/2561

[2] http://www.w3.org/2008/xmlsec/Drafts/generic-hybrid-ciphers/Overview.html

This should close ACTION-832

Received on Tuesday, 6 September 2011 21:32:47 UTC