I've done a new draft 11 of the proposed CA certificate policy; you can
find it at the usual place:

   http://www.hecker.org/mozilla/ca-certificate-policy

Major changes in the draft are as follows (in order of occurrence in the
document):

* Strengthened the language in paragraph 4 to cover rejecting CA
requests if we believe it's appropriate to do so.

* Modified paragraph 6 to add requirements relating to verification of
certificate signing requests.

* Added a new paragraph 7 to describe minimum verification requirements
for each type of certificate. (Renumbered succeeding paragraphs
accordingly.) The requirements are as I've outlined them previously.

* Added a new paragraph 14 noting that the Mozilla Foundation will
designate someone to handle CA requests. I used the term "module owner"
rather than "CA coordinator" as suggested by Ian G for consistency with
terminology used elsewhere in the Mozilla project.

As always, comments, questions, and suggested changes are welcome. The
changes in this draft were primarily intended to address putting a
minimum "floor" in place regarding requirements on CA, particularly for
audit regimes like WebTrust where some have contended that no such floor
is actually present. (Note that I added language regarding authorized
agents, as previously promised.)

I've previously explained my reasons for choosing the particular
requirements I've included, so I won't repeat those comments here. I
realize that some may see the language regarding "reasonable measures"
as unnecessarily subjective, however I don't want to try to anticipate
(and more important, provide policy language for) all the different ways
in which CAs might vet subscribers. I'll include examples and additional
guidance on this subject in the policy details FAQ.

"Hope springs eternal...", as they say, but I really do believe that
this draft (or something very close to it) is suitable for submission to
the Mozilla Foundation for consideration as a 1.0 policy. If you
strongly object please let me know.

Frank

--
Frank Hecker
hec...@hecker.org

My apologies, I forgot to add a diff listing of the detailed changes
from draft 10 to draft 11; please see the attached file.

Frank

--
Frank Hecker
hec...@hecker.org

[ ca-certificate-policy-diffs.txt 7K ]
Index: mozilla/ca-certificate-policy.html
===================================================================
--- mozilla/ca-certificate-policy.html  (revision 360)
+++ mozilla/ca-certificate-policy.html  (working copy)
@@ -40,7 +40,7 @@

 <div class="para">
 <p>This is the official Mozilla Foundation policy for CA certificates
-that it distributes with its software products:</p>
+that we distributes with our software products:</p>

 <ol>

@@ -54,8 +54,15 @@
   <li>We will not charge any fees to have a CA's certificate(s)
   distributed with our software products.</li>

-  <li>We reserve the right to discontinue including any CA certificate
-  in our software products, at any time and for any reason.</li>
+  <li>We reserve the right to not include a particular CA certificate
+  in our software products, to discontinue including a particular CA
+  certificate in our products, <em>or</em> to modify the "trust bits"
+  for a particular CA certificate included in our products, at any
+  time and for any reason. This may include (but is not limited to)
+  cases where we believe that including a CA certificate (or setting
+  its "trust bits" in a particular way) would cause undue risks to
+  users' security <em>or</em> cause technical problems with the
+  operation of our software.</li>

   <li>We will consider adding certificates for additional CAs to the
   default certificate set upon request.</li>
@@ -68,23 +75,56 @@
       <li>provide some service relevant to typical users of our
       software products;</li>

-      <li>publicly disclose information about their business practices
-      (e.g., in a Certification Practice Statement);</li>
+      <li>publicly disclose information about their policies and
+      business practices (e.g., in a Certificate Policy and
+      Certification Practice Statement);</li>

-      <li>operate to published criteria that we deem acceptable;
-      <em>and</em></li>
+      <li>prior to issuing certificates, verify certificate signing
+      requests in a manner that we deem acceptable for the stated
+      purpose(s) of the certificates;</li>

+      <li>otherwise operate in accordance with published criteria that
+      we deem acceptable; <em>and</em></li>
+
       <li>provide attestation of their conformance to the stated
-      criteria by a competent independent party or parties with access
-      to details of the CA's internal operations.</li>
+      verification requirements and other operational criteria by a
+      competent independent party or parties with access to details of
+      the CA's internal operations.</li>

     </ul></li>

-  <li>We consider the criteria published in any of the following
-  documents to be acceptable:
+  <li>We consider verification of certificate signing requests to be
+  acceptable if it meets or exceeds the following requirements:</li>

     <ul>
+      <li>for a certificate to be used for digitally signing and/or
+       encrypting email messages, the CA takes reasonable measures to
+       verify that the entity submitting the request controls the
+       email account associated with the email address referenced in
+       the certificate <em>or</em> has been authorized by the email
+       account holder to act on the account holder's behalf;</li>

