Subject: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 24 Apr 2007 11:16:12 +0200

I need a simple protocol to delegate the validation of a certificate to a server, 
to be used in environments where a client does not need to demonstrate
to somebody else that it got a given response from a server. This implies 
that the server is fully trusted by the client.

I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", 
or "Standard" anymore, but "Server-based".

However, the use of CMS to encapsulate everything and allowing to optionally sign requests
is not needed, and the use of a subset of the various OIDs is not trivial as well.

I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. 

This proposal is for lightweight clients, hence why it is called Lightweight 
Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP.  :-)

LCVP only supports a subset of the mandatory requirements described in 
[RFC3379] for DPV, hence it does not conform to RFC 3379.  LCVP is 
not either a profile of SCVP.

The major differences with SCVP are the following:

   - the protocol only supports DPV, i.e. it includes no provisions 
     to support Delegated Path Discovery (DPD);

   - requests and responses are not signed, since they are protected 
     by TLS, where clients are not authenticated;

   - validation is only for one certificate at a time;

   - there is no specific parameter in the request to add any 
     parameter to a validation policy known by the server. 
  
LCVP allows a client to delegate certificate path validation to 
a trusted server.  The path validation (e.g. making sure that none 
of the certificates in the path are revoked) is performed according 
to a set of rules called a validation policy.  It allows simplification 
of client implementations and only uses of a set of validation policies 
known by the server.  The document defines a protocol 
that can be used to:

      (1) validate one certificate according to one validation policy,
      (2) query the validation policies supported by an LCVP server. 

At this time, the document is a strawman proposal and has not yet been implemented.
There are certainly errors in it and it can certainly be improved - while keeping it "light".

At this time, the document is an individual draft targeted for the experimental category.

The document is available at: 
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt

The document is proposed to the PKIX WG for consideration and comments.

If the WG, later on, finds this approach interresting, then the document could be 
re-targeted to the standard track category.
 
Denis

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 24 Apr 2007 12:28:20 +0200

LCVP  as well as SCVP allow two different ways to identify a certificate.
Either by providing the certificate or by a reference.

In the second case the server needs to access a repository to obtain
a certificate. To which degree does a server trust the repository to
deliver a valid certificate? Or, in other words, would it be equivalent
or not that the client obtains by whatever means a certificate and
provides it as input.

If the server is provided with a certificate as input, what is the meaning
of a successful response:

- this is a valid certifcate that has in fact been issued by the CA and 
it is trusted etc
- this certificate seems indeed to be signed by the CA etc.

Peter

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 24 Apr 2007 07:27:43 -0700

It may be better for LCVP to rely on signed objects and not change the
SCVP.

While I realize that most clients do SSL/TLS, if we want thin clients to
differ the certification path discovery and validation to a Server,
assuming that TLS or SSL client is there (which requires certification
path validation), may not be the best assumption.

Thus, leaving SCVP alone and processing signed CMS objects for LCVP may
be a better choice.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, April 24, 2007 5:16 AM
To: pkix
Subject: Lightweight Certificate Validation Protocol (LCVP)

I need a simple protocol to delegate the validation of a certificate to
a server, 
to be used in environments where a client does not need to demonstrate
to somebody else that it got a given response from a server. This
implies 
that the server is fully trusted by the client.

I considered using a profile of SCVP. Remember that the "S" does not
mean "Simple", 
or "Standard" anymore, but "Server-based".

However, the use of CMS to encapsulate everything and allowing to
optionally sign requests
is not needed, and the use of a subset of the various OIDs is not
trivial as well.

I looked at other alternatives, outside the IETF, but they do not
provide an adequate answer. 

This proposal is for lightweight clients, hence why it is called
Lightweight 
Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP.
:-)

  

At this time, the document is a strawman proposal and has not yet been
implemented.
There are certainly errors in it and it can certainly be improved -
while keeping it "light".

At this time, the document is an individual draft targeted for the
experimental category.

If the WG, later on, finds this approach interresting, then the document
could be 
re-targeted to the standard track category.
 
