Subject: RE: OCSP-X vs SCVP

From: Ambarish Malpani <[email-masked]>
Date: Fri, 10 Nov 2000 10:54:33 -0800

Hi Guys,
    Just to keep things simple, it would be good to break up this
debate into 2 separate discussions:

1. Should PKIX protocols/work items support XML well or should
they just stay with ASN.1

2. Which is a better way of doing remote path processing:
a. SCVP
b. OCSPv2 with OCSP-valid and OCSP-path

I will follow up with posts on the two topics.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

---

From: Paul Koning <[email-masked]>
Date: Fri, 10 Nov 2000 14:25:55 -0500 (EST)

>>>>> "Ambarish" == Ambarish Malpani <[email-masked]> 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

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 10 Nov 2000 15:31:04 -0500

> BER/DER/etc. instead, I wonder...

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

---

From: Timothy Fisher <[email-masked]>
Date: Sat, 11 Nov 2000 17:31:54 -0500

I think that the discussion really should be XML vs. ASN1, and not
just XML vs. BER/DER/*ER.

-- 
Sincerely,
 Timothy Fisher                       mailto:[email-masked]

>>>>>> "Ambarish" == Ambarish Malpani <[email-masked]> writes:

PK>  Ambarish> Hi Guys, Just to keep things simple, it would be good to
PK>  Ambarish> break up this debate into 2 separate discussions:

PK>  Ambarish> 1. Should PKIX protocols/work items support XML well or
PK>  Ambarish> should they just stay with ASN.1

PK> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ?   It
PK> sounds more like the latter, and given that "ASN.1" is sometimes
PK> mentioned when a more precise reference would be to
PK> BER/DER/etc. instead, I wonder...

PK>        paul

---

From: Timothy Fisher <[email-masked]>
Date: Sat, 11 Nov 2000 17:35:25 -0500

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.

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

>> BER/DER/etc. instead, I wonder...

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