Hi All, being the devil's advocate here, personal opinions if any...
Eddy Nigg wrote: > On 10/03/2008 04:29 AM, Frank Hecker: >> Well, it does matter how difficult it is to implement a policy, and I >> think we have to exercise some judgment here. At one end of the spectrum >> we have situations where we have a small number of subordinate CAs, each >> of which issues lots and lots of certificates. T-Systems is apparently >> like this, as are KISA and perhaps others. Here I think it is realistic >> for us to take a closer look at the subordinates. >> > > I agree that we need to think about it and provide clear guidance about > what is acceptable one what not! Lets go... > > The physical evidence gathering at the CA is a *substantial* part of an > audit, it's one of the cornerstones of auditing. Without it, auditing > would be very difficult and mostly meaningless. The physical > walk-through and on-spot evidence gathering is a a *substantial* effort > in relation of time and money to the CA. It's also the basis which > allows Mozilla to trust those audits and have some confidence about the > CA, being it the controls in place and general functioning. I am not entirely convinced that it is as easy as that. The audit is a far more nuanced thing than "auditor checks, it's ok." If you think that, then, I've got a subprime to sell you. > Now, you are suggesting that we can rely on meaningless contractual > requirements set up by the CA with no guaranties whatsoever that the > external entities which aren't even part of the same company and don't > share the physical infrastructure, have really done so. Actually, this is one of the weaknesses of the entire cycle. Currently, the contractual relationships between any of the parties in the cycle are weak. This weakness then flows through to other areas, and inspires worried people to ask for more and more checks ... which is fruitless because the checks that are in place are not anchored to a general need and/or any contractual backing. In general, I'd agree that even more weak contractual links will not help; we should sort out the ones we already have before expanding or adding to them. > How does an auditor confirm requirements set up by the CA without > actually visiting those intermediate CAs? Either the auditor gathers > evidence about the controls in place which govern those CAs; in which > case the auditor has no problem confirming them. Otherwise the auditor > hasn't done so, can't confirm conformance of the controls set up by the > CA. It's a chicken and egg problem, either the CA has sufficient > controls in place and set up requirements which resemble those of the > root - in which case the auditor must confirm them, or the CA doesn't > have those controls in place and the auditor has nothing to confirm > either. In either case the result is the same - the sub-ordinate CAs > were part of the audit or not, the auditor can confirm it or not. This seems a little black and white. Auditors do not check everything, and indeed they do not necessarily check that a particular thing is good. What they more do is check that reasonable checks are in place; this might be checking of the checking of the checks, rather than checking the physical evidence. Which is to say, an auditor can check an internal auditing department. And lean on that. Or can choose to audit by self. Or some other thing. The important thing would be that the method take is clear and obvious to all. >> To echo what I wrote earlier, it's analogous to the case of CAs that >> out-source the RA function to others, especially in the enterprise >> environment. I doubt that, e.g., a WebTrust audit entails auditing each >> and every organization participating in RA activities; I presume what is >> done is instead to look at the overall controls in place for such >> arrangements. > > Yes, but the RA doesn't control the CA infrastructure nor does the RA > actually issue the certificates. Neither has the RA the power to move, > remove, modify anything about the CA - it validates the subjects > according to some criteria and the CA is obligated to assert control and > assure the quality of the RA by various means. This is NOT the same as a > sub-CA or cross-signed CA. See "Business Continuity Management" and > "Physical and Environmental Security"... > > Hey! An RA can make a mistake here and there (the most), the RA can't > take the whole CA infrastructure down or compromise the CA keys. This is > a substantial difference! Well, what's your most likely attack? A rogue RA works for a phishing enterprise, delivers a 1000 dodgy certs on demand, and faces 1000 revocations and loss of privileges? Versus, a rogue sub-CA which does the same, and gets the same treatment? Yes, there is a technical and infrastructure difference, but how much does this matter, in a material sense, to a real attack, to a real user? Maybe the attacker is just at a different point in the food chain? >> It is not clear to me that it's realistic for us to require actual >> audits for each and every third-party subordinate CA. > > ...If the audit requirement can be > circumvented by simply getting into a contractual agreement with another > CA, than I request to skip the audit requirement altogether, why bother? > (This should serve as an example, I don't really mean it) :) Certainly if Mozilla succeeds in creating a good framework that covers this situation, there will be an incentive for CAs to band together and vote on one victim to go through the pain once, for all. I'm not sure that is a bad thing, that's just an economic argument, so far. As to whether the audit is needed ... well, there are *many* issues with the overall process. Here's one: what does it offer to the users? How much safer to people feel because there are lots of extra audit processes these days? http://www.sslshopper.com/article-phishing-with-ev-ssl-certificates.html >> Even beyond the >> WISeKey model (the "CA in a box" appliance device), I suspect that a >> number of other CAs serving the enterprise market have enough >> subordinates that it would be unrealistic to require actual audits of >> all subordinates in these cases as well. > > Who said that everything which was done to date was correct and useful > (to the relying parties)? Ahhh, relying parties, who are they, he asks innocently :) > Just because it exists it doesn't mean it's > the right thing to do really. "CA-in-a-box" is a risk Mozilla shouldn't > accept without some guaranties (which auditing provides). Lets suppose > CAs stop verifying domain control of server certificates because some > hardware vendors decided that the enterprise market needs it, will you > also call it unrealistic to make it a requirement? Most likely not! The current *implication* I would draw is that anything that is expressed in the policy applies to all sub CAs. So that particular question is covered. We would have more of a question about something in a CPS of the primary CA, that was reversed in a sub-CA. > Your effort to admit more CAs shouldn't come on the expense of basic > requirements; and those are confirmed by an audit. No audit, no > confirmation, no confidence and a higher risk. There are ways of extending that basic requirement down the line to the other subCAs. Also, it's a good chance to show that the basic requirements make sense; if we can't figure out a comfortable way to deal with this, we may have to ask higher level questions. >> (Which is not to say that >> there's no auditing at all -- for example, the (root) CA could have some >> sort of random or spot auditing scheme.) >> > > You know what's that worth...are you promoting CAs to be auditors now? > Having the cats take care of the milk... Yes, that's one direction. Internal audit. Another development (which I have frequently commented on without any particular favour :) ) is that Mozilla itself is auditing the audits. E.g., what's this 40 week backlog, if not that process of auditing the audits. So we end up with: super-audit -> audit -> sub-audit Is that a problem? Another direction is more auditing done by the users; those who benefit. The public comment period is a first step in that direction. > Random checking goes as far as it's convenient. There is no problem > performing such a check around the next corner, but going all the way to > the Falkland Islands is neither convenient nor financially attractive, > hence it will not happen either. It's simply useless, besides that I > question the effectiveness of such a check performed by the CA itself. Have you read the auditor's opinion? It generally starts with something like "*management* has put in place procedures and policies..." If you don't trust the checks performed by the CA, then you're sunk, because the auditor should check the system of checks, not do the checking by self. > Would you be willing to loose a good paying customer because of some > "minor deficiencies"? These are all standard issues; but they are issues for everyone in the food chain. Would an auditor be willing to lose a good paying customer because of some "minor deficiencies" ? Does an auditor check every RA operation, physically? Does an auditor verify the creation of certificates? I think Frank's direction bears thinking about, not knocking on the head just because it clashes with some old ideas. iang _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
