Subject: RE: DPD & DPV Basics

From: Frank Balluffi <[email-masked]>
Date: Thu, 11 Jan 2001 13:30:53 -0800

Steve,

I like your approach. Here goes ...

1. Can someone explain the value of a DPD server returning a path that may
not be valid? I would argue that path discovery should be an optional
internal operation performed by a DPV server. I say this as someone who has
implemented support for SCVP draft 4's path building types of check. To me
the operation should be implicit.

2. I would like to see the option of passing certificates and other input
(e.g., CRLs) by reference for use by PKI-unaware (e.g., XML-enabled)
applications.

Frank

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 3: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: Steve Hanna <[email-masked]>
Date: Thu, 11 Jan 2001 16:59:35 -0500

> the operation should be implicit.

I agree that there's not much utility in having a DPD server return an
invalid (or unvalidated) path. However, I don't agree that path
discovery should be part of a DPV server's job. Instead, I would argue
that validation should be part of a DPD server's job.

My team has also implemented path discovery and validation (although not
yet delegated discovery and validation). Validation is a fairly simple
matter of running the PKIX validation algorithm using certain
parameters. Discovery is *much* more complicated, involving heuristics
for guessing which certificates might lead to the target certificate (or
to the trust anchor, if building forward), partial validation to
discover when a partial path is futile, and loop detection. I would
argue that DPD is substantially harder than DPV and DPV is often
sufficient. So it is definitely worthwhile to define DPV as a separate
operation. Many servers may only want to support that operation.

> (e.g., CRLs) by reference for use by PKI-unaware (e.g., XML-enabled)

I think this item really belongs in the discussion of Steve's detailed
requirements. It doesn't pertain to reaching agreement on the basic
concepts. It's definitely a good point to discuss, just not in this
thread.

Thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 18:04:43 -0500

Steve,

>that validation should be part of a DPD server's job.

The strawman already calls for a DPD server to perform validation. 
You're suggesting that a DPV server should not have to perform 
discovery. That would imply that either:
	 (1) the client passed in a complete path, and matching 
revocation status data,
	(2) the client called the DPD server first, then passed on 
the result to the DPV server
	(3) or that a DPV server called a DPD server in support of discovery.

What simplifications to the overall architecture arise if we split 
responsibility this way? Certainly if we expect one server to do 
both, i.e., to have DPV piggyback on DPD but with slightly different 
interfaces, this isn't all that helpful. I'm not rejecting this 
approach, but I want to understand it's benefits in more detail.

>operation. Many servers may only want to support that operation.

No argument that discovery is harder, and it subsumes validation. 
But, what is the basis for arguing that validation, based on 
supplying complete cert chains and revocation status data, will be 
the more common case and thus we should optimize for it? Several 
protocols allow for transmission of certs and CRLs, but some allow 
transmission only for certs, perhaps because that it static data that 
is easier to configure into the client.

><snip>

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 12 Jan 2001 10:16:55 -0800

Steve,

> On Thursday, January 11, 2001, 3:05 PM you wrote:
>

While I await WG consensus on the requirements, in Pittsburg the DPD I-D
authors observed that a DPD server need not be subject to ITSEC/Common
Criteria/whatever certification due to its untrusted role.  Suggesting that
a DPD server must perform validation seems to refute this objective.  A DPD
client certainly has every reason to expect that the information it receives
from a DPD server is well structured against the subject certificate. Any
thoughts on how we can or should balance these two?

Mike

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jan 2001 13:26:08 -0500

Mike,

>thoughts on how we can or should balance these two?

There is no conflict here. As the strawman already notes, a DPD 
client is PKI-aware and is expected to validate the returned data. so 
any failure by the DPD server has no adverse security implications 
for the client, other than denial of service.  A DPD server is still 
untrusted.

Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 12 Jan 2001 14:31:09 -0500

>         (3) or that a DPV server called a DPD server in support of discovery.

As I see it, a DPV client would provide a complete path and other inputs
required by RFC 2459 (such as acceptable certificate policies). The
client could supply some revocation status information, but I would not
expect this to be common. The DPV server would be responsible for
performing the validation algorithm described in RFC 2459 (or its
successors), including checking revocation. This could involve
consulting CRLs or OCSP servers.

