Please consider the following matching rules for certificates, based on the X.500 series. I would really like to see products developed that can invoke them (as client) and products developed that can retrieve them from the storage (as repository). I am not advocating this exact syntax, but something very similar would be extremely beneficial. Sandi >---------- >From: Stefan Santesson[SMTP:stefan@accurata.se] >Sent: Thursday, September 24, 1998 8:41 AM >To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com; >cert-talk@structuredarts.com >Subject: NEW Data type for certificate selection ? > >All, > >During the TLS session in Chicago (IETF meeting) I discussed with Jeff >Weinstein, Netscape, the problem of certificate selection in an environment >where the client is populated with many similar certificates for different >purposes. > >We concluded that this is a general problem, not only for TLS, but for >S/MIME, Java, Java script, etc, where signing and encryption based on an >X.509 PKI is an option. I also conclude that the current TLS approach, >using Issuer name as selection criteria, is hopelessly insufficient for the >general case. > >In fact we can NEVER claim that we have an X.509 based architecture ready >for the big market IF WE DON'T SOLVE THIS PROBLEM. > >A normal user (I.e grandmother) will never be able to pick the right >certificate by herself, if there is more than 1 to pick. > >The question raised here is: > >WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START. > >If we could create a standardized ASN.1 data type with the purpose of >defining the criteria for selecting 1 out of n certificates, then this >could be used as a common base for enhancing TLS, Java, Java script, S/MIME >etc. > >The data type could be communicated from server to client, client to >server, server to server, client to client; I.e in any case where one party >which to assist another party in selecting an appropriate certificate for >any purpose (defined by the context). > >Do anyone have a better idea. > >I think this is a lost problem that has to be fixed, hopefully in a >standardized way. > >Comments, suggestions. > >/Stefan Santesson >------------------------------------------------------------------- >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 >------------------------------------------------------------------- >
Attachment:
MATCH.DOC
Description: MS-Word document