Re: KeyInfo Extensibility poll

How can we avoid having option 1?  If we only permit option 2 or 3 then we
are assuming that all future extensions are going to be related to one of
the types we have defined.  The question is whether to support option 2 or 3
in addition to option 1.  Since processing for option 1 must exist, i.e. we
must be able to discard children of KeyInfo we don't understand, why clutter
the model with similar processing one layer down?

One of the problems with option 2 with regard to the required KeyValue is
that the contents of KeyValue can be completely replaced by custom content.
This renders the interoperability intent of KeyValue moot.

Option 1 does not impose a "fixed, non-extensible scheme".  It simply allows
us to define what we believe are reasonable structures that may be used in
the interim, before other WGs define alternative structures, or beyond, if
they serve an applications needs.  If someone wants to use an alternative or
custom structure they can, as a child of KeyInfo.  I'm puzzled by the need
for "extensibility everywhere".  Why must all of the structures be
extensible or all of the structures absent?  This seems like a drastic
assessment.

Options 2 and 3 provide the ability to decorate the primitive types we
define.  For an application that does not understand one of these adornments
what is the proper course of action?  Should it discard the entire element
or only the adornment?  How do new, custom elements color the meaning of the
DSIG defined elements or vice-versa?  Options 2 and 3 beg for criticality
flags and no one wants that.  Even if criticality flags are not explicitly
present, their behavior is implicit if we define a scheme to permit
ignorable content in the primitive types and "critical" content in an option
1 style extension.  When you move material to an option 1 style extension
you lose the relationship to the DSIG structure, which is presumably the
goal.  Further how do we relate new elements to DSIG elements in a
structure.  Take X509Data as an example.  This structure currently permits a
dizzying array of names, serial numbers, certs and crls that may identify
the signer or a CA from one of multiple paths.  If a new element is added,
how does an application know which sibling it relates to?  A side question,
since we permit the inclusion of multiple CA certs why limit the number of
CRLs to one?

Everyone acknowledges there are issues with the X.509 extension mechanism:
criticality flags, interoperability woes, etc.  Imagine if in addition to
custom extensions applications could alter, replace or add to the content of
basicConstraints or other X.509 defined extensions.  That is what options 2
and 3 propose to do for DSIG.  The real question may be do we want to define
an extensibility mechanism for relating elements from DSIG structures to new
content at this point in time?  I think the ability to add children under
KeyInfo should be a sufficient extensibility mechanism for this version of
DSIG, if not beyond.

Carl


> 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 13:12:56 UTC