Subject: RE: OCSP-X vs SCVP

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

> From: "Phillip H. Griffin" <[email-masked]>
>
> This will provide a means to extend the capability 
> deployed today - the ability to unambiguously encode
> and decode a value of an ASN.1 type. A standard markup
> for the ASN.1 notation will provide a new format for
> expressing the same ASN.1 values.
> 
> By binding a standard markup to the values defined as
> valid for ASN.1 types, it will be possible for an ASN.1
> application to send or receive ASN.1 values in either
> text or binary formats.

Phil,

This description does not do justice to the powerful advantages a
standard XML schema would provide.   See below.

> From: Dan Ash <[email-masked]>
> 
> I might be completely off track here, but is it possible, and does it
> make sense to include within the definition of a protocol not only
> different languages to represent the content,  but also a specification
> of how to translate from one language to the another?  If so,  perhaps
> some arbitrary software (independent of the client or the server) could
> translate from one language to another... allowing both the client and
> the server to deploy in either language.  This might alleviate the
> problems mentioned above.

Dan,

The idea of a standard XML schema is that each protocol would *not*
need to specify how to translate one to the other.  Every protocol
would use the same translation.

The protocol document ensures that the ASN.1 and the XML specifications
are equivalent (by mechanically generating one from the other), and
once that is done, the VB programmer doesn't have to know jack about
ASN.1 in order to write an application which exchanges data to and from
an ASN.1 application operating in text mode!

Anders seems puzzled that his suggestion to discard ACs and replace
them with something written in XML was not warmly received, but that
specifying SCVP etc in both ASN.1 and XML seems to be getting more
support.  This is not puzzling; the former involves inventing something
'equivalent' from scratch, whereas the latter involves first
standardizing the information to be exchanged and then writing two
equivalent ways of encoding that information.  Applications can be
developed completely independently - XML developers use their favorite
tools to implement the XML protocol specification, ASN.1 developers use
their favorite tools to implement text mode encoding from the ASN.1
protocol specification, and the two applications work together.

I believe that PKIX should evolve to include both ASN.1 and XML
specifications of each protocol, and should require that those
specifications be equivalent for each protocol which includes
an XML specification.

> From: "Phillip H. Griffin" <[email-masked]>
> 
> What I am proposing is to modify the ASN.1
> standards so that the values of all ASN.1 types can
> be expressed using a common XML markup.

I agree.  But just as RFC 2459 includes both 88 and 92 appendices,
PKIX documents should include both ASN.1 and standalone XML appendices.

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 13 Nov 2000 17:41:47 +0100

David,

<snip>

> an ASN.1 application operating in text mode!

I may be off-track but I don't see how you can generate an XML shema from an ASN.1 spec
without having an "ASN.1-shema".  Or was the idea that the protocol document is
an XML schema only?  On-the-wire format, would it be XML *or* DER?
I see no point in doing that.

> equivalent ways of encoding that information.

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

OK, you *can* represent the entire AC attribute part as *one* XML schema but that
is IMO to use XML the wrong way as it leaves practically all interpretation (guesswork) to
the application layer.  Using a *specific* named schema for each profile things gets much easier.

Another reason to use a "self-contained signed attribute container object" instead of
defining a "certificate" is that you eliminate the need for direct protocol support of things like
cert-path information which could be critical given the "lukewarm" interest to change TLS etc.

And certificates stay in current PKC form (XML or ASN.1).

Using XMLDSIG, ACs would be "yet another business message profile" riding on top
of what others are aleady building, instead of a separate infrastructure.

How do you anticipate that ASN.1 ACs should be differentiated and read (identified, parsed, and
checked for correctness vs a specific profile definition) by verifier software?

With XML schemas, this is already in place without any plumbing at all.
Either the verifier application recognizes the specific AC profile as indicated by the schema
or not.  I see no such possibility with ASN.1 without requiring constant updates of
the reader/parser part.

I.e. to *me* the XML-schema-route is a one-way street with no easy (automatic) turning back.

Regards
Anders

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Tue, 14 Nov 2000 04:54:57 -0500

David,

I seek a broader solution than just support for
XML-schema base text transfer. My goal is to support
transfer of all, and of the exact same set of values 
in binary and text. And I wish to be able to exchange
these values with the biggest possible community. 

I wish to exchange data with folks that simply use
XML markup, XML markup with DTD, XML markup with 
RELAX, XML markup with DT4-DTD, XML markup with 
XML-schema, XML markup with ASN.1 schema, and 
others. I seek a solution that allows me to not
simply transfer XML, but to transfer textual
ASN.1 values tailored to the many XML derivative
markup communities.

My default behavior is simply to exchange values 
with communities that use binary and XML markup
solutions. This requires no further definition 
than the current ASN.1 notation. But I also 
propose to allow additional notation, defined in
an associated file that gives the application
writer the ability to completely control the
form of generated markup.
 
snip

> would use the same translation.

My idea is to guarantee that values can actually 
be exchanged by automatically generating valid
XML markup containing valid ASN.1 values. Of
course, the non ASN.1 application could augment
these values as it desired, adding its own DTD,
DT4-DTD, schema, stylesheet, etc. But these would
not interfere with the format or content of the
data exchange.
 
> an ASN.1 application operating in text mode!

In some ASN.1 specifications this approach may be
possible. But in general, these two schema are not
equivalent. But even where they are, this approach 
does not help all XML communities - just one.
 
> PKIX documents should include both ASN.1 and standalone XML appendices.

I believe that a best ASN.1/XML solution would 
serve the needs of the broadest XML (and HTML 
or XHTML) community. That can best be accomplished
by what seems to be the most simple approach. All
of the XML communities understand marked up values.
This is the common link I seek to exploit for textual
data exchange of binary values.
 
Phil