Subject: OCSP-X vs SCVP

From: Russ Housley <[email-masked]>
Date: Thu, 09 Nov 2000 17:11:21 -0500

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: Khaja Ahmed <[email-masked]>
Date: Thu, 9 Nov 2000 17:26:35 -0500

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

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

Let the debate begin ...

Russ

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 10 Nov 2000 11:16:18 +1100

Khaja,

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.   

Does Identrus use TLS? Do the target users 'want' use it? 'Can' they? Or
should we start of re-implementing TLS so that the TLS handshake protocol
exchanges XML messages from now on?
Would you agree it is quite absurd? Hope so.
 
We must realise that there is always a line between XML and 'everything
else'. Pushing that line down may be justified in one environment, and be
totally unprudent for others. The justifications would be the same as
always: what you want to see and what you don't, ease of use by the
end-apps, ease of implementing, ease of problem tracing, and I dare to say
efficiency (knowing it'll be never accepted as an argument by XML community
:).
 
Anyway, here is a deal: imagine that I can give you an OCSP responder which
implements both ASN and XML. Make your move, and give me a hypotetical but
realistic case of an XML system which will be using 'my' OCSP. Explain how
does your XML end-user application, or any other application in your system
WANT to use it. Also please explain how that very application CAN use it.
 
Show me where the reality of OCSP internal messaging and encoding gets
actually visible, and how doing it in XML way would make it more
appropriate. 
 
And who knows - I may agree with you after all.
 
Best regards
Michael
 
 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]
<mailto:[email-masked]> ] 
Sent: Friday, 10 November 2000 8:27 
To: 'Russ Housley '; [email-masked] ' 
Subject: RE: OCSP-X vs SCVP 

Khaja 

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

Let the debate begin ... 

Russ

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 10 Nov 2000 14:05:45 +1100

Paul,

I think this is a classic example of MZ been taken wrong once again,
unfortunately.

And it was the least of my intentions to be "loud and repetitive".

The point I'm trying to make is that we have to be really careful about
rushing into XML. 
In many cases - and I'm sure you'll be able to confirm it more than anybody
else - people say XML, and want XML, and 'can' XML just for heck of it.
Trying to push XML into places where it doesn't really belong, or have no
technical reasons to be.

The line between protocols and APIs is a subtle one. There is a common mixup
between what is protocol, and what is the presentation layer. The use of
OCSP by XML-enabled applications can be, and should be IMHO facilitated by
APIs. With the application been completely unaware of what goes through the
wire, and what is the format of what was transmitted.

And so far I didn't hear any single argument which justifies (except just
saying 'our customers want it') the opposite. Still waiting...

Again, I'm not against XML in PKI. And I can be as loud and repetitive as I
am defending use of XML in other areas of PKI. But with OCSP - sorry, I'm
not convinced.

Michael

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Friday, 10 November 2000 12:03
> To: Michael Zolotarev; Marc Branchaud
> Cc: [email-masked] '
> At 12:06 PM +1100 11/10/00, Michael Zolotarev wrote:
> >  >
> >>  > >  But that ain't how the world works, and
> >>  > > that ain't how
> >>  > > people want it to work.
> >>  >
> >>  > Proof, please. I want the proof.
> >>  >
> >>
> >>  The fact that people seem to care about this is proof 
> enough for me...
> >
> >MArk, this is really speculative thing to say... I don't buy it as an
> >argument, sorry.
> 
> It is not speculative. There have been people on this mailing list 
> who have said that they want an XML-based solution. Telling them that 
> you don't buy their opinion as an argument will tend to cause them 
> not to contribute again, yes? At that point, the WG will reduce to 
> those of us who are loud and repetitive. That is not a good way to 
> produce good protocols.
> 
> >Dont think it is a real issue with hosts and desktops. Dont 
> think there is
> >an issue with mobile devices either. I am not saying it is a 
> bloat, or it is
> >not. I just want some approx figures. Compare bare-minimum
> >ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I 
> assume that XML
> >parser is present on the platform regardless, so it doesn't count).
> 
> This level of argument reduces to "the customer is usually wrong". 
> That works in some areas, not in others. Given two protocols that 
> could meet the same objectives, such arguments are likely to squelch 
> input from the very people we should be listening to.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Nov 2000 14:28:41 +0100 (MET)

> that SCVP is the better answer.

If I remember correctly, the first element of the discussion was
that we are actually talking about 'two services', i.e., path
determintation and path validation. And that there was some feeling
that the SCVP definition of path determination is not sufficient.
  
Or, SCVP contains two completely different parts, and at least
one of them is not a protocol at all. 

Furthermore, I do not think that having defined two concrete encoding
for the same abstract data is enough reason alone to choose a protocol. 

The ASN1 SCVP encoding use 'yet another signature scheme'.
It is already unfortunate that in the ASN1 case we have at least three
different ways of signing data, i.e., x509 certs, pkcs7 signeddata, 
ocsp responses. I don't think we need a new one. Think about the
the code to validate a time stamped pkcs7 extended signature
containing some responses from ocps and maybe scvp.
 
