ACTION-24: Schema review

I guess this is more of a "later" item, but there are a number of
deficiencies and outright bugs in the current xmlsig schema that I would
like to see corrected if the WG ends up defining a completely new version of
the spec with a new namespace.

There are a few improvements that might be possible as extensions of the
existing schema, but not for the most part.

1. IDness

Obviously there's the question of using xml:id in any new schema, but that
postdates this spec, so obviously wasn't an option. I would assume we would
use xml:id in any new one.

With respect to ID attributes in general, the current problem is that
KeyInfo itself has an ID declared, but its child elements don't. This is a
problem because RetrievalMethod can refer to these elements but requires a
transform inside it to do so. This should be corrected.

Note that since KeyInfo is extensible, a brute force fix would be to define
new KeyInfo children in a new namespace that correct the problem and start
supporting them in addition to the older ones.

2. Attribute Extensibility

There are a few elements that I would have included an <anyAttribute>
extension point inside, such as SignedInfo, CanonicalizationMethod,
SignatureMethod, Reference, Transform, DigestMethod. 

Many are already intended to be extension points for new algorithms, but
then require element extension to supply parameters, which could be more
easily supplied as attributes in many cases.

3. Mixed Content

A few of the elements seem to needlessly declare mixed="true" (KeyInfo,
KeyValue, Transform, CanonicalizationMethod, SignatureMethod, DigestMethod),
which is fairly esoteric for a data markup schema, and imposes additional
costs to implement properly (frankly, my guess is that very few do).

As a rule, I would avoid it, and probably review the original intent behind
marking any of the elements that way before leaving it.

4. KeyInfo child issues

X509SerialNumber is of integer type, and this needs to be changed to string
to correct problems with large serial numbers. Most parsers are limited in
the range of integers they can validate.

The certificate encoding issue is obviously documented at this point. More
generically, I am extremely militant in believing that XML needs to be
self-documenting, and if you're burying any variability in format into any
element, that element needs a type switch (or multiple elements need to be
defined). X509CRL may be another case of this.

Finally, I believe that the current decomposed RSA/DSAKeyValue elements are
too complex and should be either replaced or supplemented with something
directly supported by common libraries for loading keys, such as the
base64-encoded DER supported by OpenSSL. These blobs are easy to get from
command line tools and for specialized applications where interaction with
the KeyInfo structure is needed, much simpler for humans to deal with. This
would actually reduce the use of certificates where the real goal is to use
bare keys, and certificates are used mainly as a wrapper because of
transport issues.

-- Scott

Received on Sunday, 23 November 2008 21:08:54 UTC