Frank Hecker wrote:
We've had some lengthy discussions about the issue of auditing
subordinate CAs. I'm not going to rehash all those discussions, I'll
just summarize my current thinking:
First, the general issue of auditing subordinate CAs was something we
didn't think through much when we did our Mozilla CA policy: We were
thinking of a fairly simple model where a CA organization operated both
its root CA(s) and also any subordinate CAs under those roots, with a
CPS and associated audit that covered the both root and subordinates
all. In actual practice things are more complicated, and our policy
didn't really capture that complication.
Yes, I agree. IMHO, the policy has served remarkably well, and of
course issues will arise with more experience.
My personal opinion is that it doesn't make sense to try to address this
complication by mandating traditional WebTrust-style audits of any and
all subordinates under a root. I think this approach is impractical, and
I don't think it's necessary. I'd rather look at the overall manner in
which CAs exercise controls over subordinates, legally, technically, and
otherwise, as well as the general nature of the subordinates and how
they function in practice. I think in some cases it might make sense to
require audits for all subordinates, and in some cases it might not.
Some musing on this. I agree it is an issue that we should try and
clarify, if not nail down.
One way to short-circuit this is to simply state that the root CA is
responsible for any/all subroots. So this would imply that the root
CA's policies and audit drill down through the subroots, and they apply.
Then, it would be up to the root auditor to decide whether a subroot
needed a separate audit or not.
One problem with this is that it might also not be realistic. Consider
two CAs, one of which does "style A" and another does "style B". In the
doco and audit for the root CA, there will be a need somehow to capture
that distinction. The natural direction here will end up that the
root's policies will tend to say "see the subroot's policies for more
detail."
So Mozilla's review of this will be looking at a blank spot. E.g.,
future subroots. I see this contrast all frequently. We accept the
base situation, then the CA goes and issues another subroot. Suddenly a
whole new class of activity has occurred, and there is no check done on
this until the next audit, and none at all by Mozilla.
One way to deal with that is to add a criteria that says "audit should
list the allowed subroots" or somesuch. So new subroots would have to
wait until the next audit. But this might slow down the process, add
complication, push the audit into too much management, and be also
somewhat arbitrary; CAs can be inventive and find ways around it, and
audits might be sympathetic to these ideas. Mozilla only does one
review, so in time the topic will drift.
Either way we look at it, I feel that the more controls are put in
place, the more we end up putting in "paper fixes" and the more we
complicate things for a gain that we don't fully understand.
Alternatively, we just set the responsibility, and pass it to the root CA.
This does somewhat put the finger on the relationship between the CA and
Mozilla. Currently, this is an informal agreement based on the policy,
bug filing, and other communications. What might be better is a single
document (or mod to the policy) that specified what the complete
agreement was (listing the others). In this we could typically include
the disclaimers of liability, and how we would deal with the disputes,
e.g., over the activities of the CA's wilder subroots, and at an extreme
level, any root revocation at Mozilla's discretion.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
