RE: Unsigned DPD responses for SCVP15

["Michael Myers" <mmyers@xxxxxxxxx>]

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