Subject: Re: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 27 Apr 2007 15:07:29 +0200

Stefan,

>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

I fear you have not fully read my e-mail. Please re-read carefully.

>Quote:
>> LCVP supports  additional parameters, whereas SCVP does not (please
>> read the draft for the details):
>
>So we would have a "Lightweight" version of a protocol that is richer than the standard protocol.

LCVP  is a "Light" version of CVP, not a light version of a "Server-based Validation Certificate Protocol 
(alias SCVP)".

>Good or bad, that logic can also be a hard sell.

If you take the time to read the document, you will get the answers to most of your questions.
If there are some points that are not well explained, I may help.

Denis

>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
>> -----Original Message-----
>> 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,
>> >
>> >> 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
>>
>>

Regards,

Denis Pinkas

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Apr 2007 18:11:02 +0100

Denis,

I have read your e-mail and your draft, at least a majority of it. It does not provide the answers I need.

I need you to motivate why we need yet another protocol for on-line status checking.
A "Read the document" reply is not sufficient for me.

I don't want a list of technical features you provide. I want an analysis of the impact of the industry.
Personally I'm totally against writing yet another protocol for this, and you have so far not been able to convince me.

Stefan Santesson
Senior Program Manager

> Sent: den 27 april 2007 15:07
> To: Stefan Santesson
> Cc: pkix
> >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.
> >

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 27 Apr 2007 19:55:25 +0200

Stefan Santesson wrote:
> Personally I'm totally against writing yet another protocol for this, 
> and you have so far not been able to convince me.
>
>
I have read the text, and I am waiting to at least a response to one 
question concerning the service
(send some days ago).
I also agree with all those who do not want yet another protocol just for
certficate verification.

As a detail, the definition of the initial verification, revalidation, the
required inputs for both cases, their security feature, the requirements
for external access to a repository or not, is very unclear, thus difficult
to compare with SCVP, XKMS, OCSP, DVCS

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 27 Apr 2007 09:34:27 -0800

I vote against this proposal as a PKIX standards-track work item.  Should it
be implemented and fielded in a scope that materially affects the Internet,
then and only then publish an Informational.

Mike