At 9:09 PM -0700 5/25/07, Nelson Bolyard wrote: >Paul Hoffman wrote: > > My feeling is that we would be better off not making this leap of >> limitation. Either someone is allowed to certify in all domain names, or >> in none. > >Paul, that argument sounds to me like you're saying that constraining the >name space for which a CA may issue certs is somehow not part of the PKI >model.
If you read the second sentence without the first, and if you don't know that I haven't been an active participant in the PKIX work for a decade, I can see how you might think that. It's not true. Let me restate it to be clearer: My feeling is that we would be better off not making this leap of limitation. Either a trust anchor is allowed to certify in all domain names, or in none. >You seem to be suggesting that no CA should be constrained in >the name space for which it can issue certs. I didn't say "CA", and I didn't mean CA: I meant trust anchor, which is what we are really talking abou there. >Yet name space constraints are a fundamental part of X.509 v3 certs, >and well defined in RFC 3280, (and implemented in NSS). In RFC 3280, name constraints do not apply to trust anchors, only to subordinate CAs under a trust anchor. >Any CA may >choose to constrain the space(s) for the names that subordinate CAs may >issue as cert subjects. Exactly right. >I see no reason (certainly no technical reason) not to allow the user >to constrain the space for which he trusts a CA to issue subject names. This is a completely orthogonal argument to the thread of this discussion. We were talking about *Mozilla* constraining the allowed namespace for a trust anchor, not users constraining the namespace that a trust anchor is allowed to use. In order for the latter to happen and be consistent with RFC 3280, the user needs to be her own trust anchor and issue an sub-CA cert with name constraints to what was previously a trust anchor, and to remove that previous trust anchor from the trust anchor list. This can be done, but only if the user's admin GUI effectively hides the PKIX gunk. That is difficult but possible if we engage HCI folks in the task. Security people have a long record of designing crappy admin interfaces for features such as this. >Remember that, unlike the DoD's single root model, in which the root CA >cert is the trust anchor and has final say in all matters, in our open >Internet trust model, there are multiple roots, and the user himself >ultimately decides what he does and does not trust. Fully disagree. The vast majority of trust decisions in Firefox are done without the user's knowledge; how can the user "ultimately decides what he does and does not trust" when she is never told what is happening? >In effect, all the root CA certs are subordinate to the user himself. Not currently, no. We would need to change the trust model so that there was a single trust anchor and subordinate CAs for that to be true. I would love to see Mozilla do that, if it were done with a good admin GUI. >Why, then, should the user not be able to constrain those subordinate >CAs, just as any CA can constrain its subordinates? If we adopt that model, they can. But, again, that's not what this thread was about. It was about Mozilla unilaterally constraining the names without asking the user based on a feature of the audit. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
