Re: revocation of roots
Frank Hecker wrote: So personally I'd consider a 5-day timeframe reasonable, and based on past conversations with people doing update releases, I think it might be pushed down as low as 3 days. I should clarify that this timeframe doesn't include any CA-related time prior to the Mozilla project being informed of a problem. This is just for the Mozilla fix-and-release process. Also note that IIRC the Firefox automated update mechanism doesn't update all users at the same time -- it's staggered a bit to avoid overwhelming the update servers. (I can't remember what the relevant delays are, and couldn't find this info in quick search.) So it might take a little more time until all Firefox users get the new release with the revoked root. 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: revocation of roots
Paul Hoffman wrote: If you want to to be able to revoke roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. Thanks for the suggestion; I presume that http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-00.txt is the main document of interest? At first glance this looks interesting, though I haven't yet read it in detail. 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: revocation of roots
Eddy Nigg wrote: Now IMO as the root certificate signs itself, with the same authority it should be able to revoke itself. This would result obviously in repeating the process until the root is removed and not used anymore, but it would mark the root and all certificates signed by it revoked. I'm not sure what you mean by repeating the process. How would such revocation work in practice (assuming a PKI library that did CRL checking for roots)? Would the root just sign a CRL with its own certificate's serial number on it? Presumably at that point any application retrieving such a CRL would note revocation of the root certificate, and from that point forward would refuse to recognize as valid any certificates chaining up to the root, any subsequent CRLs signed by the root, and so on. Or am I missing something? 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: Microtec CA inclusion request
Nelson Bolyard wrote: Frank Hecker wrote: * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, Microsec is removing AIA extensions with OCSP URLs from end entity certificates and from intermediate CA certificates, and this should address this problem going forward. ... after some period of time has elapsed. Certainly the day after they begin to issue certs without the OCSP URL in the AIA extension, 99+% of the existing certs will still have those AIA extensions. Over time that number should decline. Please refresh my memory here: As I understand it, the basic problem was that if the Microsec root were included in Firefox (or other products) and a user surfed to an SSL/TLS-enabled site with an end entity certificate issued by Microsec (a cert with the AIA extension with the OCSP URL), then this would cause an error in Firefox 3, because Firefox 3 does OCSP checking by default and it would get what it considered to be a bad OCSP response. Do I have this right? At what point does it become appropriate to consider the problem to have abated enough to no longer be an issue? Is it when the number of remaining outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%? 5%? 1%? I think it is in Microsec's interest to revoke and reissue certificates for sites that encounter problems with Firefox. I would consider this problem to be effectively addressed after Microsec actively begins an initiative to work with its affected customers to get them new certificates. At that point if customers do not update their sites IMO it is their problem, not Microsec's or Mozilla's. If approved, the Microsec root would not go into Firefox 3 until late this year or early next year. So I think there is plenty of time for Microsec to put together a suitable plan for how to ease the transition for its customers and minimize any errors that might be experienced by Firefox users. Although we haven't tested it with libPKIX, as far as I know, OCSP URLs in root certs will not be a problem for NSS. NSS will never check a self-issued cert for OCSP revocation. Thanks for looking into this. My conclusion is therefore that there is no need for Microsec to reissue its root certificate, at least as far as Mozilla is concerned. However as Rob Stradling noted, I do suggest that Microsec look at what GlobalSign did with its root refresh, in case Microsec wants to do something similar in the future. (I should also note that if Microsec's current root is approved for inclusion, I would give expedited approval to any future refresh of the root, as long as nothing had changed in terms of Microsec's operations and there were no technical problems with the new root.) One final question: Does anyone know what Thunderbird 3 will be doing in terms of OCSP checks? Will this problem affect end entity certificates issued by Microsec for S/MIME use? 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: revocation of roots
Eddy Nigg wrote: b. Is there a way in the root list (code) to signal that a root is revoked (other than by a self-signed CRL of self)? E.g., by a flag or something? Not that I'm aware of. I don't know if this is what Ian was referring to, but in theory we can leave the root certificate in NSS but set the trust flags off. This would result in rejecting any use of a certificate whose cert chain terminated in that root. Note that we've never actually done this for any root. Note also that (I think) in this case a user could manually set the flags back to allow the root to be used again. 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: Microtec CA inclusion request
Frank Hecker wrote: In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=370505 First, my apologies for the delay in my responding to the public comments. I've messed up the schedule I previously outlined; see below for my proposal to revise the schedule and deal with the Microsec request. I've read through all the public comments. Rather than try to respond to each and every comment, I've written a brief summary of my understanding of the various issues raised. Please feel free to correct my understanding where appropriate. * Translation of the Microsec CPSs. As I noted in my original message, all of the Microsec CPS documents are available in Hungarian only. Our policy does not mandate that CA documents be available in English, so I don't see a justification for requiring that Microsec prepare official English translations. Thus far we've relied on Microsec-provided translations of key CPS sections; the Mozilla Hungarian localization team (in the person of Kálmán Kéménczy) was kind enough to verify the accuracy of the translations. IMO Getting human-created English translations of all the CPSs is going to be too difficult and time-consuming to be feasible, at least in the near term. I've followed up on the tips provided by Eddy Nigg and researched various options for machine translation of Hungarian. It appears that the best online option is the Webforditas.hu site: http://www.webforditas.hu/web-translator.php http://www.webforditas.hu/translation.php The company behind the site also sells a Windows-based translation application (MorphLogic). I'm going to try and see if I can use either the site or (more likely) the application to get rough translations of relevant CPS sections, starting with the tables of contents. * Liability associated with Microsec certificates. There were a number of comments relating to the monetary liability associated with Microsec certificates. The thread was interesting in relation to understanding practices in Hungary and the EU, but I think that ultimately it is not relevant to our consideration of this request. Our policy does not have any requirements relating to monetary liability of CAs, and I am not persuaded that disclaiming liability in certain contexts causes security issues for typical Mozilla users. I'm therefore minded to ignore this issue for purposes of evaluating this request. * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, Microsec is removing AIA extensions with OCSP URLs from end entity certificates and from intermediate CA certificates, and this should address this problem going forward. However there still appears to be an open question as to whether having an AIA extension with OCSP URL in the Microsec root certificate will cause a problem with NSS. (Nelson wrote that he was going to investigate this, but I don't recall seeing a followup to this.) Based on the above, my inclination is to postpone consideration of this request for at least two weeks. That will give me time to try to get more of the Microsec CPS content translated, and also to get a final answer on the question of root certificates with AIA extensions with OCSP URLs. Once those two things get done I'll formally start a new public comment period. (You can still comment in the meantime, of course; I'm just setting a formal date for purposes of scheduling CA requests.) I've revised the CA schedule to reflect this delay: https://wiki.mozilla.org/CA:Schedule 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: Setting a schedule for CA evaluations
Eddy Nigg wrote: Shouldn't have been there an announcement for bug 371362 or shall we simply follow the schedule? I guess a summary from you would be in any case useful as you've done with Microsec. Please advice... Sorry, there wasn't an announcement because I was too busy with other stuff to close out phase 1 of public comment on Microsec. I'm going to make some comments on Microsec, and then push the whole schedule back a few days to account for my delays. My apologies... 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: Microtec CA inclusion request
Eddy Nigg wrote: On 10/03/2008 12:43 AM, Frank Hecker: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Frank, I think we should buy some tool that helps us with translating such stuff. Apparently Google doesn't support Hungarian - English yet, but I searched and found some useful tools on the net which can do that. Please get something that can translate the CP/CPS and publish it somewhere so we can read about it. We can consider this in the longer term. In the short term Kálmán Kéménczy of the Mozilla localization team for Hungary has confirmed the accuracy of the translations in the Microsoft bug, and is willing to check further translations as needed. Frank P.S. I was out of the office all day, which is why I haven't been participating in the discussion. I'll read all the comments in this thread tonight and comment tomorrow. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Setting a schedule for CA evaluations
My apologies for having gone silent for a while; with Mark Surman (the new Mozilla Foundation executive director) coming on board I've been busy helping him get started and taking care of related responsibilities. However I now have more time, and I'm going to be devoting it to getting more CA request processed. Right now we have over 40 CA requests in the queue. After thinking about it, I have decided that the best way to proceed is to have a published schedule for when we will look at each of these requests. This will provide some predictability for the CAs, give us deadlines we can work toward, and allow us to be held accountable for meeting those deadlines. I've published an initial version of such a schedule at: https://wiki.mozilla.org/CA:Schedule There are some additional points worth commenting on: * I'm going to try for one CA request processed per week, which means that at any given time we'll have two CAs in public comment periods. We can revise the schedule later if it turns out that we can process requests faster than one per week, or if it turns out that we need more time for particular CAs. * Right now I have the public comment periods starting on Mondays. If people would prefer the comment periods to start on other days I'm open to changing this. (For example, another option would be to start comment periods on Friday, for people who like to look at these over the weekend.) * I am no longer going to try to coordinate CA evaluations with the Firefox release schedule, at least not explicitly. It was just too difficult, especially when code freeze dates kept changing. If for some reason we'd like to get a particular CA's request processed for a particulare Firefox release, we can just revise the schedule to put the CA into an earlier slot. * The current schedule has only two CAs scheduled. I will add more CAs to the schedule as I figure out what the state of their requests is, and whether and when they're ready to go into the public comment phase. If you have any questions or comments about this please let me know. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Dealing with third-party subordinates of T-Systems and others
Kathleen Wilson and I have been discussing how to re-start the evaluation process for T-Systems. If you recall, that request (bug 378882) got bogged down in a discussion of how to deal with situations where the root CA doesn't actually issue end entity certificates and the root CA's CPS doesn't address issuance of EE certs, but instead all the EE certs are issued by third-party subordinates. Kathleen thinks, and I agree, that the best way to approach this both with T-Systems and with other CAs in general is to ask the CA to update the CP/CPS for the root to include language addressing the following: * Clear requirements for subordinate CAs for how information in end-entity certs is to be verified, such that section 7 of the Mozilla CA policy (http://www.mozilla.org/projects/security/certs/policy/) is satisfied. * Requirements for subordinate CAs in regards to whether or not subordinate CAs are constrained to issue certificates only within certain domains, and whether or not subordinate CAs can create their own subordinates. * Audit requirements for subordinate CAs with regard to the frequency of audits and who can/should perform them, as per sections 8, 9, and 10 of the Mozilla CA policy. Our goal here is to avoid having to evaluate lots and lots of subordinate CAs, and instead have the roots take care of their own subordinates and ensure they're compliant to policy. Does this sound reasonable? If so we'll proceed as noted above. Frank P.S. One thing I asked for before at some point, and I'll re-ask now, is a clear brief technical description on how root CAs would constrain subordinates to issue EE certs only within certain domains, and also prevent them from creating their own subordinates. I'd like to add this to https://wiki.mozilla.org/CA:Recommendations_for_Roots to provide some technical background for anyone interested. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Microtec CA inclusion request
In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=370505 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Microsec Some points worth mentioning about this request: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Microsec has provided translations of the relevant sections in the bug comments, as well as other background information. I've asked András Tímár [1] of the Hungarian localization team to double-check the translations; for now I'm assuming the translations are accurate absent any information to the contrary. * Though a commercial CA, Microsec is audited by an agency of the Hungarian government. (This appears to be a fairly common practice in Europe, especially for CAs issuing so-called qualified certificates, as Microsec does.) The audit is against ETSI TS 101 456 and 102 042 and is annual. Kathleen has verified the relevant information with a government representative. * Microsec has a separate root used for OCSP, and apparently does not offer OCSP as a general public service; please see the comments in the bug. I'd like those of you who are OCSP experts to look at this issue and tell us if you see any potential problems there. This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. Frank [1] Fun fact: Within Hungary names are normally given in Eastern order (i.e., like China or Japan) with surname first. In this case I've transposed to Western order (I think). -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microsec CA inclusion request
Frank Hecker wrote: I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to D'oh! It's Microsec, *not* Microtec. I got it right everywhere except for the subject line and the first sentence. Sigh... 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: Dealing with third-party subordinates of T-Systems and others
Justin Dolske wrote: Out of curiousity... How many (if any) such CAs are currently included in NSS? It's not clear, since we've never gone back and looked at all the legacy CAs. There are certainly a number of root CAs that authorize third parties to run subordinate CAs and issue end entity certificates. This is fairly common with large companies -- they get a subordinate CA cert issued by a root, and then run their own CAs internally. It seems a little scary to be providing a way for these 3rd party CAs to become operational in Mozilla products without going through the Mozilla approval process. It seems like a different degree or trust. I don't think the practice of having third party subordinates is in and itself a problem. It's just that the root CA needs to have some sort of control over the subordinates (e.g., through appropriate legal agreements), and some way of ensuring (e.g., through audits) that the subordinates operate in accordance with the controls. Remember that a lot of CAs working with enterprises outsource the Registration Authority function to those enterprises. In other words, the enterprise is ultimately responsible for doing verification of subscribers (e.g. when issuing certificates to employees and corporate web sites), even when the CA itself is issuing the certificate. Going from outsourced RAs to third-party subordinates adds some additional risk, but it's not a qualitatively different situation as I see it. 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: Dealing with third-party subordinates of T-Systems and others
Eddy Nigg wrote: The principal guiding us should be the audit requirements mentioned above and there shall be no CA included which hasn't undergone such an audit, being it as part of a root or in its own rights. A root shall not be included in case sub-ordinate CAs exist which haven't seen the face of an auditor at least once (not speaking about yearly re-auditing yet). This issue is going to come up with WISeKey (scheduled for public comment next week), but I may as well speak of it in general terms right now. It is not clear to me that it's realistic for us to require actual audits for each and every third-party subordinate CA. 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. (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.) Since the Mozilla CA policy clearly calls for auditing of the CA, I think that Mozilla will have to share the burden in cases the CAs in question haven't been part of such an audit and would like to apply in their own right. Not sure how many there will be, but in such a case it's simply a matter of implementing the policy. 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. In other cases, like the enterprise CA case mentioned above, there are lots of subordinates, and each subordinate issues relatively few certificates. Here I think it is unrealistic to look at each and every CA; it's quite possible we won't even know the actual names of each and every CA. In these case I think we will instead have to look at the overall manner in which the (root) CA oversees and controls the subordinates. 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. I think path length should be 0 for such CAs. It's a requirement for the issuing CA certificate of EV certificates and makes sense also here. Thanks. If you have time please feel free to edit the wiki page and add a note on this near the bottom (where subordinate are discussed). 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: questions on root creation
Nelson Bolyard wrote: The 3 sets of claims used for SSL servers have names DV, OV and EV. Of those, EV is well defined and documented. DV is pretty well understood but I don't know of any document that defines it very well. OV is the least well defined, which is why browsers do not give any special treatment to OV certs. In some sense, for Mozilla browser users, the definition of DV is (I think) the minimum set of things a CA must do to have its root CA cert accepted by mozilla foundation. Maybe Frank can write up a statement of what it takes to qualify a DV CA. Mozilla's CA policy implies that such a definition exists, but doesn't seem to give it. I did a first draft of definitions for DV, etc., at https://wiki.mozilla.org/CA:Glossary Please revise it as you wish. I think that, in practice, there are effectively two sets of claims widely used in email certs, and a third one is now being planned. The first two do not have vendor-independent names, so I will use one vendor's names for them: class 1 and class 2. Class 1 is for email what DV is for SSL. It proves a connection between the email address in the cert and the mailbox associated with that address, but nothing about the identity of the person behind the mailbox. I unilaterally coined the term AV (address validation or address validated) for this. class 2 proves something about the identity of the person behind the mailbox, but it may be little more than a person's name or employee number. I think the existing term IV (identity validation or identity validated) covers this. 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: Working on Perl bindings for NSS
Wan-Teh Chang wrote: On Wed, Sep 24, 2008 at 2:28 AM, Claes Jakobsson [EMAIL PROTECTED] wrote: snip The module itself will be licenced under the MIT license so if you want to include it with the nss distro please feel free to do so. My SVN repo is at http://svn.versed.se/public/ (altho I haven't synced the module yet from my local SVK repo) but I'll drop a not when that has been done. This sounds good. If we decide to include your work with the NSS distribution, we'll need to consult [EMAIL PROTECTED] about the license (http://www.mozilla.org/MPL/license-policy.html). If the Perl binding code is under the MIT license then that's OK in terms of the Mozilla license policy. The MIT license is compatible with every open source license known to me, including the MPL/GPL/LGPL scheme we use for NSS and other code. We have MIT-licensed code in the Mozilla tree already, and I see no problem with just including such code in the NSS release. 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: Documenting default trusted CAs
Nelson B Bolyard wrote: Dennis Darch wrote, On 2008-08-19 09:23: In the next update of our software product we are using NSS 3.11.9 to upgrade our LDAP client to support LDAP/SSL. I would like to include in our documentation a list of the public certificate authorities that would be trusted without having to be added to the client's cert8.db. Where would I look in the source code to find that list? Maybe Frank can answer that. I'm not aware of a page with a complete listing of the trusted CA certs in an easy-to-read form. Maybe I'm forgetting something. No, we don't yet have a single web page providing a list of all the pre-loaded root CA certs in readable form. For now the certdata.txt file is the only complete and authoritative source. 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: Comodo ECC CA inclusion/EV request
Robin Alden wrote: Sure, but CAs issue certificates to IP addresses too (as we discuss below) yet the policy does not allow for the possibility. Either the policy is imprecise, or it is being flouted by the CAs that issue certificates for IP addresses. You're correct, this is a gap in our policy, which assumes the more typical case of an SSL certificate being tied to a domain name. We can discuss revising the policy later, but for now I think it's reasonable to say that issuing an SSL certificate tied to an IP address is OK as long as the following is true: * the IP address is public, i.e., reachable from the public Internet * the subscriber owns/controls the IP address on a permanent basis, i.e., it's a static IP address assigned to the subscriber by the subscriber's ISP (either a standalone address or part of a subscriber-controlled block of addresses) This is basically the current policy with public static IP address standing in place of domain. As with domains, there are natural extensions to this case, most notably an SSL cert with multiple IP addresses included using SubjAltName; in this case the CA would do the verification for all the IP addresses referenced in the cert. (To others with more knowledge of this than I: Is there a notion of an IP wildcard cert, i.e., an SSL cert with a wildcard like 1.2.3.*, where the cert would be recognized as valid for an server with IP address in that range? If so, the implications for policy seem pretty straightforward: the CA should verify that the subscriber controls the entire IP address range.) We do not consider dynamic IP addresses when validating IP addresses. We look for static registration of an IP block. Ideally we want to see the applicant registered as the owner of the block containing the IP address being requested. Failing that we will accept written confirmation (directly) from the block owner confirming that the IP address in question is delegated to the applicant. IMO this meets the proposed policy requirements I outlined above. I'm sure that some of our customers would argue over how easy it is to replace these hostnames with FQDNs, but on reflection we do accept that the use of what we are calling hostnames here could provide for an increased risk that such a certificate could be used in a MITM attack, especially with the (topical) possibilities of practical DNS poisoning attacks meaning that there is an increased chance of an attacker being able to direct a reference to a server by what appears to be an internal hostname to an external server. Although not subject to the same threat of attacks on DNS we would also include non-internet routable IP addresses as being of increased risk. We therefore give a commitment that we will not issue any certificates which are signed by, or benefit from cross-signing by, or otherwise inherit trust from the ECC root which is the subject of this application that would otherwise be allowed by the provisions of section 2.4.1 (f) of our main CPS. Thanks, this addresses an issue I was concerned about. Frank, would you consider these practices of issuing certificates to hostnames* and also of issuing to non-internet routable IP addresses as being something to add to your problematic practices list? Yes, I'll do that. (Incidentally, I'm now calling it the potentially problematic practices list, because there's a lack of consensus on the extent to which some of these practices are problems in general.) In other words, Comodo would issue multiple certificates for the very same domain name? You could have multiple valid certificates for www.mozilla.com? [Robin said...] Yes, we would. Jean-Marc identified one case where it is desirable. There are also cases when a server has been wiped (and so they private key lost) and must be re-installed. I don't think it is realistic or appropriate to mandate that all currently valid certs issued by a CA have unique FQDNs associated with them; in other words, I think that having multiple certs with the same FQDN is not and of itself indicative of a problem. (I should also add that there's a similar case that's fairly common and unremarkable, where a CA issues a wildcard cert for, e.g., *.example.com, and also a cert for a specific domain otherwise encompassed in the wildcard, e.g., foo.example.com. As with the case of multiple certs with the same FQDN, here too we have the theoretical possibility of having one cert/private key pair that could be substituted for another without a typical user noticing.) To the best of my knowledge we've now covered all the outstanding issues for this request, and we're past the end of the second comment period. I'm going to proceed now to render a final decision. More later... Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo
Re: Comodo ECC CA inclusion/EV request
Frank Hecker wrote: Frank Hecker wrote: I am now opening the first public discussion period for a request from Comodo to add the Comodo ECC Certification Authority root certificate to Mozilla and enable it for EV use. This is bug 421946, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=421946 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Comodo The first comment period has closed, and I've made a preliminary decision to approve this request, per comment #17 in bug 421946. The second public coment period now begins, after which I'll make a final decision. We're past the end of the second comment period, and based on all the comments up to now I'm now ready to make a final decision. Of the additional issues that came up in the second comment period, a couple (wildcard DV certs and long-lived certs) I've already dealt with in a prior request, one (multiple certs with the same FQDN) I don't see as a reason for rejection of the request (per my previous message), and one (certs with hostnames and private IP addresses) I consider now moot based on the previous public statement/commitment by Comodo. Also, I've given my opinion that issuance of certs for static public IP addresses, though not strictly speaking addressed in our policy, is in fact consistent with the intent of our policy assuming ownership/control of the addresses is verified. Based on the resolution of these issues I'm therefore officially approving the Comodo request to add the Comodo ECC Certification Authority root certificate to NSS and to enable it in PSM for EV use. I have filed bug 450427 against NSS and bug 450429 against PSM for the actual changes: https://bugzilla.mozilla.org/show_bug.cgi?id=450427 https://bugzilla.mozilla.org/show_bug.cgi?id=450429 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: Comodo ECC CA inclusion/EV request
Frank Hecker wrote: Robin Alden wrote: snip Frank, would you consider these practices of issuing certificates to hostnames* and also of issuing to non-internet routable IP addresses as being something to add to your problematic practices list? Yes, I'll do that. Done: https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses As usual, others should feel free to make revisions as appropriate; it *is* a wiki after all. 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: Comodo ECC CA inclusion/EV request
Eddy Nigg wrote: Frank Hecker: Yes, I'll do that. (Incidentally, I'm now calling it the potentially problematic practices list, because there's a lack of consensus on the extent to which some of these practices are problems in general.) Frank, where is the lack of consensus exactly? IIRC the reason I changed the wording to potentially problematic was that some of the practices weren't necessarily problematic in all contexts, at least IMO. Thus, for example, distributing private keys using PKCS#12 is not necessarily a problem, rather it's a problem if the CA doesn't exercise proper care in how the keys are distributed. The issue here may be in how we interpret the word problematic. I was interpreting the term problematic to be simply a fancy way of saying this *is* a problem, as opposed to potentially problematic, which to me means this *could be* a problem. I saw that Kathleen is already asking new applicants for CA cert inclusions those questions from the Problematic Practices which I think to be quite effective. Yes, I encouraged Kathleen to collect that information, so we could get a better idea as to how widespread these practices are, and where they might constitute real problems. (I was also trying to anticipate any concerns you might express :-) 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: Comodo ECC CA inclusion/EV request
Eddy Nigg wrote: My point was that Comodo does issue certificates according to the problematic practices listed in our document. Not only that, it does more than one of those practices. You stated in the bug however that Comodo doesn't issue certificates according to the Problematic Practices! A fair point. My comment was based on the fact that Comodo isn't currently issuing DV certs under the ECC root, and there's no firm schedule for when they might do so. However you are correct that Comodo reserves the right to do so under the scope of the existing CPS, and Rob and Robin have stated that Comodo will expand the use of this root at some point. 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: Comodo ECC CA inclusion/EV request
Eddy Nigg wrote: As per your comment in https://bugzilla.mozilla.org/show_bug.cgi?id=421946#c17 you state that no problematic practices associated with this CA, but I found that in section 2.4.1 domain validated wild cards are issued, which is listed in http://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates My understanding is that this root and it hierarchy at present are not being used for DV certs, but Comodo could do so in future, per the existing CPS. We went through the issue of Comodo DV certs on a previous request; if you recall, my final determination was that the practices of issuing wildcard DV certs and long-lived DV certs, though potentially problematic, were not in my opinion sufficient to justify denying the request. That's my position in this case as well. 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: Wells Fargo CA inclusion/EV request
Frank Hecker wrote: I am now opening the first public discussion period for a request from Wells Fargo to add the WellsSecure Public Root Certificate Authority root certificate to Mozilla and enable it for EV use. This is bug 428390, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=428390 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Wells%20Fargo The first comment period has closed, and I've made a preliminary decision to approve this request, per comment #13 in bug 428390. The second public coment period now begins, after which I'll make a final decision. 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: Comodo ECC CA inclusion/EV request
Frank Hecker wrote: I am now opening the first public discussion period for a request from Comodo to add the Comodo ECC Certification Authority root certificate to Mozilla and enable it for EV use. This is bug 421946, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=421946 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Comodo The first comment period has closed, and I've made a preliminary decision to approve this request, per comment #17 in bug 421946. The second public coment period now begins, after which I'll make a final decision. 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: Comparison of OpenSSL and NSS
Julien R Pierre - Sun Microsystems wrote: Copyright owner : RSA security should be removed ! Netscape/Sun/Red Hats are the original developers of most of the code. But they don't hold the copyright (see GPL/LPGL/MPL licenses) Let's not confuse licensing with copyright ownership. AFAIK Netscape, Sun, and Red Hat between them do hold the copyright to the vast majority of the NSS code. The copyright holders have all agreed to license the code under the Mozilla tri-license (MPL/GPL/LGPL), so people can use NSS under the terms of any of those three licenses. However copyright ownership is not affected by this. In this connection, note that to my knowledge the Mozilla Foundation holds copyright to none (or at least very little) of the NSS code, because the Mozilla Foundation and its subsidiaries (Mozilla Corporation, Mozilla Messaging) have never employed any full-time NSS developers. The rights the Mozilla Foundation has with respect to NSS are by virtue of the MPL/GPL/LGPL license terms. Also, for people who are *really* interested in this question... I suspect that the copyright situation with regard to NSS is even more complicated than I've mentioned, because Netscape/AOL and Sun had a sort-of-joint-venture relationship (iPlanet) that IIRC involved some joint ownership of IP rights, and then AOL subsequently sold iPlanet assets (including IP assets) to Red Hat. However this doesn't change the basic picture with respect to licensing as far as downstream licensees (including Mozilla) are concerned. 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: Wells Fargo CA inclusion/EV request
Bruce wrote: Not my issue, but I would like to add some clarification. Its a chicken or the egg problem. A CA cannot start issuing EV certificates without first passing an EV Pre-Issuance Readiness Audit (see 35a of the Guidelines). On the other hand, a CA cannot have an WebTrust Audit for EV until they have been in operation for a minimum of two months. The pre-issuance readiness audit was put in place to bootstrap the process. Bruce, thanks much for the info. This confirms what I thought. 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: Wells Fargo CA inclusion/EV request
Eddy Nigg wrote: Frank, I'd like to know (again) what our policy is in regards of EV audit requirements. As I understand from the bug report, Wells Fargo didn't actually absolved the EV audit, but some EV readiness audit. I think we are past the time where we'd accept such audits? A quick answer, I can research more later... We had a discussion about EV audits against the draft EV guidelines, and decided we would stop accepting such audits after a certain date (June 30, 2008?). But I think EV readiness audits are a different issue. IIRC readiness audits are done when a CA has implemented the infrastructure for EV but has not yet accumulated a significant operational history of EV issuance. So any CA that is new to EV will likely do a readiness audit first. IIRC this was true of some other CAs we've dealt with -- they started out with readiness audits, started issuing EV certs, and then by the time we were able to consider their requests in some cases they were still covered by the readiness audit and in other cases had advanced to a regular audit. 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: Deutsche Telekom/T-Systems CA request
rainer_k wrote: If this is such a serious concern, why did Microsoft decicde to put this CA inside the Windows CA store and even distribute this via automatic update? Installment of the Telekom CA into Firefox and putting more restrictive policies for CAs into action in general are two different topics and should not be interwoven. I have not yet had time to read and respond to all the messages in this thread. However I do want to make two points: First, as Eddy Nigg mentioned, Mozilla does not have exactly the same policy as Microsoft with respect to adding root CA certificates. We are a public project in which anyone can participate, and our policy is designed to address the concerns that many Mozilla community members have about adding new roots. In particular, our community members want to have a reasonable level of assurance that CAs follow basic security practices when issuing SSL, email, or object signing certificates, and they want to have some publicly-available evidence regarding those practices. That is why our policy has some (relatively minimal) requirements regarding verification of subscribers' domains, email addresses, and identities (for SSL, email, and object signing certificates respectively). That is also why we want to see Certification Practice Statements or other published documents that state that such verification is done. Second, in the case of T-Systems the issue seems to be that T-Systems functions primarily as a root CA, not as a CA issuing end-entity certificates. Therefore the T-Systems CPS does not address practices relating to issuance of end-entity certificates. The solution seems to be that we need to look at the CPS documents for DFN and other subordinate CAs of T-Systems, or obtain some other public statement about the practices of these subordinate CAs. 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: GlobalSign requests (replacement root, EV)
On Jul 11, 8:21 pm, Frank Hecker [EMAIL PROTECTED] wrote: Frank Hecker wrote: GlobalSignhas submitted requests to include a replacement root certificate for an already-included root certificate (same public key, new expiry date) and to enable it and a secondGlobalSignroot for EV: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 https://bugzilla.mozilla.org/show_bug.cgi?id=406796 snip I think we now have all the information we need to start the first public comment period for this request, so I'm formally declaring it open. The first comment period is over, and I've made a preliminary decision to approve these requests; see my comments in the above-referenced bugs. The second (one-week) comment period is now open. The second comment period is now over, and based on my evaluation and comments thus far I'm formally approving these requests. I've filed bug 446407 against NSS to refresh the GlobalSign Root CA root cert, and bug 446409 against PSM to enable the refreshed GlobalSign Root CA root and the existing GlobalSign Root CA - R2 root for EV: https://bugzilla.mozilla.org/show_bug.cgi?id=446407 https://bugzilla.mozilla.org/show_bug.cgi?id=446409 Frank -- Frank Hecker ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: GlobalSign requests (replacement root, EV)
Frank Hecker wrote: Eddy Nigg wrote: snip Not sure what GlobalSign deems as a secure manner to provide PKCS12 files (including private keys) mentioned in 1.9.6.9 of their CPS. I'll ask about this issue. My apologies, I forgot to post what I found out. Briefly, GlobalSign is not currently doing this; the CPS language is there against the future possibility. I made them aware of our general concerns about CA generation and distribution of subscriber private keys (including pointing them to the relevant discussion threads, etc.). They are working with their auditors to come up with a mechanism that passes muster in terms of security. The bottom line is that I don't see this as an issue affecting the requests, given that a) no key generation and distribution is being done at present and b) at this time I have no reason to believe that GlobalSign might do this in an insecure manner. 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: Comodo ECC CA inclusion/EV request
Paul Hoffman wrote: Has anyone validated the ECC paramters they used? Not that I'm aware. There's a test site with a Comodo-issued ECC cert at https://comodoecccertificationauthority-ev.comodoca.com/ and the Comodo ECC root CA cert itself is available at http://crt.comodoca.com/COMODOECCCertificationAuthority.crt Are those sufficient input to do validation against, or do we need further information? 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: Public comment periods
Eddy Nigg wrote: I think that by committing every two weeks another CA to the public comments period (or alternatively as you started to do, twice a one week period) we can include and process potentially 26 CAs per year. This should be sufficient by estimating the number of CAs which are more or less ready and have information collection complete. Unfortunately I think that that rate is too slow. The problem is that as we clear existing requests new requests come in, and if we don't process existing requests fast enough then the queue of unprocessed requests will continue to grow without limit. Instead of artificially throttling the rate at which we process requests, I'd rather take CAs into public discussion as soon as we have sufficient information to do so. In practice some CA requests will be relatively straightforward to evaluate, and some will be more complicated. If you or anyone else feel that we need more time to discuss a particular request, just tell me and I will extend the public discussion period for that request as needed. 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: Public comment periods
Eddy Nigg wrote: Eddy Nigg: It's the time to discuss, which is obviously extended once there is a potential issue, it's the time one needs to review. Should have been It's *not* the time to discuss...' Understood. But note that from my point of view the start of the first public comment period is essentially the signal that the request is at a state where further public review is called for. (Of course you or anyone else could have been doing review prior to that, based on the information in the bug.) 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: Comodo ECC CA inclusion/EV request
Wan-Teh Chang wrote: In your summary of information for CAs, you should replace Modulus (key length) by EC parameters (named curve) for ECC roots. I've revised the information checklist to reflect your comments; see item 2.6: http://wiki.mozilla.org/CA:Information_checklist Please let me know if this is accurate, or needs further revision. 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: Comodo ECC CA inclusion/EV request
Paul Hoffman wrote: At 9:27 AM -0400 7/18/08, Frank Hecker wrote: Paul Hoffman wrote: Has anyone validated the ECC paramters they used? Not that I'm aware. I think that's unfortunate. It is easy for all of us to test the parameters for RSA certs, but few of us have software for testing ECC certs. Are there NSS, OpenSSL, or other open source utilities available for this purpose? Could you point me to more information on this topic? There's a test site with a Comodo-issued ECC cert at https://comodoecccertificationauthority-ev.comodoca.com/ ...which no browser will let me into. :-) For Firefox at least that's because we haven't added the root CA cert yet, though there might be additional reasons relating to the OCSP responder (see the bug for more info). I was able to add a security exception for this site and then could access it successfully (using Firefox 3.0.1 on OS X), however it's not clear to what extent Firefox was able to validate the cert signature. (Firefox still gives me a certificate did not verify for unknown reasons message.) 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: Public comment periods
Nelson B Bolyard wrote: I'm not clear on the separate purposes of the two comment periods. Is there a statement somewhere, of what their separate purposes are? What (if anything) are the would-be public participants supposed to do differently in one period than in the other? My intent is that I will start the first comment period at the point where I am reasonably sure that a) we have enough information to make a decision, and b) for cases where I'm leaning towards approval, that there are no immediately obvious showstopper problems with the CA in terms of our requirements. During the first comment period people have an opportunity to point out where I might be wrong about either (a) or (b). What is the event (other than the passage of a fixed amount of time) that marks the end of the first and the beginning of the second? At the end of the first comment period I make a preliminary decision to approve or reject the request, or I postpone consideration until some issue gets addressed or some question gets answered. This is the point at which I sit down and provide written justifications for why I'm doing what I'm doing. Assuming that I decide to do a preliminary approval or rejection, the second comment period is for people to point out where my justifications might be bogus or mistaken. My impression of these things, based on what I've seen so far, is that the difference is that the first period says We're thinking of approving this request. Will you object if we do? and the second one is We've tentatively approved this request. Do you object that we have done so? ;) Not quite; see above. The reason I decided to split the comment periods this way is that once I make a preliminary decision I really don't want to have to go back and reverse it. In the old system people didn't have a formal opportunity to register objections until after I'd already made a decision. In the new system I want to get the bulk of the objections raised up front, before I make any decision at all. 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: Decline in firefox usage due to lacking CA certificates
Rob Stradling wrote: Frank, is there any reason why you can't have multiple candidate CAs having their public discussion periods simultaneously? No reason at all; in fact, technically we have two in public discussion right now (GlobalSign and T-Systems). The major bottleneck is collecting the CA information and getting the last 10% of questions answered. Kathleen Wilson has some CAs that are in that stage now, and I've asked Gerv Markham to start the process on two more. There are also a couple of CAs that got bogged down at the public discussion stage earlier, and I'm going to see if we can move them forward. 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: EV SSL cert user experience
[EMAIL PROTECTED] wrote: I have specific question to a preferred setup of a EV SSL server PKI and how the user experience will be. Im not the expert on this, but I can perhaps give you a preliminary answer until the experts show up. Assume that a EV compliant primary root cert of CA X is accepted and preinstalled in Firefox 3.x (FF3). The hierarchi is now CA X PCA root | +- CA X SSL Issuing CA | +- SSL server cert for _www.domain.com_ https://webmail.tdcwebmore.dk/plugins/html_mail/fckeditor/editor/www.domain.com I guess that this is a setup without any problems and that FF3 shows it as a EV cert as long as the issued SSL cert include the CA's reported EV policy OID? Yes, my understanding is that this will work as long as the following is true: * The SSL cert has the proper EV policy OID value. * The cert for the CA X SSL issuing CA (subordinate to the root) has either the EV policy OID value (same value as that in the SSL server cert) or the AnyPolicy policy OID value. * The CA X PCA root cert has the EV policy OID value associated with it as metadata in Firefox 3. (In other words, we've approved the CA X PCA root for EV, and made the corresponding changes to the Firefox 3 code.) Ever if the PCA also has non-EV subCA's? Yes. Whether the PCA has other subordinate CAs (EV or not) is irrelevant, since they are not part of the cert chain in question. For the purpose of being backwards compatible with legacy browsers the CA X PCA will now obtain a subcertification from a widely recognised CA Y (e.g. Entrust.net) and the SSL server cert customers will be encouraged to install the path CA Y | +- CA X PCA root | +- CA X SSL Issuing CA | +- SSL server cert for _www.domain.com_ How does the browser resolve the path and does the user still experience the EV cert as an EV cert. In this case there are two possible paths from the SSL server cert to a trust anchor, one terminating in the CA Y root cert and another (shorter) one terminating in the CA X PCA root. My understanding is that Firefox 3 has special code that for the EV case ensures that the CA X PCA root is chosen as the trust anchor, and the SSL server cert is properly recognized as EV (assuming that the CA X PCA root is enabled for EV as described above). Note that there are real-life examples of this scenario already, and as far as I know they work fine. 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: Decline in firefox usage due to lacking CA certificates
Rob Stradling wrote: Frank, in Bug #421946 Comment #15 you said: I'll proceed with the first public comment period once I figure out where this request sits in the queue relative to other similar requests. If the public comment/discussion periods are not the major bottleneck, then can you explain why there has been no movement on this bug for over a month? Because I dropped the ball on that one, for which I apologize. I'll look at it and start public discussion as soon as I can. Frank P.S. Incidentally, I have no problem whatsoever with CAs pinging me directly (via email or phone or whatever) to remind me that their requests need attention. Please feel free to do that if ever you should need to. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Wells Fargo CA inclusion/EV request
I am now opening the first public discussion period for a request from Wells Fargo to add the WellsSecure Public Root Certificate Authority root certificate to Mozilla and enable it for EV use. This is bug 428390, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=428390 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Wells%20Fargo Some points worth mentioning about this request: * This is a new root (though note that Wells Fargo has an older root already in Mozilla). Initially it will have a subordinate CA used for issuing EV SSL certs, but as I understand it Wells Fargo will potentially use the hierarchy under this root for other types of certs (both EV and non-EV). * The flag problematic practices section at the end of the info document has the sentence fragment Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA. That's just the reference to checking for the practice. Kathleen forgot to add (no) or (not an issue) afterwards; Wells Fargo issues end entity certs through subordinate CAs. The same comment as in the previous item applies to the Long-Lived Domain-Validated SSL certs items; to my knowledge Wells Fargo does not issue long-lived DV certs. This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. 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: Decline in firefox usage due to lacking CA certificates
Thorsten Becker wrote: I'm responsible for a university site in Germany that is SSL secured, with a certificate issued by a CA which is trusted by T-Systems. The T-Systems cert is not (yet) included in firefox, the details can be seen in Bug 378882. As it happens, I will be starting the first public comment period for T-Systems today. If there are no problems with the request then we will be able to approve the inclusion of the T-Systems root certificate in a couple of weeks, and it will show up in a security update release of Firefox later this year. (I can't give you an exact estimate because it depends on NSS and Firefox development schedules.) So please act now and quicken the pace on CA inclusion! We are doing what we can. However by design we do not simply rubber-stamp CA requests. We have an official policy which was developed through a process of community consultation, and we follow a similar process of community discussion when considering CAs. We do have more people now working on CA-related tasks (unlike previously when I was the only person, and could do it only part-time). However the process will never be quick IMO. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Deutsche Telekom/T-Systems CA request
As I previously mentioned, I am now opening the first public discussion period for a request from T-Systems (a subsidiary of Deutsche Telekom) to add the Deutsche Telekom Root CA 2 root certificate to Mozilla. This is bug 378882, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=378882 Some points worth mentioning about this request: * T-Systems actually has two other root CAs, T-TeleSec GlobalRoot Class 2 and T-TeleSec GlobalRoot Class 3. Those are not included in this request (although of course we'd be glad to consider those as well in future). * T-Systems has undergone at least two audits, for ETSI 101 456 and WebTrust for CAs. The WebTrust for CAs audit is the relevant one for our purposes, since the WebTrust audit report we have is more recent. (Also, the ETSI 101 456 audit was apparently a self-audit, though there is some ambiguity about this.) Note that the WebTrust for CAs audit covered all three T-Systems root CAs. * There was apparently a bit of confusion about email certificates. As I understand it, T-Systems does not directly issue certificates usable for email. (T-Systems issues qualified certificates to individuals, but those do not contain email addresses, and are apparently used primarily in client authentication to web sites.) However T-Systems does have subordinate CAs, most notably the Deutsche Forschungsnetz (DFN, the German academic research network), that do issue email certificates and verify email account control per the relevant CPSs/CPs. This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. 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: GlobalSign requests (replacement root, EV)
Eddy Nigg wrote: This is perhaps the first EV request which doesn't have an operating OCSP responder at this stage. The EV guidelines requires it only in 2010 however I haven't come across a CA which doesn't provide this service *and* issues EV. As Nelson notes, I don't think GlobalSign is the only one, though I can't think of others' names right at the moment. In any case, GlobalSign is planning to offer OCSP in the future, it's not a current requirement of the EV guidelines, and not a requirement of our policy either. So it doesn't affect approval of this request one way or the other. Not sure what GlobalSign deems as a secure manner to provide PKCS12 files (including private keys) mentioned in 1.9.6.9 of their CPS. I'll ask about this issue. Even though Frank mentioned it in the bug and referred to the information checklist and after examining the CPS (not too thorough however), I couldn't clearly find out about how exactly email (and domain ownership) are verified. It merely states that Globalsign has the right to request proof of the ownership of the domain name or can ask the owner of the domain name to validate the request of the applicant. This seems somewhat vague to me. The same is true for email validation. GlobalSign however provides a limited liability of 100,000 Euro for invalid domain names, which should be incentive enough to actually do so in some way... ;-) GlobalSign has stated that they do in fact verify email account control using the typical mechanisms used by other CAs, and they will revise future versions of the CPS to state this more clearly. I too think they could have made this more clear up front, but I don't see a real issue here. Ditto re domain ownership. 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: The TLS Report
Eddy Nigg wrote: Also interesting choice of the CA, even though I realized that you happen to change your server cert quite frequently ;-) Well, the price was a factor :-) However what I found even more important was support for SubjAltName and the ability to get a certificate for both hecker.org and www.hecker.org with minimal hassle and expense. My original Go Daddy certificate was for www.hecker.org only, but then I switched my site so that hecker.org was the primary name and requests for www.hecker.org just redirected to hecker.org. This broke the browser cert checks, so I couldn't turn on redirection on the SSL side. (Now that I have the new cert I finally did that, so https://www.hecker.org/ gets redirected to https://hecker.org/) IIRC Go Daddy offered no simple/cheap way to include hecker.org as an alternate name to www.hecker.org on the same cert. They do offer UCC certificates that allow use of multiple domains, but the minimum price is $90/year compared to $30/year for a traditional single-domain cert. Also the documentation seems to indicate that this feature is intended primarily (perhaps only?) for cases where you use multiple TLDs, e.g., www.example.com vs. www.example.net vs. www.example.org; that may not be true in practice, but I didn't feel like spending $90 only to possibly find that Go Daddy's CA interface wouldn't handle my particular case. Note in that regard that the StartCom interface is actually not as flexible as I'd like. It forced me to specify www.hecker.org as the CN and hecker.org as a SAN, when I would have preferred it the other way around, since hecker.org is now the canonical site name. 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: The TLS Report
Eddy Nigg (StartCom Ltd.) wrote: Eddy Nigg (StartCom Ltd.): Frank Hecker: I tried out my own site on it, and got a C. LOL, I got a A 80 :-) Actually it doesn't honor SAN DNS extension...but it's a cute utility. Reached a A 82 as well, just need to use the CN value of the certificate. After regenerating the server private key (using a 2048-bit modulus), getting a new certificate (from StartCom), and changing the server ciphersuites, I managed to get a score of 84 (A), which matches the highest scores reported for other sites: http://tlsreport.layer8.net/reports/www.hecker.org?protocol=https Benjamin Black still hasn't published a detailed discussion of how the scoring is done, but here's some basic info based on my and others' experiences: * As Mohamad Badra previously noted, enabling EDH ciphersuites will greatly improve your score (enabling you to get a 100 score for key exchange). * Enabling only ciphersuites with FIPS-compliant algorithms gets you a couple of points at least. (I'm just using AES-256 and 3DES, with SHA-1; no RC4, no MD5.) * As Eddy noted, you get a higher score on the weak certificate test if the site name used matches what's in the CN (as opposed to what's in SubjAltName). In my case the CN is www.hecker.org, while SAN has both www.hecker.org and hecker.org; the TLSreport score for the site accessed through www.hecker.org is 9 points higher than when accessed through hecker.org (84 vs. 75). I have no good ideas as to how to further improve the score beyond 84. In particular, I'm puzzled as to how one might further improve the score on the default cipher and overall ciphers measures. 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: GlobalSign requests (replacement root, EV)
Frank Hecker wrote: GlobalSign has submitted requests to include a replacement root certificate for an already-included root certificate (same public key, new expiry date) and to enable it and a second GlobalSign root for EV: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 https://bugzilla.mozilla.org/show_bug.cgi?id=406796 snip I think we now have all the information we need to start the first public comment period for this request, so I'm formally declaring it open. The first comment period is over, and I've made a preliminary decision to approve these requests; see my comments in the above-referenced bugs. The second (one-week) comment period is now open. 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: GlobalSign requests (replacement root, EV)
Eddy Nigg wrote: Both bugs from above have status information incomplete and the entry at the pending page is also marked as incomplete (Red). Is this intentional and can/should I wait for any additional review? Sorry, that was an oversight on my part. I've updated the bug status information and changed the pending list to mark the entry as complete. (I just checked in those changes, so it may be an hour or so until they show up on the production site.) Can you guide me on the exact status of this request and how I should relate to the information in the bugs and pending page? This request is in the first comment period. After this comment period I will make a preliminary decision on whether to approve the request, and if so then we'll have a second (last call) comment period before final approval. Note that GlobalSign is a legacy CA, i.e., it has roots in NSS/Mozilla from before my time. There are three separate issues related to these requests: 1. Approval of the roots for EV. This is the main point of the requests, and I delayed bringing the request into public discussion until GlobalSign had completed its EV audit and made the report available (which just happened in the last week or two). IIRC the EV stuff looks pretty straightforward. 2. Refreshing one of the roots, i.e., replacing the current root cert with a new cert with a longer lifetime (same public key). IIRC the public key in question is a 2048-bit key, so this is pretty straightforward also IMO. 3. General review of the roots, since this never happened previously. IIRC the only thing out of the ordinary here was GlobalSign having some subordinate CAs operated by third parties. I can comment more on that as we get into the discussion. 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: Firefox 3 connection now results in ssl_error_bad_cert_domain
Bruce Keats wrote: Don't forget that if you have host names in the Subject Alternative Name extension, then ALL the names in the cert belong there, not all-but-one. But This is no different than it was in FF2. I don't think I fully understand the ALL the names in this context. What might help me is if can you elaborate with a simple example? I'll let Nelson or someone else provide the definitive answer to this, but I believe what he's saying is that, e.g., if you have three hostnames a.example.com, b.example.com, and c.example.com that are used for a given server, and you use SubjAltName, you should put all three names in the extension, as opposed to (e.g.) putting CN=a.example.com and then just b.example.com and c.example.com in SubjAltName. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
GlobalSign requests (replacement root, EV)
GlobalSign has submitted requests to include a replacement root certificate for an already-included root certificate (same public key, new expiry date) and to enable it and a second GlobalSign root for EV: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 https://bugzilla.mozilla.org/show_bug.cgi?id=406796 Kathleen Wilson has been gathering information for these requests; I've attached copies of her reports to each of the bugs. Also, GlobalSign just completed its WebTrust EV audit and got it published. I've updated the GlobalSign entry on the pending list accordingly: http://www.mozilla.org/projects/security/certs/pending/#GlobalSign (Note that I checked in GlobalSign-related updates for this list just a few minutes ago, so it may take an hour or two for them to show up on the site.) I think we now have all the information we need to start the first public comment period for this request, so I'm formally declaring it open. Based on prior experience I'm going to fine-tune things a bit and set this first comment period at a week long, unless we need more time. So my tentative plan is to make a preliminary decision on these requests late next week. Frank P.S. Note that I think this is the first request for which we're using the new information checklist at http://wiki.mozilla.org/CA:Information_checklist Thanks go to Kathleen for all her work in collecting the information! -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: questionable CA practices: CA's generating users' private keys
Eddy Nigg wrote: From what I've heard about such practices is, that the PKX file is password protected and delivered by simple email. But obviously anybody getting hold of the mail and file can easily brute-force attack it with a simple script. I think this is the issue Nelson is addressing. Receiving a PKX file from a CA web site doesn't really involve the same risk. I'm unclear on what you're saying here: Are you saying that sending a copy of the PKCS12 file to a user via email is less secure than having the user go to the web site and retrieve it himself? But if the CA tells the user where to download the PKCS12 file, and sends those instructions via email, I'm not sure what the difference would be -- someone could intercept the email and then download it also. (Although CAs could presumably detect the double download case and at least be aware that something non-standard was going on.) 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: make sure upgraded users get new cert8.db
Nelson B Bolyard wrote: 2. Mozilla's trademark policy says that if you change certain things about Mozilla in your own build or packages, then you cannot release your build using Mozilla trademarks (e.g. the Firefox brand name). The set of trusted root CA certs is one of those things, I believe. See http://www.mozilla.org/projects/security/certs/policy/ (last 2 paragraphs) and http://www.mozilla.org/foundation/trademarks/policy.html The CCK page cited above suggests that if you limit distribution of the modified browser to just your company or institution it may be OK to retain the trademarks. Maybe Frank Hecker will say more about that. Strictly speaking the Mozilla Foundation doesn't evaluate and approve potential uses of the Firefox trademarks (word mark and logo); that's done by the Mozilla Corporation. Send an email to [EMAIL PROTECTED] and explain your request. My personal opinion (FWIW) is that organizations should be able to distribute Firefox versions with modified root lists within the organizations without running afoul of trademark licensing restrictions. 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: Entrust EV request, second round
Frank Hecker wrote: We've completed the first round of public comment on the request from Entrust to have its new Entrust Root Certification Authority root enabled for EV. Based on the results of the first comment period and other available information, I'm inclined to approve this request, and am now starting a second public comment period (one week long) on this request. For more information see comment #19 in bug 416544: https://bugzilla.mozilla.org/show_bug.cgi?id=416544#c19 The second comment period is now over, with no further comments received. Based on my evaluation and the comments received thus far, I am officially approving this specific request to enable the Entrust Root Certification Authority for EV use, and will now proceed to file a bug against PSM for the actual change. 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: Entrust EV request, second round
Frank Hecker wrote: The second comment period is now over, with no further comments received. Based on my evaluation and the comments received thus far, I am officially approving this specific request to enable the Entrust Root Certification Authority for EV use, and will now proceed to file a bug against PSM for the actual change. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=442561 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: Update on DigiNotar and Entrust
David E. Ross wrote: Has the failure by Entrust to enforce its policies against DigiNotar been brought to the attention of Entrust's auditors? I think it should. For the record, Entrust understands what our concern is and has been cooperative in trying to come up with a way to address it. However the problem is that even if Entrust were to revoke DigiNotar's intermediate CA certificate that would not help resolve the problem, for the reason I mentioned earlier (Firefox/Thunderbird et.al. don't do revocation checks for CA certs). 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: Update on DigiNotar and Entrust
Eddy Nigg wrote: Perhaps Nelson can provide more information about the road map for CRL fetching, but it will be soon supported by NSS. This would solve the problem once it is. Note that there are other things besides CRL checking per se that I'd like to see in NSS. There seem to be a lot of scenarios where we'd like to have certain things happen from a policy point of view, but we'd need enhancements to NSS (or PSM) to implement them from a technical point of view. As I written before many times, I'd be happy to work to get Mozilla Foundation funding for NSS/PSM development, provided that there are people who can do the work. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Entrust EV request, second round
We've completed the first round of public comment on the request from Entrust to have its new Entrust Root Certification Authority root enabled for EV. Based on the results of the first comment period and other available information, I'm inclined to approve this request, and am now starting a second public comment period (one week long) on this request. For more information see comment #19 in bug 416544: https://bugzilla.mozilla.org/show_bug.cgi?id=416544#c19 Frank P.S. Note that I haven't forgotten about the DigiNotar/Entrust issue we've discussed previously. I'll post an update on that later today. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Entrust EV request
Frank Hecker wrote: I've been looking at a request from Entrust (bug 416544) to (among other things) have its new Entrust Root Certification Authority root enabled for EV. This is a new Entrust root that was approved for inclusion last year by Gerv (bug 382352) and subsequently added to NSS (bug 387892). \snip Entrust recently completed and published a WebTrust EV audit for this root. (There's a WebTrust audit as well.) At first glance everything looks in order. I'm therefore opening up an initial public comment period for this request. At the end of that comment period I'll make a preliminary determination whether to approve the request or not, and then we'll have a final public comment period before I make a final decision. It's now been a week since I opened the first public comment period on this, and there haven't been any new comments in the last few days. Would anyone object if I went ahead and rendered a preliminary decision on this request? (Then we'll have a second public comment period.) 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: Problematic Practices
Wan-Teh Chang wrote: That page lists Allowing external entities to operate subordinate CAs as a problematic practice. I think that a better title for that page would be potentially problematic practices. This is not really a binary good vs. bad issue. There is a spectrum of possible practices, some of which are really not problematic at all, and some of which are. If a company or school needs to issue a lot of certs to its internal servers, what is the recommended practice? I always thought the organization should operate an intermediate CA subordinate to a root CA. There are a number of possible options and associated practices. For example, one option would be for a commercial CA to operate a subordinate CA on behalf of an organization, with the organization serving only as an RA. Another option would be for the commercial CA to authorize the organization to operate a subordinate CA on its own premises, but constrain the subordinate in terms of what types of certs it can issue. And a third would be for the organization's subordinate CA to have broad powers to issue any types of certs, for any domain, as well as to create its own hierarchy. As the amount of autonomy granted to the organization increases, so do potential risks: the organization might not be as diligent in key protection as the commercial CA, it might be more lax in its verification procedures, and so on. That's why I think it's worth marking this practice at least with a yellow flag, as being worthy of further investigation. 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: Entrust EV request
Nelson B Bolyard wrote: Bruce wrote, On 2008-06-06 14:46: snip Business ID is generally performed through third party database look- ups. Individual ID is accepted by fax. Is that good enough for Individual ID? Can you detect if an individual faxes a stolen ID? Before we go too far down this path... I believe that having people fax in identity documents (whether individual or corporate) is a fairly common and accepted practice in the CA world. Unless someone can show me that I'm wrong and that Entrust's practices are significantly out of line with the rest of the industry, this is not an issue I'd see as relevant for this particular request. This touches on the point I made earlier about reasonable measures as used in our CA policy, and the term commercially reasonable as used in US and Canadian legal contexts. The contrasting legal term to commercially reasonable is best efforts, which is a more stringent standard implying (in a CA context) that the CA would take pretty much any and all measures practicable to verify identity (leave no stone unturned) and would strive to minimize as much as possible the possibility of accepting a fraudulent application. In my opinion the level of verification for IV/OV certs, as practiced in the CA industry and required by our policy, corresponds to a commercially reasonable efforts standard. If we want to apply a best efforts standard then IMO that's what EV is for. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Entrust EV request
I've been looking at a request from Entrust (bug 416544) to (among other things) have its new Entrust Root Certification Authority root enabled for EV. This is a new Entrust root that was approved for inclusion last year by Gerv (bug 382352) and subsequently added to NSS (bug 387892). (NOTE: This has nothing to do with Entrust legacy roots in NSS, and nothing to do with Entrust cross-signing of other CA's roots. AFAICT this root is used only for Entrust EV certificates. In bug 416544 Entrust has also requested EV status for its legacy roots, but I'm handling that as a separate issue.) Entrust recently completed and published a WebTrust EV audit for this root. (There's a WebTrust audit as well.) At first glance everything looks in order. I'm therefore opening up an initial public comment period for this request. At the end of that comment period I'll make a preliminary determination whether to approve the request or not, and then we'll have a final public comment period before I make a final decision. This idea of having two comment periods is one I think I mentioned previously in this forum. You can consider this a first call for comments, and then we'll have a last call if/when I do a preliminary approval. This is the first time we've done it this way, so I'll arbitrarily set the first comment period at 2 weeks, and the second one at 1 week; we can make these longer or shorter as needed. For more information about the Entrust EV request please see the pending list entry for Entrust: http://www.mozilla.org/projects/security/certs/pending/#Entrust For more information about the previous request from last year please see the Entrust entry in the included list: http://www.mozilla.org/projects/security/certs/included/#Entrust Note that I checked in Entrust-related updates for these list just a few minutes ago, so it may take an hour or two for them to show up on the site. 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: Entrust EV request
Eddy Nigg (StartCom Ltd.) wrote: Does the document http://www.entrust.net/CPS/pdf/webcps051404.pdf not apply for this root and if so how do you know about it? Per Entrust, at present this root has only one subordinate CA, the Entrust Certification Authority - L1A used to issue EV certificates. So in that sense, yes, the governing CPS for the hierarchy is the EV CPS. 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: Modulus length (was Re: Draft CA information checklist)
Paul Hoffman wrote: At 11:02 AM -0400 5/30/08, Frank Hecker wrote: I'd be glad to soften the language about cause for concern, but I still want to flag 1024-bit roots as worthy of a further explanation. (E.g., is this a root created some time ago that is only now being proposed for inclusion? Was/is the root intended for use in low-end devices where performance was deemed an issue? Did the CA not think about the issue of modulus length at all? And so on.) Ah! That sounds reasonable. Cause for further checking covers that without making it seem that we're concerned just about the length. I made a change to the wiki page to reflect my previous comments. BTW, I would flag *all* ECC certs with Cause for further checking due to the very low amount of interop testing that has been done with them. Again, not to say don't do this, just we want to ask a few questions that might start a dialog. I haven't made a change for this yet. I think I need a separate questions relating to the public key scheme used; that would be an appropriate place to discuss this. 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: Modulus length (was Re: Draft CA information checklist)
Paul Hoffman wrote: What does is cause for concern mean when the majority of the certificates in our list are 1024 bits? (I think that is still true) As noted by others, the checklist is for new roots, not legacy roots. If we're going to have a gradual transition to 2048-bit modulus length for RSA keys, I think it's legitimate to question why a CA is applying to have a 1024-bit root included. I'd be glad to soften the language about cause for concern, but I still want to flag 1024-bit roots as worthy of a further explanation. (E.g., is this a root created some time ago that is only now being proposed for inclusion? Was/is the root intended for use in low-end devices where performance was deemed an issue? Did the CA not think about the issue of modulus length at all? And so on.) As for having a formal schedule for transition (i.e., not accepting new 1024-bit roots after a certain date), I think that's a good idea. As for the ECC question: 256 bits is equivalent to 128 bits of symmetric strength, as in AES-128. Thanks! 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: Including FNMT cert in Firefox 3 (Spanish government)
Eddy Nigg (StartCom Ltd.) wrote: Just for the better understanding, but there is no preferential treatment for any type of certification authorities. The only exception which has been made, was the recent adding of roots and acceptance of CAs which issue extended validation (EV) certificates. For the record, that's not *quite* true. In the past we had a concern about including root CA certificates for government-operated CAs below the country level, e.g., CAs operated by municipalities and regional governments. Our concern was based on the impact on browser footprint (especially for mobile Firefox) of adding root CA certificate data for what could turn out to be hundreds of government CAs, combined with the time that we'd have to spend evaluating requests from all those CAs. Because of that we postponed considering applications from regional/local government CAs, including ACCV if I recall correctly. We've discussed whether our official policy should address the question of including government CAs below the country level, but we never could reach consensus on what to do. One option we considered was having localized versions of the root store, so that, for example, Firefox users would not see roots for ACCV, etc., unless they were using one of the Firefox versions localized for Spain and its regions (e.g., es-ES, eu, ca, etc.). However there was strong opposition expressed to having localized root lists, and in any case we don't currently have the technical capability to do that. Given the lack of consensus, I think the best course is simply to consider requests from local/regional government CAs on a first-come, first-served basis, just as we do for requests from commercial CAs. However I believe we should prioritize requests for country-level government CAs over requests for local/regional government CAs, whether in the same country or a different one. 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: Deutsche Telekom Root CA 2 inclusion into Firefox 3
rainer_k wrote: Since several months a lot of people from German Universities and research institutes are waiting for inclusion of Deutsche Telekom Root CA 2 into the Firefox built-in root certificates. Today I downloaded FF3 RC1 and was disappointed by not finding it there. Apparently it is still on the pending list http://www.mozilla.org/projects/security/certs/pending/#T-Systems Does anybody know whether it will be included in the final FF3 version? No, it will not be included in the first release of Firefox 3.0. Firefox 3 RC1 contains all the roots that will be in that release. Other roots, including this one, will be considered for inclusion in later update releases of Firefox 3 (e.g., 3.0.1, 3.0.2, etc.). Since almost all Firefox users get these update releases through the Firefox automated update mechanism, any new roots added will quickly be available to almost all Firefox users. In terms of schedule, right now we have over 40 CA requests pending. I have someone else working with me now to help clear the backlog, but it still takes a lot of time to process each request. At present we are giving priority to CAs issuing Extended Validation certificates, since EV support is a major new feature in Firefox 3. However your request is relatively early in the queue, so once we get through the EV requests we should look at your request soon thereafter. 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: Including FNMT cert in Firefox 3 (Spanish government)
Nelson B Bolyard wrote: It's pretty apparent that NONE of the people who have been responding to you in this thread had any idea that you were affiliated with Mozilla. I think this may be the first thread in which you've ever posted in this list/newsgroup. Maybe you should introduce yourself. You may be well known in certain circles, but in this newsgroup, you're unknown. Personally, I will look for confirmation from Frank before proceeding. I'm sorry, proceeding with what? Should I draw the conclusion from your comments that you are now the new person in charge of certificates for Mozilla Foundation replacing Gerv? As NSS module co-owner, I share in the responsibility for ensuring that the certs put into NSS have followed Mozilla's policy. And to add to this, for Pascal's benefit: I am responsible for the overall process of evaluating root CA certificates for inclusion in Mozilla, and I make the final decisions. Gerv has been at school and so has not been involved with certificate stuff for the past 9 months or so; however he may do some cert-related work this summer. Finally, we have a new person, Kathleen Wilson, helping gather information from CAs for use in our evaluation. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CA pending and included lists updated
I've updated the root CA certificate pending and included lists to reflect all the new roots that got approved in time for Firefox 3 RC1: http://www.mozilla.org/projects/security/certs/pending/ http://www.mozilla.org/projects/security/certs/included/ Some additional comments in relation to this: * As Kathleen gathers more information about the pending requests I'll start adding more CA entries to the pending list. * I'm thinking about writing a script to take the certdata.txt file and generate a minimal set of entries for the included list for all the legacy roots. I don't know when I'll have time to do this, so if someone else wants to try writing such a script I'd certainly appreciate it. * I'm thinking of making minor tweaks to the format of the entries. In particular right now the entries have a single place for the authorisation bug report, and a single place for the inclusion bug report. However with EV things are more complex: We have the possibility of having a bug requesting an upgrade of an existing root to EV, and a separate bug to make the EV change in PSM. So I'll likely change the entries to allow for the possibility of two additional bug types. 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: Including FNMT cert in Firefox 3 (Spanish government)
Nukeador wrote: One doubt, how are the new certificates included in Firefox? With new releases? Are they updated from a server? New root certificates are first added to NSS (the cryptographic library used by Firefox) and then new releases of NSS are incorporated into future versions of Firefox. We do not currently have a mechanism to update the root certificate list from a server. However Firefox does have an automated update mechanism that is used by almost all Firefox users, so once a new Firefox version is released the vast majority of users (90% or more) will be updated to the new release within a few weeks. New Firefox versions are released every one or two months to address security vulnerabilities or other bugs. However because it takes time for us to process CA requests, it may be 6 months or more from the time a request is submitted to us by a CA and the time a version of Firefox including that CA's root is released. 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: Looking for help in processing CA inclusion requests
Frank Hecker wrote: I'm therefore looking for people who are willing and able to help specifically with the information-gathering phase of processing CA requests. Note that I found someone to help with this. Kathleen Wilson will be assisting with information gathering on CA-related bugs; Kathleen used to work for VeriSign, and knows her way around a CPS. I've asked Kathleen to start with various outstanding EV-related requests and make sure we have all the necessary information to proceed with an evaluation. I'll take the lead when we get to the evaluation and public comment period, as before. More later as I start to hand over various bugs to Kathleen. 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: Certificate Vulnerability
Eddy Nigg (StartCom Ltd.) wrote: Therefore I think it's wrong to categorically deny OpenSSL as a useless piece of code not worthy to be used by CAs - just because some code-hero (or script-kiddy) had it wrong. That's certainly no the case! You're right, my comment was a bit snarky in a way I didn't really intend, and I apologize for that. I agree that OpenSSL is a good product (and one that the Mozilla Foundation has helped fund some development for, BTW), and in any case the present problem is really an OpenSSL on Debian problem, not an OpenSSL problem per se. However it's still unclear to me how many public commercial CAs have incorporated OpenSSL+Debian, or even just OpenSSL, as a core part of their infrastructure. You're willing and able at Startcom to hand build large parts of your CA system, but I'm not sure if that's common among public commercial CAs, or whether Startcom is unusual in this regard. I'd rather guess that most public commercial CAs are deploying off-the-shelf commercial CA software bought from a third party. Frank P.S. Since we're talking about hackable CA software, I'll also mention the Dogtag project out of Red Hat, the open source version of the commercial Red Hat Certificate System. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certificate Vulnerability
David E. Ross wrote: See http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0166. Discussion of this at the Risks Forum 25.15 indicates that All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. See Debian OpenSSL Predictable PRNG Toys and Debian OpenSSL Vulnerability at http://catless.ncl.ac.uk/Risks/25.15.html. The recommendation is that all affected root certificates be revoked and replaced. The question is whether any of the root certificates installed in the past two years or are approved or under review are affected. I presume that by affected root certificates you mean root certificates with key pairs generated using OpenSSL on Debian-based systems, correct? The only CA I can think of that would possibly be in this situation is CAcert, and of course it's not even applying for inclusion at this point. Maybe I'm naive, but I can't imagine any commercial CAs are using OpenSSL for CA functions -- but in any case we can certainly ask CAs about this. Could you please file a bug on this against mozilla.org / CA certificates and assign it to me? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Looking for help in processing CA inclusion requests
As I think I've mentioned previously, we've got a big backlog of CA inclusion requests, and I am not going to be able to clear it all by myself. It turns out that a major bottleneck in processing CA requests is the time and effort needed to gather basic information about CAs: getting copies of root certificates, figuring out what types of certificates CAs actually issue, tracking down CPS sections dealing with subscriber verification, determining what subordinate CAs exist and how they're controlled, verifying the authenticity of audit-related documents, untangling any cross-signing arrangements a CA might have entered into, getting URLs for example sites using certs issued by the CA, ascertaining the status of OCSP support, and so on. It's only when we have all this information that we can do a reasonable job of evaluating CAs to determine if they comply with our policy and don't have technical issues that would cause problems with our software. In fact, it's probably fair to say that once we obtain complete and accurate information for a given CA we've probably done 80% of the work needed to properly evaluate it. I'm therefore looking for people who are willing and able to help specifically with the information-gathering phase of processing CA requests. This does *not* mean that I'm not interested in having more people participate in the CA evaluation phase (e.g., as have people like Eddy, Nelson, and others). It's just that, as noted above, I think more effort put into the information-gathering phase will pay off in terms of making evaluations easier. If you're interested in helping with this on a volunteer basis, great, I'd be happy to talk with you and explain what needs doing. However note that I'm also willing to talk with people interested in doing this on a part-time consulting contract. The major difference is that if you want to do it as a volunteer then you don't necessarily have to know lots about CAs right now (I'm willing to help you get started), and you can work on this whenever you have spare time and feel like doing it. On the other hand, if you want to do this as a paid consultant then I expect you to have relevant experience and knowledge in the CA/PKI space and to be able to commit to a minimum number of hours per week. Note also that this is not an either/or situation: Because we have lots of CA requests to process and they can be done independently, we could in theory have multiple people working on this. (I've already talked to two people who've expressed interest in doing it as consultants.) However I have a limited budget for any consulting work, so I'm going to be somewhat conservative in terms of hiring consultants, If you're interested in helping with this, please contact me directly via email. If you're interested in doing this on a consulting basis, please include information on relevant experience (e.g., a CV/resume), your typical rates, and the minimum and maximum hours per week or month you'd want to work. 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: Entrust CA, Staat der Netherlanden CA, Proposal
Michael Ströder wrote: This whole issue cannot be resolved on this mailing list. Very likely Entrust takes $$$ from the sub-CAs. So they are in charge of clarifying this with their sub-CAs. If I'd be a representative of the Mozilla foundation I'd write them an e-mail with some critical questions they must answer within a certain time-frame. If the answer is not satisfying turn off the e-mail trust flag after this time-frame. I think I may have mentioned this already, but I'm already in contact with Entrust on these issues. 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: Entrust CA, Staat der Netherlanden CA, Proposal
Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: snip Eddy, I think it would be unwise (to put it mildly) to make a major change like disabling Entrust's email trust bit in a rush. We have no idea at this point what the impact of a change like that would be. And in any case the change is irrelevant to Firefox 3, since AFAIK Firefox would never consult the email trust bit. I took this comment from the bug also to here, since I think it more appropriate to discuss it at the mailing list. I think we have some opposing views on the subject. Well, it isn't the first time... :-) So let me make my own views clear on two points that you made on we ma have some opposing views: First, with respect to the impact of turning off the Entrust email trust bit, my concern is as follows: There may Entrust-controlled subordinates under the Entrust root that issue email certificates, and also non-Entrust CAs cross-signed by Entrust (like DigiNotar) that issue email certificates. Unlike DigiNotar, some of those subordinate CAs or cross-signed CAs may actually comply with Mozilla CA policy with regard to issuing email certificates. If so, I'd like to look at the possibility of adding their CA certificates as trust anchors, so that their email certificates will continue to work, and so users of Thunderbird and other Mozilla-based mail clients will not be unduly impacted by any disabling of email trust at the Entrust root level. I especially interested in whether any of the CAs waiting in our request queue have cross-signing arrangements with Entrust. If so, that may affect the priority we assign to evaluating their requests. There may be other CAs that are taking advantage of Entrust cross-signing to get their certificates recognized in Firefox, Thunderbird, etc., but have never submitted a request to us to include their roots. I am less worried about these CAs, but it might be nice to at least be able to tell them what we're doing and ask them to submit their own inclusion requests. Second, with regard to schedule: We are at a critical point in the Firefox 3 schedule, with Firefox 3 RC1 coming up fast. Firefox 3 does not use the email trust bit, so there is no need to tie any Entrust email trust bit changes to the Firefox 3 schedule. Instead we should look at the schedule for upcoming update releases of Thunderbird and SeaMonkey, and determine what sort of timeframe we have for making a change like this. 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: Entrust CA, Staat der Netherlanden CA, Proposal
On Fri, May 2, 2008 at 8:08 AM, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote: In comment https://bugzilla.mozilla.org/show_bug.cgi?id=431621#c5 the representative of DigiNotar (Kick) notes that their CA root has been cross-signed by Entrust. Now this effectively circumvented our policy in case of DigiNotar. DigiNotar is not alone in having a root cross-signed by Entrust; this was apparently fairly common practice among new CAs trying to get recognized in browsers. This issue will take a while to sort out I think. I don't know exactly how widespread this practice was/is, and I think there are also some technical issues in NSS regarding certificate path processing that may affect this. As I understand, until the release of FF3 no new CAs will be included and approved. That is half true. I will still consider CA applications during the time between now and Firefox 3 launch, and if appropriate I will approve new CAs for inclusion and file the necessary bugs against NSS and (for EV) PSM. However as a practical matter I think any new CAs approved past today will not appear in Firefox until the 3.0.0.1 update release (at the earliest). I suggest that we invest our time to bring our house somewhat in order before we continue. I would like to put the following points to the agenda: snip I agree that this would be a useful time to do some housekeeping work. Frank, could we work out a plan and time frame for the points above? Are there other issues which should be added? Other suggestions, objections? Besides the points you mentioned, here are some things I think need to be done: 6) Make sure that bugs have been properly filed for all known CA requests. 7) Make sure that all bugs forCAs have a correct status. (For example, mark bugs as RESOLVED FIXED where appropriate). 8) Make sure the included page on www.mozilla.org is revised to reflect all new CAs approved for inclusion as of now. 9) Make sure the pending page on www.mozilla.org has an entry (possibly very minimal) for all CA requests for which bugs have been filed. 10) Find a person or persons to help with basic information gathering on CAs. (This is somewhat different from your point about the overall CA decision process). The items above are actually my highest priority right now. I think we need to have correct information for where we are right now before trying to start major new projects like CA management tools. Frank -- Frank Hecker ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DigiNotar EV root inclusion request
Frank Hecker wrote: DigiNotar has applied to add a new root CA certificate to the Mozilla root store and enable it for EV, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=369357 snip I have evaluated this request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve the request after a public comment period. Based on the results of the public comment period, this application is in sort of a half-way state: The basic inclusion request (for SSL and object signing trust bits only) looks good, but there are some remaining open questions regarding enabling DigiNotar for EV (mainly Eddy's concern about EV re-audit). Rather than delay this application indefinitely until those questions get resolved, I've decided to proceed in two steps. For step 1 I'll be formally approving inclusion of the DigiNotar root in NSS, with SSL and object signing trust bits enabled (no email trust bit). In step 2 I'll make a decision about approving the DigiNotar root for EV, once we have more information. Formal approval for step 1 will follow shortly. Frank P.S. Note that I'm shortening the normal public comment period somewhat. I'm doing that because based on the public comments I see no impediment to including the root for basic SSL and object signing, and I'd like to have Kai include it with the NSS changes for Network Solutions. The issues still under discussion are the email issue and the EV audit issue. The comment period remains open as far as those issues are concerned. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: EV email usage
Frank Hecker wrote: Appendix C of the EV guidelines contains requirements relating to EV certificate extensions. My apologies, that reference should be to Appendix B of the EV guidelines. 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: EV email usage
Eddy Nigg (StartCom Ltd.) wrote: Perhaps in that case email addresses MUST not be included in server certificates and extended key usage MUST be present and NOT include E-mail protection. I'm not 100% sure about any requirement in that respect and/or if additional key usage (such as Key/Data Encipherment, Email protection) may be present or not. Or if there is a explicit requirement either way to make sure these certificates can't be use for email. Appendix C of the EV guidelines contains requirements relating to EV certificate extensions. For subscriber certificates extendedKeyUsage is *not* required, and not mentioned explicitly in the guidelines; even keyUsage is optional. If keyUsage is present, the only requirement is that it *not* include keyCertSign and cRLSign; nothing is mentioned about keyEncipherment, etc. The EV guidelines reference RFC 3280 as the guiding document on matters not addressed in the EV guidelines themselves. Section 4.2.1.7 of RFC 3280 allows (and recommends that) email addresses to be included in a certificate using the subjectAltName extension; it also says Because the subject alternative name is considered to be definitively bound to the public key, all parts of the subject alternative name MUST be verified by the CA. Note that this requirement applies no matter what the values of keyUsage or extendedKeyUsage happen to be. So my interpretation is as follows: Nothing in the EV guidelines mandates that email addresses be included in an EV SSL certificate, and nothing in the EV guidelines prohibits email addresses from being included in an EV SSL certificate. However if email addresses *are* included in an EV SSL certificate, then the EV guidelines implicitly require that they must be verified by the CA. This is a consequence of the EV guidelines' requirement in Appendix B that EV certificate fields and extensions not specified in the EV guidelines must be set in accordance with RFC 3280. 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: EV email usage
Eddy Nigg (StartCom Ltd.) wrote re email addresses in EV certificates: Can somebody else have also a look at this? In case the claims are correct and email address fields are allowed or required for EV SSL server certificates and *no* extended key usage is set *and* validation of the email address does not have to be performed, I suggest to take this to the CAB forum urgently! I just looked at the latest EV guidelines, doing a search for various email-related terms (e.g., email, e-mail, RFC 822, rfc822, etc.) and also reading section C in detail. As far as I can tell, the guidelines do not mention email addresses in any context relating to the content of certificates. There certainly does *not* appear to be any EV-related requirement that email addresses be included in EV certificates. I also looked at real-life examples of EV certificates from several CAs. None included an email address. Where present, the Certificate KeyUsage extension had values of Signing and Key Encipherment, and the Extended Key Usage extension had values of TLS Web Server Authentication and TLS Web Client Authentication. (One certificate also included the Netscape Certificate Type extension with values SSL Client Certificate and SSL Server Certificate.) 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: Governing EV
Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: I agree with your general point, namely that we should start doing better tracking of audit dates, particularly for EV audits. However I don't know at this point what would be appropriate in terms of setting timeframes for when an audit would be considered to be out of date. snip Then there is only one answer for this: *The EV criteria!* Apply the EV guidelines according to what it says. The problem is that while the EV guidelines contain an explicit requirement for annual audits, they don't dictate things like the length of the grace period that browser vendors should give CAs once their audits expire. In fact, it's not even clear from the EV guidelines exactly when an audit expires; for example, should we count from the end of the period for which the audit applies, from the date that the audit report was actually issued, or from some other date? It's not clear to me why we would need this. No? :-) To be clear, I agree with you that we should remove our EV blessing from CAs that don't meet the EV guidelines requirement for annual audits. When I wrote the sentence above, what I meant is that I didn't understand why we needed a special mechanism (in NSS, Firefox, or wherever) just to turn off EV capability for CAs, when we already had a general-purpose mechanism to do automated updates for any sort of security issue. Second, we already have the ability to quickly update Firefox (or SeaMonkey, or Camino) through the normal security update mechanism. Mhhh...that might be a lot of annoying updates quickly to come, if we adhere to the EV criteria...Which in itself doesn't guaranty that users update their software. I think there should be something better than that, seriously. First, if and when we do have to turn off EV for CAs, we don't need to do it one by one. We can simply schedule such changes for the normal security update cycle, and batch changes for multiple CAs into a single update release. Second, the security updates are very effective in terms of getting changes out to users. For example, for Firefox 2 we got 90% of all users upgraded within a week of releasing a new Firefox 2.0.0.x update, and overall got ~95% penetration for the updates: http://blog.mozilla.com/security/2007/06/18/time-to-deploy-improvement-of-25-percent/ http://arstechnica.com/news.ars/post/20070518-firefox-users-lead-the-way-in-keeping-up-to-date.html Since the automated update mechanism is turned on by default in Firefox, I suspect that almost all of the people not getting automated updates are those that have turned it off themselves, or whose organizations have turned it off for them, presumably out of a distrust of automated updates in general. Those same people would likely turn off other features that automatically contacted Mozilla for updates. 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: DigiNotar EV root inclusion request
Eddy Nigg (StartCom Ltd.) wrote: Well, I consider this the minimal technical validation required. Identity/Organization validation for S/MIME implies prove of ownership of the email account/address. Thunderbird doesn't validate the common name or organization field, but the email address. A fair point; it's the distinction between what the software checks (from address vs. address in cert) and what the person could check (name in cert). Considering for a minute your statement above, what are the CAs in question doing in order to guaranty domain/email ownership? What are the controls in place which let them rely on identity validation only? This is where I think we need further investigation, and is partly why I suggested talking to some people in the Netherlands familiar with use of these certs. It may be that certs issued to individuals by these CAs in the context of Dutch law, business and government services, etc., are primarily used in non-email contexts (e.g., client authentication to SSL sites, digital signing of documents separate from email, etc.), and email addresses are put in the certs just for completeness. In any case, if it comes to that we can certainly move forward with this application for SSL and code signing, and leave the email trust bit turned off until such time as this gets sorted out. Staat der Nederlanden is not a legacy root in the sense of being approved in the Netscape days. I approved it myself a while back, though at the moment I can't recall whether it was before or after adoption of our current policy. Nelson added this root at the 2005-04-11, certainly when the CA policy already existed, but maybe still unapproved. Actually I approved the Staat der Nederlanden application back in September of 2004 (see bug 243424), but it didn't get added to NSS until several months later. At the time Staat der Nederlanden was approved we were in the midst of discussing a new CA policy, but hadn't yet finalized it. So during that period I was operating under an interim policy that basically matched Microsoft's policy at the time, of approving CAs based on completion of a WebTrust audit. That's why the issue of validating email account control didn't come up at that time. As for doing something about Staat der Nederlanden now, and in particular turning off the email trust bit for its certs, that warrants further discussion. Even if the CA is not in compliance with our current policy, I still have to balance that against the potential impact of having Staat der Nederlanden certs no longer work with S/MIME email in Thunderbird, etc. (Because disabling signed and encrypted email for an existing user base itself has security implications.) That's another reason why I'd like more input from people more familiar with how the certs are used in practice. 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: DigiNotar EV root inclusion request
Eddy Nigg (StartCom Ltd.) wrote: Fank, I suggest that you balance what impact it has on the relying parties in first place (e.g. the users of your software) before you take care about the effects of the CA. In case it wasn't clear, my primary concern is for end users of Thunderbird who might be currently relying on email certs to send and receive encrypted and signed mail. I don't want us to suddenly disable such functionality without a clear rationale as to why we're doing it -- and that includes evaluating the relative security benefits and risks of both courses of action. ** Concerning the Staat der Nederlanden CA, this is currently just a claim brought forward in the bug by the representative of DigiNotar and must be confirmed first. Maybe you know for certain that this is correct, I haven't verified that claim. No, I haven't verified it either, that's why we need further investigation. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
DigiNotar EV root inclusion request
DigiNotar has applied to add a new root CA certificate to the Mozilla root store and enable it for EV, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=369357 and in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/#DigiNotar I have evaluated this request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve the request after a public comment period. Note that there was an issue with DigiNotar's EV audit because at the time its production CA software did not have the necessary features to issue EV certificates; the software has since been upgraded and DigiNotar has since successfully issued EV certificates. My inclination is to accept the EV audit as suitable for our purposes, since our main interest is in the audit of DigiNotar's validation procedures, and we can verify technical correctness of the actual EV certificates ourselves. Frank P.S. to Nelson: I've changed the status whiteboard in the bug and checked in a change to the pending list (not yet on the site) to mark DigiNotar as 'pending'. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DigiNotar EV root inclusion request
Eddy Nigg (StartCom Ltd.) wrote: Before going any further and after reading the entries in the bug, it seems to me that issue concerning email validation hasn't been positively resolved...can you confirm that or provide some explanation? This was/is another judgment call. IIRC when we formulated the Mozilla CA policy the idea of email validation was basically seen as a (less-desirable) fallback position for CAs that did not do full identity validation. When I originally evaluated the Staat der Nederlanden application I was following this line of thought, and considering validation of identity as sufficient. Also do you have any intention doing something concerning the comment https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c37 about the Staat der Nederlanden Root CA in respect to email validation? Judging from the details of that root, this is a legacy root. Staat der Nederlanden is not a legacy root in the sense of being approved in the Netscape days. I approved it myself a while back, though at the moment I can't recall whether it was before or after adoption of our current policy. I think it's worth discussing this issue further. As noted in the bug report, one argument is that (assuming identity validation is effective) any vulnerability is restricted to cases where people share the same name (e.g., someone else named Frank Hecker and I both apply for a cert). It might also be useful to have input from some people in the Netherlands who have first-hand experience with these CAs and can describe actual practices. 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: Network Solutions EV root inclusion request
[EMAIL PROTECTED] wrote: To clarify, Network Solutions does not, so far, issue any types of certificate other than EV from or through this root. The hierarchy is: Network Solution Certificate Authority - Network Solutions EV SSL CA - End Entity This request to add a root (enabled for EV) to Mozilla is for this top level CA Network Solution Certificate Authority. For everyone else's benefit: There was some confusion between Charlie Buckley and I which has now been resolved. I've corrected the Network Solutions entry in the pending list and added a comment to bug 403915. As noted, Network Solutions issues only EV certificates through the hierarchy rooted at the Network Solutions Certificate Authority root that's the subject of this application. Non-EV Network Solutions certificates are issued through an independent hierarchy. We reserve the right to issue other types of certificate from this root in the future, but our intention would be to have a separate subordinate CA issued by the Network Solutions Certificate Authority for each major type of certificate we issue. From my point of view Network Solutions also satisfies Mozilla policy requirements for non-EV SSL certs, based on the current CPS and audit situation. However issuance of email or code signing certs would require a new application and separate approval, since the current CPS doesn't address those types of certificates. (As noted in bug 403915, the current application is only for the SSL trust bit.) 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: What we want [was: Audit requirements for government CAs]
Eddy Nigg (StartCom Ltd.) wrote: Yes, this is a good argument in favor of EV and EV is exactly intended for that. Just a pity the rest of the public PKI is left broken, no matter what the reasons are (by design, lack of interest, commercial interests, etc), because there is more to protect than Paypal, Ebay and few banks. EV however might be an overkill for others. Ah, but isn't EV really returning the public PKI to the ideal of what CAs are supposed to be doing in theory, namely binding a (strongly) verified identity to a public key? So in theory any site supporting high-value transactions (financial or otherwise) should migrate to EV certs. This certainly should include major sites like Bank of America, E*Trade, etc., Amazon, etc., as well as any ecommerce site for which the annual EV cert fee is a small fraction of overall operating expenses. 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: Audit requirements for government CAs
Gervase Markham wrote: Frank Hecker wrote: It's a reasonable proposal, and we did look into doing this. Unfortunately there are .com domains and perhaps other non-.kr domains with certs issued by CAs in the KISA-rooted hierarchy. This is not unique to KISA and Korea either AFAIK. I personally think that, if all the other technical capabilities in place, our response to that could reasonably be Tough. Sorry.. Note that if we implemented a general enough facility then we wouldn't necessarily have to exclude support of all domains outside the country's TLD. For example, we could have a constraint permitting use of *.kr (or whatever) domains, as well as a selected set of *.com or other domains. This would be unwieldy or downright unpractical in cases where a government wants to establish lots of .com domains, but might work OK for cases where a government has just a few non-country-TLD domains. In the current state of affairs I don't think we have any general way to restrict government CAs or other country-specific CAs to issuing certs under their particular national TLDs; we'd need to have additional code in NSS or PSM to enforce custom restrictions. (Or just not include the roots at all.) As Nelson says, this is a capability we don't have. I personally think we should. My checkbook is open :-) However note that before doing this I think we should make sure we have a full up-to-spec implementation of existing standards around CA name constraints. Then we can think about extending the constraints to include Mozilla-specific requirements. 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: What we want [was: Audit requirements for government CAs]
Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: (As a side note, based on my experience with and reading about industry dynamics, I think that advances in PKI-related technologies are much more likely to occur in new protocols and new products than in mainstream cases like browsing SSL web sites. A good example is Skype's implementation of an internal PKI infrastructure for securing VOIP traffic.) Outshhh, I don't like to even get into this one :-) Except that they are using some kind of PKI and I'm not sure what's so exceptional or new with it. I don't want to go off on a tangent, but I think the Skype model is more significant than you think. I don't agree with Ian Grigg on everything, but I do think his proposed rule that there is only one mode, and it is secure is worthwhile: http://iang.org/ssl/h3_there_is_only_one_mode_and_it_is_secure.html As I understand it, out of the box Skype achieves encryption of users' VOIP calls and strong identification of a particular user's node (not tied to IP address), with no action needed on the part of the user. It doesn't tie a verified legal identity to the Skype instance (and so doesn't fit the classic X.509 model), but arguably this is not important for typical Skype use cases. I also think that with the advent of EV and the Firefox 3 UI that the world of certs will divide into EV and everything else (OV/IV/DV). Maybe I'm missing something, but I can't see any discernible difference between the UI for https://www.bankofamerica.com/ (OV cert) and the UI for https://www.hecker.org/ (DV cert). Which I personally view as a mistake, because I believe DV and IV/OV certificates should be separated. See my separate comments on this point. If EV doesn't become mainstream and will replace IV/OV certs, than Mozilla (and the industry) will have to come up with some better answers and address this particularly. If EV doesn't become mainstream, then IMO that will signal the utter irrelevance of the traditional PKI/CA model in terms of protecting user security for high-value transactions. After all, the EV model is the very embodiment of traditional thinking about how PKIs can protect user security: have a trusted third party do strong verification of legal identity and bind that identity to a public key, and have users then rely on that authenticated identity before entering into high-value transactions. If web site operators don't care to participate in the EV scheme, and web site users don't care if they don't see a strongly validated identity in the browser UI, then the only significant function of SSL in practice is to provide over-the-wire encryption and some minimal protection against MITM attacks. When in the software world an exploit is detected, the software is usually patched. When an exploit is detected in NSS, it's going to be patched. If however an exploit is detected by a CAs procedure you propose we do nothing until you are convinced that actually somebody is exploiting it and than you propose to adjust the thinking about the proposed threat. Really Frank? If there is a significant cost to protecting against a hypothetical exploit, and there are alternate means of dealing with the exploit in question (particularly more general measures that address more than just the exploit in question), then I suggest that we think carefully before investing time in implementing protection measures designed to deal specifically with such a hypothetical exploit. Take your idea of requiring identity verification for wildcard DV certs, which is designed to address the hypothetical threat of people setting up SSL-enabled phishing sites under their top-level domains (e.g., paypal.example.com). There's are multiple cost to implementing such an idea: a cost to CAs (who may have to change their procedures and product offerings), a cost to cert subscribers (who may have to pay more for certs), a cost to us (who have to figure out all the CAs doing wildcard DV certs, and then try to persuade them to change what they're doing), and potentially a cost to end users (e.g., if they can no longer access sites because we decide to punish CAs by removing their roots or disabling validation of certain wildcard certs). At the same time there are measures already in place to protect users against the general phishing threat, most notably the Firefox phishing protection features; these measures work against phishing sites using the hypothetical wildcard DV cert exploit, and against other phishing sites as well. There is also a general measure available to provide more assurance and accountability for web sites doing high-value SSL-enabled transactions, namely EV certs. So the specific question for me is as follows: Should I devote Mozilla Foundation resources (including my own time) to trying to combat the hypothetical threat posed by wildcard DV certs, a threat for which other protection
Re: Comodo request for EV root inclusion (COMODO Certification Authority)
Frank Hecker wrote: Comodo has applied to (among other things) add a new EV root CA certificate for the COMODO Certification Authority to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=401587 snip I have evaluated this request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve the request after a public comment period. The public comment period ended last week, but we had some additional discussions around various Comodo-related issues, most notably the wildcard DV cert issue and the long-lived DV cert issue. Although I acknowledge that there were/are valid concerns associated with those issues, in the end I made a judgment call that they didn't rise to a level that would justify my rejecting Comodo's request or delaying approval. I've therefore given my final approval to this request and filed bugs 426568 and 426572 against NSS and PSM respectively: https://bugzilla.mozilla.org/show_bug.cgi?id=426568 https://bugzilla.mozilla.org/show_bug.cgi?id=426572 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: Comodo request for EV-enabling 3 existing roots
Eddy Nigg (StartCom Ltd.) wrote: Even though the Comodo request has been approved, I wonder about two additional points which you haven't addressed at all: The first is about having CA roots with wrong details in NSS, like companies which effectively don't exist anymore (AddTrust AB, UTN), location (Sweden, Utah) and other information irrelevant and incorrect. To the extent that this information is in the certificates themselves, we can't change it. I guess we could look at changing the friendly names which NSS uses to refer to the certs, but that might be confusing for people who actually look at the root list in the various versions of Firefox. I think there's also an issue with how the certs get displayed in the Firefox certificate manager display window, based on what the cert contents are; I recall a comment from Kai (I think) about this in a bug I looked at recently, but can't recall the bug number or what the exact issue was. The second is about the audit statements which refer to a specific part and location of the CA business, like New Jersey. I didn't think this was a material issue with respect to Comodo's overall compliance with the EV guidelines, and so left it out of my considerations. 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: Audit requirements for government CAs
Benjamin Smedberg wrote: At the time, I believe I counter-proposed that the government certificate in question should be trusted to validate the identity of sites within that country: i.e. a Korean government CA would have a limited root which could only verify the identity of sites within the top-level .ko. It's a reasonable proposal, and we did look into doing this. Unfortunately there are .com domains and perhaps other non-.kr domains with certs issued by CAs in the KISA-rooted hierarchy. This is not unique to KISA and Korea either AFAIK. In the current state of affairs I don't think we have any general way to restrict government CAs or other country-specific CAs to issuing certs under their particular national TLDs; we'd need to have additional code in NSS or PSM to enforce custom restrictions. (Or just not include the roots at all.) 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: What we want [was: Audit requirements for government CAs]
Kyle Hamilton wrote: What do I want? I want a use-case which expresses why the certificate validation policies (as implemented by NSS) must be so draconian. I want a use-case which expresses, clearly, why certificate validation problems have to be modal and completely disrupt the user's workflow. I want a use-case which expresses why certificates from unknown CAs have to show up as certificate validation errors in situations where there are no forms to harvest private information. This isn't a CA policy issue per se, it's a Firefox/PSM UI issue. For the record I was/am sympathetic to the idea of being more permissive with self-signed SSL certs. However the developers and UI people made the decision that for typical users the better approach was to throw an error on any nonstandard SSL configurations. Per my previous comments in my response to Eddy, I think a move to more opportunistic crypto (including use of an SSH-like model) is much more likely to occur in new applications than in the traditional SSL web server context. I want a user interface which allows me -- at a minimum -- to see what CA signed a given certificate, how that CA is in my store (whether it was provided by Mozilla or the administrator or through my own action), the subject of the certificate, and the validity period of the certificate without having to click on more information and then scroll through the byzantine hierarchy of certificate fields. Again, the Firefox/PSM developers decided that the current UI was simpler for typical users, and that stuff like this was mainly of interest to power users. The Firefox approach to satisfying the needs of power users has been to rely on third-party Firefox extensions, and then to move functionality into core Firefox if it proves popular. If you want to see this info easily available, I suggest trying to persuade one to write one. I want a policy in place which prevents situations such as the transition from Thawte CPS version 1 (which did not allow for domain-validated certificates) to Thawte CPS version 2 (which did allow for domain-validated certificates) without a new CA being created and vetted. This brings up a point that was implied by my previous comments in response to Eddy, but that I want to make explicit: IMO the reason why we have a CA policy is *not* because the Mozilla Foundation wants to be or needs to be the CA police, tracking down and punishing bad deeds of CAs, and motivating them to behave better. We have a CA policy because SSL sites exist and are accessed by typical Mozilla users, because those SSL sites require CAs to issue them certificates, and because we need some sort of baseline policy by which we can balance inclusion of CA root certs (to make SSL work) against potential security concerns of doing so. In the thawte case you cite, thawte changed its practices to start issuing DV certs from a CA hierarchy not previously used for that, but its practices were still within boundaries outlined in our policy (which does allow issuance of DV certs). So I don't really see a security issue here in terms of how this would affect typical users. 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: Audit requirements for government CAs
Eddy Nigg (StartCom Ltd.) wrote: How stupid! If that's limited to secure government to government or citizen to government transactions, how is that limited in the software or certificate(s)? And what would its use be for the regular, typical average user? I'm not a government nor employed by a government so it doesn't apply to me. You're a citizen of a state, so government-run CAs do apply to you, at least for the government of your country. Nor am I a citizen of Zimbabwe, so it doesn't apply to me either... I guess I represent in that respect the majority of a typical user. I'm not sure where the reference to Zimbabwe came from, but never mind... Your question about how this applies to the typical user is something we've discussed before. There's no question that most users of Firefox, etc., will never encounter certs issued by, e.g., the government of Taiwan (to take one example of a government root already in NSS). It's arguably of interest only to people living in Taiwan (who might use SSL sites set up by the Taiwan government). So why did we include this root in all versions of Firefox? I've previously proposed having localized versions of the pre-loaded root list, so that (for example) the Taiwan government root might be loaded only in the traditional Chinese version of Firefox that might be used in Taiwan, but not in other versions (including the US English version). There would be technical problems of doing this (since the root list is embedded in NSS, we'd have to generate localized NSS versions), but those could probably be overcome. More importantly, there was strong resistance to the idea of moving away from a universal root list. Some people pointed out that the localized language versions didn't exactly map to particular countries, and that many people in particular countries used the US English version or another version other than the one assumed to be correct for them. However IIRC the more vehement objection was that we should have a situation where some sites worked in some versions of Firefox and didn't work in other versions of Firefox (because the root was missing). That's basically where we left the discussion. I didn't see any real support for the idea of localized root lists, so I dropped the idea. And that's why I'm still processing requests from government CAs. The alternative idea would be not including government-operated CAs at all; however that would cause problems for Firefox users in countries where such CAs existed and were used to issue certs for government sites used by citizens or for related purposes. Nope, I guess we'll have to find something better then that (if at all). I'm still not clear on your exact objections to the Microsoft policy, or what you would consider a better one. 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: KISA root CA certificate inclusion request
Eddy Nigg (StartCom Ltd.) wrote: OK, so in that case KISA itself is becoming an auditor. Would KISA then issue audit reports about the various CAs in question? What would be the pros and cons of having each licensed CA approved instead of KISA as a wild card CA for a whole country? One major issue is that as a matter of policy we don't do inclusion of certs for subordinate CAs; we just approve and include roots. If we were to explicitly require evaluation and approval of subordinate CAs (leaving aside for the moment whether this is a good idea or not) then consistency would require that we do this for every CA, including commercial CAs. Consistency would also require that we do this for every subordinate CA in a root's hierarchy, no matter how far down in the hierarchy it was. For example, suppose for a given root CA R we evaluate and approve all of R's subordinate CAs S1 to Sn, and a given subordinate Si then issues multiple subordinate CA certs in turn, perhaps enterprise CAs operated by individual companies. By the same logic that prompted us to evaluate all of the root's subordinates for inclusion, we'd have to evaluate and approve all of the enterprise CAs as well. I personally think this is both unworkable and unnecessary, even if we were to restrict this to direct subordinates of roots. See also below. KISA is a CA authorized and commissioned by the their government, however the operating CAs are not government CAs, but regular CAs with commercial interests etc. So this makes it a bit tricky I think...As I proposed earlier already concerning independent CAs operating under a unified CA root, but which are independent companies and the sole purpose of the CA root is to act as an anchor, each CA should be audited explicitly on its own or each CA should be at least explicitly confirmed. Thoughts? My main thought is that our current policy does not explicitly address either auditing of subordinate CAs or approval of subordinate CAs. I have no problem with looking at overall audit-related issues as part of evaluating a root CA for inclusion. However to condition root approval on the exact details of how subordinates are audited (e.g., whether we prefer to see audits done by a third party vs. audits by the root CA itself) is IMO trying to stretch the policy too far. Yes, we have a general provision in the policy regarding not including roots where it would cause undue risks to users' security. However as the person who wrote the language into the policy, I can tell you that it was not intended to condition overall root approval on our evaluation and approval of every aspect of how a CA hierarchy operated; it was rather intended to cover egregious security problems that might occur at a CA (as implied by the example violations I chose). I personally don't think having independent subordinate CAs be audited by the root CA (as opposed to by a third party) is an example of an egregious security problem sufficient for us to invoke this policy provision. Rather than trying to evaluate and approve an entire CA hierarchy up front (including all subordinate CAs), I think it is better to operate on an exception basis: We evaluate and approve roots, not individual subordinates. If it turns out later that there are security problems at a particular subordinate, and those problems are severe enough that we want to deny recognition of certificates issued by that subordinate, then from a technical point of view we have the ability to do so: We can pre-load in NSS the CA cert for that subordinate (and just that subordinate) and can mark it as untrusted. 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: KISA root CA certificate inclusion request
Eddy Nigg (StartCom Ltd.) wrote: I agree with everything you said below for regular, standard CAs. This is what the policy knew when it was written. There is a CA, they have a root and some intermediate CA certificates (according to the recommendations after all), they are one entity taking responsibility for their CA business and PKI and there is mostly one infrastructure in every respect. snip I don't agree, when the CA acts as a boot strapping CA, where the CAs under this root themselves are effectively independent CAs, companies and PKIs. Maybe I'm missing something, but I don't think this situation is unique to KISA. I believe there are commercial CAs, including CAs already in our root list, that issue CA certs to independently operated CAs. If I recall correctly, this is what our IT department did when I worked at Netscape, namely run a Netscape enterprise CA using an internally-operated CA infrastructure, with a CA cert issued to Netscape by an external commercial CA. So I don't think this is a question of government CAs vs. non-government CAs, or even standard CAs vs. bootstrapping CAs, it's part of the more general question of how to handle subordinate CAs. As I said, I think there are CAs operating today, including commercial CAs, that in some contexts act like standard CAs issuing end-entity certs out of their own infrastructure, and in other contexts act as bootstrapping CAs enabling other organizations to operate their own CAs. I don't believe that the distinction is as clear-cut as you suggest it is. It doesn't help that you point to the Mozilla CA policy which was written for regular, standard CAs (It does more or less good job in that). I evaluate requests according to the policy we have, not the policy you (or anyone else, including me for that matter) wish we had. As I've written before, if the policy doesn't address certain issues that arise in the context of individual CA requests, I am not going to hold up such requests until we hash through all the details of changing the policy, nor am I going to impose on the CAs making such requests new requirements that go beyond the policy as it's written and as it's been applied in the past. If we want to change the policy in future, that's a separate discussion, and I believe it should be a general discussion that reflects a wider base of information about current CA practices. We've already had instances where we thought one CA was doing something problematic and considered singling them out for it, and it turned out that the practice(s) were not unique to the CA. Getting back to KISA, I did indeed look at what the LCAs were doing and what sort of regulatory and auditing regime they're subject to. I saw no issues there that would justify my rejecting KISA's request based on our current policy, whether that be the explicit requirements of the policy or the more implicit requirements related to protecting user security. I therefore plan to approve KISA's request as soon as the other issue gets resolved about the audit of KISA itself. There are no definitions for cases such as these (or others which came up or will come up in the future). That's why you yourself felt the need to ask about how to define Audit requirements for government CAs Right, but that was for the purposes of discussing future policy changes, not for the purposes of evaluating the KISA request in particular. That's exactly why I started a separate thread. and that's why I asked in a different post What we want. And because no definition exists and the policy wasn't written for such cases, or because of the lack of such definitions, it doesn't makes it right to approve something we don't want. That's why I asked about What we want. Do we want to assure a certain standard and quality for CAs which are shipped with NSS or is it something else? If it's something else, than you should tell us about it. If it's the former then either we have to define it in the policy or act accordingly and on a case to case basis with rules which make sense. I really want to know the guidelines about What we want. What are the principals guiding us. Once we know that, we can take our arguments accordingly. This is better addressed in the separate thread you started. If it turns out later that there are security problems That point would be too late already, except that I don't believe that such actions would happened. This is better responded to elsewhere as well. It's part of a more general discussion about the respective emphasis we should put on prevention of potential problems vs. detection of and response to actual problems. 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: KISA root CA certificate inclusion request
Nelson B Bolyard wrote: But I believe we have already decided, in principle, to approve certs for CAs that are subordinate to some root that is not approved, when the subordinate CA meets the criteria, but the root does not. Yes, I recall this discussion. However in the KISA case my opinion is that KISA itself does meet our policy requirements (assuming that my remaining concern about the MIC audit gets addressed). I think the Korean situation is different from the Austrian one because KISA doesn't indiscriminately create subordinates, rather the LCAs subordinate to KISA are subject to regulatory constraints imposed by the government (including regulations mandating verification requirements, etc.) and are subject to oversight by KISA, including audits. 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: What we want [was: Audit requirements for government CAs]
security concerns (e.g., they have long lifetimes, use wildcards, whatever). Would the security of typical users be improved by having this CAs EV certs be recognized, enough to more than offset any potential security harm associated with the CA's DV practices? I can't absolutely prove that this might be so, but I also can't dismiss the possibility out of hand. Another (thinly-disguised) example: Typical users in a particular country use IE rather than Firefox because (among other things) Firefox doesn't recognize the major government-established and regulated CAs in that country. Would the security benefits of giving those users the ability to use Firefox be sufficient to justify our including those CAs' certs even though there are some open questions about how the CAs exactly fit into our policy framework? Again I suspect this might be the case, can't absolutely prove it, but certainly wouldn't reject it. My point (and I do have one, to quote Ellen DeGeneres) is that the Mozilla CA policy is just a tool, not an end in itself, and it doesn't exist in isolation from everything else in the world of Mozilla security and the world of CAs. If we're going to change the policy, I don't want to have us change the policy simply to address theoretical concerns and proposed threat scenarios of uncertain importance, and ignore any associated trade-offs. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Audit requirements for government CAs
As I implied in my previous message about the KISA request for inclusion of its roots, government CAs can pose special problems in the context of our current Mozilla CA policy, and I wanted to take the opportunity to discuss the topic briefly, since we may want to consider future changes to our policy to address these. Some government CAs undergo truly independent audits, e.g., by getting WebTrust for CAs audits using WebTrust-certified auditors. (I think the government of Taiwan did this, for example.) However in many countries the government CA is audited by a separate agency of government; this is the case in South Korea (where MIC is the auditor of KISA) and elsewhere. Furthermore, some of these audits (including KISA's) are based on laws and regulations specific to the country in question, as opposed to being based on globally-applicable criteria like WebTrust, ETSI 101 456, etc. This causes more work for us (because we have to investigate each country's practices individually) and also raises questions about governments auditing themselves. In its new policy for its root program http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true Microsoft has taken an interesting approach to this problem, one that I think is worth discussing: [F]or government CAs who issue certificates to secure government to government or citizen to government transactions, Microsoft will accept a statement from a government or private party auditor attesting to the CA’s audit status, giving the name of and reference to their audit guidelines, the date of the last audit, and equivalence of their audit criteria to the Operating Standards (e.g. WebTrust For CAs, ETSI TS 102 042, ETSI 101 456, ISO 21188). Should we think about adopting similar language in a future policy revision? I'll give my own thoughts about this in a subsequent message, but I'll pause here to let others comment. 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: KISA root CA certificate inclusion request
Eddy Nigg (StartCom Ltd.) wrote: I think the question raised with that CA was also, if the audit covers the whole CA infrastructure, i.e. all different independent CAs operating under the KISA root. If I remember right, the CPS has no provision in that respect and the audit covers only KISA's operations itself. I looked into this a while back. Auditing of the subordinate CAs (licensed CAs or LCAs) was/is mandated by the relevant Korean law and regulations that set up KISA in the first place and established MIC authority over it. KISA itself does the auditing of the LCAs, as mandated by the law and regulations. If we would apply Microsoft's new criteria (not that this matters for us really) of having the audit covering the full CA infrastructure, this one wouldn't go through. Actually, Microsoft has special provisions for audits of government CAs (as I mentioned in a separate message). The audit requirements on commercial CAs (item 7, General Requirements) don't apply to government CAs. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