+      <li>for a certificate to be used for SSL-enabled servers, the CA
+      takes reasonable measures to verify that the entity submitting
+      the certificate signing request has registered the domain(s)
+      referenced in the certificate <em>or</em> has been authorized
+      by the domain registrant to act on the registrant's behalf;</li>
+
+      <li>for certificates to be used for digitally signing code
+      objects, the CA takes reasonable measures to verify that the
+      entity submitting the certificate signing request is the same
+      entity referenced in the certificate <em>or</em> has been
+      authorized by the entity referenced in the certificate to act on
+      that entity's behalf;</li>
+    </ul>
+
+    We reserve the right to accept other requirements in the future.</li>
+
+  <li>We consider the criteria for CA operations published in any of
+  the following documents to be acceptable:
+
+    <ul>
+
       <li>Annex B, "(Normative) Certification Authority Control
       Objectives", of ANSI X9.79-1:2001, <a
       href="http://www.x9.org/catalog2.cfm?item_no=%24%23%20%2F%217%20%21O%0A&...">Part
@@ -134,8 +174,8 @@
     </ul></li>

   <li>By "independent party" we mean a person or other entity who is
-  not affiliated with the CA as an employee or director, and for whom
-  at least one of the following statements is true:
+  not affiliated with the CA as an employee or director <em>and</em>
+  for whom at least one of the following statements is true:

     <ul>

@@ -158,7 +198,7 @@
   requirements. However the CA may request a preliminary determination
   from us regarding the acceptability of the criteria and/or the
   competent independent party or parties by which it proposes to meet
-  the requirements.</li>
+  the requirements of this policy.</li>

   <li>To request that its certificate(s) be added to the default set a
   CA should submit a formal request as follows:
@@ -195,18 +235,25 @@
           <li>digitally-signed executable code objects;</li>
         </ul></li>

-      <li>a Certification Practice Statement (or links to a CPS) or
-      equivalent disclosure document(s) for the CA or CAs in question;
-      <em>and</em></li>
+      <li>a Certificate Policy and Certification Practice Statement
+      (or links to a CP and CPS) <em>or</em> equivalent disclosure
+      document(s) for the CA or CAs in question; <em>and</em></li>

       <li>information as to how the CA has fulfilled the requirements
-      stated above regarding its conformance to a set of acceptable
+      stated above regarding its verification of certificate signing
+      requests and its conformance to a set of acceptable operational
       criteria.</li></ul>

-    We will reject requests where the CA does not provide such
-    information within a reasonable time after submitting its
-    request.</li>
+  We will reject requests where the CA does not provide such
+  information within a reasonable period of time after submitting its
+  request.</li>

+  <li>We will appoint a CA certificate "module owner" to evaluate CA
+      requests on our behalf and make decisions regarding all matters
+      relating to CA certificates included in our products. CAs or
+      others objecting to a particular decision may appeal to
+      mozilla.org staff, who will make a final decision.</li>
+
   <li>We reserve the right to change this policy in the future. We
   will do so only after consulting with the public Mozilla community,
   in order to ensure that all views are taken into account.</li></ol>
@@ -232,6 +279,11 @@
 to related questions.</p>

 <div class="important">
+<p>Version 0.11, February 27, 2005. Added requirements relating to
+subscriber vetting. Added blanket statement reserrving right not to
+include certificates. Added note about appointment of module
+owner.</p>
+
 <p>Version 0.10, Feburary 16, 2005. Dropped "fully" from financial
 disclosure requirement. Added section on revising the
 policy. Corrected date references on version history.</p>

 >  <p>This is the official Mozilla Foundation policy for CA certificates
 > -that it distributes with its software products:</p>
 > +that we distributes with our software products:</p>

"we distributes"  reminds me of the old Popeye cartoons.  :)
Popeye talked like that.

Two questions about this draft:

1. Does this floor address the "Click Yes to continue" phenomenon?
Should it?

2. Recently I encountered an SSL server cert from a low-assurance CA
in which the cert's entire subject name consisted of the
"Common Name" which was the server's domain name.  There was no other
information at all about the person/organization behind that cert.
That seems like something mozilla's policy ought to address in its floor.
IMO, that's not good enough for an SSL CA in mozilla's CA list.  Agreed?

--
Nelson B

OK, ok, you know I'm *usually* pretty good about keeping typos out of
these drafts :-)

I'm guessing you mean what was previously discussed about misleading
names in certs, in object signing certs in particular IIRC. I'm hesitant
to try to craft policy language on this; exactly how would one
"legislate" against this particular practice?