> approach, but I want to understand it's benefits in more detail.

One benefit of this definition is that such a DPV server would be
substantially easier than a DPD server (which may have to try many
possible paths). In many cases, such a DPV server will be sufficient.

Here's an analysis of use cases for S/MIME and TLS/SSL:

  A TLS/SSL client could pass the certification path supplied
  by a TLS/SSL server to its trusted DPV server (along with any
  necessary parameters, such as the client's list of trust anchors) and
  the DPV server would determine whether the path was valid. If mutual
  authentication is in use, a TLS/SSL server could do the same thing to
  validate a certification path supplied by the TLS/SSL client. A DPD
  server could also be used in either of these cases. It would increase
  the probability of finding a successful path, but with a considerably
  higher cost.

  With S/MIME, a DPD server will probably be required, in general. A
  signed email comes with a bag of certificates. In order to form a
  chain from one of the recipient's trust anchors to the signer,
  certificates must be selected from this bag (and perhaps from other
  sources). Simple validation is not usually sufficient. When attempting
  to determine the public key of a previously unknown party in order to
  send them an encrypted email, discovery is also required.

To summarize, DPV (as I defined it) is a subset of DPD. In some
circumstances, DPV is sufficient. But not always. We could simplify the
model by eliminating DPV and adding a flag so the client can say "don't
add any certs to this chain".

---

It seems to me that others on this list consider it perfectly OK for a
DPV server to add or remove intermediate certificates to/from the
certification path supplied by the client. In that case, the only
distinction between a DPV server and a DPD server is that the DPD server
is expected to return the validated certification path to the client.

Is that what you had in mind, Steve? Mike? If so, I agree with Steve
that there's little distinction between a DPV server and a DPD server
(as so defined). Let's just add a few flags to say "don't add any certs
to this chain" and "return the completed path to me" and call the whole
thing a DPD server (or whatever we want to call it).

> is easier to configure into the client.

As I described above, I agree that clients will rarely have revocation
status data. Providing a DPV function that can validate a certification
path without including the extra complexity of path discovery would be
nice. But since path discovery is also important and usually more
desirable, perhaps we should just focus on that.

-Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jan 2001 18:06:36 -0500

Steve,

>consulting CRLs or OCSP servers.

If a DPV client is not PKI aware, then I don't expect it to be able 
to have a complete path in many cases, and I would rarely ex[ect it 
to have all the relevant revocation status info.  In S/MIME or in 
IPsec, where there is a good chance that the peers have different 
CAs, it is not necessarily feasible to send a complete path to the 
other party, because you may not know enough about that party's PKI 
context.

>possible paths). In many cases, such a DPV server will be sufficient.

Yes, it would be simplier, but I worry that in making it simple, we 
have over burdened the client. A PKI-ignorant client can't even go to 
a DPD server to get the data to pass on to a DPV server.

>   the probability of finding a successful path, but with a considerably

For a client, given the common multi-root CA mode of operation for 
browsers, none of this seems applicable, so I'm having trouble seeing 
the utility for clients here. In either case you cite above, the apps 
are PKI aware already and thus capable of calling a DPD sever, as you 
noted.  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.

>add any certs to this chain".

See comments above re client capability assumptions.

>is expected to return the validated certification path to the client.

My proposal requires the DPV server to be able to do the same, though 
as an opaque blob.

>thing a DPD server (or whatever we want to call it).

I think the request/response formats for both servers could be almost 
identical, and with the right control flags one could cause the 
relevant subset of operations to occur, yes.

Steve

---

From: Steve Hanna <[email-masked]>
Date: Mon, 15 Jan 2001 14:09:57 -0500

Stephen Kent wrote:
> Maybe the root of our disagreement is the assumption of what

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: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 15 Jan 2001 13:56:33 -0800

>would be very useful in determining the proper requirements for the DPV

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?"

--Paul Hoffman, Director
--Internet Mail Consortium

---

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

> 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: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 15 Jan 2001 14:51:57 -0800

>free to correct me as necessary (as if IETFers would be shy about doing

Done. :-)

Where you go wrong on both of your responses is to assume that an 
application that can parse a cert is the same thing as one which is 
PKI-aware. This is not the case. A program that can parse a cert just 
fine might still want/need a DPV to do the path checking (which 
includes the CA policy checking) and the validity checking.

>be preconfigured along with the rest of Alice's validation parameters.

That is not needed in the examples I gave. Alice's IKE implementation 
can parse the certificate from Bob and decide if the key usage bits 
in the cert match her security policy. Yes, she might want to trust 
the DPV system to do that, but she doesn't have to.

>payload sent by Bob is included in the certificate.

Not tricky at all: parse the cert, find the SubjectAltName in it, and 
compare it to the ID payload.

>them to be PKI-aware. This seems sensible to me.

Nope: you conflated to different possible attributes of the agents.

Does that make more sense?

FWIW, I got this wrong when I started the SCVP work. I wanted clients 
to not need to be able to parse the cert, and for the SCVP server to 
not only pass back a yes-no answer, but also the relevant parts of 
the cert. It was pointed out to me that this was doable but not that 
useful: parsing a cert for the ID, the key, and the key usage isn't 
as hard as some people think.

--Paul Hoffman, Director

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 13:20:00 -0500

Steve,

I'll weigh in on the IPsec scenario too.

I would expect the (IKE) client to send in the target cert and either 
explicit validation parameters, or a reference to a stored set. 
Checking the key usage could be done at the server or in the client. 
But I do expect the client to do the ID matching against the returned 
cert or cert contents.  I would not want the the server to do this 
because it is application specific and we don't want to require 
servers to know about such things for every application that might 
make use of them.

Steve

---

From: Steve Hanna <[email-masked]>
Date: Tue, 16 Jan 2001 14:01:20 -0500

Ambarish Malpani wrote:
>     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.

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

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).

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.

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).

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)?

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

