Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 16 Oct 2000 16:03:28 +0200

Michael,

>> Using XML, an AC draft specification would not have to
>> define a single attribute or attribute syntax!
>
>Well, you would have to define a commonly used XML name space to let
>different applications from different vendors work together. Same
>thing as the ASN.1 type definitions used now.

Are you the slightest familiar with XML parsers and schemas?  There
is AFAIK not any standardized way to verify that an ASN.1 document
corresponds to its definition.
And if there is such a feature it is certainly not a part of the standard itself. 
And it is definitely not a part of current operating systems!
Unlike XML which has DOM and SAX APIs.  Regarding the name-space it is
fairly simple using BizTalk as an example.  You publish the XML schema on
a web-site and the name is essentially the URL.  No magic whatsoever.
AC XML schemas (like most XML schemas) would be specialized for different
purposes and geographic regions and must be agreed upon before used. 

Anders

---

From: Michael Ströder <[email-masked]>
Date: Mon, 16 Oct 2000 16:57:06 +0200

Anders Rundgren wrote:
> 
> Are you the slightest familiar with XML parsers and schemas?

There's no doubt that it would be interesting to use XML for the
presentation layer because of automatic validation against DTD
retrieved by URL etc. 

But there would be still a need to define the semantics of the
attributes (name space in XML) to make different applications from
different vendors interoperable. Or did I get you totally wrong?

> There is AFAIK not any standardized way to verify that an ASN.1
> document corresponds to its definition.

I leave this question open to the ASN.1 compiler experts.

Ciao, Michael.

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 16 Oct 2000 13:05:03 -0400

> presentation layer because of automatic validation against DTD

Yes, XML has great potential for data display. 
But if the data transfer has been performed using
an efficient binary method, such as provided by
any of the ASN.1 encoding rules, there is no need
or benefit for performing further validation of 
the data using either XML DTDs or any of their 
many (relax, etc.) XML schema. 

Simply decoding ASN.1 encoded data validates the 
gross structure of the information, and assures that
the data conforms to the schema specified by the 
ASN.1 notation - decoding guarantees that the data
values are valid members of the distinct set of 
values indicated by the their tag type. 

> > document corresponds to its definition.

This is exactly the opposite of true. Each ASN.1 value is
a member of an ASN.1 type. An ASN.1 type is a class of
distinct values. Given the tag for the type, the validity
of every value can be easily determined. 

In ASN.1 the schema is built into and underlies the actual
notation. There is just one schema in ASN.1, but there are
many encoding rules (soon to include one for XML). One schema
seems to be more than enough for most folks.

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------