The client-side processing of digital signatures is the major problem, I think. And the main barrier against the adoption of PKI. Key stores are far from a standardization. CryptoAPI, CNG, Mozilla, JAVA KS, CSP, PKCS#11, etc.
Bruno de Paula Ribeiro Analista de Sistemas (11) 4501 1886 Certisign Certificadora Digital certisign.com.br -----Mensagem original----- De: dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org [mailto:dev-tech-crypto-bounces+bribeiro=certisign.com...@lists.mozilla.org] Em nome de Anders Rundgren Enviada em: terça-feira, 10 de fevereiro de 2009 17:39 Para: mozilla's crypto code discussion list Assunto: Re: Application of client certificates on a US government website Nelson B Bolyard wrote: >>Kyle Hamilton wrote >> Hey, I just ran into the first application of client certificate >> authentication requirement on a public US government website that I've >> seen. <snip> >I played with it a bit. >As far as I can tell, it is not doing SSL client authentication, per se', >at least not using the browser's built-in SSL client auth capabilities. >The page https://sas.uspto.gov/authenticate/AuthenticateUserLocalEPF.html >downloads some Javascript which in turn downloads a Java applet named >EntrustTruePassClient. This looks for a file on your local disk with >a file name ending in .epf. The page says: >> NOTE : DIGITAL CERTIFICATES provided by USPTO have a file name that ends in ".epf". >I gather that it also contains your private key. What it does, exactly, >after that is unknown to me. I lost interest after seeing that it's not >doing SSL client auth. You are probably right. May I as a person living in a country where at least 20% of the adult population use "soft certificates" for on-line banking and e-government services provide some facts why this situation is far from being unique? Soft certificates may be a piece of junk but they are at least available. However, provisioning of soft certificates is close to N/A since there is no standard and the stuff that's available is below any reasonable quality; you cannot even set a PIN policy, not to mention how different these schemes appear to users! In Safari the user will have to select between medium or strong keys and in Vista/IE you must typically put the issuer in the trusted site-list in order to get a ActiveX control to work. Therefore Java applets is a good choice since it make authentication an application, taking care of the missing pieces, policy and provisioning and it works in most browsers and OSes. In case you feel that this is not what you want, may I suggest that we start by identifying what's lacking and see if there is any way we could fix it? Regards Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
