Subject: Re: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 27 Apr 2007 14:19:37 +0200

Stefan,

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

>This by itself is highly problematic.

I fear that you stopped reading the document, after having read this sentence,
otherwise you would have seen the benefits.  :-)

>As you state, this causes your draft to not be a profile of SCVP. Instead it would technically 
> be a 3rd alternative protocol for on-line certificate status checking.

??? It is not a third alternative, but a second one. 

The goal of LCVP is NOT "on-line certificate status checking", but on-line certificate validation.
It is not intended to be used as an alternative to OCSP.

>It would take extreme reasons to justify creation of such new protocol.

The main arguments to use LCVP are: 
"It is simple and provides more benefits when compared to SCVP".

The main argument to use SCVP is:
 " Why keep it simple, when you can make it complicated ?"

>I have a hard time seeing this happen unless we actually change SCVP 
> to allow your document to be a profile. But to take back SCVP at this stage
> to the working group and to re-shape the requirements would also be 
> very hard to motivate and extremely hard to get consensus on.

A lightweight client profile for SCVP would not be realistic without changing SCVP. 
However, I am NOT in any way asking for any change to SCVP, which is already 
in the hands of the RFC editor.

>I think you need to focus a lot more on the justification for this work.
>Not only why it is useful, but why it is so extraordinary important 
>that it motivates any of these measures.

Besides simplicity, the other arguments have already be given in an e-mail sent to Tim. 
Here there are again:

LCVP supports  additional parameters, whereas SCVP does not (please read the draft for the details):

       validationTime            GeneralizedTime,
       fullSubjectName         FullSubjectName,
       keyUsage                   KeyUsage                  OPTIONAL,
       extKeyUsage             ExtKeyUsageSyntax  OPTIONAL,

validationTime allows to support the validation of signer's certificates used with electronic signatures 
as specified by ETSI, in the case where the signature policy includes a grace period. 

SCVP is unable to do it, unless adding "yet another" extension.

fullSubjectName allows to handle unique names, and thus avoids intentional or deliberate DN collisions.

SCVP is unable to do it, unless adding "yet another" extension or asking the client 
to interpret itself the CertBundle parameter. In the later case, the client is no more a thin client.

keyUsage and extKeyUsage simply allow a application to know these parameters
without the need to process the certificate. It is for thin clients and allows them to know 
the intended key usage(s) of the certificate.

SCVP is unable to return that information, unless adding "yet other" extensions.

BTW, there is a syntax "error" in LCVP that needs to be corrected to make it effectively "lightweight". 
This error originated from the fact that I copied some of the ASN.1 structures from SCVP. Since 
SCVP is not lightweight anyway, this may not be a major problem, but the next version of SCVP 
could possibly take benefit of it.
      
I let you discover it, unless someone else discovers it before you. :-)

It will obviously be corrected in the next version to be published.

Denis

>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Denis Pinkas
>> Sent: den 20 april 2007 14:19
>> To: pkix
>> Subject: Lightweight Certificate Validation Protocol (LCVP)
>>
>>
>>
>> I needed 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
>>

Regards,

Denis Pinkas

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Apr 2007 13:36:58 +0100

Denis,

I'm trying to bring this discussion up above the technical details and features. Listing of technical features does not stand as a motivation for doing the job.
You have to explain why these features are important to the industry and why solving the same problem can't be done without the rather extreme measure you propose. If you protocol was covering new areas of standardization, you would be required to do less of motivation than, as now is the case, your work overlaps with current standards.

This would be the third alternative for on-line certificate status checking:
- OCSP
- SCVP
- LCVP

> read the draft for the details):

So we would have a "Lightweight" version of a protocol that is richer than the standard protocol.
Good or bad, that logic can also be a hard sell.

Stefan Santesson
Senior Program Manager

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 27 april 2007 14:20
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Lightweight Certificate Validation Protocol (LCVP)
>
> Stefan,
>
> >Denis,
> >
> validationTime allows to support the validation of signer's
> certificates used with electronic signatures