Re: DPD & DPV Basics

[Steve Hanna <steve.hanna@xxxxxxx>]

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