Thanks,

Steve

Note 1: If the certificate provided to the DPV server contains a DSA key
with inherited parameters, even an ASN.1-savvy application can't get
those parameters from the certificate (since they are inherited from
other certificates that the application may not have). In that
circumstance, the DPV server must return these parameters to the
application.

---

From: Steve Hanna <[email-masked]>
Date: Tue, 16 Jan 2001 14:18:15 -0500

Stephen Kent wrote:
> 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'm glad to hear we're approaching agreement on this. Why would you like
to make the trust anchors explicit, especially if the rest of the
validation parameters are implicit? Or are you simply arguing that the
client should have consider flexibility in deciding which parameters are
explicit and which ones implicit?

> 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.

It sounds like we need to decide whether non-PKI aware,
non-ASN.1-capable clients need to be supported. If so, we should
probably define a set of requirements for such clients and include this
item in that list. I would suggest that such clients are an important
group and should be supported.

> servers to know about such things for every application that might

I am also reluctant to have the server perform application-specific
checks. But matching an ID against a set of subject names and subject
alternative names can be complicated. This is especially true for email
addresses and DNS host names (for TLS/SSL connections), since there are
legacy conventions for including these names in X.500 names, as well as
specific name types for subject alternative names.

Therefore, I think there's a strong case that, at least for non-PKI
aware, non-ASN.1-capable clients, the DPV server should perform this
check.

-Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 21:00:46 -0500

Steve,

>explicit and which ones implicit?

I'm open to specifying parameters as a mix of explicit ones and ones 
specified by reference to a policy configured at the server, with the 
explicit ones overriding the specified ones, UNLESS the policy 
precludes such override. I think this is what the strawman spec says.

>group and should be supported.

I put this question to the list in my strawman spec over 2 weeks ago, 
and have not yet gotten a concrete proposal on how to accommodate 
such clients.  I will soon decide that we will NOT support them for 
now, unless I see such a proposal.

>aware, non-ASN.1-capable clients, the DPV server should perform this

I sympathize with the concern, but there is still the issue of why 
should we do this application-specific function, vs. others that 
might arise in the future?

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 16 Jan 2001 19:33:04 -0800

At 9:00 PM -0500 1/16/01, Stephen Kent wrote:
>I put this question to the list in my strawman spec over 2 weeks 
>ago, and have not yet gotten a concrete proposal on how to 
>accommodate such clients.  I will soon decide that we will NOT 
>support them for now, unless I see such a proposal.

