AW: KeyInfo Extensibility poll

Carl,

> > Allowing option (2) is the same mechanism at one structural level
> > lower, isn't it? If there is information within a X509Data element
> > which I do not understand, I simply ignore it. If the information
> > is critical, then (1) must be used to derive a new x509 data type
> > in a different namespace.
> 
> It is a similar mechanism one level lower, but isn't it cleaner for the
> mechanism to exist at one level instead of two and in one data 
> type instead
> of five?

You are right, this is the cleaner solution, since there are less options
to do similar things. But (2) allows it to augment types, and this types
can still be used by applications only aware of the basic XML-Signature
syntax.

> Option two opens the possibility of encountering an X509Data
> element, or potentially worse a KeyValue element,  that contains only
> material that you do not understand.

As I already stated in my first response to the poll earlier this day [1],
one should use option (2) only if there is enough information in the type
that an application only aware of the basic syntax of XML-Signature can
still process the - lets say - X509Data element.

If the X509Data is augmented in a way that there is no common structure with
the ur type any more, one should not use (2) but define a new type using
option (1).

---
[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0040.html

Regards, Gregor
---------------------------------------------------------------
DI Gregor Karlinger
mailto:gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------

Received on Wednesday, 24 January 2001 08:31:53 UTC