RE: finding services : DCS, OCSP, Timestamping, ..

[Stephen Kent <kent@xxxxxxx>]

Alan,

Well, we may be getting closer, but I'm not completely sure.

>> I think we have to pay close attention to the specific services in
>> deciding
>> what constitutes a good way to find appropriate servers.  For
>> revocation, I
>> think the CA has an obligation to state how/where is makes revocation
>> data
>> available, because the CA is the ultimate authority for this data.
>> Thus,
>> for example, we can bind into each cert one or more CRL distribution
>> pointers. If a CA chooses to delegate that authority to some 3rd
>> party, it
>> needs to do so in a highly secure fashion.
>	[Alan Lloyd]
>	The X.500 CA related data structures do provide some of this.
>The  CA entry can have  its CRL DP  reference pointing to a directory
>entry of a third party that has the CRL DP with signed CRLs in. My usual
>point here is that it is easier to add a new data structures to a
>directory service to solve the prolem than hand config info objects with
>server knowledge all over the place.
>	I think the issue is that its back to the approach of hand
>crafted knowledge of where things are and configuring them into
>everything or using the naming/knowledge/authentication/ACI regimes of
>directory services and appyling these in the CA issuer/subject and CRL
>DP objects.
>
>	The directory service provides exactly that - named items in  a
>distributed environment. So why try to emulate that service in data
>structures with manual effort.

I'm confused by this example. If I attack the directory and change the CRL
pointer to a different entry, this would be a serious security problem,
unless the CRL in the other entry is signed by the CA.  If so, then what
difference does it make in which entry it is stored?  Is your suggestion
that the layer of indirection provided by the directory is important, even
if the CRL is signed by the same entity in any case?

>
>> One could include a set of OCSP
>> server pointers, which would permit a more robust mechanism, though at
>> the
>> cost of cert size growth.
>>
>> For a directory system to provide a highly secure way to discover such
>> delegation, I think we must have some way for a CA to post a signed,
>> dated,
>> attestation that provides the equivalent info.  We currently have no
>> structure for such data.  Also, there is a potential performance
>> tradeoff
>> here as well, i.e., use of a directory server seems to add another
>> level of
>> indirection to the process, thus requiring more network accesses, ...
>	[Alan Lloyd]  Dont think of the directory as a server, but as a
>distributed service. If things are all over the place then by definition
>the network traffic through a directory service will be the similar or
>less than the client making the same requests to independent items. Its
>just that with the directory service, the directory service has the
>distribution mechanisms and knowledge all built in. And in this case all
>the client does is access the single interface of the directory service
>with requests for named items. Whereas with the client identifying with
>bits of config info from many data structures (eg. like the WEB mode of
>working), just means that all such structures are hand configured and
>the client has many connections to retrieve all these fragments. And in
>addition, each time the client connects to these fragmented servers, it
>has to authenticate itself. Yet more hand crafted configuration,
>replicated passwords and/or and key management.
>	Ie. The latter model is more complex, key management starts to
>get N*N, its harder to manage and has more network traffic and
>interaction from the clients perspective.

We certainly disagree here.  Nothing in the example I described changes the
key management to an order N**2 problem, from an order N problem. We
certainly are NOT introducing passwords into these systems; we are trying
to replace them with certificates.  I still don't see how the number of
transactions does not grow as a result of putting more data into the
directory.  Your comment is rather vague on this point; perhaps the intent
is to say that "if we distribute all of the admin data need to communicate,
then  what's a few more items?"  I understand that analysis, and might
agree with it in general.  But, if we pursue that path, we will definately
create a more fragile system, by requiring a greater number of directory
accesses and requiring that the directory services be highly available.  I
think your point is that this is a good tradeoff if it results in an easier
to manage system, overall.  Here too I think we need to look at specific
cases; sometimes the tradeoff may be appropriate, but in other cases we may
be creating unacceptably fragile systems.  Maybe my work on the Trust in
Cyberspace report for the NRC over the last 2 years has heightened my
concerns over fragile infrastructures :-).


>
>	As a bit of an after thought and thinking about OCSP-directory
>integration. In a multi domain environment where domain a users send a
>signed transaction to users in domain b. And domain A uses convetional
>CA/CRL processes for its own validation , but domain B choses to use
>OSCP validation processes, the certificate server configuration approach
>will have problems. The point is that a user or a CA in one domain may
>not know or care (at that level) the validation techniques of another
>domain as this will be a system design and policy issue.
>	It would be very hard for a CA issuer in any domain to foresee
>where the cert would be propageted to and what servers (and the server
>configs and mechanisms) it would be validated on. Naturally very small
>systems dont have this issue.

Validation for certificates is a standard process, codified in X.509 and
PKIX. It is not a purely local policy matter.  Local policy comes into play
with regard to how to make use of the data extracted from the certificate.
Also, some aspects of the validation process are under the control of the
CA issuing the certificate being validated, e.g., marking extensions with a
critical bit or choosing to use CRLs vs. OCSP.

>	I still quite like that the approach that a receiving client of
>a cert, presents it to its "local" validation process (via OCSP) and
>that server, can off load that to other OCSP validation servers if it is
>necessary -  and these OCSP servers use the distributed information
>services of the directory to find CRLs or validation items or references
>to where CRLs might live. ie the business policy for within domains and
>between domains is engineered as directory information objects (signed
>or otherwise) according to trust requirements.

Here is where we disagree again, though I appreciate the attraction this
holds. As I noted some time ago, if one offloads all of the validation
process, in order to construct a very thin client, then the opportunities
for subverting validation for a potentially large number of subscribers is
greatly increased. The local validation server becomes a prime tagret for a
wide range fo attacks, and its required high availability makes denial of
service an even greater concern.  With cacheing and normal, client
validation capabilities, an inability to access a directory for a CRL may
be an annoyance, but may not be fatal in many instances.  However, if one
pushes off all of the processing, ...

Steve