[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NEW Data type for certificate selection ?
Sob story introduction - still on the road in the UK now - and flat chat
with the upswing in big X.500 systems and PKIs from every point on the
compass. So the details below may have been skipped...
anyway.
I always thought that the matching rules for certs and crls as defined
in X.509 were like other matching rules in that objects/attrs of
particular types can be searched for and managed whilst in the directory
system.
The issues is that the PKI /CA design has been designed as a set of
"sort of related objects, but operationally there are multipaths and
multi domains.. so we have an information relationship and managment
issue (in an originators domain).. and in some form, knowledge of this
"environment" must be propagated to the recipient of signed message with
a cert - so that efficient validation can occur.
The matching rule system is a mechanism for finding what one wants and
it can be configured with the desired values - ie knowledge (not
knowledge as per DSA access point knowledge) english meaning.
It strikes me that this knowledge (and the certficate)of the originating
domain should be transferred to the recipient domain and this knowledge
supplimented by the recipient - where appropriate - and this applied
through the matching rule mechanism into the directory system to achieve
validation.
the draft I submitted - draft-lloyd-dir-cert-stat starts the
validation/matching rule direction off. And in fact permits orgainised
knowledge of validity - which is maintained by a CA..
Any way please read.
Its an information management and knowledge issue associated with
CA/directory systems we are dealing with - it wont be fixed by more
attributes on certficates and more protocols like OCSP.
thoughts are welcome
regards alan
----------
From: Stefan Santesson
To: Dave Horvath
Cc: Alan Lloyd; 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com ';
'pgut001@cs.auckland.ac.nz '
Sent: 10/1/98 8:53:52 AM
Subject: Re: NEW Data type for certificate selection ?
Dave, (Sorry for misspelling your name before)
I really do agree with you, sticking with the X.500 matching rules makes
it
possible to link a certificate select from a local application to a
suitable directory.
Say that the client certificates is stored in a directory and not in the
client application (or any mix). When receiving the match rule from the
server it would then be very easy to use the same match data to perform
an
extended lookup in the directory.
The question is now, Should this be worked on in IETF ?
Is there enough interest in getting this done and implemented?
Steve and Warwick, what do you say? Is this something for PKIX?
Unfortunately I just represent some of those service providers who need
this to be done, I will not be implementing this myself. Personally I
can
just predict better business for all if we solve this.
/Stefan
At 01:20 PM 9/30/98 -0400, Dave Horvath wrote:
>Stefan,
>
>Agreed, particularly on the point of not creating any new extensions.
>
>I would add that I firmly believe the matching rule mechanisms should
be
>compatible with the work being done in X.500 and LDAP. I would also
like to
>see X.500 and LDAP join forces and be compatible in the area of
matching
rules,
>I am not sure where LDAP stands at this time.
>
>
>Dave Horvath
>
>Stefan Santesson wrote:
>>
>> David,
>>
>> Thank's for putting this issue in the right focus.
>>
>> Alan, I don't suggest any new certificate extensions
>> Ed, I don't want to define any universal criteria for how certificate
>> selection SHALL be done or any who decides what for whom,
regulations.
>>
>> All I want to do is to define some mechanisms that CAN be used, if
>> required, by local PKI-related services in order to make it POSSIBLE
for
>> them to build working services with STANDARD components.
>>
>> Let me highlight this again and describe a realistic problem relevant
to
me.
>>
>> Bank A offer web-based banking applications. This requires the end
user to
>> get a specific certificate issued by Bank A. The certificate and the
>> corresponding private key is processed through the standard web
browser of
>> the client.
>>
>> Two certificates and private keys are used in the normal process.
>> 1) Certificate for SSL (TLS) security
>> 2) Certificate for non-repudiation protection of Bank transactions.
>>
>> In addition to these certificates, a specific end-user may be
populated
>> with several other certificates, un-known to the Bank.
>>
>> The question is. How can this Bank create a web based application
without
>> distributing a customized client plug-in for the purpose. Well the
Bank can
>> get far using Java Scripts but it will fail due to the problem that
the
>> end-user may have to select a certificate.
>> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK
APPLICATION.
>>
>> I realize that today there is no way to do this without distributing
>> customized plug-in components to end-users, but I strongly would like
to se
>> options developed that helps getting around this. The current
matching
>> mechanism in SSL and TLS is just not good enough to solve the
problem.
>>
>> So If we instead had a standardized matching rule that could be
invoked
>> into protocols and Java Scripts etc, then the situation would be much
more
>> hopeful for the Bank in my case.
>>
>> They would then construct a match rule that with high probability
would
>> point out the right end-user certificate and invoke that matching
rule both
>> in the TLS protocol and in the Java Script, forming their secure
>> transaction application.
>>
>> It wouldn't have to be perfect, just good enough to handle some 95%+
of the
>> cases as long as the Bank could detect cases where it didn't work.
Then the
>> non-working cases could be fixed by personal customer service.
>>
>> I see even more use for this matching rule. It could be used in
S/MIME so
>> specify a preferred encryption certificate for replies to a mail. Of
course
>> this matching rule could be used for X.500 directories as well
(that's what
>> it was built for). MY concern here is however not _where_ the
certificates
>> are stored but, how to select 1 of several known certificates
regardless of
>> where they reside.
>>
>> Comments?
>> How do wee proceed ?
>> Could we have any comments from Microsoft and Netscape ?
>>
>> /Stefan
>>
>> At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>> >--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>> >
>> >Alan,
>> >
>> >While I personally agree that X.500 provides a mature and feature
rich
>> >core to implement certificate repositories, I am having trouble
>> >understanding some of your assertions as to why X.500 is the answer
to
>> >so many problems.
>> >
>> >It seems to me that the first step for locating certificates in a
>> >repository is to define the fields in the certificate object that
are a
>> >prerequisite to perform the match. Matching rules are a good start
and
>> >foster the thought process required to provide a well designed
solution.
>> >Once the matching rules are defined, a protocol such as DAP or LDAP
V3
>> >with extensions may be used to exploit the matching rules. In some
>> >cases, clients may choose not to use the matching rules and retrieve
all
>> >certificates. Perhaps matching rules are not supported by the
protocol
>> >(LDAP V2 or HTTP), therefore the client will collect all the
>> >certificates and perform the match locally. This may be even more
>> >efficient than submitting multiple searches with different
variations of
>> >matching rules. It could easily be more efficient to submit one
search
>> >and retrieve 10 certificates, then to submit 3 searches with
different
>> >matching rules each time until the required certificate is found.
This
>> >should be defined by local policies based on performance analysis.
>> >
>> >Once the rules for matching certificates are defined ( and I think
X.500
>> >matching rules are an excellent start ) the distribution model can
be
>> >analyzed. This is another case where X.500 may be superior to LDAP,
but
>> >unless you have a well planned global infrastructure neither X.500
or
>> >LDAP can help with the distribution model.
>> >
>> >Dave Horvath
>> >
>> >Alan Lloyd wrote:
>> >>
>> >>
>> >> Snip
>> >>
>> >> ----------
>> >> From: pgut001@cs.auckland.ac.nz
>> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> >> list@seis.nc-forum.com
>> >> Sent: 9/29/98 1:01:30 PM
>> >> Subject: Re: NEW Data type for certificate selection ?
>> >>
>> >> Peter - you went through great lenghts to define the problem with
>> >> relationships between and searching directory based objects and a
>> >> distributed information issue and then you say:
>> >> "
>> >> If anyone has any useful solutions for this (apart from "We
should
>> >> force
>> >> everyone to use an X.500 directory, that would solve everything"
:-) I'd
>> >> be interested in hearing them.
>> >>
>> >> "
>> >> Oh well - that counts me out. I cannot do solutions - without the
>> >> solution :-)))
>> >> regards alan
>> >>
>> >> Peter.
>> >>
>> >
>> >
>> >----------------- SEIS mailing list (list@seis.nc-forum.com)
>> >Info about this list: http://www.nc-forum.com/seis
>> >SEIS Contact: info@seis.se
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson <stefan@accurata.se>
>> Accurata Systemsäkerhet AB
>> Lotsgatan 27 D Tel. +46-40 152211
>> 216 42 Malmö Fax. +46-40 150790
>> Sweden Mobile +46-70 5247799
>>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>--
> ================================================
>
> _/_/_/ David J. Horvath
> _/ _/
> _/ _/ Chromatix, Inc.
> _/ _/ _/ 10451 Twin Rivers Road, Suite 265
>_/ _/_/ Columbia, MD 21044
> _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com
> _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------