Anders Rundgren wrote: >> And in opposite to you IMO it's more the user's interest to use a secure >> key store. > > So you mean that banks and governments run their eID/PIV programs > because their customers and citizens have asked for it?
Yes, here in Germany people do care about security of on-line banking. Government failed to provide good services (and still fails despite some buzz coming recently through the news.) >> Furthermore I don't see a reason why there can't be an additional HTML >> attribute for <keygen> which lists the names of acceptable PKCS#11 >> and/or CAPI key stores. > > You mean that issuers must know the name of their client's cryptographic > drivers? Yes. The overall security does not only depend on whether a private key is stored on a smartcard or not. It also depends on how the smartcard drivers interacts with the key store. > You mean that consumers should understand this? More or less. Depends on the enrollment and the provisions the CA makes. Note that you can already mandate with XENROLL.DLL which CAPI key store to use without the user noticing it. > You mean that issuers in spite of having a "standard-to-be" method like > <keygen> > *still* must know if client's are on msie, firefox, mac etc? No. My idea would be to have a namespace for key stores registered with IANA which could be used in a multi-valued attribute in <keygen> to specify the acceptable key stores during enrollment. >> I'd vote against an abstract "smartcard bit" or "HSM bit" anyway. > > Me too since this thing is not resistant to malware and thus is no guarantee. > >> If a CA wants to make a provision about which key >> store to use it should explicitly specify acceptable key stores by name. >> Because these names e.g. registered with IANA can be explicitly written >> into a CPS. > > "Microsoft Enhanced Cryptographic Service Provider" is registered by IANA? No, it's not. It could be though. > Don't take it personal, Don't worry, I won't. ;-) > but browser-PKI is totally lame. It is a 15-year old > Netscape "hack" that is since long overdue. Well, I still disagree. And if you want a really detailed client-side smartcard provisiong you could already implement this with a Java applet doing exactly what you want. <keygen> is not one of the main problems. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto