Subject: RE: OCSP-X vs SCVP

From: Khaja Ahmed <[email-masked]>
Date: Thu, 9 Nov 2000 18:48:48 -0500

Michael,

Let me begin by saying that, from a purely objective perspective, a
reasonable to good case can be made for either approach.  But it isn't about
what approach is technologically / demonstrably more efficient or in some
way better. It has more to do with what the target users of a protocol /
standard / solution want and can use.  That is what drives usage of
technology.  I do not claim to know what the broad market wants. I just
happen to know what a section (an important one) leans towards.

The XML community I am referring to and am aware of is a group of financial
institutions.  (There may be others)  These financial institutions have a
group of application and solution developers within their ranks who (most of
them) know and love XML.  They prefer to avoid dealing with ASN.1.  This XML
community finds it easier to read, deal with and encode information in XML.
They are able to debug protocol implementation problems where XML encoding
is used. They know and are comfortable with XMLDSIG and use that rather than
PKCS#7 to send signed transactions back and forth.  They have plans to use
delegated path validation so they will not be doing PKIX section 6.1 stuff
locally.  They want to increasingly move towards a set of protocols that use
XML encoding for these reasons.  

As you clearly and correctly point out their applications cannot really get
away completely from ASN.1 - at least yet.  They are, therefore, willing and
able to use an API, which as you rightly observe, has to have ASN.1 parsing
capability to pop a key out of a certificate to verify a signature and do
sundry inescapable ASN.1 fiddling. What is however possible (and to the XML
community, desirable) is to increase the XML encoded content and decrease
the ASN.1 encoded content in their environments.  I know of at least one
bank that has a team of engineers, which does everything XML in-house, and
need to get a fairly pricey contractor to deal with ASN.1 stuff.  They are a
canonical representation of what I refer to as the "XML community".

I would suggest that it is reasonable to want to move along a continuum
towards increasing XML encoded content in one's space without getting all
the way there.  Just because you can't completely escape ASN.1 is no reason
to continue to do everything in ASN.1.

Finally, (suspecting that this will come up) in the debate over how ASN.1 is
more compact and efficient relative to XML I would suggest we consider one
other aspect.  In large scale use and deployment the number of people who
can deal with a given technology is a key factor.  The fact that XML is more
human readable and easier to deal with is an efficiency factor that impacts
application availability.  

Khaja

-----Original Message-----
From: Michael Zolotarev
To: Khaja Ahmed; 'Russ Housley '; [email-masked] '
Sent: 11/9/00 5:51 PM
Subject: RE: OCSP-X vs SCVP

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: "Anders Rundgren" <[email-masked]>
Date: Fri, 10 Nov 2000 08:59:28 +0100

RE: OCSP-X vs SCVPKhaja,

<snip>

>The XML community I am referring to and am aware of is a group of financial institutions.  
>(There may be others)  These financial institutions have a group of application and solution
> developers within their ranks who (most of them) know and love XML.  They prefer to avoid
>dealing with ASN.1.  This XML community finds it easier to read, deal with and encode
>information in XML.  They are able to debug protocol implementation problems where XML
>encoding is used. They know and are comfortable with XMLDSIG and use that rather than
>PKCS#7 to send signed transactions back and forth.  They have plans to use delegated path
>validation so they will not be doing PKIX section 6.1 stuff locally.  They want to increasingly move
>towards a set of protocols that use XML encoding for these reasons.  

I would say that this statement is valid for the e-business sector in general. 

According to some notable persons on this list, XML-encoded systems are not
the target for PKIX as it is based on ISO-standards which currently are ASN.1-based.

Steve K et al: Is'nt time to "adjust" the scope of PKIX and make the "X" not only refer
to "X"500 but to "X"ML? 

<snip>

Regards
Anders

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Nov 2000 17:32:09 -0500

>Steve K et al: Is'nt time to "adjust" the scope of PKIX and make the 

No, but thanks for asking.

Steve