Frank Hecker wrote: > Nelson B wrote: > > Or is it to preserve the trust of the users? Maybe we have to say no > > to a few CAs to preserve that trust.
> I am perfectly willing to impose other > requirements on CA, like issuing technically correct certs, operating to > particular criteria, putting a "floor" on acceptable vetting of > subscribers, and the like. I'm happy to take suggestions on this from > you and others. Suggestion: Require support for programmatic revocation checking before illuminating the "safe for e-banking and e-commerce" light. That means either raising the bar on CAs that qualify for the lock and gold background, or, making a UI change that enables an intuitive distinction between those that do and those that don't. > As with key lengths, someone actually has to look at the work necessary > to "break" CA issuance processes > Has anyone actually done such analyses? If they have, I'd certainly be > very interested in reading them. A back of the napkin version: 1 Bad guy registers domain name using bogus contact information and carefully choses a domain name that looks like it is "Example Bank of America"'s, let's say "examplebankofamericaonline.atld." 2 Get domain-control certificate for it, process requries ability to receive email for [EMAIL PROTECTED] and pay for it with a [stolen] credit-card. 3 FF will now light up 'safe for commerce and banking' and the user will see they are interacting with Example Bank of America's online presence. Let's assume the domain-cert issuing CA has a reasonble revocation policy and decides to revoke that cert to protect future would be victims. Without revocation data being present in the EE certs, or someother way of relying-party software programmatically checking for revocation, this method of mitigation is useless. Given such support this enables shutting down that site as quickly as the latency associated with the revocation process, technology, and service characteristics. Costs of revocation support policy for commerce and banking profile: 1 the marginal cost to the phisher which is zero. 2 the marginal cost to the CA - this is the cost of running revocation which is non-zero, perhaps revocation is to heavy a burden to place on CA services that are not trying to serve internet commerce sites. 3 cost to the user is relaively small - the increased cost of CA operations is built into the service price which is effecitvely shared across a site's customers. Such that Big Bank passes on their marginal $WHATEVER over their 100,000 customers. Benefit of revocation support policy for commerce and banking profile: Quick and easy method for closing down window that doesn't require finding ISP contacts in every country that each have relationships with the appropriate governing body in country with jursdiction to have a domain name taken down (don't forget their is technology latency their too). > > If users cease to have a clear indication of "good enough for banking", > > I would expect banks to react to that, not with another user education > > campaign, but by refusing to work with those browsers and their tiny > > market shares. Some banks already do this. > > Nelson, I hate to repeat myself, but according to your definition users > today don't have a "clear indication of 'good enough for banking'" in > the browser with the dominant market share, since to the best of my > knowledge IE will happily display a padlock for a site with a "control > of domain" cert issued by any of a number of CAs. There was very little UBE in 1995. I wouldn't count that as an argument to say that the email infrastructure was good enough for broad adoption. The value of UBE went up and the problem grew to suit. > > No CA should ever > > certify information they haven't validated. > > The challenge is to ensure that the control-of-domain CAs don't issue > > certs that include the unverified "Acme Widgets, Inc." in the name. > > That's a reasonable position to take, but my question from my previous > message remains unanswered: If an SSL cert should use subjectAltName for > the domain name instead of CN, then what information should a "control > of domain" SSL cert use for the subject? (As a point of interest, Thawte > and Go Daddy, to name but two CAs, are still using CN for the domain > name, and if you don't define O, OU, etc., then they will stuff in text > like "domain validated" and the like in those attributes; more on this > in a future message.) If a CA doesn't want to make a statement about the identity of EE they issue a certificate to it should be possible to allow them to do so. Since the CN shows through the UI (sometimes) to users it might be reasonable, given no support by the browser providers for any alternative, to distinguish it by including a satement in the otherwise empty subjectDN like "CA did not confirm the indentity of the site operator" - an empty subjectDN is something we can build a five-year-plan for if that's of value but I suspect a lot of the consumer and enterprise software will choke on it and we need to allow a transition period. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