No, I respectfully disgree: IMO this is a legitimate use case. If the
domain in the cert matches the domain as requested, and if the CA has
verified that the "cert owner" is the same as the "domain owner", then
the basic anti-phishing protection has been provided. Beyond that one
might justify additional identity verification using something like
Gerv's argument ("we need names and addresses so we can track down
phishers and hold them accountable"), but IMO this is likely to be
ineffective in practice against real phishers (due to the relative ease
of creating fraudulent ID documents) and imposes verification
requirements (and consequent costs) that are arguably overkill for
various legitimate use cases involving SSL server certs (e.g.,
password-protected "friends and family" personal sites).

What I included in the draft policy is meant to be a true "floor", i.e.,
absolutely minimum requirements that are compatible with all possible
legitimate use cases. The policy is not meant as a "best practices"
recommendation.

Frank

--
Frank Hecker
hec...@hecker.org

Looks good to me!

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

That's a thorny issue.  The company's name was indeed
that, in Canada.  In that case, as the company's name,
there is a well established precedent to use that name.
In company naming there are a few things you can't do,
such as use rude words and use others' names.  Also,
most countries have restrictions on the national labels.

But using a branding or advertising slogan is fine.  Using
a common expression is fine - as long as nobody got their
first.

At the extreme, "Click Yes to continue" would even have a
plausible complaint against any company that declined
to accept its name!

Which is not to say that I think it's right or wrong, but
that dealing with this issue in policy terms is real tough.

My perspective on this is taken from years of doing
issuance contracts in an unregulated field.  The
natural tendency is to expect there to be a standard
and for everyone to follow it.  But in practice, there
often isn't much of a standard, and that which is
there isn't of any help;  in fact in terms of addressing
fraud, most standards hinder more than they help.

In order to address this, I developed a simple rule:
tell the truth.  Everything that was written into a
contract should be the truth.  The digital signature
should attest to that.  Now, this might seem quite
basic, but I had a lot of trouble getting people to
follow this rule in writing contracts... in contrast,
there was rarely any problem with readers of
contracts.  As soon as they read the document,
the knew when things were missing, in general.

So as long as whatever is in that cert is the truth,
I don't see an issue.  That's just me, tho!

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

What is an issuance contract?  (just curious)

Ian,  You're the anti-phisher guy.  I would expect you to want
certs to contain more info to help fight phishing.  Just how does
a cert that contains only CN=pay.pal.com help avoid phishing?

--
Nelson B

Not to speak for Ian, but it permits the basic check that Gerv recommends:

   http://www.gerv.net/security/stay-safe/

assuming of course that the user can recognize that "pay.pal.com" !=
"paypal.com". And if they can't recognize that, I doubt very much
they're going to be clicking on the lock and checking the information in
the cert.

So the question is, what is the purpose of the O and OU information in
SSL certs? If the values of these fields are not exposed in the standard
browser interface by default then it seems to me that (unlike CN) they
have minimal or no relevance when it comes to protecting the security of
typical users.

Frank

--
Frank Hecker
hec...@hecker.org

<comments on usefulness of SSL cert info beyond CN snipped>

Incidentally, I want to correct a possible misapprehension that might
arise from my comments here and elsewhere:

I am quite interested in seeing Firefox, Thunderbird, and our other
products implement effective anti-phishing strategies. I just don't
think that the SSL protocol and the CA infrastructure can bear all or
even most of the burden of protecting users from phishing. I think basic
SSL checks related to domain name have to be supplemented and
coordinated with other measures, which might include site blacklists,
automated comparisons of site names with a whitelist of common phishing
targets, and other heuristics designed to present the user with a
qualified determination that "yes, this site is likely legitimate" or
"no, it's no legitimate".

I would compare the role of PKI in the context of web site phishing
attacks to the role of Sender Policy Framework (SPF) and related schemes
in preventing spam: Neither are complete solutions (although often
touted as such in a "marketing" context) but rather must be supplemented
by other measures, and both impose costs that have the potential to
negatively impact perfectly legitimate use cases.

Frank

--
Frank Hecker
hec...@hecker.org

Just in case anyone was wondering, I'd endorse all of those principles
and most of those practices (except perhaps the "common phishing"
whitelist; I think we can do better).

Gerv

A contract for issuance of value.  There is a contract
underlying Paypal's money for example, but they way
they do things is pretty ropey, they change their
contract every time some old lady phones up and
complains.  E-gold is another issuance, and famously,
in late 2000, they changed their contract of issuance
from "you own the gold" to "you don't own the gold..."

