Re: Need to support non-ASN.1 DPV clients?

[Steve Hanna <steve.hanna@xxxxxxx>]

Denis Pinkas wrote:
> > I have seen one response to my question:
> >
> > >   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."
> 
> 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."

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

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

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