Subject: RE: Open issue: DPV relay

From: Peter Williams <[email-masked]>
Date: Fri, 05 Apr 2002 17:28:38 -0800

Todd,

I do not believe we should formulate any
particular use-model at this time, for DPV REQUIREMENTS; 
leaving aside the philosophical issue of 
whether use-modeling would or would not help IETF standards 
adoption. The requirements should prepare for 
protocol-specification, not establish operational
usage constraints.

The only valuable use-issues topics I can forsee that might
serve us (in contradiction to the above) are precisely
those that Ambarish mentioned: do what OCSP did,
so succesfully in the Internet environment... for the 
same issue; and dont lets sucumb to the temptation to
over-architect!

--------------

In my view, on Russ side comment, constraining DPV to 
require users to interact
with a service provider at a single access-point is 
like setting the clock back on X.509, and requiring
the world to adopt the Entrust use-model
of PKC key management. Entrust's use-model makes
for a fine and highly-manageable system, but it 
competes (successfully) with other domain-management 
models that are equally succesful in the wider Internet
environment we server.

The only trust issue for DPV requirments I can see
is this:

Just, as Sharon recently indicated, PMI's SOAs
are trusted as authoritative for their policy
scope, so DPV servers are trusted. PMI deals
with privileges; DPV deals with remote processing
of chains against validation policies. The two
authority models are really identical, otherwise.

Lets note that PMI didnt constrain an AC verifier to use
only a single SOA-headed source of AC paths. So
should the DPV requirements not constrain the
DPV client from accepting results from
any  set of (possibly (out of IETF scope) constained) DPV 
servers - whose service is provided at the
access point to which the client is bound (including 
that operated, perhaps, by a simple-proxing or a 
chaining&resigning DPV server).

-----Original Message-----
From: todd glassey [mailto:[email-masked]]
Sent: Friday, April 05, 2002 3:52 PM
To: Housley, Russ; jim
Cc: [email-masked]; Tim Polk; [email-masked]
Subject: Re: Open issue: DPV relay

Russ is 100% dead on  but this is about the mechanics of the use model more
than anything - let me demonstrate...

----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "jim" <[email-masked]>
Cc: <[email-masked]>; "Tim Polk" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 05, 2002 12:42 PM
Subject: Re: Open issue: DPV relay

>
> Jim:
>
> I am not talking about trust in the X.500 system.  I am talking about
trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it
is
> an error from the client's perspective.
>
> I see no reason for the client to be made aware of an chaining or
multicasting.
>
> I do not think that we should include referrals in the DPV system at all.

The only way this would not want to be true is if the trust model between
the requesting agents and the supplying agents had a pre-existing agreement
that the trust supplying agent could look beyond its own services as sources
of the trust model its looking for from this DPV server. It would then stand
as a referred trust provider when it cannot satisfy the trust request
itself.

In fact from a use model perspective, it would seem that only the client
could authotize this  for privacy reasons, and it seems that it would need
to be on a per transaction basis (I.e. the Trust provider says " my trust
processes cannon fulfill this request so I have passed it onward to someone
that can" ... the only problem is that you run the potential that the  next
link in the trust envelope would also not be able to satisfy this request
either or coupdl get locked in a loop... so where does it stop???)

The "what" of what you have now is a situation where the referring agent is
going around and shopping for an external DPV agent who can and is willing
to satisfy this trust validation request.  And this seems at best kinda
clunky and potentially a real problem  over privacy and context information
from the actual agent requesting this validation service.

I suggest that becuase of this, that unless specifically authorized or
requested from the client, that the DPV services should be restruicted to
stay on a single platform... and it be the Client's responsibility to
hierarchicly check out the trust element in question.

> Russ

SNIP

---

From: "todd glassey" <[email-masked]>
Date: Sat, 6 Apr 2002 06:06:40 -0800

Peter - All - I agree with you to some extent but let me also that there is
another side and its about a bigger picture.  And in this bigger picture
PKIX is way out of control. What it really needs is to have a thread of
commonality drawn through all that PKIX produces. What I mean by that is
that the entire process of  complex-decision-support and evidentiary
processing of x.509 certs is out of control.

