RE: Unsigned DPD responses for SCVP15

[Russ Housley <housley@xxxxxxxxxxxx>]

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