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

RE: Unsigned DPD responses for SCVP15


Mike,

Why delay to San Diego?

Really, it makes no sense to require a DPV client to be capable of asserting a flag that will incur a response it cannot hope to process!!! That is the result if a client that does not implement path validation asserts that flag!

I strongly believe that:

(1) some clients will be DPV-only since they will not include an X.509 path validation module, and need not implement the flag at all;

(2) some clients will be designed for unsigned DPD only, and will be hard-wired to assert the flag; and

(3) some clients will support unsigned DPD as well asat least one of (a) signed DPD and (b) DPV, and will need to implement flag and provide configuration

Let's forward a spec that reflects this reality.

Tim

At 03:14 PM 7/15/2004 -0700, Michael Myers wrote:
Russ,

Seems a matter for San Diego at this point.

Mike

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Russ Housley
Sent: Wednesday, July 14, 2004 2:10 PM
To: Michael Myers; Tim Polk; ietf-pkix@xxxxxxx
Subject: RE: Unsigned DPD responses for SCVP15



Mike:

Recently, I have done a fair amount of work in the wireless space, and I
am
convinced that clients on these devices with limited processing
capabilities will make use of DPV.  So, maybe what we need is a profile
at
the end of the document that lists the features that must be implemented
to
be considered a DPV client, a DPV server, a DPD client, and a DPD
server.  This should be pretty easy to put together, although I doubt
that
it can be done before the draft deadline for the San Diego meeting.

Russ

At 04:03 PM 7/14/2004, Michael Myers wrote:
>I'm not sure that can be predicted to such a degree.
>
>When Carlisle Adams, Stephen Farrell and I first addressed introduced
>DPV and DPD to the WG, it was Stephen who was forceful in convincing
>Carlisle and I that one of the most difficult issues wrt PKI was simply
>acquiring the data necessary to path validation.  This was due in no
>small part to the various protocols and schemas associated with that
>process, as now amply documented in 3379.  Further, a "client" is not
>just, for example, a web browser.  It could be amalgamation of back
>office mechanisms, AAA, Radius and what have you.  I suspect there
might
>come to exist a non-trivial number of such instances.
>
>Also, are you saying that in your view an SCVP client is compliant if
it
>fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
>id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
>syntax?
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
>Sent: Wednesday, July 14, 2004 12:37 PM
>To: Michael Myers; Tim Polk; ietf-pkix@xxxxxxx
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>I do not accept your assumption.  I expect many clients to be DPV-only.
>
>Russ
>
>At 03:31 PM 7/14/2004, Michael Myers wrote:
> >True, SCVP clients that assert the OID that drives a server to
produce
>a
> >validity assertion MUST accept and process a signature.  But assuming
> >that same client is also implemented to assert simply a return of
>{path,
> >rev-info}, then it seems reasonable to assume it should also be
capable
> >of asserting the flag.
> >
> >
> >Mike