Subject: RE: OCSP-X vs SCVP

From: Michael Zolotarev <[email-masked]>
Date: Fri, 10 Nov 2000 09:51:59 +1100

Can anyone bother explaining a simple thing to me (I didn't have my morning
coffee yet, so I'm still mentally a bit retarded):
 
What is XML community, exactly? Is it a bunch of applications sitting on top
of XML-messaging backbone? Now then, do those application call any APIs at
all? Or do they do all the heavy-weight stuff themselves? I hope that a
concept of APIs is not totally abandoned in the "XML community". Does
anybody in the community create PKCS10 in hard way? Or parse a certificate,
or a CRL by doing it bit-by-bit, doesn;t matter what the encoding is? I
guess no. They use APIs.
 
If so ( if not, stop further reading), then obtaining OCSP is just another
matter for an API. And it absolutely doesn't matter if the API uses ASN1 or
XML or whatever else. The XML-community won't see it, and must't see it.
Exactly as it is for VB community, Fortran community, Cobol community and
IBM360 mcaro assembler community.
 
Time for my morning coffee. I'll be more bright when I'm back :) Please
response.
 
Michael

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]]
Sent: Friday, 10 November 2000 8:27
To: 'Russ Housley '; [email-masked] '
Subject: RE: OCSP-X vs SCVP

I would even go so far as to say that for the community that is XML
dependant the nomination you make is the only workable one.

Khaja 

-----Original Message----- 
From: Russ Housley 
To: [email-masked] 
Sent: 11/9/00 5:11 PM 
Subject: OCSP-X vs SCVP 

A few weeks ago, there was a brief discussion of OCSP-X vs SCVP.  The 
only 
consensus point was that we need to have one PKIX solution for 
certification path validation, not two.  However, we did not pick one of 

these two alternatives.  I think we need to pick one.  We should not put 

further efforts into two solutions. 

There are at least three communities that need to be served by this 
protocol: very lightweight clients, organizations that want centralized 
control, and clients that do not parse ASN.1 but understand XML.  I am 
not 
sure that there is consensus about these user groups.  If not, we need 
to 
get to consensus ... 

If these are the user groups that we are trying to satisfy, then I think 

that SCVP is the better answer. 

Let the debate begin ... 

Russ

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 09 Nov 2000 16:08:04 -0800

> matter for an API. And it absolutely doesn't matter if the API uses ASN1
> or XML or whatever else. The XML-community won't see it, and must't see it.

Well, somebody has to see the ASN.1, because somebody has to write the API. 
Sure, us PKI vendors would be pickled tink if everyone would just buy our
toolkits to do PKI.  But that ain't how the world works, and that ain't how
people want it to work.

Of course people will use APIs.  But one way to judge the success of a
protocol is by the number of toolkits that support it.  I believe that it's
important to design a protocol to be easy to implement, even if the vast
majority of the protocol's users will never care.

(No flames, please!  I'm quite happy with either standard.  If I've one
criticism, it's that the ASN.1 specs are not free.)

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

---

From: Rich Salz <[email-masked]>
Date: Thu, 09 Nov 2000 20:40:07 -0500

I think that we should wait, let vendors (and communities) get some experience
deploying solutions, and see what shakes out.  There are certainly risks, but
I think it imprudent to create something from scratch.  By waiting, we at
least get to see which community(ies) form, and what needs must be addressed. 
Until that happens, it's just like guess hypothetical dot-com marketshare. :)
	/r$