Re: OCSP-X vs SCVP

["Phillip H. Griffin" <phil.griffin@xxxxxxxxx>]

"David P. Kemp" wrote:
> 
> > From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
> >
> > 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.

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

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

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

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.
 
> 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" <phil.griffin@asn-1.com>
> >
> > 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.

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