Re: KeyInfo Extensibility poll

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

Agreed.

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

Certainly.  But the current syntax makes the task of trust establishment
difficult, particularly in X509Data.  Allowing replacement or addition only
adds to the confusion.  While the info in KeyInfo is not guaranteed to be
correct, and can't be mandated to be so, the syntax can guide folks to
proper usage.

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

Not providing an indication as to who the signer is while packing the
signer's certificate along with any parent certificate from any path ina
single X509Data element is a bad idea, in my opinion, and I have proposed
changes to mitigate this.

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

We are talking about X509Data elements which are required to be about a
specific cert.  That one can have multiple certs for the same key is
unquestioned and not part of this issue - such certs would reside in sibling
X509Data elements.  Since extensions from a specific cert indicate to a
relying party if a signature is valid, establishes valid uses for the
private key, etc., they imply a great deal about the semantics of the
signature.

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

In my initial poll response offlist to Donald Eastlake I indicated that I
was against option 3 and think option 2 is OK if the syntax is changed to
support it as option 2, i.e. so it doesn't degrade to option 3.  Option 1
must exist and is a non-issue.

Received on Tuesday, 30 January 2001 07:28:21 UTC