[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deciding on how to proceed with DPD/DPV Was: WG Last Call CL OSED: DPD/DPV Requirements



Peter,

>We have to be balanced.

I don't exactly know how to interpret this statement but let
me rephrase the issues.  I have neither said that DPD/DPV
is a bad design, nor that it does not address valid issues.
On the contrary I think such systems will popularize PKI.

So which are the current problems?

- OCSP is out there and so is XKMS

- Due to the "Web Services" craze, the need for DP* is *now*,
  not 24 months ahead, as a friendly off-list supporter of my
  request-for-action just wrote. XKMS may fill that purpose.

- Being a member/spy of competing standards-bodies, I feel that
  the presumed need for a particular IETF-flavored DP* is not
  justified, particularly not if there already is a working solution,
  sanctioned by major players, that you can  without cost get the
  specification for, like: http://www.w3.org/TR/xkms
  In the case of XML, there is an ocean of free Java-software as
  well, so you could be running XKMS in hours if you really want.

Maybe my suggestion to take a bold decision in some direction
is asking for a little bit too much.  OTOH I think that just "forgetting"
a "draft in despair" and let it silently disappear in obscurity, mainly
to avoid tricky decisions, is a rather inefficient way of moving things
forward.

But insisting that the DPD/DPV-promoters should clarify the need
for DPD/DPV in the light of XKMS, is though not asking for too much,
as this question will pop-up anyway when DPD/DPV is to be supported
by a vendor, or deployed by a customer.  We'd better come up with
some good answers now!

BTW, shutting down projects is unfortunately something most
people have experienced in some way, and why should standards-
efforts be different from other projects, if something unexpected
happens on the way?

I believe that I'd better cease my part in this issue for now, and can
only hope that others, including the authors take the opportunity to offer
their views on this matter in concrete, pragmatic, project-like terms. 

Regards
Anders Rundgren

>DPV/DPD will not suddenly break through a notional barrier
>that holds back adoption of digital signatures: we have
>PEM+ out there in practice, in the midst of Microsoft 2000
>and Microsoft Office XP, and despite the excellence of
>that offering, subscriber reaction is luke warm.

>I'm personally at the crux of my own Phd work, which asserts 
>that what we lack is, actually, a means of limiting certain effects
>that our signature mechanisms now provide - for the lack of
>such limiting function is a major cause of user failure to 
>now adopt our abundant technology.

>I dont happen to focus in my research work on DPV, but I do recognise
>that DPV represents within IETF the best means to accomplishing
>a more refined notion of trust (via certs), as a DPV service will 
>enable a highly subjective evaluation of cert paths - a feature that 
>may overcome user reluctance to actually go out, multiply,
>and even use digital signatures.

>Peter.


-----Original Message-----
From: Stephen Kent
To: Anders Rundgren
Cc: ietf-pkix@xxxxxxx
Sent: 7/17/02 2:04 AM
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call
CLOSED: DPD/DPV Requirements


At 11:20 AM +0200 7/17/02, Anders Rundgren wrote:
>Thanx Steve,
>
>Your phrase "the rest of us" indicates that I am the only PKIX'er who
have
>doubts regarding the validity of the DPD/DPV-effort.  I won't argue
with that
>as I have no proofs for the opposite, but rather base my view on
information
>gathered from other communities, drafts etc.   But please continue
reading...
>
>Long-term suggestion
>------------------------
>A problem with the e-mail-list approach including "rough consensus",
>is that most people are rather timid, and do not particularly enjoy
getting
>publicly bashed.  Due to this fact, I believe it could be of some value
to
>add a voting-system to the IETF-mailing lists, where a list-member
could
>send a vote on a certain topic without being exposed on the list.  Then
an
>admittedly sensitive topic like "Should we continue the DPD/DPV
effort",
>could be voted on, and you would not only get a ratio of Yes and Noes,
>but also a clear indication on how many who cares about a subject at
all.
>The suggested purpose of this would in no way be changing anything in
the
>IETF-process rules, but to gather additional input to critical
decisions.
>

Again, thanks for your suggestions on how to improve IETF processes. 
They will certainly receive due consideration.

Since we have at least 3, and maybe 4, proposals for protocols to 
satisfy the DPV/DPD requirements, I have complete confidence that 
there is a sufficient support for continuing the work in PKIX. If it 
were of no interest, we would have one proposed protocol, at best. As 
before, if you or others, feel that this is not a good use of your 
time, then you are free to ignore the activity.

Steve