A genuine problem is that <keygen> and its cousins cannot actually tell the CA if the key is stored on the hard-disk or on a smart card and if there is PIN protection etc. From a practical point-of-view this means that smart cards are out-of-scope for <keygen>.
Real card provisioning systems therefore typically cost $10 000 and up and mostly only run on Windows. They usually come with professional services as well :-) Now, over to your concerns.... >the standard should make it clear how the signed response is handled. Yes. >currently, after you visit a malicious page the only thing you see is: >"your certificate is installed [OK]" >the certificate can be issued to whatever name the attacker choses. >if an attacker can force a weak private key which is later broken, it >can be self signed and stored on the poor user's machine - this is not >much fun anymore. I think you need to analyze this a bit more. It is the RP (relying party) that trusts the certificate and the CA who issues it. If the key is weak (short?) the CA (who has a policy) will presumably reject the request. If the key is self-signed the RP will reject it (unless it is S/MIME which is very difficult to deal with anyway since you need to "trust" an infinite number of CAs but that's not a <keygen> issue). >i think the standard should write something like: >after receiving the certificate, the user must be given an option to >examine it and to ignore it. The user should IMO have an option to abort a key generation request because such opens for (pretty lame) attacks on key db space. The rest is in the hands of RPs and CAs. CAs that produce bogus certificates do not constitute of a threat to end-users but maybe to RPs but that's out-of-scope for most users. It is similar to credit-cards; you don't have to verify the validity of your VISA card, that's an issue for merchants and payment networks. If users want to study certificates, the existing browser GUIs already offer this option. If you pay money for a bogus certificate that's bad but unfortunately PKI is far too complex for human verification so there is no cure. It is BTW no different to buying anything else on the Internet. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
