RE: certificate path services [ was RE: NEW Data type for certificate selection ? ]

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

IMHO This issue is not solved with YAP - yet another protocol, .....As
these create yet more complexity, scaling issues, knowledge and
addressing issues when building a system ..

Why is OCSP and yet another being promoted - as they seem to solve
nothing. - and what they do is add yet more implementation problems.
The issue of CA info/ client validation is one of (object - directory
style) information, information management, system knowledge and dealing
with a name based distributed environment. The protocol , semantics and
syntax of the information transfer and testing of all this can all be
dealt with quite naturally by directory services.

So unless OCSP or cert server protocol specs can define the information
model (in named distributed objects) for CAs, multiple paths, and the
validation process that clients need .. then what to they solve.

regards alan


> -----Original Message-----
> From:	Carlisle Adams [SMTP:carlisle.adams@entrust.com]
> Sent:	Friday, 16 October 1998 1:50
> To:	'Alan Lloyd'; 'Sarbari Gupta'
> Cc:	'ietf-pkix@imc.org '
> Subject:	RE: certificate path services [ was RE: NEW Data type
> for certificate selection ? ]
> 
> Hi Sarbari,
> 
> > ----------
> > From: 	Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> > Sent: 	Thursday, October 15, 1998 10:46 AM
> > To: 	'Alan Lloyd'
> > Cc: 	'ietf-pkix@imc.org '
> > Subject: 	certificate path services [ was RE: NEW Data type for
> > certificate selection ? ]
> > 
> > I seem to agree with Alan that there are certain situations where it
> > would be very beneficial to have third-party services available to
> > assist with certificate path development and/or validation. 
> > 
> > If (and when) large scale PKIs become widely deployed, it could
> become
> > a
> > real problem for each end entity to look up and then validate the
> > certificate path to its peer's certificate. It requires a large
> amount
> > of processing power as well as complicated path processing software
> to
> > do this task. Additionally, it requires repeated interactions with a
> > remote Directory Server to build the certificate path.
> > 
> > There are (at least) two ways to resolve this issue:
> > 
> > 1) We introduce the concept of a trusted service, let's call it
> > "Certificate Path Validation Service (CPVS)" which could take in
> > requests for validation (comprising the end entity certificate and
> > possibly a trusted root, policy IDs, etc.) and return an YES/NO
> > answer.
> > The  CPVS could be hosted on a high-end server that caches recent
> > requests and has the capability to interface with
> > Directories/Repositories over the internet to quickly obtain an
> answer
> > for the subscriber, thus relieving the end entity system from the
> > overhead of certificate path processing. The CPVS would also support
> > revocation models. The CPVS would be particularly useful in an
> > organizational environment, where a single dedicated system runs the
> > CPVS for that organization and services path validation requests for
> > other users within the organization. To support the notion of a CPVS
> > service, a new service interface needs to be defined and
> standardized.
> > 
> > 
> This is precisely one of the services specified in the Data
> Certification Server protocol.  Please take a look at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
> (recently re-introduced into the PKIX Working Group) and let me know
> if
> this meets the functionality you had in mind.
> 
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> cadams@entrust.com
> --------------------------------------------
>