let's clarify what is CA from the user's point of view. i *did* install certificates in a test scenario, so my self signed openssl setup is without doubt CA to the users - no matter if it verifies up to the root chain.
the point is i don't want certs in *my* keystore with CN="joro the terrorist" signed by whatever CA - FYI i trust the root CAs as much as i trust viagra spammers. about the weak key: the idea is to force a <keygen> to generate weak key that is sent to attacker. the attacker cracks the private key by only using the public key and returns self signed cert to the luser - the luser doesn't realize this. On Tue, Jun 02, 2009 at 10:31:21AM +0200, Anders Rundgren wrote: > 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
