Re: NEW Data type for certificate selection ?

["$B5HIp!!=_(B " <yositake@xxxxxxxxxxxxxxxxxxx>]

I have two comments.
(B
(B1. I'd like to clarify the scope.
(B
(BIs it limited to the case where one party
(Bwhich to assist another party ?
(BI suggest that it include the case
(Bwhere a person has multiple certificates
(Bin his / her PC, WS, etc. It will be more
(Buseful and more efficient if there is
(Ba standardized mechanism for the case
(Blike this rather than that each application
(Bmanages its certificates in its own way
(Bon one machine. Some applications could
(Bhold a certificate in common.
(B
(B
(B2. It would be better that we consider
(Bthe generation management of a certificate.
(B
(BSuppose a certificate has expired and you
(Bget the new certificate on your PC. Namely,
(Byou have two certificates on your PC, the old
(Bone and the new one. Attention should be paid
(Bnot to let an application select the old one.
(B(Of course, things are easy if the old one is deleted.
(BBut is it really always good for all the cases, all applications,...?)
(B(Issuer and Serial Number is nice, but you need
(Bthe mechanism to record "this serial number is for
(Bthe new one" when you get it for the first time.)
(B
(B
(BJun Yoshitake
(BMitsubishi Electric Corp.
(B
(B
(BStefan Santesson wrote:
(B
(B> All,
(B>
(B> During the TLS session in Chicago (IETF meeting) I discussed with Jeff
(B> Weinstein, Netscape, the problem of certificate selection in an environment
(B> where the client is populated with many similar certificates for different
(B> purposes.
(B>
(B> We concluded that this is a general problem, not only for TLS, but for
(B> S/MIME, Java, Java script, etc, where signing and encryption based on an
(B> X.509 PKI is an option. I also conclude that the current TLS approach,
(B> using Issuer name as selection criteria, is hopelessly insufficient for the
(B> general case.
(B>
(B> In fact we can NEVER claim that we have an X.509 based architecture ready
(B> for the big market IF WE DON'T SOLVE THIS PROBLEM.
(B>
(B> A normal user (I.e grandmother) will never be able to pick the right
(B> certificate by herself, if there is more than 1 to pick.
(B>
(B> The question raised here is:
(B>
(B> WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START.
(B>
(B> If we could create a standardized ASN.1 data type with the purpose of
(B> defining the criteria for selecting 1 out of n certificates, then this
(B> could be used as a common base for enhancing TLS, Java, Java script, S/MIME
(B> etc.
(B>
(B> The data type could be communicated from server to client, client to
(B> server, server to server, client to client; I.e in any case where one party
(B> which to assist another party in selecting an appropriate certificate for
(B> any purpose (defined by the context).
(B>
(B> Do anyone have a better idea.
(B>
(B> I think this is a lost problem that has to be fixed, hopefully in a
(B> standardized way.
(B>
(B> Comments, suggestions.
(B>
(B> /Stefan Santesson
(B> -------------------------------------------------------------------
(B> Stefan Santesson                <stefan@accurata.se>
(B> Accurata Systems$BgL(Berhet AB
(B> Lotsgatan 27 D                  Tel. +46-40 152211
(B> 216 42  Malm$Bö (B                  Fax. +46-40 150790
(B> Sweden                        Mobile +46-70 5247799
(B>
(B> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
(B> -------------------------------------------------------------------