Subject: RE: some thoughts re DPD and DPV

From: Santosh Chokhani <[email-masked]>
Date: Sat, 24 Mar 2001 07:11:19 -0500

With all due respect to PKI and X.509, a more versatile and simpler approach
to revise the path validation algorithm where the validator says for which
policies in the relying party domain the path is good for, if any.
 
The application then will have a simple check to make (locally) if any one
of these policies is acceptable to it.
 
This however, may not reduce the need for setting other policy related state
variables, the most important of them being, inhibit policy mapping related
initial skipCerts value.
 
-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]]
Sent: Saturday, March 24, 2001 6:13 AM
To: [email-masked]; Stephen Kent
Subject: Re: some thoughts re DPD and DPV

I'm not against the idea of having a (validation) policy registered on the
server, which the client refers to in its request message.  However, IMO
would it not be more practical for the CA which issued the certificate to be
responsible for defining this policy and registering it directly with its
validation server?  This may remove some of the complexity of each client
having its own policy and a protocol for registering this at the server.
The client would only need to refer to the appropriate policy, which will be
based on the target certificate being checked.   Just some initial
thoughts...
 
Regards,
Liaquat

----- Original Message ----- 
From: Stephen Kent <mailto:[email-masked]>  
To: [email-masked] <mailto:[email-masked]>  
Sent: Saturday, March 24, 2001 12:09 AM
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve

---

From: Michael Zolotarev <[email-masked]>
Date: Sun, 25 Mar 2001 15:31:30 +1000

All,
Been fully agree with Paul in what he is saying about greivances of
client-server policy management, I suggest we do not limit ourselves to a
particular use mode. Instead, I would solicit leaving both the policy OID
and the explicit parameters options available (and optional) for the
clients.
Having a place for both an OID and for the parameters in the message
provides clients with flexibility to fine-tune a predefined policy, saying
"use this policy, but append/modify THAT parameter of it". Which may be a
real requirement down the track.

At that stage, our judgment is based on a very little practical experience
regarding what DPD/DPV client may become, and the environments they may be
operating in. Defining a protocol as a framework, and later on profiling it
for particular uses, may be a better choice.

Michael

