Subject: RE: DPD & DPV Basics

From: "Covey, Carlin" <[email-masked]>
Date: Mon, 15 Jan 2001 13:21:20 -0800

It seems to me that DPV would be very useful for devices that
are bandwidth limited, such as cell phones, or are protocol-
complexity-limited, such as VPN devices implemented in hardware.
In both these cases the device would not be interested in the 
supporting evidence, just a good/not-good indication.

Regards,
Carlin

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

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:10 PM
To: Stephen Kent
Cc: PKIX List
Subject: Re: DPD & DPV Basics

Stephen Kent wrote:
> Maybe the root of our disagreement is the assumption of what
> the common requirement is for a DPV client.  My strawman cites
> PKI-ignorant (to use Denis' term) clients as a major motivation for
> DPV, which seems incompatible with a DPV server that requires perfect
> inputs.

From this message and several others, I gather that the basic motivation
for having a DPV server is to provide services to simple, "PKI-ignorant"
clients. Could someone please supply some examples of such clients? What
protocols will they be speaking (other than the DPV protocol)? This
would be very useful in determining the proper requirements for the DPV
protocol.

Thanks,

Steve

---

From: Steve Hanna <[email-masked]>
Date: Mon, 15 Jan 2001 17:10:41 -0500

> supporting evidence, just a good/not-good indication.

For cell phones, TLS/SSL would probably be the primary certificate-using
protocol that we would need to support. For VPN devices, it would
probably be IPsec. Please correct me if I'm wrong on this.

Let's take a look at what we would need to support a cell phone talking
TLS/SSL (server side authentication only, let's assume). For IPsec, see
my response to Paul Hoffman's email (coming out next).

When an TLS/SSL client receives a Server Certificate message, it needs
to decide whether it believes that the server's end-entity certificate
is valid. It also needs to make sure that this certificate includes a
subject name or subject alternative name that matches the expected host
name and that the appropriate key usage and extended key usage bits are
set (or that those extensions are absent). Finally, it needs to extract
the public key from the certificate (along with any public key
parameters), so that it can complete the handshake and authenticate the
server.

With a DPV server, the TLS/SSL client could send the TLS/SSL server's
end-entity certificate to the DPV server. The DPV server would decide
whether the TLS/SSL client should trust it, by trying to discover a
validated path from one of the client's trust anchors to the
certificate. Once the DPV server had completed this validation, it could
inform the TLS/SSL client of the result (Valid or Invalid).

In order to make the TLS/SSL client's life as easy as possible, the DPV
server could be preconfigured with its trust anchors and other
validation parameters. The TLS/SSL client and the DPV server would need
mutual authentication with replay protection for their conversation and
probably confidentiality, too.

But what about the TLS/SSL client's need to check that the TLS/SSL
server's end entity certificate includes a subject name or subject
alternative name that matches the expected host name? This task could be
handled by the DPV server, but we would need to include a way for the
DPV client to send the host name to the DPV server and the DPV server
would need to know about the special, legacy ways that host names may be
included in certificates. Or the DPV server could send the list of
subject names and subject alternative names to the DPV client, which
would could parse these items itself and decide whether they were
acceptable. Or we could just have the TLS/SSL client parse the
certificate, but now it's not PKI-ignorant any more.

The key usage and extended key usage checks can be handled by including
the desired values in the preconfigured validation parameters on the DPV
server. But the DPV server will definitely need to send the public key
value to the DPV client, since the end-entity certificate may have
inherited DSA parameters.

Note also that the TLS/SSL client should really send the other
certificates included in the Server Certificate message to the DPV
server. They may be essential to building the path.

I certainly don't think these requirements are impossible to meet.
However, they should be added to the requirements for DPV (which are
diverging quickly from the requirements for DPD).

-Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 12:18:25 -0500

Steve,

><snip>

I agree with your example, in almost every detail (I'd like to see 
reference to the trust anchors in the call, not have the reference 
implicit by client ID). I think the current spec alludes to the 
capability you describe, specifically it says:

"For a non-PKI aware, non-ASN.1-capable client, the results returned 
by the DPV protocol should not be merely a certificate and a status 
indication. Rather, the contents of a certificate that are relevant 
to the client application should be returned as distinct values, in a 
syntax appropriate for the client. For example, the public key and 
associated algorithm, the subject name (and/or alternate names) and 
the issuer name (and alternate names), the key usage bits, and the 
extended key usage field are all candidate values to be returned as 
distinct objects to the client."

We have not included these specific requirements so far, because we 
have not agreed whether it is appropriate to provide the results in 
ASN.1 or via some other means, a tension noted elsewhere in the 
requirements spec.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 16 Jan 2001 16:18:13 -0800

Carlin,

It might also be useful to extend this concept the "asymmetric OCSP" case,
where a client's trusted server not only confirms the validity of the
client's certificate via an external trust server but acquires from that
same server an assertion of the validity of its (the protocol server's)
certificate.  This response could be included in-band to the client and so
relieve the client of any further interaction with infrastructure to
establish the server's trustworthiness.  IPSEC's protocol architecture seems
well suited to this design.

Mike

> From: Covey, Carlin [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 1:21 PM
> To: PKIX List
> Subject: RE: DPD & DPV Basics
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 22:40:54 -0500

Mike,

>well suited to this design.

One could imagine doing this, but when do we stop providing such 
info? Do we provide a cert path and revocation status data for the 
OCSP responder too?

Maybe one should include the OCSP server's cert in an NR package, but 
for a DPV server, I think it would not  be appropriate to pass back 
this info discretely.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 16 Jan 2001 23:43:22 -0800

Steve,

Are we talking about the same thing?  Given a client-side initiation, it's
an OCSP request from an IPSEC GW/whatever to an OCSP server regarding that
incoming cert, then that GW/whatever turns around, gets *its* own OCSP
signed validation back from that same server (which public key the client
trusts) and drops it into the IPSEC handshake.

This scenario should bear no impact on the protocol's definition (modulo
IPSEC implementation impact, of course.)  It's an enterprise trust policy
issue.  It's just using the BOTW protocol as defined, although in a somewhat
interesting way in order to: 1) simplify the client side (esp. wrt the road
warrior); and 2) concentrate processing power in the back office where in
fact such power exists.  It also simplifies things tremendously at the
system level.

BTW, I've been kicking this around with various IPSEC folk as far back as
the Binghamton interop.  Harkins and I also discussed it in Orlando.  CF
also my message to Khaja on this list on Fri Sep 1 12:50:51 2000 re: "OCSP
in S/MIME and IPSEC".

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 7:41 PM
> To: Michael Myers
> Cc: PKIX List

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jan 2001 11:02:23 -0500

Mike,

>trusts) and drops it into the IPSEC handshake.

I guess we're not talking about the same thing.

I thought we were talking about a query to a DPV server by an IPsec 
client, where the DPV server then made use of an OCSP server. Thus I 
interpreted your comment as suggesting that the DPV server return not 
only an OCSP response, but also the cert for the OCSP responder. My 
observation is that if on choose to do this, why stop at the OCSP 
server cert, given that there is potentially much more context that 
might be required. For instance, do we assume that the OCSP server's 
cert has to fall under one of the trust anchors specified by the DPV 
client?

I would not have guessed, from the original message below, that the 
focus of your message was pushing OCSP responses in IKE.

Steve