Subject: Re: RE: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 2 May 2007 10:09:36 +0200

Stefan,

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

What are your TECHNICAL  questions ?

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

You got the arguments in previous emails. They may not be sufficient, but so far 
you have not raised arguments against them.

>I don't want a list of technical features you provide. I want an analysis of the impact of the industry.

It is the first time that a chair asks for "an analysis of the impact of the industry".

We may discuss technical advantages and drawbacks of one solution to a problem 
versus another, but an "an analysis of the impact of the industry" is an inappropriate 
question in the context of this WG..

Denis

>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
>Windows Security, Standards
>
>
>> -----Original Message-----
>> From: Denis Pinkas [mailto:[email-masked]]
>> Sent: den 27 april 2007 15:07
>> To: Stefan Santesson
>> Cc: pkix
>> Subject: Re: Lightweight Certificate Validation Protocol (LCVP)
>>
>> 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
>>
>>

Regards,

Denis Pinkas

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 2 May 2007 09:23:01 +0100

Denis,

Your job is to convince the WG that there is substantial reason to work on your draft. So far you have not been successful.

I can only offer you honestly what I personally need to be convinced. In this case I will mostly not be convinced by technical arguments listing all things you can do with your protocol. To convince me you need to demonstrate the need in the industry and also convince me that the negative impact on the industry by adding another protocol, is less than the benefits.

That consideration is valid for IETF in its mission to make the internet better and therefore also for this WG.

However I'm not telling you what to do and I am not the WG. As chair I do determine consensus but I'm only 1 voice.

Stefan Santesson
Senior Program Manager

> Sent: den 2 maj 2007 10:10
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: RE: Lightweight Certificate Validation Protocol (LCVP)
>
>
> Stefan,
>
> >Denis,
> >
> >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

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 02 May 2007 17:49:19 +0200

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.

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.

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.

I think that there are missing service definitions in your proposal, but
they may also missing similarly in scvp or others. At least you claim
that *something*is not possible, I think Stefan really wants to see what.

Peter

Peter

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 May 2007 09:31:24 -0700

At 9:23 AM +0100 5/2/07, Stefan Santesson wrote:
>Your job is to convince the WG that there is substantial reason to 
>work on your draft. So far you have not been successful.
>
>I can only offer you honestly what I personally need to be 
>convinced. In this case I will mostly not be convinced by technical 
>arguments listing all things you can do with your protocol. To 
>convince me you need to demonstrate the need in the industry and 
>also convince me that the negative impact on the industry by adding 
>another protocol, is less than the benefits.
>
>That consideration is valid for IETF in its mission to make the 
>internet better and therefore also for this WG.
>
>However I'm not telling you what to do and I am not the WG. As chair 
>I do determine consensus but I'm only 1 voice.

Let me add a second voice, agreeing with Stefan. From this thread, I 
see that your proposal is close to SCVP in functionality with some 
differences he considers important. Others have said that most of the 
differences you gave are already in SCVP.

If there is a large industry segment who need your differences, we 
might consider it for WG action. Otherwise, this should be an 
individual contribution with its own mailing list and occasional 
pointers here to the new drafts.

--Paul Hoffman, Director
--VPN Consortium