[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-------------------------------------------------------------------