Subject: RE: DPD & DPV Basics

From: Ambarish Malpani <[email-masked]>
Date: Mon, 15 Jan 2001 22:13:32 -0800

Hi Steve,
    I agree with both this mail and the one you sent to Carlin
earlier - I would fully expect the client to send the server
the kind of use it wants to use the certificate for (IPSec, S/MIME,
SSL) and the appropriate information that would depend on the
protocol (the e-mail address of the sender/recipient, the address
it thinks it is connecting to, etc).

The DPV server needs to figure out what the right key usage/
extended key usage bits are, how to do validation, etc. I would
expect servers to support commonly known protocols and be expandable
for other/future protocols.

Regards,
Ambarish

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

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 2:32 PM
> To: Paul Hoffman / IMC
> Cc: PKIX List
> Subject: Re: DPD & DPV Basics
> 
> 
> Paul Hoffman / IMC wrote:
> > At 2:09 PM -0500 1/15/01, Steve Hanna wrote:
> > >  >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.
> > 
> > Well, the one that started me on SCVP a few years ago was IPsec
> > implementations. All they really care about is "is the party that
> > just presented me with credentials someone for whom I have 
> a security
> > policy?". They use PKI to get that information, but they actually
> > don't care about what the identity is after they have a) verified
> > that they trust the identity and then b) found a match for it in
> > their security policy set.
> > 
> > Another example would be non-human S/MIME clients, such as a secure
> > automated order-processing that uses CMS messages over email. If the
> > recipient of the message can establish trust in the identity in the
> > cert and knows what to do with messages from that identity, that
> > recipient doesn't really care about the identity itself.
> > 
> > In both cases, the details of what the path to the root is, 
> who is in
> > that path, and why they are in that path, are irrelevant. "Is this
> > the signing/encrypting key for someone with whom I have an automated
> > security policy: yes or no?"
> 
> I'm afraid that, as with TLS/SSL, the situation is not as simple as it
> might appear. I am certainly not an expert with IPsec or 
> S/MIME, so feel
> free to correct me as necessary (as if IETFers would be shy 
> about doing
> so!).
> 
> Let's start with IPsec. During an IKE or ISAKMP exchange, one party
> (Alice) receives a certificate payload from another party (Bob) (or
> perhaps Alice receives a hash of a certificate that she already has or
> can easily get). Alice needs to decide whether she trusts this
> certificate. If so, she must check that the identification 
> payload sent
> by Bob is included in the certificate and the public key 
> included in the
> certificate can be used to verify the signature payload sent 
> by Bob. And
> she must look up Bob's identity (as specified in the identification
> payload) in her security policy database to decide how to treat him.
> 
> With a DPV server, Alice could send the certificate to the DPV server.
> The DPV server would decide whether Alice should trust it, by 
> trying to
> build a valid path from one of her trust anchors to the 
> certificate and
> checking revocation along the way. Once the DPV server had completed
> this validation, it could inform Alice of the result (Valid 
> or Invalid).
> 
> In order to make Alice's life as easy as possible, the DPV 
> server would
> probably be preconfigured with Alice's trust anchors and other
> validation parameters. Alice and the DPV server would need mutual
> authentication with replay protection for their conversation and
> probably confidentiality, too.
> 
> A few tricky bits, though. The DPV server should check that the
> certificate in question does not have key usage and extended key usage
> extensions inconsistent with the use that Alice is planning. 
> This could
> be preconfigured along with the rest of Alice's validation parameters.
> 
> A trickier bit is that Alice needs to check that the identification
> payload sent by Bob is included in the certificate. I suppose 
> that Alice
> could send the identification payload to the DPV server in her initial
> request. But there are many Identification Types listed in RFC 2407. I
> guess the DPV server would have to know about all of those. 
> How can they
> be listed in certificates, etc. Maybe only a few are used today
> (ID_IPV4_ADDR), but we would need to design the protocol so that it
> could support all of them in the future. Or the DPV would need to send
> all of the subject names and subject alternative names back 
> to Alice and
> she could check for herself. So much for keeping Alice PKI-ignorant!
> 
> Another tricky bit is that Alice must check that the public 
> key included
> in the certificate can be used to verify the signature payload sent by
> Bob. The DPV server should send her the public key in its 
> result, along
> with any DSA parameters and such. Then Alice can use it to verify the
> signature payload.
> 
> Please correct me if I have made any mistakes with the IPsec part of
> this. I really know very little about IPsec and it seems to be quite
> complicated. I just want to make sure we understand all of the
> requirements that are implied for the DPV protocol and server.
> 
> 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.
> 
> 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.
> 
> Please feel free to correct my analysis. I just want to make sure we
> have thought about what DPV will be used for before we decide what the
> requirements should be.
> 
> Thanks,
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 14:30:07 -0500

Ambarish,

>for other/future protocols.

As I mentioned in my response to Steve Hanna, I think this is not a 
good model, because it suggests that the protocol and server can 
anticipate all the requirements for ID matching that any client might 
require. I prefer a model in which the server returns extracted data 
from the cert for use by the client, for clients that are not capable 
of parsing the target cert.

Steve