RE: KeyInfo Extensibility poll

>[Carl 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.

The analogous issue in KeyValue is not wholesale replacement of
algortihm-specific contents but rather the replacement of sub-elements of a
particular algorithm's structure.  E.g., Replacement of some or all of the
subelements of an RSAKeyValue or DSAKeyValue, which makes no sense.  It
makes perfect sense to allow wholesale replacement of the contents of
KeyValue since two parties much choose to communicated using another
asymmetric algorithm (e.g. ECC) that they both understand.  If you don't
know anything about your recipient, the only guaranteed-interoperable
algorithm is DSA.  

Independent of the above paragraph, none of the three Options Don presented
have any bearing on the contents of KeyValue.  I would strongly object to
any change in the current extensibility model for KeyValue -- what we have
right now is correct.

>> 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.

I just posted another message on how this approach will lead to duplicate
information & bloat in the backward-compatible case.  I do not believe
requiring such bloat to be backward-compatible down the road is acceptable.

>> >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.

Trust policy is explicitly outside the scope of DSIG.  If another spec or a
private agreement between corresponding parties assigns particular trust
semantics to the presence or absence of KeyInfo clauses, more power to them,
but that's outside the scope of our work here.  (It would be a stupid thing
to do, of course, unless you forced every KeyInfo to be Referenced in the
SignedInfo, and then you've slid back to S/MIME and lost the clear
separation we have between signature mechanics & semantic meaning.)  

Remember that the evidence contained within KeyInfo is not in any way
guaranteed to be correct -- it really is just a collection of hints.  A
trust management engine that consumes only KeyInfo information may not have
enough info to satisfy its trust policy.

>> 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.

You're right, there isn't a huge deal if you separate old & new content this
way, but then you've punted on the subtyping model that Joseph proposes and
there's no structural link between the old & new content.  (This is Case (c)
in my previous message.)

>> 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.

Actually, it all depends on what your definition of "relate" is in X509Data.
The definition the WG chose was that "relates to the same subject key"
included any parent certificate in a chain where the subject of the end
entity cert was the subject key.  You can argue whether that was a good
definition or not, but that's what it is.

>> 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.  

Sure they can -- what do you think a Certificate Policies extension does?
It modifies the meaning of the CA's signature by specifying the semantics of
that signature.

>They modify the meaning
>of signatures generated using the cert subject's associated private key,

I have to stop you here because this is one of the classic mistakes people
make with certs.  Just because I (a) create a signature with a key pair, and
(b) also happen to have a certificate on that key pair, does not necessarily
imply (c) that the certificate has anything to say about the semantics of
the signature I just made.  If relevant at all, it is a matter of contract
between me and the CA.  There is *nothing* in PKIX that prevents me from
having multiple certificates issued to a single key pair.  In fact, it is
perfectly OK to have multiple *conflicting* certificates issued to the same
key pair, up to contract issues between the CA and the owner of the subject
key pair.  

[This notion people have that by simply including a certificate in a signed
message automatically modifies the semantic content of the message is just
plain wrong.  The blame for this confusion really falls on S/MIME though,
not PKIX, since S/MIME created the notion that you had to have a
*certificate* issued on a key pair in order to be able to generate a signed
message with that key pair.  That's totally bogus, and it's one of the
things we worked hard to get right in DSIG.]

>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.

Again, this supposes a particular signing model where the semantics of the
signature are dependent on the evidence supplied with it.  That's not part
of the general DSIG model.

>> 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?

Your trust management engine; the entity that is going to take some
potentially dangerous action based on the signed statements it receives.  It
it charged with making trust decisions in accordance with its policies.  The
contents of KeyInfo might help it make those decisions, but then again it
might not.

>> 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.

We respectfully disagree.  I do not consider a V1 model that *knows* it will
be extended and *cannot* gracefully deal with backward-compatibility issues
to be acceptable.  

					--bal

Received on Monday, 29 January 2001 23:50:39 UTC