Re: subroots (was WISeKey)
On 11/19/2008 03:56 AM, Ian G: 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. ...and I might add, how are the basic requirements of the Mozilla CA Policy governed... 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. 100%! Certification is about the relying party, nothing else. I'm not actually sure a formal legal agreement is needed. I suggested and supported the call for a formal agreement between the CAs and Mozilla a while ago. It would strengthen the relationship and commitment to the Mozilla CA Policy. Without it, governing CAs is rather difficult. 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. This could be another way doing the same thing. Obviously signing a real paper is a stronger act than simply agreeing to a policy statement. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: subroots (was WISeKey)
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
Re: subroots (was WISeKey)
Ian G wrote: IMHO, the policy has served remarkably well, and of course issues will arise with more experience. I wouldn't go so far as to say the policy has served remarkably well. However I think it has served as a useful document in terms of providing a context for our discussions, has helped in surfacing some long-standing CA-related issues, and has I think shed more light on what for many years was sort of a overlooked part of the overall Internet/web infrastructure. 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). 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. 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. 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. 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. 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 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
Re: subroots (was WISeKey)
Eddy Nigg wrote: On 11/15/2008 06:29 PM, Ian G: smip 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. Not to speak for Ian, but I interpreted his comments as follows: We can add more provisions to the policy to address particular situations, but what do we ultimately gain in terms of enhanced security for end users? It's like adding more and more provisions to laws or regulations in order to cover special cases, to close loopholes, and so on. Is the extra complexity (in terms of writing the laws and regulations, interpreting them, enforcing them, etc.) worth the trouble? And in our case we have to remember that me, Kathleen, and others don't have infinite time and resources at our disposal. 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. As I said, our time is finite. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: subroots (was WISeKey)
Ian G wrote: Eddy Nigg wrote: snip Right. It was suggested to require a yearly audit or by other frequency. Related to this point: I don't know if anyone's noticed this, but WebTrust seems to be getting clogged in terms of getting new audit reports out and published. I periodically do a web script that downloads reports from webtrust.org by number (so I catch all reports issued), and it seems like there aren't a whole lot of new reports coming out -- at least, I would have have expected to have seen more reports given the number of CAs out there supposedly doing WebTrust audits. This is by way of saying that even if we required annual audit reports, it's not clear to me that CAs could produce them. There seem to be some bottlenecks in the CA audit realm, at least in the WebTrust case. I don't know if this is a problem with WebTrust specifically (i.e., central program administrators) or with the availability of WebTrust-authorized audit teams. 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. Well, it doesn't make any extra money for me, or for the Mozilla Foundation :-) More seriously, I think the analogy to Sarbanes-Oxley is relevant, for reasons I've previously expressed. 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. Eddy's talking about cases where CAs issued certificates with email addresses but did not apparently validate control of those addresses by the applicant. These were fairly straightforward violations of our policy, and also were directly relevant to the intent of the policy to provide some base-level assurance relative to using certificates. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: subroots (was WISeKey)
On 11/18/2008 08:40 PM, Frank Hecker: This is by way of saying that even if we required annual audit reports, it's not clear to me that CAs could produce them. Microsoft made it a requirement and you might ask them how it goes. But there are many CAs supported by MS, apparently they are capable to request the audit statements on a yearly basis. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: subroots (was WISeKey)
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
subroots (was WISeKey)
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
Re: subroots (was WISeKey)
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. 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. 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. 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. 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. 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. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