In brief, take a contract, stick a few program-readable
terms in there, cleartext sign it, and then hash it.  The
hash becomes the identifier for the units of issue, and
the accounting system manages hashs.  By this means,
people have issued dollars, gold and other units, and
then run payment systems denominated in these units.
The benefit of doing it this way is that the contract
is fairly shared between the user and the issuer, and
the issuer can't arbitrarily change the contract without
breaking the accounting and every payment that was
ever made.  The hash for my dollar contract is:

SHA:e3b445c2a6d82df81ef46b54d386da23ce8f3775

and that SHA1 hash is bound into every signed payment
and signed receipt, so the contract is set in stone.

http://www.webfunds.org/ricardo/contracts/systemics/
http://www.webfunds.org/ricardo/contracts/webfunds/

Is a couple of pages of issuance contracts.  The second
group are 'toys' and the first group are 'real'  But the
same rule applies;  if you hold some units of the toy
contracts, the issuers are bound to follow them.  If
you mail them you'll find they take their responsibilities
seriously, I hope :-)

The only value in a cert is provided by the CAs
willingness to sign it.  If the CA signs on a
CN=pay.pal.com then that's the only value
that is there!

It matters not whether the additional info is
in there.  There could be addresses, phone
numbers, there could be corporate numbers
and even the attorney's name.  But in the real
world of hard and crooked commerce, the
question is not what info is there, but what
the CA was willing to sign off on.

In this sense, forcing more information into
the cert actually does the reverse of what you
want;  it creates a false sense of security based
on the presence of additional uncertain info.
Making rules and insisting on CAs following
standards raises costs for honest cert owners,
and it lowers security for honest relying parties,
*if* they are fooled by the extra info.

The most important thing is *which CA*.  After
that, the 2nd most important thing is which
root cert was used, because that tells the user
what level of assurance that CA was promising.
Finally, once the user establishes the reliability
of the cert, she can factor that in to whether
she hands over her credit card to no-risk-porn.com
as signed by the Gambino CA, or whether she
decides to go with something signed off on by
VeriSign or QuoVadis or etc etc.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Ha!  I didn't know about that page... excellent,
it rounds out the Top Tips on Security on my
blog.  Added, thanks.

Right.  The only security for the average user is
what is displayed - and this is why the Amir&Ahmad
trustbar displays logos.  The average user can get
a very very quick security impression from a logo
of Verisign, and can ally that to a logo of Paypal,
both of which are secured by the browser.

(I'm hoping that in the interim Gervase or someone
will add the name of the CA on to that little status
bar thing.)

Has anyone looked at the new Opera browser?  I
saw the press release about their anti-phishing
SSL cert display, but I don't have a copy myself.

Right.  The obvious thing is to display them.  But
then we run into 'too much information."  So what
are the essentials?

For me, the domain name and the CA (and the root
cert if more than one).

After that, a petname or a logo approach would be
fantastic, because if a user knows the site and needs
more security, she can make a small quick decision
on that basis, and she can use all the info in the cert
for that decision, if it helps.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

I currently think it's mostly true - it's certainly good advice.
However, we may be changing that spec for 1.1.

I've been thinking about this. Say we did add the name. Say some company
screwed up, and got a bad reputation. Say lots of other sites changed to
buy certs from someone else. Wouldn't that cause a lot of false
concerns? "Hang on a minute, I think this is ebay.com, but ebay.com are
signed by USERTRUST, and this site is signed by Verisign...". (Let's
leave aside for a minute that my Grandfather couldn't think like that in
a million years.)

We're back onto an issue that I think we've discussed before - how does
the user benefit from having the CA name there? If they want to visit a
particular shop, they have a choice of doing so while protected by
SUPERTRUST, or not at all. They can't say "Hmm, I don't trust
SUPERTRUST, I want Verisign to protect me."

In the absence of even the ability (never mind the understanding and the
will) to make that choice, I'm not convinced that adding the CA name is
worth the real estate and added UI complexity.

I hope to soon.

Gerv

Well, for a start, think it through.  Most sites will not
change their certs.  Only a few will actually waste the
remaining time .. until renewal.  But some will; and
these some will cause the pressure on the company.
New companies will go somewhere else, as the scandal
is fresh in mind.  That's the pressure we want.

Secondly, what you are pointing at is a *derivative*
problem.  The primary problem is that the CA issued
a duff cert.  How do you solve that?  Well, there has
to be some pain somewhere, and the closer it is to
the users, the more likely the pain will actually respond
to user security needs.  So, yes, some users are
going to have some pain.  That's part of the process.

