Frank Hecker wrote: > Ram0502 wrote: > > What do you think about requiring that for each root or CA to be > > included (new or legacy!) require that the CA respond to: > > Before I get into the actual suggestions themselves, one overall issue > is what (if anything) we are going to do with this information. Is this > simply information we could make available to interested users, e.g., as > I've done with my CA cert page? > > http://www.hecker.org/mozilla/ca-certificate-list
I believe there is value to the community in having an easy to compare page; your page is a solid start but I would add all the included CAs as well and I think breaking out some fields (use of secure hardware, some policy details) would be of tremendous benefit. I can imagine thousands of savvier folks using a breakout table of policies to conifugre their root list but I can't imagine more than 100 would be willing to read the CPSs off the various CAs to do the comparison (actually I doubt more than a dozen have read the CPS of all MF embeddec CAs). I understand MF may have hesitation to establish criteria for inclusion that include a subjective component but I have no doubt that one could easily argue that MF already does that by the simple fact of having an included root list (which by the way I think is the right thing to do!). By relying on the WebTrust style standard MF I think MF is hoping to leverage a self regulating or best practices approach and thereby remove itself from making a qualitative statement that may bring with it liability. I am not a lawyer but I can use words like best practice and material comply :) I believe that: 1 if MF breaks out the practices and policies of the various CAs (included or otherwise) into some 'obvious' security attributes AND 2 if there are obvious groupings of security levels then one could make an argument for using the naturally occuring thresholds to define best practices for various applications and thereby continue to abstain from making potentially risky decisions in favor of again leveraging market driven best practices. For example perhaps enough CAs offer OCSP/CRL pointers in certificates that MF can take advantage of that to require this feature for roots to be trusted to issue software publishing credentials. This has the excellent feature of strongly encouraging competition between the root providers for example to include automatic revocation checking, or anti-spyware policies or whatever practical considerations emerge as supported by the open market. > For now I'm going to assume that the main point of your suggestions is > to provide additional information for interested users, as well as > information we could use in evaluating our own potential policies. (For > example, if we discover that there are strong commonalities in how CAs > do things, we could use that in support of the various proposals for > having standard cert "classes" and reflecting those in the UI.) > > e Do you include an issuerLogo in every certificate? This helps enablee > > consumers and relying parties to identify you and builds a reputation > > of trust in your brand. > > Well, yes, but only if we and other browser/email vendors actually do > something with the issuerLogo :-) I suspect we could get the for profit CAs to implement this in the MF source base as they would clearly benefit from the branding. As I understand it the real question is if the security value (which is obvious to me) is conveyable apparent to whomever controls the UI real estate. I think there are many workable approaches to this. For example allowing the user to make a (perahps deeply hidden at first) configuration selection about it. Generally this concept would be well leveraged by asking the user one or two questions to tailor their setup (rate your clue and your daring/parnoia on a 5 point scale) and adjust their security policy (XPIs must be signed with revocation, must be signed by anyone, don't care) and UI (show me brand, hide this stuff) based on their selection. I think this is a much better approach to balancing usability and security needs. BTW Thanks Frank for your ongoing hard work here - managing the root list and policies for MF is not a glorious job but it is an essential one. _______________________________________________ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
