Thanx for the super quick response! c-i-l "Nelson B" wrote: >> I created a certificate path consisting of root CA, sub CA and EE cert and >> put it in a PKCS 12 file including the private key to the EE cert. >> >> When I import it in MSIE 6 I get the question if I want to install the root >> CA. >> >> In FF I don't get any question about that and the root is indeed installed as >> well.
>Just installed? Or installed and marked trusted? <snip> >To see if a cert is trusted (in FF's cert manager) you must go to the >"edit trust" page for that cert and look at the trust check boxes. You were quite right. It was NOT trusted. Conclusion: IE and FF are entirely different in this respect which certainly is not making things simpler. That does not mean that IE is right or the opposite :-| >> In principle I don't think that a EE certificate or yours (including path) >> has anything to do with your trusted parties. That the root was supplied >> could be due to the fact that it may be a good idea to supply the entire >> path, at least to new contacts. >>Well, it's certainly disingenuous to expect others to trust a CA cert to >>validate your EE cert, when you yourself do not trust that CA cert. Have you ever tried that phrase on consumers? They don't know what a CA is and I hope they never will. Note. I'm not talking about S/MIME because S/MIME is a marginal technology that has no validity whatsoever in the consumer space. >NSS separates trust by usage. A cert may be separately trusted for SSL >server use, for SSL client auth use, for SMIME use, and for code/object >signing use. OK, sound good. >> That signText required the EE cert to be trusted as reported before is IMO a >> clear bug. There can be no *requirements* for having any CA certs because >> that is a relying party issue. >On the contrary. When generating a signature, the user wants to be assured >that the recipient will be able to verify the signature. This is quite different to how most similar software work. Commercial signature software for browsers, usually filter EE certs because that is the only thing need for on-line signatures. If the relying party does not *immediately* recognize the EE cert or the signature is broken, it will puke on the signature in the same way as for SSL client-auth. e-mail is something rather different but the requirement you are mentioning is not universally implemented AFAIK. To make it even more "fun" there are quite a few CAs that consider their root as secret. You have to *pay* to get see it. I don't say that this is good or so but it is important to know that on-line is an entirely different thing than off-line because in on-line signature scenarios users do not have to verify or trust anything but SSL server certs. >> In the US Higher Education PKI TAG they are reportedly working with Mozilla >> to change a related thing which they claim is a bug. >I'm not aware of any such request from those folks. >Maybe they've make this request more-or-less anonymously. >Can you/they cite a bug number? All bugs/RFEs are recorded in bugzilla. >We don't keep bugs/RFEs "off the books". I will transfer this information back so that they do it properly. <snip> Anders R _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
