Subject: RE: DPD & DPV Basics

From: "Covey, Carlin" <[email-masked]>
Date: Thu, 11 Jan 2001 14:34:32 -0800

Steve Hanna,

Your take on the basic concepts of DPV and DPD services matches mine.  
I think a bit of confusion was introduced during discussions of how 
those services should be mapped to protocols.  There was a suggestion
that a DPV-service protocol might also return a chain of evidence 
supporting the validation status - thus providing a kind of DPD service 
within the same protocol.  It has also been observed that there is no point 
in returning invalid (or unvalidated) paths in a DPD response  -- thus
implying a sort of DPV service as part of the DPD protocol.  I suppose
the distinguishing characteristic is whether or not the client trusts the
response, or will perform its own validation.  This is out of the scope 
of the protocol itself, unless we want to build in mechanisms for the client
to impose constraints on the path construction and validation process.

Regards,

Carlin

---------------------------------
- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 1:34 PM
To: PKIX List
Subject: DPD & DPV Basics

It seems that at least some members of the working group have not yet
agreed upon certain basic concepts. Perhaps it would be useful for me to
articulate these concepts so that they can be discussed separately from
the detailed requirements supplied by Steve. Discussion of those
detailed requirements can proceed simultaneously, but it would be good
if we could reach agreement on these basic concepts or at least
understand why we don't agree on them. I suspect that we already have
rough consensus on these concepts, but it would be good to get any
debate on them out into the open so that we can understand the technical
foundations from which that debate arises.

Here's my take on the basic concepts of DPD and DPV:

The basic job of a DPV server is to validate a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a certification path and other inputs
   to the validation algorithm (trust anchors, required certificate
   policies, etc.)
2) Validate the supplied certification path using the supplied inputs
3) Send a response containing the results of the validation (at least,
   an indication of success or failure)

Many refinements to this are possible: the client supplying only a
subset of the necessary inputs (by referring to an established policy),
the server returning supporting evidence such as CRLs and OCSP
responses, the client supplying CRLs or OCSP responses that may be
useful to the server, etc. But I think it may be useful to reach
agreement on the basic model described above before discussing these
refinements (however worthy).

The basic job of a DPD server is to discover a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a target certificate and inputs to the
   validation algorithm (trust anchors, etc.)
2) Attempt to discover a certification path ending in the target
   certificate that will validate properly given the supplied inputs
3) Send a response containing the results of the discovery process
   (at least an indication of success or failure and, in the success
   case, the discovered certification path)

Most of the refinements listed above with respect to the DPV server can
also be applied to the DPD server. In addition, other refinements might
include having the client supply additional certificates that may be
useful to the server (such as certificates received with an S/MIME email
message).

I look forward to seeing a discussion on this topic. If no discussion
results, I suppose that I will conclude that there is general agreement
about these basic concepts. However, simple affirmative messages
agreeing with these basic concepts would be useful in judging rough
consensus.

Thanks,

Steve

P.S. Due to the short timeline, I will submit more detailed comments on
Steve's requirements soon.

---

From: "Covey, Carlin" <[email-masked]>
Date: Thu, 11 Jan 2001 15:30:28 -0800

I agree with you Steve.

- Carlin

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:22 PM
To: Covey, Carlin
Cc: PKIX List
Subject: RE: DPD & DPV Basics

Carlin,

The examples you cite of benefits from having cert chains returned by 
a DPD server, even if not strictly valid, are examples of the R&D 
problem area I alluded to in earlier messages. I don't think we have 
a good set of parameters to express the "not quite valid, but maybe 
close enough to be useful" notion you are describing.  We would need 
a specific set to be part of the spec, else we will not be able to 
have a good spec for server operation, nor for client control of 
server operation.  So, I'd discourage heading down this path uless we 
have such a set of parameters, and Wg agreement on their desirability 
and completeness.

Steve

---

From: Hal Lockhart <[email-masked]>
Date: Tue, 16 Jan 2001 15:18:02 -0500

> Typical IETF situation. We all agree that the answer is 
> obvious. We just
> don't agree what the answer is!

Wow! I'm going to save that one. I know we will be quoting it years from
now.