The error and status codes defined a character strings are not reusing
semantically equivalent and already existing data like PKIStatus.

The XML part still requires that an implementation knows something about
ASN1. What about having the protocol not just validate the certificate,
but also to extract the textual components like X509IssuerSerial, keyInfo
etc, i.e. allow a very light client that has no ASN1 knowledge at all. 

The overall OCSP response data structures are also somewhat unfortunate.
There are several layers: an unsigned outer part, a security envelope
(signature), signing arbitary content defined by an OID. Several content
definition. IMHO, the outer level is useless, because you need to look at
the signed content anyway. The signature scheme is as bad as the X509 cert
scheme, two passes necessary for verification. I am not quite sure why one
hadn't simply used pkcs7. 

I have the impression that any of the content types that are defined
in OCSP, or TSP, etc, could be encoded as well in XER++ instead of DER, 
CER, BER. IMHO this encoding rules should not be defined on a protocol
by protocol basis, but in a general way. This may needs some restriction
of the use of some ASN1 features or/and a way to express things like asn1
structures encapsulated in octet/bitstrings, in order to get a non blob
version of Extensions for example.

Then, for example If someone likes the PSResponse content, it seems possible
to me to define an OID for that and use this either in an OCSP response, or
as a pkcs7 signed data content, or as xmldsig protected data.
In other words, any protocol should specify the data to be transported, 
requirement about the security needs for transport and long term, and one
should try to use already established techniques. 
 
BTW: Marc is right about ASN1: "liberez A S N un, liberez A S N un" !!! :-)

nuf said.
Peter

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 10 Nov 2000 07:03:25 -0800

It seems to me that this discussion has focused on encoding and syntax, but
not on the semantics of path creation and validation. In other words, what
are the requirements for server-based (including delegated) path creation
(or discovery) and validation.

I would like to see PKIX's solution support the ability for a client to make
one request to a server to create and validate a certification path given an
end-entity certificate, with the option of having the server return the path
in its response. It should also be possible to include one or more
end-entity certificates in a request.

Frank

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Friday, November 10, 2000 8:29 AM
> To: [email-masked]
> Subject: Re: OCSP-X vs SCVP
> 
> 
> >

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 10 Nov 2000 12:07:44 -0500

Hi Russ,

> ----------
> From: 	Russ Housley[SMTP:[email-masked]]
> Sent: 	Thursday, November 09, 2000 5:11 PM
> To: 	[email-masked]
> Subject: 	OCSP-X vs SCVP
> 
 
I think we're all in agreement here (including the chairs).  My
understanding is that by the end of this year (perhaps at the San Diego PKIX
meeting, or perhaps immediately afterward via straw poll on the list) the
PKIX group will have chosen a single protocol into which to put its efforts.

> sure that there is consensus about these user groups.  If not, we need to 
 
I don't know if there is consensus about these three groups either, but they
sound reasonable to me.

> that SCVP is the better answer.
 
Here is where your train of thought loses me.  

 - Is SCVP significantly lighter weight than OCSP with the validation
extension?  I think it may possibly be lighter, but it's not clear to me
that there is a significant difference, so I see little distinction here on
which to make a decision.

 - Organizations that want centralized control -- and want to achieve this
through the use of a central server that gives validation answers -- can
equally use SCVP or OCSP/DPV.  The central responder model is the basis of
both protocols, so again I don't see a distinction here.

 - The value of XML (versus ASN.1 DER) for delegated path validation or
discovery can be debated long and hard, and probably will be  :-)  However,
these are just alternate encodings for the information that travels over the
wire between the requester and the responder.  Either protocol can be
encoded in either way (as illustrated by SCVP, which is encoded in both
ASN.1 DER and XML in the spec.).  OCSP and its extensions does not currently
have an appendix saying how to encode the protocol in XML, but there is
nothing preventing a competent XML devotee from spending an hour to write
this up and give it to the editors for inclusion.  So, the XML "argument"
does not distinguish these protocols either.

> Let the debate begin ...
 
Agreed.  Let the debate begin, but let it be based on something that will
allow us to come to a conclusion.  To me, the real distinguishing feature
between the two offerings is fairly straightforward:  does it make sense for
the PKIX Working Group to define a framework for the "responder model"
within which various questions can be asked in a standardized manner?  If
so, then OCSP is the right answer.  (It currently proposes three possible
questions:  what is the status? what is the validity with respect to a given
purpose? and what is the path with respect to a given root?  Other questions
can be defined if and when needed.)  If we don't want such a framework, then
we should go the other route and define a brand new protocol for every new
question that someone dreams up.