Thirdly, your grandfather could think like that, and
probably does - ask him what car brands he knows.
Then ask him if he knows anyone who buys Ford
every time ... and ask him what would happen if
he saw the guy go and buy a renault or a seat?

Fourthly, what exactly are you saying in terms of not
showing the cert?  Are you saying that you believe that
when a company screws up, it should be dealt with
behind the scenes?  That the users shouldn't know
that UserBust is continuing to issue duff certs, and
it is stuck in the root list of 90% of issued product?

Right.  But, bear in mind - their relationship with
their site is far greater than with any CA.  What
happens is if the site is an online bank, they decide
they want one or two or three CAs.  If it is a record
shop, then maybe half a dozen.  If it is an online mail
service, then *any* cert will do.

Somebody's going to establish themselves as the
"safe enough for online banking" CA.  Others will
dominate the mail space.  Yet others will concentrate
on small internal sites.

Users are capable of analysing what it means to
use a recognised cert and and when not to.  They
just have to be given the chance, and get comfortable,
make a few mistakes, etc.

They have the ability.  They use it every purchase
of they make.  Ask anyone who is in marketing.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

You've made such analogies before; but I again repeat they the brand
visibility is vastly different in both cases, and note that "the CA I
use to protect my connection to Amazon" is not a consumer choice like
"the car I buy".

Fundamentally, when we had no market share, we had no leverage. When we
have some, we'll have some. So how about this for an idea to kick around:

- CA Foo issues a bunch of duff certs to phishers
- People lose money
- The MF decides, pragmatically, that CA Foo has sold too many certs to
yank their root cert, due to user inconvenience.
- The MF instead declares that CA Foo's root cert will be yanked in 6
months, unless they clean up their act, and that sites should not rely
on CA Foo's certs working in 15% of browsers 12 months from now.
- The resultant storm of publicity and uncertainty and doubt causes CA
Foo registrations to drop, and CA Foo to clean up their act, and beg us
to issue a joint press release to that effect.

It might work...

I meant the ability to choose the CA who protects their connection to a
particular site - an ability which you've admitted they don't have.

Gerv

The point I am making is that users understand
branding.  Their understanding of branding gives
them information that they can use.  You're right
to point out that that will use this branding info
in different ways.

In this case, they can use the information to understand
the risks.  We're not asking anyone to "choose a CA".
Instead, we're asking the users to a) choose to avoid
CAs and merchants where the CAs have a bad rep,
and also to notice when a CA changes.  If a CA changes,
that's a signal that they may be being spoofed.

If they're being spoofed via the same CA, then the
reputation issues kick in.  But they will only kick in
if the user has a reason to get upset at the CA,
which means it must be branded to them, in their
minds, on the chrome.

Sure, something like that.

The reason for showing them the CA is not to
"give them choice in CAs" but to allow them to
develop a sense of the risks they are taking.  If
the see SafeCA being used at a bookshop then
they will put their details in a form... if they see
DodgyCA then they may decide it's not worth
the risk;  maybe they know DodgyCA is bad, or
maybe they know it wasn't there last time and
that's a bad signal.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

I am highly sceptical that we can ever raise a user's CA branding
awareness and security awareness to a point where they will choose not
to shop with their preferred retailer when they otherwise would, merely
because of the CA that retailer has chosen.

Earlier, you pointed out the branding success of Intel. Intel has had
correctness scares in the past over bugs in Pentiums, and privacy scares
over things like chip ID; however, no-one goes into an Internet cafe and
demands an AMD computer because an Intel chip might get calculations
wrong on their machine and corrupt their email, or might send copies of
it to Intel.

It's also a signal that the merchant concerned has heard of problems
with their original CA and switched.

Therefore, a "good thing" (merchants switching CAs), as defined by this
strategy, has almost exactly the same UI effect as a "bad thing"
(spoofing). This is deeply concerning.

Note that this plan doesn't require and end user action, or CA names in
chrome.

Gerv

We are not asking them to choose not to shop
with their preferred retailer.  We are simply
making them aware of the risks when they do
so.  It's a different thing.

Yes.  Branding works.  It works for ordinary
people;  it works for non-technical users.

Right.  We aren't asking them to "change CA."

We are asking them to be aware that when
they shop at their favourite shop, that the
choice includes a component of risk towards
the CA, as well as towards the retailer.

Right now, they are unaware of that risk, and
they can't understand why the phishing occurs.
Part of the deal with addressing phishing is
getting the real security information to them;
such that users can assess whether a phishing
attempt is underway.

As a short term phase, it is important to move
secure form filling across to SSL.  So that the
users know and work with this.  That means
making it much more obvious ...

