Subject: Lightweight Certificate Validation Protocol (LCVP)

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

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

---

From: "Dave Engberg" <[email-masked]>
Date: Fri, 20 Apr 2007 10:25:58 -0400

I would recommend writing this as a profile of SCVP instead of implementing
yet another certificate validation protocol.  This would be similar to what
Hurst and Deacon did with their Lightweight OCSP Profile, which put
constraints on OCSP client requests to improve performance and scalability.

I believe that a profile of SCVP could meet the design goals that you list,
below, but you could still use existing SCVP relying party toolkits and
servers rather than reinventing the wheel.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, April 20, 2007 8:19 AM
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. 

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.

  
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:

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: "Santosh Chokhani" <[email-masked]>
Date: Sun, 22 Apr 2007 09:36:10 -0700

I agree with Dave Engberg.  Prior to PKIX taking this on as a Standards
Track or Experimental RFC or other work item, an attempt must be made to
profile SCVP for lightweight operations that meet most community needs.

I have not done an analysis as to how this would turn out, but got
curious and looked at the signature aspects of validation responses.  My
reading of the draft SCVP I-D is that it requires signed data or
authenticated data for valid responses.  In addition, the Server must be
capable of generating signed data.

It seems that Denis wants unprotected valid responses since the channel
protects the responses.  I think either the SCVP or the lightweight
version can be revised to accommodate this.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Friday, April 20, 2007 10:26 AM
To: Denis Pinkas; pkix
Subject: RE: Lightweight Certificate Validation Protocol (LCVP)

I would recommend writing this as a profile of SCVP instead of
implementing
yet another certificate validation protocol.  This would be similar to
what
Hurst and Deacon did with their Lightweight OCSP Profile, which put
constraints on OCSP client requests to improve performance and
scalability.

I believe that a profile of SCVP could meet the design goals that you
list,
below, but you could still use existing SCVP relying party toolkits and
servers rather than reinventing the wheel.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Denis Pinkas
Sent: Friday, April 20, 2007 8:19 AM
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 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:

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

 
Denis

---

From: "Seth Hitchings" <[email-masked]>
Date: Sun, 22 Apr 2007 15:42:46 -0400

Santosh and Denis,

My reading of the current SCVP draft (31) is that it allows unprotected
responses to DPV queries when the transport mechanism is protected.

Section 3.2.5.3, protectResponse, reads:

   SCVP clients that support delegated path validation (DPV) as defined
   in [RQMTS] require an authenticated response.  Unless a protected
   transport mechanism (such a TLS) is used, such clients MUST always
   set this value to TRUE or omit the responseFlags item entirely,
   which requires the server to return a protected response. 

And section 4, Validation Response, begins:

   There are a number of forms of an SCVP response:

    1. A success response to a request that has protectResponse set to
       FALSE.  These responses SHOULD NOT be protected by the server.

    2. The server MUST protect all other success responses.  If the
       server is unable to return a protected success response due to
       local policy, then it MUST return an error response.

It seems to me that a client can make a very simple DPV request over TLS by
setting protectResponse to false, asserting only the
id-stc-build-status-checked-pkc-path check, and omitting the wantBack item.

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Sunday, April 22, 2007 9:36 AM
To: pkix
Subject: RE: Lightweight Certificate Validation Protocol (LCVP)

I have not done an analysis as to how this would turn out, but got curious
and looked at the signature aspects of validation responses.  My reading of
the draft SCVP I-D is that it requires signed data or authenticated data for
valid responses.  In addition, the Server must be capable of generating
signed data.

It seems that Denis wants unprotected valid responses since the channel
protects the responses.  I think either the SCVP or the lightweight version
can be revised to accommodate this.

-----Original Message-----

  

 
Denis

---

