Re: operational protocols

[Mike Smith <[e-mail]>]

In the thread, some mention "agreements", "legally binding", "contractual relationship" -- These would need user authentication to enforce (charge for) the service agreement.  I realize that this thread is really discussing X.500 with unathenticated access assumed, but the business models become difficult outside a "private" or no-Trusted-Third-Party relationship.

With charging the certificate holder for access and not the entity accessing, then anyone can freely duplicate the contents of the directory for their own service.  Or, if the subscriber (owner of cert) has paid for "x" number of accesses (especially if their is a "reliance limit" or value associated with a cert or it useage) then a (potentially expensive) denial of service attack would be easily and anonymously available to even the most unsophisticated user.

By providing a free CIL to any and all, one then gives away their customer list (searching for individual certs is another matter).

I firmly believe that the only way certs will become accepted is if there exists explicit trust in the complete cert system -- especially across the public networks.  This requires knowing who your users are and what contractual obligations you have to that user.

Yes, I'm in the business of building repository services that require user authentication, but feel that I would build a system that requires authentication anyway.

Also, X.500 was to be just one of the directory options in PKIX.
Repositories, publication authorities, LDAP directories and more will be seen.  The strongest business model, IMHO, will survive (maybe that is a fully subsidized freely accessible anonymous access model, but I doubt that).

Michael

>>> David Boyce <[e-mail]> 04/07/97 05:01AM >>>
Stef Hoeben writes:
>
>Russ:
>
>> I do not see how the CIL can be usefully used as a certificate
>> extension.
>> Please provide a more detailed explaination.
>
>Normally, a CA gives its certs and CRL to a Directory, which is
>normally no _Trusted_ Third Party. Because the certs and CRL are
>signed by the CA, the Directory can't mess these up. But the
>Directory can answer on a request for a certificate: 'I don't have
>it, the CA never issued it'

[ My comments are being made from an X.500 point of view.  In order to 
understand where Stef is coming from, it is a good idea to read Silvio 
Micali's paper he referred to previously.  

An understated presumption is that the user has some kind of legal 
contract with the Directory to be supplied with certificate 
information, which places a duty on the Directory to justify its 
responses.  This seems dubious in the general case, although perhaps 
individual exceptions may be desirable. DJB]

There may be any number of reasons (insufficient access being just one 
of them) why a Directory might not return a certificate, and it doesn't 
even have to tell you why.  It doesn't have to be interpreted as a 
denial of service attack.

>So if a Directory really doesn't have a certificate, it must prove
>it to the user.

I don't see why, without some special contractual requirement.  This is 
an administrative issue.

> This can be done by the CIL: a list with the serial
>numbers (or other ID's) of all certificates the CA has given to the
>Directory, and this list must be signed by the CA.
>So if a user requests a cert which the Directory didn't have, the
>Directory _must_ give the CIL which the user can check so verify
>the requested cert isn't in the CIL.

This cannot be enforced.  Attribute substitution of this kind is not 
part of DAP or LDAP (the concept of attribute type hierarchy is an 
exception, although unlikely to apply in this case).

The user, on failing to obtain a cert, might then request a CIL, 
perhaps from some other entry;  but the Directory may still decline to 
supply one.

>=> The only problem looks: how to tell the users they will get a
>   CIL instead of a 'I don't have that cert' if they ask for a
>   non-existing cert.
>   I don't think you can put it in a private extension of the
>   certficate, because that's exactly what a nasty Directory
>   won't give...

Depends on what level you are viewing the 'user' from;  at the DAP or 
LDAP level, the user can request either or both of the cert and CIL, 
and the Directory may or may not decide to supply them;  but if 
supplied they are separate attributes.  The application may of course 
translate this into more 'user-friendly' information subsequently.

>> How is LDAP different than any other access to a certificate and CRL 
>> repository?  I do not see what makes the CIL important in the LDAP 
>> environment more than any other environment (like FTP or full DAP).
>
>Oops, mistake: LDAP isn't different. It's the same for the other
>protocols. Sorry for the confusion.

Indeed it is the same.

>> Also, does the use of distributed, replicated Directories help solve 
your 
>> concern? If not, how about the use of more than one distriution 
mechanism, 
>> say FTP and LDAP.
>
>You mean some independent directories with the same info? Sure, that 
would
>help, but isn't that expensive and impractical in most cases?

I think he means multiple Directory System Agents holding copies of the 
same information, which is part of the standard X.500 model.  

(This would mean that the same certificate in the same entry could be 
held on multiple servers.)

However, the issue at the heart of the question remains one of the user 
wanting to establish a legally-binding requirement of service on the 
Directory, which is quite a different matter.  I don't see that CILs 
solve this either - if the Directory refuses to provide certs, why 
should it provide CILs?

David.

-- 
David Boyce

Tel:	[phone]		Richmond, Surrey, ENGLAND
I'net:	[e-mail]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;