On 11/14/2008 11:12 PM, Frank Hecker: >...in the short term I'm going to try to restart CA public
discussions on a regular schedule.
Nice to see you back here!
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.
I'm glad that this issue is recognized as such!
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.
Even though your statement would on general issues make sense, we must also recognize that it would be very difficult to implement. First of all it's a matter of policy and every time the policy didn't address a specific issue in the past we were in a Grey area. The "problematic practices" were implemented as a result of it.
I believe that the policy (and/or other relevant policy guiding statements) should be clear in respect what Mozilla requires from the CAs. This is important for planning and preparing for the CAs themselves, it's important for us in order to make the right judgment. I think that a case-by-case approach is at least unfair and hardly sustainable in the long term. Incidentally those CAs which would be most likely acceptable by the terms you outlined above, are usually the ones which either audit their whole infrastructure or are not affected by the problematic practices of sub-ordinate CAs in first place. But obviously it's difficult to draw a clear line...
There are various risks Mozilla needs to be prepared to take in case no clear policy is defined, mainly the inclusion-by-proxy of CAs (it rather would not have included) and questionable practices of sub-ordinate CAs. Additionally I believe that Mozilla shouldn't take the risk of including CAs (sub-ordinate or not) *without* having their physical and logical infrastructure confirmed and audited. Specially problematic are those which are independent entities in relation to the root CA and operate their own infrastructure (inclusion by proxy). It makes no sense whatsoever to require auditing of a root, if the issuing CA isn't audited at all. Recent examples have shown that it's no guaranty for adherence to the Mozilla CA policy - despite the fact that the very same (cross-signed or sub-ordinate) CAs were actually audited independently!!!
(I refrain from getting into the auditing aspects, but it makes a great deal and difference for all parties involved. Otherwise Mozilla and the other browsers wouldn't made it a requirement from the beginning.)
I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not.
Can you define those cases? What are the requirements and where doesn't and where does it make sense? How to draw the line? You must be specific in order for us to understand the differences!
For purposes of this particular evaluation, my goal is for us to gain a shared understanding of what WISeKey actually does, including getting answers to any remaining questions, and then I'll make a judgement call as to whether what WISeKey is doing meets the general intent of our policy.
In this particular case I think that the practice in question doesn't meet the requirements of the Mozilla CA policy. This includes in particular section 6 and 7 of the Mozilla CA Policy.
WISeKey has been through an initial comment period a while back, during which we got nvolved in a lengthy discussion about WISeKey's Blackbox product (a "CA in a box" product intended for enterprise deployment) and whether and how auditing was done for WISeKey's subordinate CAs associated with that product. WISeKey supplied more information about their arrangements, which you can find in the bug.
Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of "information gathering" in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed.
Since I can't find anything new, I assume that nothing has changed and therefore the condition for inclusion didn't change at all. If we consider that all recent inclusion requests were specifically tested for such practices - most notably CAs like Comodo, but also T-Systems who's inclusion has been delayed as a result of it - I can't see any particular reason for making an exception here. Not only do their products circumvent the audit requirement, they might be in direct conflict with the basic requirements of the Mozilla CA policy such as email and domain validation (IIRC - see comment 32 in bug 371362).
(Additionally, I couldn't confirm that this CA commands any significant market share with the information at my disposal. I'm the opinion that it would be a mistake to make an exception on the audit requirement for sub-CAs, which in the future could serve as an argument in favor for similar scenarios. It was also pointed out at the bug that this CA is in MS software, however I suspect their policies to be also in conflict of the MS root program. Just some side-note...)
-- 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
