Re: OCSP-X vs SCVP

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

Paul Koning wrote:
> 
> >>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
> 
>  Ambarish> Hi Guys, Just to keep things simple, it would be good to
>  Ambarish> break up this debate into 2 separate discussions:
> 
>  Ambarish> 1. Should PKIX protocols/work items support XML well or
>  Ambarish> should they just stay with ASN.1
> 
> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ?   It
> sounds more like the latter, and given that "ASN.1" is sometimes
> mentioned when a more precise reference would be to
> BER/DER/etc. instead, I wonder...
> 
>        paul

As very much of a side note, the group that works on the 
ASN.1 standards is nearing consensus on how to approach
standardization of an ASN.1/XML capability. Formal work
will begin next meeting and likely conclude by the 2Q 
next year. But the basic problem set has been under study
for well over a year and a half.

There are still some competing ideas, but I have proposed
recently and gotten some support for creating a default 
XML markup associated with ASN.1 values. The markup would 
be based on the structure and schema information (and the
identifier and type names) provided by ASN.1 specifications.
Further work would add the ability of the user to change or
augment the default markup. 

This would allow an ASN.1 based protocol to encode data for
transfer using either text or binary encoding rules. For the
case of text transfer, there are proposals to support both
tagged (*ML markup) and untagged text. The association of
default markup with an ASN.1 specification would make it 
possible for a sender to transfer data efficiently using
BER or PER, then decode the binary representation of the 
values into a tagged or untagged text format for direct
display - no well formed checking or validation required,
as the act of ASN.1 encoding and decoding already performs
these tasks.

The idea is to layer *ML markup on top of ASN.1 which has
a single, mature schema, well defined canonical forms, 
efficient encoding rules, and encoding control notation. 
This approach avoids completely the moving target problems
we've continued to encounter when attempting to map ASN.1 
schema into XML (DTDs, XML-schema, DT4-DTD, RELAX, BizTalk,
etc.).

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