Subject: Re: Should PKIX protocols support XML well?

From: [email-masked]
Date: Wed, 15 Nov 2000 09:49:23 -0500

Anders,

When building the Jonah freeware we put together an ASN.1 class library
that supports almost all of the features you claim as intrinsic virtues of
XML:

>- Immediately recognize the message type by its schema name as found
>  by the parser. You could even dispatch the parsed message to
>  various apps directly based on found message type!
>  Schema=>Application=>Implict semantics.

The Jonah library can do that (recognize a message type either implicitly
by its structure or explicitly by an embedded tag).

>- Have the parser automatically check that all expected elements are
>  there (no more, no less), and fully conform to their format and
>  possible restrictions (i.e. not 100K UserIDs etc.)  Supporting
>  standardized diagnostics like: "Address" field too long.
>  Missing "Session ID" tag etc.

The Jonah ASN.1 library doesn't do much checking of restrictions, but that
was an implementation choice rather than something imposed upon us by
ASN.1.  ASN.1 allows such restrictions to be expressed; we simply chose to
enforce them above the parser library.  It will certainly detect missing
fields.

>- Let each "application profile" have it own schema.  As in BizTalk.
>  And let applications evolve in their own pace.  Much simplier (and
>  futureproof) than trying to squeeze in things like it is done in AC.

Since defining a parser for a new syntax is a trivial process, a simple
extension mechanism works fine for this.

>- Have "wizards" generate access class objects directly from the XML
>  app-schema if you want.  Click on the fields of interest and you are
>  there!  That is a quantum leap above trying to decode arbitrary
>  extension at application level (well, to be honest, I am pretty
>  old-fashioned and seldom use wizards but all "new" people seem
>  very thrilled by such tools...).

Jonah doesn't have wizards; instead you simply declare a C++ class of the
appropriate type directly from the ASN.1 syntax definition.  You don't have
to write any code, just a C++ header file containing class definitions (you
may have to write a simple constructor for composite objects, but that's by
rote, and is the full extent of any programming required).

I don't understand what this has to do with "decoding arbitrary extensions
at the application level";  For X.509 certificates, Jonah simply declares
parsers for each extension type and applies the appropriate parser to an
extension based on the extension's extnId value.

>- Let you [automatically] verify that your output conforms to the spec.
Just to be a nice guy.

That's automatic with the Jonah library - once you've declared a parser
class, that class is also used if you want to generate ASN.1 DER that
conforms to the same syntax.  There's no "verification" step - the class
just generates appropriate DER.

The above isn't intended as a plug for the Jonah code;  It's simply an
existence proof that the advantages you claim for XML are also achievable
by ASN.1 (and in freeware too).

John

"Anders Rundgren" <[email-masked]> on 11/15/2000 04:48:29 AM

To:   <[email-masked]>
cc:
Subject:  Re: Should PKIX protocols support XML well?

This conversion of things to XML from ASN.1 is IMO not that interesting as
XML in itself
(except for being "trendy", "free", and "human readable") does not offer
any advantages
over ASN.1.  Rather adds som disadvantages like bloated size.

It is sad, some XML "marketers" even claim that XML solves semantics as
well (using "magic"),
but they are dead wrong!

But if you use XML *schemas* you could also:

- Immediately recognize the message type by its schema name as found by the
parser. You could
even dispatch the parsed message to various apps directly based on found
message type!
Schema=>Application=>Implict semantics.

- Have the parser automatically check that all expected elements are there
(no more, no less), and
fully conform to their format and possible restrictions (i.e. not 100K
UserIDs etc.)  Supporting standardized
diagnostics like: "Address" field too long.  Missing "Session ID" tag etc.

- Let each "application profile" have it own schema.  As in BizTalk.  And
let applications evolve in
their own pace.  Much simplier (and futureproof) than trying to squeeze in
things like it is done in AC.

- Have "wizards" generate access class objects directly from the XML
app-schema if you want.  Click
on the fields of interest and you are there!  That is a quantum leap above
trying to decode arbitrary
extension at application level (well, to be honest, I am pretty
old-fashioned and seldom use wizards but all
"new" people seem very thrilled by such tools...).

- Let you [automatically] verify that your output conforms to the spec.
Just to be a nice guy.

So IMO, ACs and similar which I consider very application-specific (*not*
PKCs), would benefit
tremendously by being split into a header document and an application
document using schemas
to avoid extensions and app-level parsing completely.

Unfortunately the XML schema route does not have an ASN.1 counterpart. A
truly one-way-street.

Off-list I have been adviced to start a new WG to avoid these time-wasting
ASN.1 - XML wars.
Is that maybe the general feeling?  How do I proceed?

Regards
Anders Rundgren

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 16:22:37 +0100

John,

<snip>

> extension mechanism works fine for this.

If you take the current AC draft which was the basis for this thread,
I would like to know how you specify and create code for something which
is outside the specification.  And how do you transmit the extenson information?

As ASN.1 source? OK, that technically *works* but I doubt that this will
get any major backing (unlike XML).

And it is not as elegant as app-specific XML schemas.

Anders