Subject: RE: DPD & DPV requirements - server usage of data proffered by cl ient

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 3 Jan 2001 14:47:36 -0800

Steve, I have some questions concerning requirements 1.1 and 1.2 from your
proposed DPD and DPV requirements.  
 
           "1.1 A client request can contain a single certificate or a
certificate chain terminating 
             in the "target" certificate, to assist the server in path
construction. " 

             "1.2 A client request can contain one or more revocation data
items, to assist the server 
              in path validation." 

In requirement 1.1, the phrase "...to assist the server in path
construction. " implies that the client's intent is 
simply to aid the server, rather than to impose constraints on the server.
This interpretation is supported by 
the absence of a requirement that would obligate the server to construct a
path using the certificate chain proffered 
by the client.  Have I made the correct interpretation?  
 
Requirement 1.2 contains the similar phrase "to assist the server in path
validation."  and again there is no requirement
on the server to make use of this revocation data.  But in this case, it
doesn't seem quite right for the server to ignore 
the proffered revocation data, nor to accept it as verity.  For example, if
the proffered data is an OCSP response that 
indicates that a certificate is revoked**, it does not seem safe for the
server to ignore this data in favor of a somewhat 
dated CRL that indicates that the certificate is not revoked.  On the other
hand, if the proffered data is an OCSP response 
that indicates that the certificate is not revoked, is the server under no
obligation to perform any further checks on the 
revocation status?  Note that the server may not be able to determine the
freshness of the proffered OCSP response
with any exactitude.

(** Of course, it would be silly for the client to proffer an OCSP response
or CRL that indicates that the target certificate 
is revoked.  However, the proffered revocation data may be for some other
certificate that the client thinks that the server 
might use for constructing a certification path.  Another possibility is
that an XML-literate but ASN.1-illiterate client is 
incapable of parsing the OCSP response or CRL, but wishes the server to make
use of this revocation data.) 

I realize that such issues will eventually be clarified in the finite state
models for the server actions, but I think these
points are important, and ought to be captured in the requirements that will
drive the development of the state models.
 
I propose the addition of the following clarifications and requirements for
the server:
 
           "The server may use a certificate chain proffered by the client,
but is not obligated to do so. " 

            "If revocation data proffered by the client indicates that a
certificate is revoked, the server must
              reject as invalid any certificate paths containing this
certificate." 

            "If revocation data proffered by the client indicates that a
certificate is not revoked, the server must
              independently verify this data before accepting as valid any
certificate paths containing this certificate." 

Regards,
 
Carlin Covey
Cylink Corp.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Jan 2001 09:21:03 -0500

At 2:47 PM -0800 1/3/01, Covey, Carlin wrote:

Carlin,

>Steve, I have some questions concerning requirements 1.1 and 1.2 
>from your proposed DPD and DPV requirements.
>
>
>            "1.1 A client request can contain a single certificate or 
>a certificate chain terminating 
>              in the "target" certificate, to assist the server in 
>path construction. "
>
>              "1.2 A client request can contain one or more 
>revocation data items, to assist the server 
>               in path validation."
>
>simply to aid the server, rather than to impose constraints on the 
>server.  This interpretation is supported by
>the absence of a requirement that would obligate the server to 
>construct a path using the certificate chain proffered

yes, that was the intent. I expected control over path validation to 
be managed by the parameters. The offered cert chain was could have 
been supplied as part of a protocol that pushed a purported path to 
the client, but the client might not have looked at it at all, 
especially a DPV client who might not be PKI aware.

One might make an argument here for two cases, one in which the 
client is passing on cert path (and revocation status data) that it 
has not examined, and one in which the client is trying to constrain 
path processing by mandating use of the supplied data.  if folks 
agree that support for both flavors of inputs is needed, we can 
mandate that. Syntactically it's probably easy to add a flag 
indicating which sort of input is being provided, but it will add 
complexity to server processing to be able to deal with both cases.

>
>Requirement 1.2 contains the similar phrase "to assist the server in 
>path validation."  and again there is no requirement
>on the server to make use of this revocation data.  But in this 
>case, it doesn't seem quite right for the server to ignore
>the proffered revocation data, nor to accept it as verity.  For 
>example, if the proffered data is an OCSP response that
>indicates that a certificate is revoked**, it does not seem safe for 
>the server to ignore this data in favor of a somewhat
>dated CRL that indicates that the certificate is not revoked.  On 
>the other hand, if the proffered data is an OCSP response
>that indicates that the certificate is not revoked, is the server 
>under no obligation to perform any further checks on the
>revocation status?  Note that the server may not be able to 
>determine the freshness of the proffered OCSP response
>with any exactitude.

As above, the intent was to accommodate clients who might know 
nothing of the supplied data and thus were merely passing it on to 
the server in case it might help. I'm more concerned here that a 
server not be mislead by outdated revocation status data supplied by 
a client, maybe an unwitting client, as that could return an 
inaccurate, "certificate valid" answer based on bad revocation status 
data that would override what the server would otherwise have used. 
I'm not comfortable making this sort of change yet.

>  (** Of course, it would be silly for the client to proffer an OCSP 
>response or CRL that indicates that the target certificate
>is revoked.  However, the proffered revocation data may be for some 
>other certificate that the client thinks that the server
>might use for constructing a certification path.  Another 
>possibility is that an XML-literate but ASN.1-illiterate client is
>incapable of parsing the OCSP response or CRL, but wishes the server 
>to make use of this revocation data.)

right. that argues for the advisory, but not authoritative, approach 
I proposed, or the safe approach you describe below.

>  I realize that such issues will eventually be clarified in the 
>finite state models for the server actions, but I think these
>points are important, and ought to be captured in the requirements 
>that will drive the development of the state models.
>
>I propose the addition of the following clarifications and 
>requirements for the server:
>
>
>            "The server may use a certificate chain proffered by the 
>client, but is not obligated to do so. "
>
>             "If revocation data proffered by the client indicates 
>that a certificate is revoked, the server must
>               reject as invalid any certificate paths containing 
>this certificate."
>
>             "If revocation data proffered by the client indicates 
>that a certificate is not revoked, the server must
>               independently verify this data before accepting as 
>valid any certificate paths containing this certificate."

This is a reasonable, safe set of clarifications to the current spec 
and I'm happy to incorporate them. If folks want to expand the 
requirements to include the mandatory use of supplied cert chains, I 
could add that, but will not do so yet.

Steve