Hal

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 17 Jan 2001 12:57:36 +0100 (MET)

> 
> Typical IETF situation. We all agree that the answer is obvious. We just

Worse, we don't even have a common meaning of the question. :-)
 
> It sounds like some applications are PKI-ignorant but ASN.1-savvy (able
> to parse a certificate). Others are PKI-ignorant and ASN.1-ignorant
> (unable to parse a certificate).

The question is: Do we want to support both types of client at the same time with
the same protocol. 

For a non asn1 client we can have at least two solutions where X ist the
ASN1 DPV protocol, and Y is the same formulated in another code. 

non-asn1-application - non-asn1 DPV front end - DPV client -X- DPV server - PKI 

non-asn1-application - non-asn1 DPV client -Y- non-asn1 DPV server - PKI 

For example, if I would need an application like XML-DSIG, I would like to
feed the key info and a certificate, and get back an answer that the
application can authenticate by simpler means, and the answer would
have a xml 'view' of the returned data i.e. textual versions of the x509
cert etc.
 
> An ASN.1-savvy application only needs a DPV server to determine whether
> a particular certificate is trustworthy (whether there is a valid path
> to the certificate, according to the appropriate policies). The
> ASN.1-savvy application can parse the certificate to check the key usage
> and extended key usage and get the name and public key. See Note 1 below
> for a minor detail.

The question from the client is not 'is this cert trustworthy', but:
Is this cert trustworthy for *my* application. The details of whether
whatever current (mis-)interpretation if certificate details is useful
for an application can be completely hidden from the application. 

> An ASN.1-ignorant application needs a DPV server to determine whether a
> certificate is trustworthy. But it also needs the DPV server to check
> the key usage and extended key usage, check the name, and return the
> public key. The ASN.1-ignorant application also needs the DPV protocol
> to not use ASN.1 (except for objects that the application can treat like
> blobs, like the certificate).

As said a non-asn1 application is also interested in getting extracts
from certificate like for example in the xml-dsig case. It can get 
also certs like blobs. The question is how much data need to be extracted
from asn1 encoded data, for example an embedded OCSP response.
 
> Does everyone (or almost everyone) agree with this analysis? If so, do
> you also agree that both of these kinds of applications should be
> supported (PKI-ignorant and ASN.1-savvy and PKI-ignorant and
> ASN.1-ignorant)?

One can see this as one protocol on top of another, since the non-asn1 application
need more data than the asn1 aware application, at least if we assume that PKI
is asn1 based.  

> Once we have agreement on all that, then I think we will have a useful
> context for discussing DPV requirements.

Do I agree with your analysis? At least there is some overlap. ;-)

PS

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 17 Jan 2001 14:33:28 +0100 (MET)

> With respect to S/MIME, several others have said that S/MIME agents must
> be able to parse CMS and ASN.1. Therefore, it is reasonable to expect
> them to be PKI-aware. This seems sensible to me.

They are ASN1-aware but not necessary PKI-aware. 

> But if you *did* want to use a DPV server for verifying signatures on
> S/MIME messages, it seems to me that you would need to deal with issues
> similar to the ones raised above and in the previous message regarding
> TLS/SSL: ensuring that the subject name or subject alternative name
> matches the From line, checking that the appropriate key usage and
> extended key usage bits are set, and getting the public key with
> parameters from the DPV server. There's also the separate issue of how
> (or whether) to send CRLs included with the message to the DPV server. A
> full-fledged S/MIME implementation would raise lots of more interesting
> issues: discovering a path to a previously unknown party in order to
> send them an encrypted email, determine which certificates and CRLs to
> send with a signed email (based on the intended recipients), etc. But
> that's clearly out of scope for DPV.

In an S/MIME  message the originating field are not included in the
signature. Furthermore, you might not even have a certificate available
in an S/MIME signed message. 

Anyway, in the first place I'd use a service that takes the whole
signature and not just the certs.

For encrytion certs: You might think of first using an 'untrusted'
directory lookup, and then make a DPV request for those certs, the
response may also include additional encryption certs like for
example your outgoing company firewal, the other companies mail
firewall, you internal company document recovery cert or some
paranoiac government cert.