[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NEW Data type for certificate selection ?
Thank you Sue,
This looks very useful. I could think of some enhancements, but since
this is standard it's a very good way to start.
Could you elaborate how the certificate mach rule could be invoked into a
protocoll.
Would it just be for the entity suggesting use of a certain type of
certificate to communicate one (or a SEQUECE OF) CertificateAssertion data
value(s)?
If this is so, then all we have to do is to have this included in various
protocolls and convince Microsoft, Netscape etc, to allow certificate
selection using this maching rule.
If we could achieve this then I think it would be a giant step in the right
direction.
What does Microsoft and Netscape say about this ???
Comments, suggestions!
/Stefan Santesson
At 12:02 PM 9/24/98 -0400, Miklos, Sue A. wrote:
>
>
>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 Converted: "c:\internet\eudora\attach\MATCH2.DOC"
>
-------------------------------------------------------------------
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
-------------------------------------------------------------------