[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NEW Data type for certificate selection ?
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