Subject: RE: SCVP-01

From: Carlisle Adams <[email-masked]>
Date: Wed, 1 Sep 1999 18:25:54 -0400

Hi Peter,

> ----------
> From: 	Peter Williams[SMTP:[email-masked]]
> Sent: 	Tuesday, August 31, 1999 9:54 AM
> To: 	Alan Lloyd
> Cc: 	[email-masked]
> Subject: 	RE: SCVP-01
 
(...some text deleted...)

> I was disappointed in the Microsoft message: ...
> 
> I was disappointed by the Novell message: ...
> 
> Carlisle's ambiguous message ...
 
What a depressing couple of days you must have had!  How in the world are
you still finding the motivation to get up in the morning?  :-)

> DCS. There was consideration of using DCS as the vehicle
> by which to introduce validation checking into PKIX: we
> were halted in our tracks when the authors required things be
> tied to the ISO NR framework.  Sensibly, Ambarish heeded the
> simplicity goal, and chose not to be tied to a heavy-weight
> concept.  
 
I just looked again at the (off-line) e-mails we exchanged a few months ago
regarding this topic.  Our objections had nothing whatsoever to do with
wanting DCS to be tied to the ISO NR framework.  You and Ambarish suggested
splitting DCS into a base document and multiple smaller documents that
provide details for particular services.  Rob and I thought that although
this sounds great in theory, in practice it tends to be confusing and
ultimately unproductive (and we cited CMP/CRMF/CMMF/CMC as an example that
would loom fresh in PKIX minds).  Our preference was to keep a single
document, essentially structured as-is with its reasonable extension
mechanism for future additional services.  Somehow you took this to mean
that DCS was tied to the non-repudiation framework in a leap of logic that
mystified me then and still mystifies me now.

In any case, our objection to splitting up DCS was not intended to "halt you
in your tracks" and force you to create a different protocol.

> We can recall, that DCS extension can
> easily wrap the SCVP ASN.1 info object and thereby incorporate
> the standard validation protocol into DCS, for the NR-grade
> certificate handling. Presumably, the NR requirements
> will add to SCVP requirements for remote path processing,
> as to-be-specified in the DCS draft.
 
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?

Carlisle.

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 1 Sep 1999 17:25:28 -0700

> framework" then DCS is a reasonable place to put the SCVP syntax and

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.