I think that many vendors would like these clients to be able to 
exist, but have bitten the bullet and done the ASN.1 to at least 
parse the cert. Given the strong arguments we had when I first 
proposed SCVP for non-ASN.1 clients, and the fact that none of the 
vendors wanted to say in public that this is what they needed, I 
think it is OK to limit the scope of the discussion to a client that 
can parse a cert and knows what pieces it needs to implement its 
security policy.

--Paul Hoffman, Director

---

From: Steve Hanna <[email-masked]>
Date: Wed, 17 Jan 2001 09:39:38 -0500

Stephen Kent wrote:
> and have not yet gotten a concrete proposal on how to accommodate such
> clients. I will soon decide that we will NOT support them for now,
> unless I see such a proposal.

Yes, that question is highlighted in your requirements document. As you
point out there, it is important to resolve this question promptly in
order to decide on DPV and DPD requirements. But, as you pointed out in
yesterday's email, the question has not been discussed on this mailing
list in a substantial manner since your requirements document was
published. Therefore, I'd like to start a thread specifically addressed
to this question:

  Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?

Let's settle this now. If you believe that such support is necessary and
should be included in this effort or if you believe that it should not,
please speak up now and explain why or why not.

As for a "concrete proposal", I doubt that it will be hard to come up
with a proposal if we decide that support for non-ASN.1-capable DPV
clients is needed.

-Steve

P.S. I will set aside the more specific points we were discussing
regarding non-ASN.1-capable clients until this more basic question is
resolved.

---

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jan 2001 16:18:15 -0500

>   Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?

Of course, the WG chair is responsible for judging consensus. But given
that the only response was in the negative (indicating that this work
will be done elsewhere) and that nobody has come forward to say we must
support non-ASN.1-capable DPV clients, I will suggest that the consensus
answer is "No, we do not need to support non-PKI aware,
non-ASN.1-capable DPV clients."

That simplifies things a bit.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 18:23:30 +0100

Steve (Hanna),

Since no answer would mean "yes", you force me to answer.

> support non-ASN.1-capable DPV clients,

Since Paul does not insist anymore, I can support this statement.

> I will suggest that the consensus

Your last sentence is not the same as the sentence above: "non-PKI aware"
and "non ASN.1 capable" are not equivalent.

For the time being I would suggest that the consensus is: "We do not need to
support non-ASN.1-capable DPV clients."

I have advocated the use of "blobs" for both the request parameters and the
optional result for a DPV client. This allows to have non-PKI aware clients.
Maybe there are some variations under that wording, but certainly a DPV
client is not DPD capable. Hence a good reason for the separation of the two
functionality.

Denis

---

From: Steve Hanna <[email-masked]>
Date: Mon, 22 Jan 2001 17:00:11 -0500

> support non-ASN.1-capable DPV clients."

Since Steve Kent's requirements did not propose to support
non-ASN.1-capable, PKI-aware DPV clients, you are right that the
decision reached last week (not to support non-PKI aware,
non-ASN.1-capable DPV clients) implies that "We do not need to support
non-ASN.1-capable DPV clients."

> client is not DPD capable. Hence a good reason for the separation of the two

The set of inputs for the DPV and DPD protocols are remarkably similar.
As long as we design the protocol properly, I don't see why there should
be any problem using one protocol for both. A non-PKI-aware client can
pass blobs in and out (binary objects whose contents it does not
understand). A PKI-aware client will understand the contents of those
objects. A non-PKI-aware client will trust the server (although it may
archive the blob for someone else to analyze later). A PKI-aware client
may or may not trust the server.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 09:51:49 +0100

Steve (Hanna),

( ...)

> non-ASN.1-capable DPV clients."

I do not "buy" your phrasing. It is not an implication, it is the basis of
the agreement. DPV has to be usable by a non-PKI aware client, or, let us
say, by a client with very limited PKI knowledge.

> The set of inputs for the DPV and DPD protocols are remarkably similar.

The inputs, the goal of request and the responses are quite different.

> be any problem using one protocol for both. 

Let us look at the details below.

> A non-PKI-aware client can

I agree with you on the above statements. It is now time to go for a
proposal where you will see the differences. I made no attempt to look for
the similarities, but I am confident you will do that exercise. :-)

I will be posting the proposal in a different message, so that it can be
discussed more easily.

Denis