RE: SCVP-01

["Peter Williams" <peterw@xxxxxxxxxxxx>]

Carlisle:

> Are you suggesting that if, in fact, DCS is not "tied to the ISO NR
> framework" then DCS is a reasonable place to put the SCVP syntax and
> functionality?


I see it as perfectly reasonable for DCS to offer its
users a validation service. This is currently a side-effect,
and not the main purpose of DCS, however. 

If a DCS authority can perform path validation for its own 
ends, upon  whose outcome its signature is contingent,
then surely it can perform the same processing
as a service for other relying parties. This
logic was my original thinking in suggesting
and investigating a DCS linkup. 

Ambarish had a different perspective,
and asked if a conforming DCS client could be 
implemented in a week? As we could not break DCS up into
components, and believed that it was necessary to 
provide for NR-grade validation, things went another 
direction. It was taking longer to talk about
it then to implement it.

Specifying a wrapper in DCS to incorporate the
SCVP ASN.1 seems like a perfect match. SCVP
stands by itself, small and light, like OCSP. But it
can play a supporting role in DCS, for those
who implement and use DC authorities. DCS should
treat OCSP similarly, perhaps. DCS can act
as the feature aggregating service, for those who
want "comprehensive, full-service PKI" - to
use a marketing phrase. I'm not sure why
a small router would want to implement a
full-service layer 7 data certification suite, 
however. And this is why SCVP should be
both a reusable and stand alone component.
 
Regards,
Peter.