Re[2]: OCSP-X vs SCVP

[Timothy Fisher <timothyf@xxxxxxxxxxxxxx>]

This is a step in the right direction, but I still believe that the
fundamental problem that many people have is with ASN1, and not just
the mechanism of encoding the syntax.

In an "Ideal" world for the e-business developers, ASN1 would go away
and PKI data would be designated by a series of PKI DTDs which would
become standardized.

-- 
Sincerely,
 Timothy Fisher                       mailto:timothyf@mindspring.com



Friday, November 10, 2000, 3:31:04 PM, you wrote:



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

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

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

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

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

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