Re: KeyInfo Extensibility poll

[I wrote...]
>>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

[Brian wrote...]
> I don't understand this comment.  First, none of the options under
> discussion have any bearing on KeyValue.  Second, as support for
DSAKeyValue
> is required; DSA is the only guaranteed interoperable structure.

Actually the text in the current draft of the spec does change KeyValue to
permit replacement of contents.  One could encounter a KeyValue that has
neither DSAKeyValue nor RSAKeyValue, in which case no interoperability is
gained from KeyValue.

> Option 1 most certainly does create a fixed schema for X509Data, SPKIData
> and PGPData.  As Don wrote:
>
> (1) Prohibit any elements, other than what we define in our
> namespace,
> inside SPKIData, X509Data, and PGPData.

Agreed.  Option one makes these 3 types non-extensible.  However, this has
nothing to do with data types "owned" by other WGs.  It does not create a
non-extensible scheme in a larger sense.  Data types owned by other working
groups are usable under option 1 as a child of KeyValue.  Other WGs are then
free to define meaningful relationships between their elements as they see
fit without regard to how they relate to our structures.

> >How do new, custom elements color the meaning of the
> >DSIG defined elements or vice-versa?
>
> They don't, by definition.  They can't, in fact.  Remember, *everything*
> contained within KeyInfo is optional

Who's to say how new elements impact DSIG elements (or other new elements)
when they are stripped of the context envisioned by their specs authors?
Another spec might very well define relationships between elements that are
lost (or altered) when they are transplanted into one of our structures.
Defining loose syntax that permits any content in primitive elements
intended to aid in establishing trust seems like a bad idea.

> The loss of relationship when moving data to a new subelement of KeyInfo
is
> exactly what creates backward- and forward-compatibility problems.  A V1
> client has no way to know that your new data type/subelement of KeyInfo
> contains the equivalent of the X509Data info it needs.  V2 clients will be
> forced to include both old & new data types, thus bloating KeyInfo.

A V1 client will still have no clue if the contents of an element it thought
it understood are wholly replaced by new content.  If both V1 and V2
contents must be included I don't see how there's (much) baggage added by
moving new content to under KeyInfo instead of under a KeyInfo data type.

> I don't understand your question here.  Any new child of X509Data, which
is
> all we're talking about here, would "live" at the same level as the other
> permissable X509Data children.  Their relationship would be the same; they
> all "relate" to a particular subject key.

They do not all relate to the same subject key.  They can refer to any CA
cert from multiple paths as illustrated by the example in the spec of a
certificate chain and by Kent Tamura on the list recently.  The intent and
extensibility mechanisms of options 2 and 3 would be cleaner if X509Data
operated as you state, i.e. all elements relate a particular subject key,
but it is currently not defined that way.  Elements under KeyInfo do have
the property of all being "related" to a particular subject key and as such
offer a cleaner place to offer extensibility.

> In your X.509 example, extensions explicitly modify the
> meaning of the signed statement contained within a certificate.

Certificate extensions do not modify the meaning of the CA's signature over
the certificate content containing the extensions.  They modify the meaning
of signatures generated using the cert subject's associated private key,
control path processing, aid in determining revocation status, etc. and thus
are what the CA is attesting to and signing.  From the CA's perspective
changing extensions in a cert it is signing is akin to changing a reference
in DSIG, not changing KeyInfo material.  From a relying party's perspective
it is very much like changing KeyInfo.

> Just to be perfectly clear let me
> restate that: no element or subelement of KeyInfo *ever* has impact on the
> meaning of a digital signature.  By definition.  Period.  That's why it is
> *always* OK to remove any all elements of KeyInfo from a signature block

If the establishment of trust, the presumable goal of KeyInfo, cannot impact
the "meaning" or value of a digital signature then what can?

> Except that our past (and current!) experience with X509Data argues
> otherwise.  Without an extensibility mechanism in X509Data we are
condemned
> to reconciliation problems between "our" X509Data and the PKIX:X509Data
that
> will surely be specified in the future.

I do not believe we are "condemned" if we disallow KeyInfo data type
extensibility and saved if we do and primarily see potential for confusion
if we do.  Perhaps redefining the KeyInfo data types, particularly X509Data,
with the sort of extensibility offered by option 2 in mind is the answer.
Certainly syntax changes are necessary for each if option 2 is to be
enforced by the schema.  Given the current syntax, I prefer option 1.

Received on Monday, 29 January 2001 20:10:47 UTC