RE: KeyInfo Extensibility poll

[Apologies if you eventually get two copies of this message.  I sent this
yesterday morning but I haven't seen it show up on the list yet or in the
archive...]

Since all of KeyInfo is optional, by definition if you don't understand a
clause you come across you drop it on the floor.  We explicitly refused to
include any form of a "criticality" flag in XMLDSIG because of the serious
interoperability problems criticality flags *created* in 
X.509/PKIX Part 1.  

One of my main objections with option 1, which I raised previously during
the flap over the exact structure of X509Data, is that the XMLDSIG WG should
not be in the position of specifying a fixed, non-extensible Scheme for data
types that are "owned" by another WG.  We are attemting to define useful
representations of the various outputs of the PKIX, SPKI/SDSI and OpenPGP
WGs, but the primary responsibility for defining those structures falls on
those other WGs, not on us.  Recall that the *only* KeyInfo sub-element that
must be supported is KeyValue; everything else is optional.  We know we're
not going to get it perfectly right the first time, so either we allow for
extensibility everywhere or we explicitly create future interoperability
problems.

If this WG is not willing to support extensibility within the "best-guess"
structures we have created to foster use of the output of the other WGs, I
humbly suggest that our best, safest course of action would be to remove the
X509Data, SPKIData and PGPData sections in their entirety from the draft and
let each of the other WGs issue RFCs that specify sub-elements of KeyInfo
that best represent their own work product.  It is inconsistent to argue
that dropping these section from the draft is unacceptable because it
doesn't provide any minimum mechanism for passing common evidence objects
back and forth in XMLDSIG v1, and then argue that extensibility within these
elements is also unacceptable because there couldn't possibly be more to
specify than what *we* have chosen to describe for v1.  You can't have it
both ways.

					--bal

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Wednesday, January 24, 2001 4:14 AM
To: Donald E. Eastlake 3rd
Cc: w3c-ietf-xmldsig@w3.org
Subject: Re: KeyInfo Extensibility poll 

By allowing these XMLDSIG defined elements to be extended, we
are restricting interoperability: What do I do with parts of an
X509Data that I don't understand? Ignoring them is not valid,
because they may be critical to the use of the element. Do we
add a criticality flag? Do we fudge the issue and say that if
a new part is critical you must define a new KeyInfo type?

Received on Sunday, 28 January 2001 11:52:04 UTC