Eddy Nigg wrote:
On 11/15/2008 06:29 PM, Ian G:
I agree it is an issue that we should try and
clarify, if not nail down.

Sounds good!


One way to short-circuit this is to simply state that the root CA is
responsible for any/all subroots.

This is the situation we had until recently, with CAs under their own control. Of course the CA is "responsible" for all its sub roots...

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.

Except that some CA policies many times don't even cover the aspects of the sub ordinate CAs. Such "root" CAs are simply audited as their CP/CPS defines. An auditor is not required to audit something not claimed in their policies. Auditors generally confirm the claims made in the CP/CPS, not those that aren't made.


So, in the above case, it seems that we have found a hole in the criteria. We might just need then to add some comments about subroots to the policy. Perhaps:

"The CPS is to identify the policy on subroots."
"The CPS is to state whether subroots are covered by the CA's policy or by other policies or other regimes." "Auditor is to opine on whether the subroots policy of the CA raises any undue risks."

(just throwing stuff up on the whiteboard here...)


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."

If that policy was part of the audit, that would already provide good indications.


Yes, sure, but the problem with this is that the CA's policy can say this year "we don't do subroots" and next year it can say "we do subroots under our own policies" and the year after "we do subroots if they give us cash" ...

Meanwhile, every fresh audit can be led along with a slight change to the previous. Frog boiling, it is called.

The Mozilla review can only catch the first one, and an acceptable part of life is that there is an (albeit controlled) method of changing the policies over time. The boiling frog is (a) going to bypass Mozo's review and (b) make someone a lotta dosh.

I can see solutions to this, but they are not going to make people laugh with joy ;) E.g., Mozo does its review every year...


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.

Right. It was suggested to require a yearly audit or by other frequency.


Yes, that is frequently suggested. I don't know why anyone believes it will work. I can sort of understand that everyone feels that if we just try harder and double the checks, it will be good, but surely we have passed the age of innocence by now? Sarbanes-Oxley and all that. More checking doesn't solve the issue, but it sure makes someone a lotta dosh.


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.

I don't perceive it as such at all. What do we not understand? There is a very competent team at work (Kathleen, Gerv, Frank) and a few of us here. I think the issues are fully understood.


Well, if you understand it, lay out your solution. Now compare the solution to the solutions of every other CA. They will be different.

So, obviously there will be a choice to make ... and the very competent team might conclude ... this is harder than we thought :)

E.g., WISeKey's solution will be "trust us, it's a grand product, and it follows the rules you laid out."


Alternatively, we just set the responsibility, and pass it to the root CA.


That's what we had previously. Some easy-to-find flaws already have been detected (DigiNotar, Staat der Nederlanden). Those were just the ones we came across by chance, I don't even want to know about everything we don't know.


Can you describe those flaws for me or us?  Case studies are helpful.


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.


One of the problems is of course that no follow ups exist currently as you correctly stated above. So far nobody has ever dedicated time to review CAs not up for inclusion.



Right. This is a clear flaw. It's also likely a trap, as we can probably imagine that at least one of those has moved over the last decade (since original incorporation) to be outside the standards of "today". I'm just speaking statistically here.

Which will bring up some fascinating choices. I wouldn't want to be over-hasty in pushing a bureaucratic solution to that, and then discovering that the result creates bad precedents and backfires on us.



iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to