Subject: Re: OCSP-X vs SCVP

From: "David P. Kemp" <[email-masked]>
Date: Mon, 13 Nov 2000 15:40:19 -0500 (EST)

> From: "Anders Rundgren" <[email-masked]>
> 
> Actually I don't sugggest that an 'equivalent' XML implementation is to be
> created.  A brand new scheme is what I believe is needed.
> 
> One reason for wanting ACs to use XMLDSIG is to be able to specify the specifc
> local/global/national/application/whatever attribute profile as an XML schema.
> Because unlike PKCs the variation in ACs is virtually unlimited which makes 
this "feature" extremely critical.
> And also unlike PKCs the exact interpretation of virtually all fields is 
probably a requirement in just about
> all likely applications.  <<<< I.e. an AC is really a "message" to be acted 
upon >>>>

I'm sorry, I don't follow the above.  In a PKC, an "exact
interpretation" of all fields is a requirement - Validity is not just
two strings, it is two dates which must be compared against a system
clock to determine if the cert is within range.  Subject and Issuer are
not only displayed, they are chained, and used as search criteria.
Public key is not just a string of bits, it is a cryptographic value
which is used in a defined algorithm in a defined manner.  The syntax
(the order of fields, the field types, and value constraints) are not
sufficient to act upon a PKC; the application must know what each field
means and process it accordingly.

In contrast, I don't see how an XML schema, whether it is local/global/
application/whatever, can communicate anything more about the semantics
of a message (how it is to be acted upon) than can an ASN.1 type
definition.   Java can say "convert this digit string to a timeval
and compare it to the system clock", but how can you say such a thing
using XML?  W3C claims: "The XML Schema Working Group is addressing means
for defining the structure, content, and semantics of XML documents", but
here "semantics" is in the eye of the writer.  I believe you can use
XML to label data values for "customer record" and "shoe size", but I
don't believe that an XML DTD can express the fact that the "key usage"
field of a certificate is involved in determining the validity of a
cert path (i.e. that a path is a series of zero or more CA certificates
followed by a single End Entity certificate).  The XML notion of
"semantics" might more accurately be called "data labels".  I'd be
surprised to learn of some semantic capability that can be expressed in
an XML DTD but not in ASN.1.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 14 Nov 2000 00:35:59 +0100

David,
I will try to explain this in another way

<snip>

> definition

<snip>

If my interpretation of the AC draft is correct, as well as my understanding that ASN.1 does
not support a schema/DTD the following is one of *many* reasons why XML DTD/Shemas
*would* make a difference if applied to ACs:

PKIX AC profile: A *single* definition for all possible AC application profiles

"Possible" XML-AC profile: Generic schema-defined header + application-specific schema for the actual
profile (the attributes). 
An AC app is unlikely to bother about more than a few such application-specific shemas.
Most only understands one.  A typical AC app simply rejects an unknown schema.
The major part of the work is therefore done by the XML-parser so the
application knows exactly (based on encountered schema having implict semantics) what to
process instead of doing own pattern matching, and data filtering.  With XML schemas you
would typically specify a 1-to-1 fit with an application instead of "trying to be smart" and make
just about everything OPTIONAL, CHOICE, critical, non-critical etc.

===========================================================
If the ASN.1-AC approach (due to lack of schema) had been applied to BizTalk
(an XML-based business-message framwork), there would be a single definition
("business message profile") that would have had optional constructs for all kinds of
business messages.  That would not have worked as it would be impossible to get
consensus, and would also have put an enormous burden on application developers.
===========================================================

I.e. IMO you SHOULD NOT structure things the same way when you have schemas
as you (are forced to) do in ASN.1.  If you do, you could [almost] equally well stay with
ASN.1 as it is comparable with XML at the element level.

Anders