Frank Hecker wrote:
Ian G wrote:
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.
I think this approach would be good if we were starting from a
greenfield environment. However I think in the current CA environment
we're faced with a situation where in practice roots don't necessarily
always accept direct responsibility for the actions of their
subordinates (or for those of other root CAs that they've issued cross
certificates for).
Hmmm... So, who takes responsibility for these CAs, or is this part of
the unanswered question?
Is there some agreement with the subsidiaries? Is the agreement
submitted as part of the Mozo review?
From a practical standpoint the issuance of
subordinate CA certificates or cross certificates has been seen as more
of a technical issue: "A needs to treat B as a subordinate CA because B
wants/needs to take advantage of A's inclusion in IE/Firefox/etc."
Right.
This predominant attitude toward subordinates is a defect to be sure.
The question is, to what extent (and in what circumstances) is it a
security-relevant defect.
and, to whom? Obviously, the security of the subordinate CA is well
improved by this "defect" ;)
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."
Right, and that's a quite common situation: There will be a root CA that
really acts just as a convenient "gathering point" for a bunch of
different subordinates to get CA certs from, with the root's policies
just having to do with subordinates, and every relevant to end-entity
certs pushed down to the subordinate CAs. This is the model for a lot of
government-sponsored PKIs where the PKI is not just government-specific
but serves as an unmbrella for commercial and nonprofit groups to set up
their own CAs under the government-operated and-authorized root.
Yes, and at a technical level I don't see an issue. At a
legal/liabilities level I see an open question: who is taking on the
liability, how is it shared, etc.
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.
Yes, and I'm going to use your comment as a jumping off point for a
broader comment:
We have traditionally treated CA inclusion as a security issue, with the
purpose of evaluating CAs for inclusion to ensure that we didn't suffer
major security vulnerabilities due to CA actions or omissions. However I
could also make the case that the CA is less like the other
security-related stuff we do (e.g., security testing, fixing reported
vulnerabilities in the code, etc.) and more like what we've been doing
in the licensing/copyright area.
OK.
I think there's general agreement that browser exploits are a "clear and
present danger", and it's worth our spending whatever time it takes to
make sure they're fixed as expeditiously as possible. Over on the
legal/licensing/copyright front, there are certainly bad things that
could happen to us, like getting code in the tree that was not
authorized by the creator, getting code in that was under an
incompatible license, and so on. Based on our experience and judgment
over time, we've deemed it adequate to set up some safeguards in place:
having formal license policies and a formal committers agreement, having
people vouch for others seeking commit access, and so on. However we
haven't gone overboard with double- and triple-checking everyone who
contributes code, vetting every single code contribution for legal
issues, and so on. This would greatly raise the bar to getting code
contributions from people, and we just don't see that as being justified
based on experience and the perceived risks.
So, which is the better model for including CAs? I'm beginning to think
that the licensing/copyright situation is perhaps a better model for us:
set up a documented framework, perform some reasonable due diligence,
and be transparent in terms of what we're doing (as happens when
approving new committers), but when making judgment calls err on the
side of inclusion rather than exclusion.
This is an interesting approach and I certainly don't disagree with the
basic thrust. If anything I would say that there isn't one "superior
model" but there are aspects from both models (bugs v. licence) that can
help, or there are aspects from both models that we are sorely missing.
I also think it helps a lot to define the target of the security model.
Who are we trying to protect? I say the end-user (and have said so in
recent documents) rather than say Mozo or the CA or whoever else we
might encounter in the path.
If one were to then ask about how certs and CAs can present risks,
liabilities and obligations, as well as benefits and protection to the
end-user, it is not entirely clear how this is done. Not only is the UI
somewhat and arbitrarily opaque as to who the CA is, there is no clear
legal relationship with the CA.
So, CAs might make a good case for end-user benefit; but this all comes
to nought because the end-user has no relationship with the CA. So if
anything goes wrong there is no apparent way to perfect the benefit /
loss. And, according to some schools of thought, if you can't perfect
it, it doesn't exist.
If I was captaining the good ship CA Policy, I would look for this sort
of added clause:
x. The CA makes an offer to typical end-users of our product
(perhaps similar to an open source licence).
i. it should be clear, understandable and accessible;
ii. it should offer permission to USE the certs;
iii. it should cover everyone who has no other agreement;
iv. it should state that there is no other permission, in
absence of an agreement that is specifically entered into by the user.
x. The offer to end-users should disclaim all liability.
x. CAs may have other arrangements for customers and others who have
higher needs.
The nice thing about this is that it is pretty much in place already.
Major CAs have some form of RPA on their site, and they match the terms
above, more or less, already.
Now, if this were to be standardised as Mozo-level policy, it clears the
way for a number of other fixes.
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.
I'd like at some point to consider formalizing our relationships with
CAs, e.g., through some sort of formal legal agreement associated with
Mozilla including a root. That would take a bit of work and involve a
number of people to get it done right,
I'm not actually sure a "formal legal agreement" is needed. Although we
understand the lawyers like to have these things reviewed and signed in
blood to the Nth degree ... we should also note that the whole open
source regime is gaining a lot of traction as a respectable legal
tradition, and there is no formal contract involved there.
From which I would say that a good model is to simply state the policy
as a "posted notice" with a clause that states "by submitting your root
to the bugzilla for consideration, you agree to the terms and conditions
of this policy." Adding that sort of clause to the policy should be a
lot easier than trying to craft some sort of "mutual agreement."
and unfortunately I have more
pressing priorities right now in the CA area. (Basically: getting
requests processed in a timely manner and doing the work necessary to
have someone else take over these duties sometime in 2009.)
However I think these sorts of discussions are useful, as they will
provide good context if/when we actually get down to drafting a formal
CA agreement.
Yes, I understand that it will require some serious work to do this.
When we saw this at the CA I know, it took a good year to write the
framework, another year to get it approved, and then the rollout is
still going on.
If we can toss the principles around in advance, it might be easier.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
