Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Message from discussion dispute resolution procedures for Mozilla CA module
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ian G  
View profile  
 More options Dec 23 2008, 8:58 am
Newsgroups: mozilla.dev.tech.crypto
From: Ian G <i...@iang.org>
Date: Tue, 23 Dec 2008 14:58:45 +0100
Local: Tues, Dec 23 2008 8:58 am
Subject: dispute resolution procedures for Mozilla CA module
In the past, lots of good stuff has been done that handles the ascension
to the root list of Mozilla.  c.f. the policy.  But not so much is
written about *what happens afterwards*.  This recent thread has been
such a case, and has afforded an opportunity to make some notes on what
might be suitable as a practices page on the wiki.

The reason for doing this, and adding yet more boring verbage to the
mass of words, is that it can prevent uneccessary legal costs by
providing clear guidepaths, and clear signals of seriousness.

Here's what I see:

1.  How to file a dispute against Mozilla and/or a CA.  This seems
fairly easy;  file a bug in bugzilla and mark it as already described
here: https://wiki.mozilla.org/CA:How_to_apply .  (With mods:  Severity:
  as appropriate.)

2.  What is the practice on revocation or un-trusting on roots?  This is
is perhaps a headline case of a dispute, so possible merits its own
notes.  Frank has suggested the test:

    a.  there is a clear and present danger to Mozilla users, or
    b.  to punish a CA, and/or to deter others.

I would suggest that (b) be modifed slightly to give it a basis, which
in this case might be "for breaches of policy or practices".  The
Policy, pt 4, gives the authority, as well as some examples, and adds
another test case:

    c.  where certificates cause technical problems with mozo software.

3.  How to resolve a dispute.  This is a Mozilla action &
responsibility.  Reverse-engineering and referring, I would suggest this
as a teaser:

   a.  The CA certificate "module owner" at Mozilla foundation is
responsible.  Ref, the policy, pt 15.
   b.  The dispute is investigated and ruled on by module owner.
   c.  The ruling is listed in the bug report above.
   d.  Many disputes will be dealt with by communication, and no ruling
will be required.  This will create a default "closed, no action" ruling.

4.  Finality.  What happens if we disagree with the decision of the
module owner?  In the policy, it says "CAs or others objecting to a
particular decision may appeal to mozilla.org staff, who will make a
final decision."  Ref, policy, pt 15.

I would wonder about this;  google suggests that "staff" is as listed here:
http://www.mozilla.org/about/staff
but that seems out of date.  Also, due to the absence of this forum in
the public eye, I doubt it musters the credibility we need in dispute
review where the legal and contractual significance is high.  E.g., is
there any way we can review the decisions they made in the past?

There are several possibilities:

   (i)   Ruling is final.
   (ii)  Mozilla.org staff, policy, pt 15.
   (iii) Review by board of Mozilla Foundation.
   (iv)  Review by some independent party.
   (v)   Review by forum at law: courts, or Arbitrator.

Personally, I would plumb for (iii) and suggest the Mozo Foundation
board as the next step.  It is expensive, but available.  The directors
already have fiduciary responsibility, and can thus deal with the
significance.  It is also aligned with the review of the manager
concerned, the policy and the general contractual issues.

End!  I'd encourage others to comment!

If nobody has any objections, I can add that as a page into the wiki as
an informal document of practices, including or without those questions.

iang

On 23/12/08 06:09, Frank Hecker wrote:

> Kyle Hamilton wrote:
>> I advocate at least temporarily removing the trust bits from Comodo
>> until a new external audit can be completed, with an eye toward
>> ensuring that Comodo, not the reseller, perform the domain
>> validations.

> There are two general reasons for pulling a root, to address a clear and
> present danger to Mozilla users, and to punish a CA and deter others. My
> concern right now is with the former. I see at least three issues in
> relation to that:

> 1. Issuance of further non-validated certs by this reseller. Comodo
> seems to have addressed this by suspending the reseller's ability to get
> certs issued. (I can testify that this is the case, as I tried to
> duplicate Eddy's feat earlier today and got my uploaded CSR rejected.)

> 2. Potential problems with certs already sold through this reseller.
> Comodo should investigate this and take action if needed. (This need not
> necessarily require revoking all certificates associated with the
> reseller; for example, the existing certs and their associated domains
> could be re-validated, the registered domain owners could be notified of
> the potential for bogus certs floating around, etc.)

> 3. Potential problems with other Comodo resellers. I'm not going to tell
> Comodo how to operate its reseller network, but they certainly should
> take a look at whether and where this might be a problem with other
> resellers, and how they could revamp their systems to reduce potential
> problems with resellers.

> Pulling a Comodo root will knock out Firefox, etc., access to thousands
> of SSL sites, maybe tens of thousands. Given the disruption that would
> cause, the final decision on this IMO should be made in conjunction with
> the Firefox security folks. From my point of view I'd wait on more
> information regarding items 2 and 3 above before making a recommendation.

> Frank


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.