What we as a culture really need is something like CDSA only for PKIX. What
I would conceptually propose as the PKIX streamlined PKI architecture. A
common PKIX transaction architecture and process model. A simpler one, and
one that does not allow recursion or ambiguity that is unchecked. What PKIX
needs to do is to simplify everything it does.

The intent would be to identify:

    1)    Is there any value in making all this PKI ware at the Network
Transport Level. I.e will the evidentiary needs of the world need and use
what we are proposing. Will it fit into Human Law and Process currently
accepted or, like the TSA, will it need artificial stimulus in the form of
something like Italy's mandating some EU approved timestamp process without
understanding exactly what the TSA provides relative to simple receipts
(i.e. not much at this point but we should spin that off as a separate
thread!).

    2)    How can the same services be used for both Evidentiary Service
Models and for Decision Support (Hey Stephen - I going Cap Crazy!)...

    3)    And who we are going to work with.

What has happened so far is that with its key architects, this WG has come
up with so many pieces that it is freakin impossible to come to any gross
agreements about anything. Take this argument - "Should DPV servers refer
their requests to another node in a chain if local policy is failed or
exceeded?" - it is totally constrained by how this system is being used and
what types of legal frameworks are manding functionality under it.

This is more than a problem with PKIX and people submitting technologies
that while the use seems mechanically cool, do not satisfy the existing
legal or process framework. And to that end PKIX and the IETF force the
world to tau-tau to its goals rather that the IETF doing what its supposed
to and that is to build protocols for the real world. Well the real world is
commercial transaction processing and without it there would be no Internet.

Todd

---

From: "todd glassey" <[email-masked]>
Date: Sat, 6 Apr 2002 06:03:02 -0800

Peter -
----- Original Message -----
From: "Peter Williams" <[email-masked]>
To: "'todd glassey'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 05, 2002 5:28 PM
Subject: RE: Open issue: DPV relay

> particular use-model at this time, for DPV REQUIREMENTS;

Then how can we make a determination on what its supposed to do in the real
world and how the policy is supposed to work? This one especially, I think,
needs a use model.

o-    Jane calls DPV server with the embedded clients in her document or
event authenticator applet.

o-    The applet transfers the query to the DPV server and then awaits
response. (and how is gross DPV discovery done anyhow?)

o-    Server responds - "No data, sorry Jane. But I do want to ask "should I
forward this request to the next link in the chain or what?"

o-    Jane responds through her applet - "Yeah go ahead and forward it."
(except that I see Safe Harbor violations in this so large that no one in
their right mind uses it without constraints.)

> adoption.

Yes lets as Stephen will not be happy if I or you open that can of worms
again (anyone else or an Earthworm?)

> The requirements should prepare for

Except that this context is supposed to carry data that is directly impacted
by any number of already in place legal regimens. The concept that Safe
Harmor is not relative to what PKIX does is more than stupid its negligent
as no protocol that would violate what these laws were setup to do will fly.

> those that Ambarish mentioned: do what OCSP did,

OCSP also suffers the same set of problems but to a lessor degree. By the
way  Myers -I never complimented you on OCSP but it is a stroke of genius.
Especially since it can be used as the policy control transport itself of a
transaction process. (Sorry for the rathole there.)

> of PKC key management.

Sure from a mechanical standpoint but the world is not a totally meshed set
of governments and we are still a planet of individual laws and
jurisdictions and so not paying attention to tools that could have impact
there is more than dumb. Its dumber.

> Entrust's use-model makes

That's the point.

> scope, so DPV servers are trusted.

OK then should the source of the trust have the ability to refer you to
another trust node as the source of the trust its proferring to you. Remeber
that the request and servicing of a trust process may in many legal senses
be a contract and as such it has peculiar nuances that we as technogeeks are
usually unconcerned with. But its time to wake up and get concerned.

