Subject: Re: Lightweight Certificate Validation Protocol (LCVP)

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 24 Apr 2007 10:32:06 +0200

Tim,

Thank you for your time for reviewing LCVP. See my responses below.

>Denis,
>
>I finally found some time this weekend to review the LCVP  
>specification.  I thought it was important to avoid snap judgements.   
>After reviewing the specification, I do not see a justification for  
>pursuing this document.
>
>If we consider this specification from a DPV client viewpoint, there  
>are very few differences between an LCVP client and the minimal SCVP  
>client.  You identify the following differences (my numbering for  
>clarity):
>
>    (1) the protocol only supports DPV, i.e. it includes no provision  
>to support Delegated Path Discovery (DPD);
>    (2) requests and responses are not signed, since they are  
>protected by TLS, where clients are not authenticated;
>    (3) validation is only for one certificate at a time;
>    (4) there is no specific parameter in the request to add any  
>parameter to a validation policy known by the server.
>
>However, this overstates the differences.  (1) SCVP implementations  
>are not required to implement both DPD and DPV.  (2) SCVP clients and  
>servers MUST support protected (e.g., signed) responses, but the  
>client may choose to use TLS as a protected transport to protect the  
>responses.  

This single argument (i.e.  SCVP clients and servers MUST support 
protected (e.g., signed) responses) illustrates why it not make sense
to mandate such a support when only transport layer security is being used.
This means it is not effective to profile SCVP to only fulfill the requirements 
addressed by LCVP.

>(3) Clients are not only permitted to submit requests one  
>certificate at a time,  conforming client implementations are not  
>required to support multi-certificate requests.  (4) As in 3,  
>modifying the validation policy need not be supported by conforming  
>clients.
>
>In short, LCVP does not provide functionality that is unavailable in  
>SCVP.  

This is incorrect. Please take a look at:

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

The meaning of producedAt in SCVP is different from the meaning of 
validationTime in LCVP. LCVP with this parameter may support 
the validation of certificates used for non repudiation puroposes, 
whereas SCVP can't. See the explanations about the grace period

fullSubjectName allows to handle unique names, whereas SCVP can't.

keyUsage and extKeyUsage simply allow a application to know 
these parameters without the need to process the certificate.

Of course, using four new OIDs it would be possible to expand SCVP 
to support these parameters, but it wan't be as simple as in LCVP.

>While LCVP's ASN.1 appears less complicated,

I am glad you acknowlege the fact that LCVP is simpler than SCVP.

> the data structures generated by minimally conforming SCVP DPV-only client  
>implementations appear to have similar levels of complexity. 

I do not think so. Beside the unneeded complexity of the response 
which results from the use of CMS:

     ContentInfo {
       contentType        id-ct-scvp-certValRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
       content            CVRequest }

there is a  lot of OIDs to manage.

Another example of overcomplexity is the mandatory use of the following OID { id-svp 1 } 
to specify the default validation policy, while LCVP may simply omit the parameter:

     valPolicyRef                 ValPolicyRef             OPTIONAL,

Furthermore, where LCVP allows any default validation policy, in SCVP :
" The default validation policy MUST use the basic validation algorithm 
as its default validation algorithm". 

There is a French common saying, which states roughly the following:

" Why keep it simple, when you can make it complicated ?"

It would perfectly apply to an SCVP profile (if any was possible).

>I cannot see any reason to pursue a new DPV protocol that ignores the  
>requirements established in 3379 within the IETF.
 
It does not ignore them, but does not take all of them.

> I can see the  
>rationale for a  lightweight client profile for SCVP, as suggested by  
>others on this list, to demonstrate how simple an SCVP client can  
>actually be.

A lightweight client profile for SCVP is not realistic without changing SCVP. 
SCVP is already in the hands of the RFC editor for publication as an RFC.

Denis

>Thanks,
>
>Tim Polk
>
>On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote:
>
>>
>>
>> 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: "Seth Hitchings" <[email-masked]>
Date: Fri, 27 Apr 2007 13:38:58 -0400

Denis,

If SCVP did not require clients to support protected responses, would you
still find sufficient need to develop a new protocol? I think that there's
some room for clarification as to whether a response received via a
protected transport mechanism is in fact protected and therefore shouldn't
require CMS encapsulation.

I'm not advocating changing SCVP at this stage, mind you.

Seth

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

Tim,

>    (2) requests and responses are not signed, since they are protected 
>However, this overstates the differences.  (1) SCVP implementations are 
>not required to implement both DPD and DPV.  (2) SCVP clients and 
>servers MUST support protected (e.g., signed) responses, but the client 
>may choose to use TLS as a protected transport to protect the 
>responses.

This single argument (i.e.  SCVP clients and servers MUST support protected
(e.g., signed) responses) illustrates why it not make sense to mandate such
a support when only transport layer security is being used.
This means it is not effective to profile SCVP to only fulfill the
requirements addressed by LCVP.

>(3) Clients are not only permitted to submit requests one certificate 
>at a time,  conforming client implementations are not required to 
>support multi-certificate requests.  (4) As in 3, modifying the 
>validation policy need not be supported by conforming clients.
>

The meaning of producedAt in SCVP is different from the meaning of
validationTime in LCVP. LCVP with this parameter may support the validation
of certificates used for non repudiation puroposes, whereas SCVP can't. See
the explanations about the grace period

keyUsage and extKeyUsage simply allow a application to know these parameters
without the need to process the certificate.

Of course, using four new OIDs it would be possible to expand SCVP to
support these parameters, but it wan't be as simple as in LCVP.

> the data structures generated by minimally conforming SCVP DPV-only 
>client implementations appear to have similar levels of complexity.

I do not think so. Beside the unneeded complexity of the response which
results from the use of CMS:

     ContentInfo {

Another example of overcomplexity is the mandatory use of the following OID
{ id-svp 1 } to specify the default validation policy, while LCVP may simply
omit the parameter:

Furthermore, where LCVP allows any default validation policy, in SCVP :
" The default validation policy MUST use the basic validation algorithm as
its default validation algorithm". 

 

>others on this list, to demonstrate how simple an SCVP client can 

A lightweight client profile for SCVP is not realistic without changing
SCVP. 
SCVP is already in the hands of the RFC editor for publication as an RFC.

Denis

>> 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".
>>
>> 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.  :-)
>>
>> LCVP only supports a subset of the mandatory requirements described 
>> in [RFC3379] for DPV, hence it does not conform to RFC 3379.  LCVP is 
>> 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:
>>
>> document could be re-targeted to the standard track category.
>>
>> Denis
>>
>>
>
>

Regards,

Denis Pinkas