From: Tim Polk <[email-masked]>
Date: Sun, 22 Apr 2007 17:23:52 -0400

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.  (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.  While LCVP's ASN.1 appears less complicated, the data  
structures generated by minimally conforming SCVP DPV-only client  
implementations appear to have similar levels of complexity.  I  
cannot see any reason to pursue a new DPV protocol that ignores the  
requirements established in 3379 within the IETF.  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.

Thanks,

Tim Polk

On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote:

> optionally sign requests
> provide an adequate answer.
>
> while keeping it "light".
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 23 Apr 2007 10:20:45 -0400

Tim,

Santosh indicates that SCVP could be "revised" (not profiled) to meet
the needs of (2) transport-only protection.  Does the working group
support modifying SCVP so that clients SHOULD (vice MUST) support signed
responses?  On the surface that sounds reasonable, but a truly
lightweight validation protocol would use message protection (signed or
authenticated) and a UDP request/response like DNS, rather than a TCP
handshake plus a TLS handshake.  Just because everyone has a TLS library
does not mean that TLS treads lightly on the network.
See http://www3.ietf.org/proceedings/07mar/slides/isms-1.pdf

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tim Polk
Sent: Sunday, April 22, 2007 5:24 PM
To: Denis Pinkas
Cc: pkix; Sam Hartman; Russ Housley; Stephen Kent; Stefan Santesson
Subject: Re: Lightweight Certificate Validation Protocol (LCVP)

Denis,

Thanks,

Tim Polk

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 23 Apr 2007 15:15:38 -0400

Hello PKI-ers,

I was looking at all the different possibilities we have now for `discovering'
PKI related resources, where by resources I include repositories and services
provided by a CA. For example an LDAP server, a CRL repository or an OCSP
service.

Actually the `standard' way to do so is to embed pointers into certificates
via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks,
as it is quite static (e.g., CA certs have usually quite long life period).
Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but
none of them seems to be supported widely across apps and systems. My take
is because possible solutions are many and they can be difficult to implement
(and some of them do not really provide an efficient solution, for example
the DNS approach requires that the application knows which is the right domain
to query for a service---which might not be trivial if the DC format is not
used).

I am working on a proposal for developing a protocol to provide a specific
solution to the problem, and I really would like the WG to discuss the
problem and the proposed solution.

I have a brief description of the work done so far here:

	http://www.openca.org/projects/libprqp

Main goals of this work are:
* to make it easy for developers to discover PKI resources
* to provide a method to dynamically update PKI resources information
* to split pki-services management from certificates contents. For example
   it would help in painless rollover between services, e.g. switching from
   CRLs to OCSP without the need to re-issuing all the certificates (an example
   could be taken from the DoD PKI)

We might say that this protocol would provide a way to map X509 certificates to
network resources by providing pointers (URLs) to applications.

I hope this idea could have some consent here and some help also in writing
a first draft. We might also setup a slot to discuss this idea at the next
IETF Meeting...

Thanks for your attention in reading this email, I hope to receive many
useful comments and suggestions and, hopefully, also some help in this
task.

-- 

Best Regards,

       Dr. Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 23 Apr 2007 15:15:38 -0400

Hello PKI-ers,

-- 

Best Regards,

       Dr. Massimiliano Pala

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 24 Apr 2007 11:43:41 +0800

Dr. Massimiliano Pala,

That is an interesting idea.

However, one imaginable problem you might face is "how
a relying party (the PRQP client) can find an authroized RQA?"

One straightforward way is to let the CA issue a certificate first to
delegate the authority to the RQA and then use AIA/SIA extnesions
to provide the URL of the authroized RQA (the authroized PRQP server)
to the PRQP client. If you are going to adopt this kind of straightforward
solution, it will not be a painless rollover from traditional ways (embed
various pointers via CDP, AIA or SIA extensions) to the new way (a single
AIA/SIA extension comtaining the authroized PRQP access info). The
reason why it will not be a painless rollover is that the goal can not be
achieved without the need to re-issuing all the existing certificates to
add the newly defined PRQP access info into the AIA/SIA extension.

Wen-Cheng Wang

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 24 Apr 2007 11:04:45 -0400

Hello Wen-Cheng,

thank you for the comment. Indeed the distribution of the RQA address
is something tricky, but the AIA/SIA extensions can be used to provide
that. Also the DHCP could be used for the same porpuse on a local
network.

Again, thanks. I'll try to come up with a draft for the WG to read
hopefully in the next few days (or the next week).
Let me know what do you think also about a possible session/proposal at
the next IETF.

Cheers,
Max

-- 

Best Regards,

	Dr. Massimiliano Pala

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 24 Apr 2007 19:44:04 +0200

Hi Max,
Some time ago you proposed new PKI protocols but then you did
not state any specific use-case.  I'm happy to see such now :-)

Regarding painful rollover, I believe a 5-year plan or so is realistic
if it involves certificate changes.   If the idea is really some kind of
"mapping scheme" between existing certificates and services it may
be faster but OTOH I don't really see how such a mapping utility
would work given the huge variations out there.  But maybe you
are thinking of some kind of centralized discovery service?

Personally I'm only interested in decentralized Internet-scale PKI
solutions (the opposite to S/MIME...) and would due to this base
a new scheme on the only Internet-scale "registry" there is: DNS.

I would suggest a scheme based on DNS names which both can
be obtained locally (from a config file) as well as being supplied
in a new certificate extension.  This would allow step-wise migration
which has proved to be the fastest route to adoption.  The following
is one way of architecting this:

In the repository/certificate extension: "example.com"

Searched for by an enhanced PKI client:
_thesuperduper-pki-lookup.example.com TXT "something"
_other-pki-lookup-service.example.com TXT "something"

Regarding applications, I would like to add automatic certificate
renewal services support.

regards
Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Tuesday, April 24, 2007 17:04
Subject: Re: PKI Resource Discovery - Proposal for a new Working Item

Hello Wen-Cheng,

Cheers,
Max

-- 

Best Regards,

Dr. Massimiliano Pala

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 24 Apr 2007 19:44:04 +0200

Hi Max,

regards
Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Tuesday, April 24, 2007 17:04
Subject: Re: PKI Resource Discovery - Proposal for a new Working Item

Hello Wen-Cheng,

Cheers,
Max

-- 

Best Regards,

Dr. Massimiliano Pala

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 24 Apr 2007 14:27:10 -0400

> that. Also the DHCP could be used for the same porpuse on a local

Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609?

If you think of DHCP, a look at SLP is certainly deserved.

I did the exercise with DNSSEC deployment, see
http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Apr 2007 12:16:29 +0100

Denis,

> not either a profile of SCVP.

This by itself is highly problematic.

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 would take extreme reasons to justify creation of such new protocol.

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.

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.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Denis Pinkas
> Sent: den 20 april 2007 14:19
> To: pkix
> to a server,
> mean "Simple",

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Apr 2007 13:53:15 -0400

> Hi Max,

Hi Anders,

> not state any specific use-case.  I'm happy to see such now :-)

Yep, I finally had time to work on a practical implementation of the
idea and figure out what can really be implemented and how easy would
this be in practice.

> are thinking of some kind of centralized discovery service?

Sort of. For the rollover idea, I was thinking about switching to one
service to another. For example a CA that wants to switch from CRLs to
OCSP, it would not have to reissue all the valid certificates to have
the clients to discover the new available service and not use the old
one.

Thinking about the future, this would really give the possibility to
add/remove/move offered services by providing an easy way for CA management
to do so.

In the future-future, if this protocol is adopted, we can also think
about an authority who will manage a network of Registration Authorities
like the DNS, but for now, we should stay focused on this first step.

> a new scheme on the only Internet-scale "registry" there is: DNS.

My solution is like DNS, but it is not hierarchical-more P2P based. I will
present the idea at EuroPKI---unfortunately because of grant rules I can
not forward the paper, yet.

> _other-pki-lookup-service.example.com TXT "something"

I am not sure about what you are saying here. If the DNS is used to store
addresses to services, you can use DNS SRV records. But actually it is
quite difficult, when you have a certificate, figuring out which is the
DNS that has the information you need because there is not (usually) a
direct mapping between DNS and certificates contents (if no DC is used).
A PRQP would allow to map services also for CAs using X500 names.
Another aspect to consider is that CA management do not always have direct
control over the DNS, which is usually in charge of the networking people
(but this may vary across different environments...). My point here is
that based on my experience, DNS is not really the simplest solution to
solve the PKI Resource Discovery problem...

> renewal services support.

In this respect the PRQP could provide the URL where the application could
apply for renewal of a certificate. A simple message could then be exchanged
and the certificate issued without a single configuration provided from the
user...

-- 

Best Regards,

	Dr. Massimiliano Pala

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Apr 2007 13:57:28 -0400

> If you think of DHCP, a look at SLP is certainly deserved.

Oh, I looked at that.. and it is quite interesting, although it is a bit
complicated, at a first glance. But it may be used in LANs to distribute
Request Query Authorities addresses.

> http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt

Interesting, but can you be more specific on how this is related to the
problem I am trying to address ? Can you make an example ?

Thanks,

-- 

Best Regards,

	Dr. Massimiliano Pala

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 27 Apr 2007 14:15:04 -0400

> Request Query Authorities addresses.

Perhaps not just addresses, SLP "service attributes", for whatever use 
you may have in PKI resource discovery.

> problem I am trying to address ? Can you make an example ?

Ooops, I didn't mean that the above draft is helping your problem. Just 
an example of first attempt to make good use of SLP.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900