Subject: Re:Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 3 May 2007 15:45:12 +0200

Peter,

>Denis,
>
>I have asked some questions and you haven't yet answered. So far, I cannot
>see, as well as others, where do you actually see important differences and
>missing things in existing texts.
>
>You have mentioned some optimisation problems or unnecssary encapsulations
>as one argument. Like other I think that if this is important, you can 
>easily
>come up with let's says as an example, just exchange directly the 
>content of  some
>requests or responses and protect them in whatever appropriate way you 
>want.
>This was mentioned as a possible ajustment to SCVP for example or you
>just do it with XKMS.

I might provide, next week, a full analysis of :

- the sentences from SCVP that do not allow a light weight protocol,
- the features from LCVP that SCVP does not support (unless extending it).

>In your text you have added (this is a standard techniques of yours) a new
>concept which is 'revalidation'. Since this is optional, I don't see what is
>the advantage to have it in a lightweight protocol. IN a providet message
>you did not explain what is is good for, what service is behind etc, 
>using the
>argumenbt that this is optional anyway.
>Actually you seem to propose two essentially different protocol features.
>In any case, both of them seem possible to me using any existing protocol.
>If you want to make simple profiles/protocols, define one for each
>feature.

You are correct, the reasons behind revalidation are not clearly mentioned:

Revalidation allows to support RFC 3126, when an electronic signature needs 
to be rechecked years later: there is no need to rebuild or rediscover a certification 
path, since the client MUST provide all the certificates, CRLs and OCSP responses. 

>I have asked that you might want to explain what you mean
>exactly by certficate validity. What is the distinction between revocation
>checking, and to explain whether and what impact this has to a server.
>In particular, where do you see a difference to what can or is supposed
>to be provided by any protocol, or more what cannot be provided
>by another protocol.

See my previous response from today.

>I think that there are missing service definitions in your proposal, but
>they may also missing similarly in scvp or others. 

Unless you are more precise, there is nothing I can do.

>At least you claim
>that *something*is not possible, I think Stefan really wants to see what.

I will group all these features in the analysis.

Denis

>Peter
>Peter

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 May 2007 17:26:09 +0200

> - the features from LCVP that SCVP does not support (unless extending it).
Sounds interesting.

> I will group all these features in the analysis.
Go ahead.