> >> But by issuing *domain validated* certificate for up to *ten years*, > >> without revalidation is completely irresponsible and borders on > gross > >> negligent. > >> > > [Robin said...] > > I disagree. With a DV certificate the only thing that we are > warranting is > > that the key holder controls the domain. > > Between us, even this isn't true exactly , or at least I'm not sure if > your CA warrants anything in the domain validated settings... But this > isn't the point at all, but the fact, that your certificates are issued > for a very long time without re-validating and confirming continued > ownership of the domain name. This is the problem here. > [Robin said...] It seems to boil down to this question. Q1) What is the maximum duration of certificate of each type in question that Mozilla's policy accepts?
> > Why go to that effort? DV certificates are easy to get. That is a > valid > > criticism against DV. > > > > I'm absolutely not against domain validated certificates and they have > a > rightful place in the landscape of this infrastructure. However I'm > completely against issuance of domain validated certificates to any > longer period which isn't reasonable and beyond the expected ownership > period of said domain name. [Robin said...] See Q1. > > > DV products exist today - that is a fact. The browsers (in this case > > Mozilla) have been content for us to issue DV certificates. Sure, a > longer > > duration certificate carries higher risk than a short one. > > Thank you for confirming this. > > > We'd also accept > > that a wildcard carries somewhat more risk than a single domain > certificate, > > but where is the line to be drawn? > > > > I'll be glad to evaluate this line together with you and other members > of this community. I have drawn my line and provided a concrete > proposal. We may discuss this and find the best solution for all. [Robin said...] Sure, so we need a documented answer for Q1. > > Also, why draw the line retrospectively and at this moment in time? > > Because your CA is a candidate for inclusion and upgrade into the NSS > store and as a matter of fact re-evaluated as if your CA never had any > roots in NSS (See this comment in the bug entry: > https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20 > > If we don't speak up now, we can't blame anybody else later. > [Robin said...] A fair point, and perhaps that is a whole other problem. Our CA *does* have roots in NSS. Is this: a) an abstract discussion to help Mozilla crystallize the details of its CA policy, b) a discussion about what changes to CA behaviour Mozilla would like to see (and may insist on) from some point in time, or c) a trial to determine whether our CAs should be removed from Mozilla products? We have certainly strayed from my point of entry into this process which was to ask to have these 3 existing roots enabled for EV. > > Should Mozilla's policy on this not be published and clear for us to > follow, rather > > than ad-hoc? > > > > The Mozilla CA policy is clear in that respect in various points, > starting with the first paragraph <snip> > > The other sections go into some more details. Additionally there is the > objective of this policy as explained in the initial sections to > prevent undue risk to the users security. > > I agree with you that we can and should refine the Mozilla CA policy to > some extend, something which has been done already once (to allow EV > upgrades) and to all of my knowledge we at Mozilla will work on that as > soon as possible and if necessary (Frank, is that correct?) > [Robin said...] The CA Policy is there, I agree, but I think we meet the objective criteria it provides. "Preventing undue risk" sounds subjective to me. > > > > > > > [Robin said...] > > It is in our interest to know about as many SSL protected domains out > there > > on the internet as possible. We do actively look for them. > > The snag is that with wildcard domains there really are an awful lot > of > > possibilities to search for. We are looking for needles in > haystacks. If > > we could get a zone transfer for the DNS server hosting domain.com > (to pick > > up all the existing sub-domains) then our life would be made simple > and we > > would certainly check them all, but that just doesn't work. > > > > Robin, I'm glad that it's *you* who made this statement and I couldn't > have it formulated better - I absolutely agree with you. And *exactly > because of that*, wild card certificates should (must) be at least > identity validated. Because CAs can't control wild card certificates in > the same way as regular certificates and because of the "card blanche" > this certificates offer to the subscriber, a CA must implement > additional measures beyond merely validating the domain name (for > example by validating the identity of the subscriber). > [Robin said...] So you suggest we may not issue wildcard DV certificates. It is at least a concrete point for discussion. Which of the "objective and verifiable criteria" in the CA Policy does wildcard DV fail to meet? That gives us: Q2) Are wildcard DV certificates permitted? > > Publish (as Mozilla) a list of policies we must follow. > Yes. > > > Also, apply those policies across the board. > > > > Absolutely! More than that, I suggest to you (and any other interest > party) to join that effort. If you know about CAs which present the > same > risk as your CA does currently (in my point of view), than provide that > information. It will help us at Mozilla to better evaluate the > situation > and help us to improve the software in relation to SSL certificates. [Robin said...] Surely this should be a discussion about whether we meet Mozilla's policy. Unless you are proposing a public beauty competition between the CAs with a view to knock out the bottom few? We are confident we won't come last. > > > If you were to block one CA but allow other CAs in to the root > program which > > operate the same policy the blocked CA must take some action to > defend its > > market position. What would you have that be? > > > > No way! Only in case said CA simply doesn't conform to the Mozilla CA > policy and isn't willing to make the required adjustments, said CA can > not be included. I agree with you that this must be evenly applied. > [Robin said...] We are driven by commercial considerations (as well as by higher motives :-)) to follow the requirements of the major browser/OS platforms, including Mozilla. We have no wish to do anything that does not follow the Mozilla CA policy. I think we will always try to drive Mozilla to document that policy sufficiently precisely that our compliance with it may be judged by us before we even present something for judgement by Mozilla. > > Likewise the old standards (such as DV) must, in an ideal world, be > phased > > out > > No, as I said previously, DV certs have their rightful place and are > excellent for the intended purpose. But we must also do that with > responsibility and take into consideration its limitations. Issuing > such > certificates for up to ten years without re-validating and/or wild card > certificates without any additional verifications are irresponsible > actions in my opinion. Specially the former. > [Robin said...] Q1) What is the maximum duration of certificate of each type in question that Mozilla's policy accepts? Q2) Are wildcard DV certificates permitted? > > I appreciate that Mozilla is at > > liberty to make any decisions on it's CA acceptance policy that it > sees fit, > > but again the policies should be clear and stated in advance. > Persuasion > > and cajoling to change standards or withdraw products should not need > to > > happen at the level of an individual CA's application to have a root > > certificate embedded (or its trust status changed). > > > > There are things which the current CA policy doesn't cover explicitly, > but in more general formulation. Supposed tomorrow a CA introduces a > scheme about which the editors of the Mozilla CA policy haven't thought > about, but pose a potential risk to Mozilla and its users, I would take > care to make the community aware of the problem and have this evaluated > accordingly. > > This makes perfect sense in my opinion. [Robin said...] Sure, but those are the reasons to update your CA policy. Mozilla defines its policy. We follow the policy. My interest here (I think) is to get a judgement as to whether we follow the policy. > > [Robin said...] > > You are missing a lot of information that is available to the > > auditors. <snip> > Which is as expected and perfectly acceptable. My question however was, > if your auditor could confirm all the locations to which the audits > apply? Since you operate at various locations, I'd like to know if the > audit covers all your operations at all locations or not. > [Robin said...] I'm happy to state that the audit does cover all of the locations which are involved in our CA operations. Comodo CA Limited does a few things other than run a CA, and those non-CA activities are not covered by the "WebTrust for CAs" audit. I'm sure the auditors could confirm that too, if I asked them to, and they would be very happy to send me the bill for doing so. > >> Personally I think that if the company to which the root was issued, > >> stopped its operation and/or ceased to exist, or if the details > within a > >> certificates (including root certificates) are not correct anymore, > they > >> should be revoked. Instead an updated certificate should be issued > with > >> the correct information included. Alternatively the same keys could > be > >> reused. We require this conditional for end users, but certainly > should > >> be true as well for CA roots. This is proper handling of PKI > certificate > >> life cycle, something which auditors confirm. As a matter of fact, I > >> believe that we have CA roots in NSS which have untrue and wrong > >> information in the subject line. > >> > > [Robin said...] > > We could conceivably issue new certificates for those root > > CAs to which you object, but the thing we can't do is change > > the common name or the CA key because a CA is defined as > > being a pairing of common name and key pair. If we change > > the name then it is a different CA. If we change the key > > then it is a different CA. Changing either would be > > equivalent to us throwing the CA away. > > We can issue new CAs and have them signed by the old CAs > > - but in fact this is what we do with most of our products > > now. We issue many certificates via intermediate CA > > certificates (whose subjects do not refer to legacy entities). > > Our main use for the UserTrust and AddTrust roots is to > > cross-sign other CAs which we rely on where possible, falling > > back on the cross-signing to inherit trust only where needed > > - usually on older platforms. You will certainly shake > > things up if you remove all root CA certificates whose > > subjects are no longer accurate. Our customers whose > > certificates stop working will be decidedly miffed, I feel > > sure. Or did you have some less drastic measure > > in mind, perhaps? > > I think this is something about which we need to gather more > information > in every respect. I'm certain that if this is confirmed to be a > problem, > we'll have the possibility to find a common understanding and approach > this accordingly. I'm not sure why you think that you can't change the > common name. Apparently the key pairs could be reused, but the > certificates content changed - the very purpose of such an exercise. > But > there could be more ideas on solving it and I think we can invest the > needed time to approach this correctly, should such a decision be > taken. [Robin said...] We can't change the common name because the common name occurs (as the issuer name) in every certificate issued by the CA. If they don't match then the certificate chain won't show as being trusted. (That's implementation dependant, but it's a good 1st order approximation.) As you suggest, there will be ways around it, but I think they all involve retaining the original CA certificate as a trust anchor. I think that's looking like Q3: Q3) Is it Mozilla's policy to remove root CA certificates from its products where the subject information in the certificate no longer accurately reflects the legal owner of the CA? Regards Robin _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