Denis

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Apr 2007 15:58:54 +0100

Hi Denis,

My €0.02:

I don't believe there's a significant demand for this. At least
I've not heard of someone who wants this protocol.

If there is a demand, (not met by SCVP), then I further doubt
that there's sufficient energy to fight all these fights all
over again. (cf. Santosh's mail just now.)

If there was sufficient energy, then I doubt that the outcome
would be much different to SCVP.

Finally, if I'm wrong about the above, then whoever it is
that wants whatever it is that SCVP doesn't do and who has
the energy to write new code should of course just use XKMS
and be done with it in a few days rather than in ~2010.

All-in-all I'm for the WG not taking this on,
Cheers,
Stephen.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 24 Apr 2007 18:58:09 +0200

One can say that SCVP has too moch of lower layer specific information. In
fact, one can fold out the signeData or authenticateddata encapsulation 
as well
as TLS transport layer security, http, and the contenttype encapsulation 
saying
the the request and response structure need to be communicated to the 
partner.

In a local unix environment, one could for example just exchange this 
via unix
sockets/pipes as with some ldap, and you do not need any of the overhead, or
one would use some IPSec authenticated channel etc.

Or, one can replace all this lower layer bindings by some usage of WSS 
or secure
WSS or beep, but that's another story.

If one takes just the content of the queries, then it is a matter of 
taste how
to encode certain details of the payload of the query. I don't see that 
there is a
real need to define yet another payload format, as far as I see the 
Denis' essential
argument is that the binding envelopes are too much overhead.

I agree with Stpehen, that in case of, the appropriate subset of XKMS 
can be used,
even if one doesn't like XML, then trasform XMKS into ASN.1 automatically
and code in PER or use the fast doc encoding, etc.

The still unclear question (at least to me) is about the service to be 
provided
and whether there is a difference between the protocols.
See my previous message.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Apr 2007 14:59:13 -0700

I heartily concur with Stephen here.

If you want lighweight PKI then you don't want a certificate based PKI at all. You want a key centric model where the only thing that a relying application needs to do is to ask an external service 'what key should I use to talk protocol X to party Y'.

XKMS is not perfect, but it exists and meets this need. The backing infrastructure behind XKMS will probably involve certificates and SCVP but the client is insulated from all that.

I don't think that you get what you want here unless you abandon the fixation with certificates.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, April 24, 2007 10:59 AM
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: Lightweight Certificate Validation Protocol (LCVP)
> 
> 
> 
> Hi Denis,
> 
> My €0.02:
> 
> I don't believe there's a significant demand for this. At 
> least I've not heard of someone who wants this protocol.
> 
> All-in-all I'm for the WG not taking this on, Cheers, Stephen.
> 
> Denis Pinkas wrote:
> > 
> > I need a simple protocol to delegate the validation of a 
> certificate 
> > to a server, to be used in environments where a client does 
> not need 
> > to demonstrate to somebody else that it got a given response from a 
> > server. This implies that the server is fully trusted by the client.
> > 
> > mean "Simple", or "Standard" anymore, but "Server-based".
> > 
> > optionally sign requests is not needed, and the use of a 
> subset of the various OIDs is not trivial as well.
> > 
> > Lightweight Certificate Validation Protocol (LCVP), like LDAP is 
> > simpler than DAP.  :-)
> > 
> > [RFC3379] for DPV, hence it does not conform to RFC 3379.  
> LCVP is not 
> > either a profile of SCVP.
> > 
> > LCVP allows a client to delegate certificate path validation to a 
> > trusted server.  The path validation (e.g. making sure that none of 
> > the certificates in the path are revoked) is performed 
> according to a 
> > set of rules called a validation policy.  It allows 
> simplification of 
> > client implementations and only uses of a set of validation 
> policies 
> > known by the server.  The document defines a protocol that 
> can be used 
> > to:
> > 
> > If the WG, later on, finds this approach interresting, then the 
> > document could be re-targeted to the standard track category.
> >  
> > Denis
> > 
> > 
> > 
> 
>