As a next term phase, we have to be ready
for when phishers attack HTTPS.  They will
do this easily by simply buying Shmoo-like cert.
The system will hide the switch.

To get users to appreciate the switch from one
good cert to either another dodgy one, or none,
we need to get them looking at the CA.  And if
the same CA issues the dodgy cert, well, then,
they are on the hook for both ends.

Right, it is up to the merchant to manage that
process, and the user to be aware of better
branding.  There will be a tendency to get a
decently branded cert, and to stick with the
same supplier.

A switch from bad cert to good cert is similar
in general appearance to good --> bad.  This
means we have a good signal, and a bad signal.

That's in exchange for no signal.  The system
isn't perfect, no system is.  It's just what we can
do with the system we've got.

Sure.  It also gets MF sued because they shipped a
browser that users can trust in, and it hid the true
risks from them.  By hiding the true risks, and by
allowing a 12 month window in which CA Foo and
its dodgy mates rip of thousands of customers, the
degree of harm is somewhat unlimited.

Neither of those are tractable.  It isn't possible for
MF to respond to CA Foo fast enough to limit
damages - because users don't patch.  And, it isn't
possible to avoid the liability implied by "if the padlock
is set, you are safe."

This is why the original security model had the CA
on the chrome.  That got dropped because there was
no threat, and nobody thought it worthwhile.  Now
there's a threat, and now people are losing money.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Very little of this has happened historically because the existing CAs
now in mozilla's list have been very very good at not issuing "duff"
certs.  As evidence of this truth, I offer the HUGE amount of press
(not to mention postings in this group) that a *single* duff cert incident
got a few years ago.  The press held that CA up to high standards
precisely because that CA already had a reputation for doing a good
job of avoiding "duff" certs.

However, mozilla is now considering changing its standards for admission
to mozilla's trusted CA list.  I think there is substantial risk of
increased "duff" certs (especially SSL certs) from this plan.

This says to me that MF needs to hold a high standard before admitting
certs to the list, because it's too difficult to take them out later.

MF might declare that, but I doubt it would ever enact the threat.
Doing so would only hurt mozilla.

When something that previously worked stops working in a browser,
end-users' perceptions are always "that darn buggy browser is junk",
never "that web site's admin hasn't got a clue about security".

Too many users live in caves.  They wouldn't learn about the CA cert
removal until their web pages stopped working.  Then they'd gripe
en-masse about mozilla.  Not about the duff CA, but about mozilla.

BTW, where do you think mozilla would tell the world about such a
plan to remove a CA cert?  If the IDN issue couldn't make it onto
www.mozilla.org's front page, what chance has CA news of getting
onto ANY mozilla.org web page?

--
Nelson B

First, I want to be disclose that I work for a commercial CA and that
the opinions I express are mine personally and should not be taken as
representing my current or previous employers unless I explicitly state
otherwise.

Comments inline...

That's insightful. Given MF's hesitation to establish direct explicit
criteria for inclusion in the root list (please don't take this as a
dig but rather an observation) there is reason to suspect MF would be
hesitant to formulate similar rules for removal from the root list.

Let's say the current expectation for security defects repair from
detection/advisement to patch distribution is on the order of two
months. It is hard to reconcile those two months against an arguably
reasonable six month tolerance period for a roots removal (given the
potential complexity of the software, process changes, customer
management etc that a CA may need to make as well as a time for the
various secure site operators to enroll for new certificates and roll
them out). It seems there is a mismatch between these expectations
which I see as supporting the notion of raising the bar on admission in
practical terms. I think it is also important to evaluate the existing
root list as critically as candidate roots rather than rely on their
existing records exclusively for the same reason.

This is a serious question, and I think it's worth looking in more depth
into the extent to which this might be true; otherwise some might
mistake your statement as simply FUD, and I don't believe you intended
it that way.