So lets look what actually happens to a contract model wherein the end-node
trust service refers that trust process to a second or follow-on server...
The contract is still between the first two players, eh? - not likely  - so
then what is the difference in DPV being driven by the Client Side as
opposed to authmatically being referred onward to the next node in a web of
trust? Simple - If the client is responsible for all escalation of the/up
the  DPV Proofing Chain (thats my term for the identified chain of trust
verifiers for any given "D"), then the legal issues become more one for the
client application to address and this is a much safer method of dealing
with the process I think.

> PMI deals

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Apr 2002 00:05:04 -0400

Todd,

>their right mind uses it without constraints.)

Your effort above shows why it's not trivial to develop use models, 
i.e., one needs to identify the essential aspects of the model that 
should guide development of the standards. Your example does not seem 
to do that; it is not clear what the essential features are, based on 
the example, and how they should affect the requirements document.

For example, I would remove all references to applets, etc.  We don't 
care what sort of software invokes the protocol. With regard to your 
second bullet, we have already discussed the fact that since a client 
is relying on a DPV to verify certs, a means of identifying an 
acceptable DPV server must be configured into the client.  We already 
have analogous provisions for local path validation in 2459 and 
2459bis, where we discuss the role of trust anchors, and in OCSP, 
where one can configure the ID of the OCSP server to be employed. 
Here we don't have the luxury of relying on PKI-based facilities, 
since the client is assumed to be pretty dumb re PKI in the first 
place, so our options will be more limited.  The precise means by 
which acceptable DPV servers are identified (securely) may be outside 
the scope of the protocol, though the need to provide for such 
binding should be part of the protocol, and of the requirements 
document. Presumably the heart of your example resides in the last 
two bullets, where you bring up a possible user interaction re 
approval of invocation of a relay function. But, I don't think your 
example helps clarify the issue. We're assuming dumb client software, 
and we have assumed reference to validation policies via OIDs. This 
suggests that the users probably ought not be assumed to be in the 
loop for a decision such as this. in fact, one could easily imagine 
that authorization to make use of a relay could be a part of a 
validation policy to which we are already referring. (By the way, the 
"next link in the chain" is an odd reference since there is no 
presumed correspondence between cert path elements and DPV servers.) 
So, at the end of the example, I don't think I have any additional 
insights into what should or should not be part of the requirements 
doc.

>as no protocol that would violate what these laws were setup to do will fly.

DPV is not for use ONLY in contexts involving NR, which I assume is 
the unstated assumption behind your reference to "legal regimens." 
Yes, NR may represent part of the use model, but it is not the 
overriding focus.  Remember we're not restricted to digital signature 
uses of the keys extracted from certs, and even when signatures are 
involved, they may be used for authentication without invoking the 
complexity of NR.

	<SNIP>

>usually unconcerned with. But its time to wake up and get concerned.

I have a lot of trouble parsing this paragraph. Is not a replying 
party ultimately responsible to ensuring that the mechanisms it 
employs to verify a cert are adequate to protect its interests, 
should a legal challenge arise? If so, the responsibility here is on 
the folks configuring the policies in the DPV server, and on the 
clients invoking those policies, to make choices consistent with 
their requirements, whatever they may be.

>with the process I think.

The client is invoking a DPV server to perform a service constrained 
by the validation policy referred to in the request. That abstraction 
is capable of addressing the concern you cite, if the folks managing 
the policies choose to do so. Not all clients may have the concerns 
you cite, so it makes sense to address this in the policy.

	<SNIP>

The bottom line is that DPV is about more than path validation in 
support of NR applications. Note that Denis previously proposed a 
signature validation capability that the WG decided was best 
separated from this path validation activity.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Apr 2002 00:05:04 -0400

Todd,

>processing of x.509 certs is out of control.

As noted in my immediate, previous message, not all the PKI standards 
we address are in support of NR. This it is not reasonable to insist 
that all of these standards have an "evidentiary" flavor to them.

