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.
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 '; 'ietf-pkix@imc.org '
Sent: 11/9/00 5:51 PM
Subject: RE: OCSP-X vs SCVPCan 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:Khaja.Ahmed@identrus.com]
Sent: Friday, 10 November 2000 8:27
To: 'Russ Housley '; 'ietf-pkix@imc.org '
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: ietf-pkix@imc.org
Sent: 11/9/00 5:11 PM
Subject: OCSP-X vs SCVPA 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