First, what's a "duff cert" in this context? A cert issued by a CA in
violation of its own policies (i.e., CP and CPS)? A cert issued by a CA
to someone that the CA "should have known" might use it for fraudulent
purposes? A cert issued by a CA to someone who turns out to use the cert
in the context of fraudulent activity (whether the CA "should have
known" this or not)? These are not really the same definitions. Which
one did you (and Gerv) intend?

Second, you seem to be saying that under the past and current policies
for adding certs to the Mozilla default set (as implemented by Netscape
and then myself) there has been minimal issuance of "duff certs"
(however defined), but that under the proposed new policy the issuance
of "duff certs" could be substantially increased. The implies (at least
to me) that such an increase in "duff certs" would be specifically
caused by adopting the new policy, to the exclusion of other factors. Am
I reading you right here?

Let's consider this: The proposed new policy differs in at least three
ways from prior policies, at least from the "WebTrust or equivalent"
policies I've been following:

1. It adds some additional acceptable criteria to WebTrust. (This
formalizes the "or equivalent" part of the current "WebTrust or
equivalent" policy.)

2. It permits approval of CAs based on evaluations by independent
parties who aren't official CA auditors or security test labs. (This
might include us, i.e., people in the Mozilla project, if we want to
take on such tasks.)

3. It puts some minimal requirements on validation procedures that CAs
have to do for SSL, email, and object signing certs respectively.

Let's take these in order:

1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456
and 102 042) is not at issue, because the other criteria are
substantially similar to the WebTrust criteria, and if anything go
beyond the WebTrust criteria in placing some additional requirements on
CAs that the WebTrust criteria do not. Do you agree with my assessment,
or do you think that adding the additional criteria will significantly
increase the risk that "duff certs" will be issued? If so, why?