-----Original Message-----
From: Carlin Covey [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 7:26 AM
To: Paul Hoffman / IMC; Stephen Kent; [email-masked]
Subject: RE: some thoughts re DPD and DPV

Paul and Steve,

I agree that the DPD and DPV protocols should be simplified by
including just a reference to a server-resident path-validation
policy.  I also agree with Paul that a typical client will
make a choice among very few policies.  In fact, most clients 
will never make a choice.  The clients and servers will be 
pre-configured with one policy per client-type per enterprise.  
Simply including one policy OID in the request (possibly echoed 
in the response) will satisfy the great majority of use cases.  

Paul points out the near-zero success-rate of policy protocols.
DPD/DPV should not be made into a quasi-policy-protocol by 
including explicit policy information in the requests.  An OID
will do.  If there remains a need for client-configuration of 
server-resident policies, put that in a separate protocol as 
Steve has suggested.  

Let's proceed with a simplified, low-bandwidth DPD/DPV that is as 
free as possible of the burden of policy configuration.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>We could make ALL requests refer to a policy configured at the 
>server, rather than allowing for explicit transmission of these 
>parameters. To make this as flexible as the current proposals, we 
>would have to add a new protocol, to allow a client to register a 
>policy with a server, so that the client could later refer to that 
>policy. We probably want a facility to inquire about a registered 
>policy as well.

This sounds horrendously complex. To date, the IETF has had near-zero 
success with defining policy protocols, with policy working groups 
pretty much being unable to get closure. The method promoted in SCVP 
(can give individual policy info in requests or can use aggregated 
OIDs) seems much more sensible than forcing all clients to know (or, 
worse, discover and push) the policies on the server.

The number of policies a typical client wants will probably be few 
(most likely, just roots). Why make this so much more complicated 
than needed?

--Paul Hoffman, Director
--Internet Mail Consortium

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

---

From: Michael Zolotarev <[email-masked]>
Date: Sun, 25 Mar 2001 16:53:15 +1000

Stephen,
 
Returning a hash of the supporting data will inevitably complicate server
design, requiring running a potentially huge evidential database. Shall we
mandate a server to support it? Or otherwise, what's going to happen if the
client asks for the hash? An error returned? Or a complete evidence (which
the client presumably won't digest)? 
 
Who would be to decide for how long the evidence should be kept by the
server? TTLs tend to be messy.
 
What happens if a client sends a certificate which happens to be
preconfigured as a trusted root by the server policy (so that the answer is
'valid')? Hash of *what* should be returned?
 
All these questions will have a number of possible answers, all reasonable
in some extent. But in the whole, I'm seriously afraid that the requirement
will dramatically complicate implementation of the server, and the overall
design of the protocol. 
 
We may consider the fact that should the evidence data be returned by a DPV,
it don't have to be signed by the DVP. Therefore, we can solve the problem
by implementing a simple client proxy located between the client and DPV
server. The proxy can remove the evidence data off the response and store
it, passing just a hash of it to the client.
 
Regards
Michael

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Saturday, March 24, 2001 11:10 AM
To: [email-masked]
Subject: some thoughts re DPD and DPV

Steve

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 26 Mar 2001 08:29:59 -0800

One of the things that we have had in SCVP for some time was the
following:

a. A configuration identifier
b. A usage area

The configuration identifier was a shortcut for a client to 
provide configuration parameters.

The usage, where the client says what purpose it wants to use
the certificate for.

The thing we need to add to the usage, is an extra parameter,
which contains data that applies to that usage - the server
URL where you are an SSL client, the sender e-mail where you
are an e-mail recipient, etc.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> Sent: Monday, March 26, 2001 7:40 AM
> To: Denis Pinkas
> Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
> Denis,
> When I said "client-type" in my previous email, I meant email-client,
> browser, VPN-client etc.  I should have said "application."  
> I think we
> are in agreement on this point.  Sorry for the confusion.
> 
> Regards,
> 
> Carlin
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, March 26, 2001 2:18 AM
> To: Carlin Covey
> Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
> <snip>
> > I also agree with Paul that a typical client will
> I do not believe so. The policy is application dependent. One 
> application
> will usually be linked with one policy. Since a client will 
> normally support
> multiple applications, he will use more than one policy.
> 
> <snip>
> 
>

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 27 Mar 2001 13:48:35 +0200 (MET DST)

> 
> Denis,
> 
> > I noticed that your were the single one at the IETF meeting advocating the
> > need for the retryReference. There migh be other individuals present at the
> > meeting or people on the mailing list supporting this idea as well, but up
> > to now they have remain silent. :-)
> 
> That never seems to bother you, so I'm ok with it in this case:-)
> 

There was a discussion on that point some months ago. If I rememeber
it right, in ended in violant agreement among me and Stephen Farrell.

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 29 Mar 2001 02:02:37 -0800

Peter, you want to be careful about what you indicate the server
is saying in its response.

The question of whether a server is making any statement about
the expiry status or issuance status of a certificate in an OCSP
response or not did come up in the OCSP discussion earlier. The
concensus at that time was, that the question being asked was
about the revocation status of the certificate. If the client
wanted to know about the expiry status of the certificate, it
could check the certificate for itself. Similarly, if it wanted
to know whether the certificate was ever issued or not, it could
verify the signature on the certificate. So implying anything
about the expiry/issuance status of certificates was not
included in the protocol.

I know of ISIS's desire to have an OCSP response indicate not
only the status of the certificate, but also its existance in a
directory. While I still don't see the benefit of the additional
guarantee, if enough people want it, I don't see a problem with
adding it in a standard way to OCSP, but I would strongly urge
the group to do so via additional extensions.

Changing the meaning of good/revoked/unknown to also include
something about issued/expired, etc. is very, very unclean.

Hope this makes sense,
Regards,
Ambarish

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 7:30 AM
> To: [email-masked]
> Denis Pinkas <[email-masked]> writes:
> 
> >There are other objections, since the model you are 
> referring is also making
> >additional major changes from the PKIX model, in particular 
> about the way to
> >check the validity of a certificate chain and the nomination 
> of the OCSP
> >servers responsible for a given CA. Once again, we are in 
> the PKIX WG with a
> >well defined model based on X.509. There are certainly 
> alternatives to this
> >model. Alernatives may have their own merits. However, they 
> should not be
> >progressed in the PKIX WG. 
> 
> Uhh, I think you're reading way too much into my suggestion.  
> All I was doing
> was making the observation that currently when you query an 
> OCSP responder it
> replies with "I could tell you all sorts of things about this 
> cert, but instead
> I'm going to return a partial response and leave you to guess 
> the rest".  By
> adding a small amount of additional information (which the 
> client is free to
> ignore if they want) the responder may provide a more 
> complete response than
> they currently can.  If the client wants to stick religiously 
> to the current
> OCSP/PKIX/whatever model they're free to ignore the extra 
> information - all
> this is is supplementary data, if you don't like it you can 
> ignore it, if you
> think it's useful and it saves you some work, you can use it.
> 
> >Everyone can make its own private extensions and in that 
> case, and we are not
> >going to stop this. 
> 
> The problem is that since there appears to be at least some 
> demand for this,
> everyone *will* add their own private extension, all of which 
> will have
> slightly incompatible semantics, all of which will be 
> completely different, and
> most of which will be undocumented.  Even worse, some groups 
> may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than 
> allow things to
> degenerate to the point where you need to handle a dozen 
> different ways of
> doing the same thing, the RFC should include a single 
> standard way of doing it
> with well-defined semantics which everyone can follow (or 
> ignore if they feel so
> inclined).
> 
> Peter.
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 29 Mar 2001 18:21:19 +0200

Peter,

> >There are other objections, since the model you are referring is also making
> >additional major changes from the PKIX model, in particular about the way to
> >check the validity of a certificate chain and the nomination of the OCSP
> >servers responsible for a given CA. Once again, we are in the PKIX WG with a
> >well defined model based on X.509. There are certainly alternatives to this
> >model. Alernatives may have their own merits. However, they should not be
> Uhh, I think you're reading way too much into my suggestion.  All I was doing
> was making the observation that currently when you query an OCSP responder it
> replies with "I could tell you all sorts of things about this cert, but instead
> I'm going to return a partial response and leave you to guess the rest".  By
> adding a small amount of additional information (which the client is free to
> ignore if they want) the responder may provide a more complete response than
> they currently can.  

If using a new extension in the request, a client wants to ask more
information about a certificate, e.g. "is that certificate present in 
the private Directory of the CA ? ", then this can be done by asking the
question explicitly. Clients worried by the response to this question should
ask the question using an extension. If they are not worried, then they
should not ask. 

In any case, as Ambarish indicated, we should change the three meanings of
an OCSP v1 response, i.e. "not revoked", "revoked", "unkown", and thus we
should not add any other status at that level. 

> If the client wants to stick religiously to the current
> OCSP/PKIX/whatever model they're free to ignore the extra information - all
> this is is supplementary data, if you don't like it you can ignore it, if you

We should no overload responses with responses to questions that have not
been requested.
 
> >Everyone can make its own private extensions and in that case, and we are not
> >going to stop this.
> 
> The problem is that since there appears to be at least some demand for this,
> everyone *will* add their own private extension, all of which will have
> slightly incompatible semantics, all of which will be completely different, and
> most of which will be undocumented.  

I agree with you that an *extension in the request* could be defined to ask
for this additional information, i.e. either using the
singleRequestExtensions sub-field of the Request structure or using the
requestExtensions sub-field of the tbsRequest. 

Note: In the case of ISIS, I believe that the former choice has been
selected.

In any case, I would recommend to define extensions in separate RFCs, so
that it is easier to be able to claim conformance when this fuctionality is
supported. A further advantage would be to support such extensions both with 
OCSPv1 or OCSPv2 (whenever it exists).

> Even worse, some groups may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
> degenerate to the point where you need to handle a dozen different ways of
> doing the same thing, the RFC should include a single standard way of doing it
> with well-defined semantics which everyone can follow (or ignore if they feel so
> inclined).

Denis