>(i.e. not much at this point but we should spin that off as a separate

Your terminology is seriously flawed. We make us of transport layer 
protocols such as UDP and TCP. Using the Internet protocol 
architecture terminology, we are developing application protocols. 
after that sentence, I begin to lose track of your point, other than 
apparently insulting Italians.

>Models and for Decision Support (Hey Stephen - I going Cap Crazy!)...

yes, you are.

>commercial transaction processing and without it there would be no Internet.

"tau-tau?" I assume you mean "kowtow," meaning to bow as a sign of 
respect (from the ancient Mandarin).

Anyway, the folks who participate in the WG do believe that they are 
building protocols that are of value to the real world. As noted 
elsewhere, many of us have a model of the real world that is a bit 
more encompassing that what you seem to advocate, and thus our ideas 
of an appropriate level of protocol generality differ from yours.

BTW, what percentage of Internet traffic do you assert is 
"transaction processing" of the sort that requires the 
non-repudiation facilities that seem to be the focus of all your 
comments?  If we eliminate all the informal e-mail, essentially all 
file transfers, web surfing for a great variety of information that 
may not result in purchases, the credit card transactions that, due 
to extant laws, are acceptably well protected, ... Yes, the Internet 
is about to grind to a halt because PKIX has not addressed your 
notion of what is required.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Tue, 9 Apr 2002 13:18:34 -0700

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 08, 2002 9:05 PM
Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay

> that all of these standards have an "evidentiary" flavor to them.

Why not Stephen?  NR is something that only a set of practices can
establish.

> Your terminology is seriously flawed.

No Stephen its not. What is flawed is the response I get from you.

1)    What I said was simple - Is PKI technology being implemented at the
TCP/UDP based network level a good idea. So far the only parts of the market
that agree with you as the chair of the Global; PKI Standards group is the
manufacturers. What this means is that you have failed to date to get the
end users to buy in.

What was that line from that Van Morrison song, "and the Girls go by,
dressed up for each other"... or something like that.

The real issue I think is that you have failed to bring the evolution of PKI
to a place where it is marketable and isnt that what you set out to do? if
not then please correct me as to what and why we are all here?

> We make us of transport layer
> protocols such as UDP and TCP.

Steve - pardon my being picking about this next point but you are not the
WG, so its "The WG makes use of"...

>Using the Internet protocol

The problem here is not with the Italian Government it is with the people
that convinced them that a Timestamp was something new that they needed for
official document processing. This has nothing to do with Italians per se
except that they came to understand something that most of the world missed
in B2B style models. The fact that you took it as an insult as opposed to an
obersvation is almost amusing to me...

> yes, you are

Come on Steve - no comment on #3? except to the spelling of Tau tau.

> respect (from the ancient Mandarin).

OK the spelling issue - yes pardon me - I was using one of the Cantonese
forms of the phrase, and in the colloquiel manner. Something like 200 ways
to spell and say POT STICKER. You understand, eh?

> building protocols that are of value to the real world.

I just advocate that the world is ready for something more that Microsoft's
Fully Fledged, Development Enabled OS. That appliance computing is coming
and that it will soon take the place of many complex services. And that
becuase of what it is many of the OS Flaws that we spend so much time
working around will not be there.

>As noted

yes, so it seems.

> "transaction processing"

100% - All of it.

> of the sort that requires the
> non-repudiation facilities

that is currently unknown, but email and corporate email in particular may
soon need NR and testimonial capability. As far as other issues go, when the
privacy legislation comes on line and the DoJ gets up to speed with managing
slamming and spamming properly who knows maybe the answer is that this
number is going to get HUGE!!!

> that seem to be the focus of all your
> comments?

Depends on what the legal framework is for the country that this traffic is
passing through.

> If we eliminate all the informal e-mail, essentially all
> to extant laws, are acceptably well protected, ...

But Steve all of these are transactions. Just not ones of the Buy or Sell
type. Everytime that a request and a fulfillment is made a transaction
happens.

> Yes, the Internet

Ahahaha - You make the joke, No?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Apr 2002 18:04:49 -0400

>Why not Stephen?  NR is something that only a set of practices can

Your comment above makes no sense relative to my text immediately 
above. It's not a good use of my time, or of this mailing list, to 
continue with this thread.  And, as Hal observed, if you believe that 
100% of Internet traffic is "transaction processing," you are 
obviously imagining some other Internet, perhaps in some parallel 
universe ...

Steve