2. Permitting "non-traditional" evaluation of CAs is certainly something
that one could imagine increasing risks, if the people doing the
evaluation don't do a good job. On the other hand, I suspect that if and
when any such "non-traditional" evaluation does take place (e.g., like
what's been proposed for CAcert.org, and perhaps for future CAs as
well), that the level of public scrutiny of such evaluation will be very
high (if I can judge by the controversy this has already stirred up),
which will likely minimize the risk of a bad evaluation being done and
approved. (Certainly I'd be hesitant to approve a CA based on a
non-traditional evaluation if there were significant questions raised
about it, until/unless such questions could be resolved to pretty much
everybody's satisfaction.)

But this may or may not be at the root of your concern, so let me ask
directly: In your opinion, would permitting such "non-traditional"
evaluations contribute to the increased risk you perceive? If so, is it
the only factor increasing risk? A major factor? Just a contributing
factor relative to other factors (like the one I'll discuss next)?

If you do believe that permitting non-traditional evaluations would
increase the risk of "duff certs" being issued, what would you recommend
we do? Tighten the requirements on when we'd allow such evaluations? Or
drop the idea entirely, and require that all evaluations be done by
authorized auditors and test labs?

The consequence of the latter would be to keep CAcert.org out of the
list permananently, or at least until they could afford a WebTrust or
other audit. It would also keep other CAs out that haven't undergone
WebTrust or equivalent audits; for example, I think there's a CA
associated with a German university/research consortium that would be
affected by this, and I think a couple of others as well.

3. Regarding requirements on CA validation of their customers, I
certainly don't have any such requirements in my current "WebTrust or
equivalent" policy, so in that sense the proposed new policy is more
stringent than the old policy. Did Netscape have such requirements? I
have no idea. However with regard to SSL certs in particular I will note
that there are already CAs issuing "domain-validated" certs, e.g., the
Thawte ssl123 and Go Daddy TurboSSL services, and to my knowledge such
CAs are already in the default Mozilla set and usable with Firefox, etc.
(There may also be other CAs like this as well, but I haven't had time
to do a thorough check.) Has this resulted in significant issuance of
"duff certs"? Apparently not, or I presume you would have mentioned this.

So, I ask you: In your opinion, would explicitly permitting such
"domain-validated" certs (as opposed to the implicit permission we've
apparently had previously) contribute to the increased risk you
perceive? If so, is it the only factor increasing risk? A major factor?
Just a contributing factor relative to other factors (like the issue
with non-traditional evaluations)?

If you do believe that explicitly permitting domain-validated SSL certs
would increase the risk of "duff certs" being issued, what would you
recommend we do? Prohibit domain-validated certs, and require that CAs
do more thorough identity verification of subscribers? Require that CAs
do additional due diligence (over and above identity verification) to
determine if subscribers might intend to use their certs for fraudulent
purposes? Would you also recommend not permitting issuance of email
certs based only on email account verification (i.e., not checking
identity)?

The consequence of prohibiting domain-validated SSL certs is that I
would reject the request that Go Daddy currently has submitted (in bug
284677) for adding new root CA certs. To be consistent we would also
remove from the default cert list the existing root CA certs for Thawte,
Go Daddy, and anyone else currently issuing domain-validated certs. If
we want to prohibit "account-validated" email certs then we'd also have
to remove root CA certs associated with those services as well. (As a
side note, I don't believe that prohibiting domain-validated certs would
affect CAcert.org, since IIRC they don't issue such certs; Duane or
someone else, please correct me if I'm wrong about this.)

Finally, let me consider some larger issues. Forgive me if I'm missing
something, but I'm getting contradictory impressions here. On the one
hand I get the impression that you and others believe that historically
there have been minimal problems (and hence minimal risks to users)
resulting from CA practices and the selection of CAs to be included in
the Mozilla default set. Now that I'm proposing this new policy I get
the impression that you and others believe it will result in significant
problems and significant risks to users, even though the sorts of CAs
and CA practices permitted under the new policy are AFAICT basically the
same sorts of CAs and CA practices that were permitted under the old policy.

(The major exception to this is the possibility of including CAs like
CAcert.org based on non-traditional evaluations; but I'm not clear there
whether non-traditional evaluations are the sorts of your concern or
whether it's domain-validated SSL certs and other low-assurance certs.)

The only way I can personally resolve this contradiction is to conclude
that it's not the policy in isolation which is at issue, it's the policy
in combination with the new environment in which protecting against
phishing has become a top priority. In other words, while existing
policies (which in practice permitted things like domain-validated SSL
certs) may have been good enough way back when, any new policy has to be
more stringent in order to counter the increased threat; it's not good
enough for us to just continue and formalize existing de facto
practices, we have to add some more requirements over and above what has
been done in the past.

Is this what you and others are arguing? If so, it's a perfectly
legitimate argument to make. But if you and others want to make this
argument (i.e., that policy needs to be more stringent in this new
environment) then I believe it's incumbent on you and others to a)
propose in some level of details what more stringent requirements we
should actually impose, and b) explain how those requirements will
actually reduce the risks experienced by ordinary users.

I think such a detailed justification is necessary because there are
consequences to adopting more stringent policies: We're talking about
eliminating (i.e., no longer accepting as valid) uses of things like
domain-validated certs that are currently in use (with apparently no
problems resulting), and closing off the possibility of such uses in the
future. We're in essence saying that use of SSL in e-commerce and
financial applications is our primary concern, that the risks associated
with SSL in such applications require us to adopt as stringent a set of
rules as we can, and that all ...

read more »

Right.  But you are misinterpreting the causes and
effects.  Very little duff issuance has occurred because
it isn't valuable.  There is and there remains no value
in duff issuance, because phishing works without
certs.

This is the problem, pure and simple:  attacks on value
bypass the CAs and certs.  Response?  Force them to
use HTTPS;  Corollary?  Certs will *then*  be attacked
and duff certs *will* be issued.

I take anything written in the press with a grain of
salt.  I'm sure they bought into the whole "perfect
security" myth and thought it was fun to write about...

Even though the Shmoo cert was obviously a bit odd,
it got issued.  But no crook bothers to do that, unless
there is money to be made.

There is a substantial, even huge risk of duff certs
being issued.  On that we are agreed.  But the _cause_
is that they will become valuable.  And that only
happens when Gervase and HJ and others start
putting the cert domain name and cert signer on
the chrome.

When users start defending themselves from phishing,
then the certs will be valuable... then they'll be attacked.

Not before.  Why attack a cert-protected site when you
can hack in and steal the database?  Why bother with
any of that when you can apply to join ChoicePoint's
open search service?

It's a chess game, thinking several moves ahead.

"needs to hold a high standard..."  Well, this is like
saying "let's ban guns!"  To which the answer is,
"then only criminals will have guns."

Nothing that MF can do will slow down a crook.
Crooks laugh at those sorts of things (well, they
would if they knew about HTTPS ...)

Right.  I must admit I'm somewhat bemused by the
threat that MF would pull a root cert.  But, in the
scheme of things, I don't see it makes a difference
to the security of the users, one way or another,
so I don't bother to think too hard on it.

Yup.  Once it's out there, that's it.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Lot of countries demonstrate banning gun works rather well, so the
argument weakens the demonstration, besides being totally unrelated.

But the merchant can't manage the process, because the user is supposed
to be using the cert to assess the trustworthiness of the merchant's
statements. After all, how would you react to a website which said
"Don't worry that your browser now says Foo CA - we've switched CAs!
Honest!".

Or do you envisage a bank paper mailing all its customers to notify them
of the CA switch?

And both signals are very similar - unless the user is so CA brand-aware
that they know that CAs A, B and C are currently considered dodgy, but
D, E and F are riding high, so A -> D is good but F -> C is bad.

The level of brand and market awareness you are requiring from an
average web user is far above their awareness of almost any market, even
ones in which they are deeply involved.

Gerv

For my part, a "duff cert" is one which is used for fraudulent activity.
That's a somewhat circular definition, indeed - but I wasn't thinking in
terms of the risk or otherwise from the policy changes.

This rather falls out of the current binary security UI. (I should say
that I'm very sceptical that it's possible to change that; this is
merely an observation.)

Gerv