Kyle Hamilton wrote, On 2009-02-09 18:29: > Hey, I just ran into the first application of client certificate > authentication requirement on a public US government website that I've > seen. > > [link] https://sportal.uspto.gov/secure/portal/efs-unregistered > [/link] has information on the "unregistered submission" process, but > it also strongly encourages people to register. The information on > the "PAIR" system they have indicates that the private, > not-yet-submitted information will only be accessed or accepted if the > client computer authenticates via certificate, as well. > > (I don't yet know details about their hierarchy. I'm working on it, > though. However, I think that it's extremely likely that they're > using a private-label CA for the certificate issuance.) > > Personally, I think this is a huge step forward. While it's still a > niche market, the fact that a US government organization is willing to > do this suggests that others might in the future. (I'm thinking I'd > eventually like to see this with the Internal Revenue Service. ;) )
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