I personally see little value in the latter alternative, regardless of how
much fun it is to create new protocols.  It makes much more sense to support
such related questions in a framework protocol, especially because there may
be cases in which combinations of questions are of interest to the requester
(e.g., "give me the status (or the validation) answer, but ALSO give me the
path you found so I can keep it for my evidence/archive records").

I think the framework protocol for the responder model is the right approach
for defining and posing a set of similar questions.  I suspect that as time
moves on and we see requirements for new questions (or nuances on existing
questions), having such a framework will stand us in good stead.  This is
why I've come down on the OCSP side, even though I currently see nothing
technically wrong with SCVP.  If XML is important (and I know that it is
perceived to be, for at least some environments), then I'm sure that someone
can find a co-op somewhere who'll do an encoding for OCSP and its extensions
faster than America can choose a new President...  :-)

Carlisle.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Nov 2000 18:14:30 +0100 (MET)

> (or discovery) and validation.

Right, one should concentrate on the requirements. 
 
From your wording, it seems to me that you mainly interested in one use case,
i.e.,  determining the validity of a cert in order either to verify a signature
or authentication or to verify the validity of an encryption cert before 
using it?

> end-entity certificates in a request.

If this requirement would be the only one, wouldn't be a conformant
implementation just be a sequence of certificates sent
within connection to an authenticatable server, and get a sequence of
chains back? 

Other "possible" requirements or questions:

- The result of the service should not only be verifiable at the
  moment when received by the client, but also later.

- If multiple certs are validated, should it be
  possible to split the result, and keeping the possiblity of
  authenticating the response parts, or not. 

- Is a response independant of the request, or is it necessary
  to include a reference to it in the longterm authenticable
  part.
  
- The server indicates why the certification path is valid and what
  efforts have been made. 

- The response may be included in some data (for example as
  part of a signed attribute).

- The service should help to verify a xmldsig signature. I.e., the
  result should allow a thin client to present a human readable
  interpretation of the certificate and the verified path without
  looking at the asn1 blobs. 

- ...

---

From: Khaja Ahmed <[email-masked]>
Date: Sat, 11 Nov 2000 05:30:48 -0500

> When I some days ago launched the idea that AC's should (or could) be
> based on XML schemas there were hardly any sentiment for that.

> Some even cocluded that XML was not a PKIX-item!

> Now I see a lot of XML "promotion" in an other PKIX-area which is
> interesting but slightly puzzling.

> IMO ACs have at least the same "informational content" as OCSP-X and
> SCVP.  Each AC "authorization profile", "receipt" or "ticket" ought 
> to be just perfect to express as an XML schema.  Wouldn't it?

It would.  Indeed that is precisely the thing needed for a distributed
authorization management solution being contemplated in some very large
applications.  If you did not get support for it previously that is
regrettable.  I certainly would support that wholeheartedly.

Khaja

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 14 Nov 2000 17:23:36 -0700

>
>But I see your point.  You weren't talking about an OCSP API, but instead an
>ASN.1 (as opposed to XML) API.  At that level, I agree: people can pick up
>toolkits to work with either.
>
>Many, though, seem to be reluctant to have to work with both.  I suppose
>there this is where the crux of the issue lies.  Most PKI folk work in ASN.1,
>while many non-PKI folk use XML.  The non-PKI folk want their XML apps to use
>PKI (as do the PKI folks, I might add), but they don't want to bloat their
>apps with an ASN.1 toolkit.  Similarly, the PKI folk don't want to bloat
>their apps with an XML toolkit.
>
>Either some non-PKI folk have to want PKI badly enough to accept the bloat,
>or the PKI folk have to want to spread PKI badly enough to adopt XML.  Either
>way, someone has to give.

Just as a data point re the alleged "bloat" caused by ASN.1.

We wrote our own toolkit, and the core functionality is about 12K of code.  

The full set with the frequently used set of OIDs, certificate prototypes, etc., 
maybe amounts to 20K+ .

So far, the overhead of statically binding a 20K toolkit is so low that we haven't
even bothered to turn this into a DLL (or the equivalent for other operating systems),
although it would be easy to do so.

As for non-vendors (high school students?) who don't have the time, money or inclination 
to acquire commercial toolkits themselves, (a) let them eat cake? :-) or (b) let them
go to people like Peter Gutmann and/or other public domain sources.

The toolkit issue is a red herring, I believe.  It is really more of a stylistic and/or 
education or religious question, like debating the merits of C vs. CORBA..

As someone once said in a different context, arguing this point is like teaching 
a pig to whistle.  It is a waste of your time, and it annoys the pig.

Bob

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Nov 2000 11:16:31 -0500

Several folks sent me private messages agreeing that Juan's comments 
were offensive, but worrying that my private message to Juan (which 
he then sent to the PKIX list) was some sort of banishment. Let me 
clarify:

I cannot and would not ban Jaun from attending a PKIX meeting. That 
is clearly not appropriate, nor would it be allowed by IETF 
procedures, to the best of my knowledge.

I meant exactly what I said, i.e., I look forward to not seeing Jaun 
at these meetings. I also look forward to not seeing several other 
folks who participate in various working groups, but sometimes I am 
disappointed and I do see them at these meetings.

Steve