Anders Rundgren 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? Are you certain that the cert was marked trusted? Or did you merely observe that the cert appeared in the Cert Manager's CA cert page? The presence of the cert in the Cert Manager's CA cert page does NOT mean that it is trusted. The mere fact that a cert is stored in FF cert store doesn't mean it is trusted. In fact, certs can be stored for the explicit purpose of recording that they are known and *untrusted*. 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. > 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. When using a "user" cert (an EE cert for which you have the private key) for signing, NSS does not require any trust on the cert's chain. The fact that you have the private key is enough for NSS to perform the signature, and send out the cert chain for that EE cert (as much of the chain as NSS can construct). PSM (the glue for NSS in FF/TB/SM) may have chosen to implement a policy of requiring valid cert chains (leading to trusted roots) in order for a cert to be considered (by PSM) a valid candidate to be used in signing. I can't speak for PSM. > That FF automatically made the root trusted is a bug or a feature. If indeed the root was actually marked trusted, I think that's a bug in PSM. > I would claim that it is a bug because if somebody like a community > distributes a certificate it is because *they* want you to use a certificate. > That is not the same as you trust their roots for everything including SSL > certs which I guess this feature will enable as well. 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. > 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. That involves ensuring that the signature is sent with a complete and valid cert chain. The only way that NSS has to know that a cert chain is complete and valid is to validate it. That, in turn, requires having a trust anchor. So, I think that PSM (signtext is part of PSM, not NSS) may require a validatable cert chain in the course of operation. > 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". > They claim that ThunderBird does not read the cert-path when supplied in P11 > interface. What does that mean? That TB doesn't read certs out of tokens? > IMO there is no standard that says that you should or must do that. Well, we try to do it. :) Some third party PKCS#11 modules have problems (understatement of the year). One of the more common problems is making the CKA_ID attributes of the certs match the CKA_IDs of the private keys. Another is returning object IDs from C_FindObjects that cannot then subsequently be accessed by the returned object ID. In short, if this is a problem with some token's PKCS#11 module, it's probably a module problem. We don't fix third parties' modules, though they often request that we do. > password for the enclosed p12 is: testing This list doesn't forward attachments unless they're text/plain. If you've verified that the root cert is added and actually marked trusted, then you should file a bugzilla bug against PSM, and attach your p12 to it. In bugzilla, PSM is product=core, component="security: PSM". -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
