Plan for draft 12 of CA certificate policy - netscape.public.mozilla.crypto

Message from discussion Plan for draft 12 of CA certificate policy

Ian G

View profile

More options Mar 31 2005, 10:13 am

Newsgroups: netscape.public.mozilla.crypto

From: Ian G <i...@systemics.com>

Date: Thu, 31 Mar 2005 16:13:23 +0100

Local: Thurs, Mar 31 2005 10:13 am

Subject: Re: Plan for draft 12 of CA certificate policy

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

Frank Hecker wrote:
> My apologies, it's been a while since I did serious work on drafting the
> CA certificate policy (as opposed to just discussing the surrounding
> issures). I plan to publish a draft 12 as soon as I can; here are my
> current thoughts for what changes I'll make in that draft:

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

> * To address some of the concerns expressed about CAs issuing "duff"
> certs, I'm considering expanding clause 4 to read as follows:

> 4. 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, or to modify the "trust bits" for a
> particular CA certificate included in our products, at any time and
> for any reason.

OK, this above sentance appears unchanged. In brief, all
of the text that is below that para above, I suggests, falls
into the bucket of "examples" or "guidance".

Generally, this would be better off in a separate document
that was entitled "Guidance on the policy." This document
would list working concerns and examples, and be modifiable
*without* reference to the board.

The reason for this is that the current set of concerns are
not tomorrow's concerns. We may get today's concerns completely
wrong, and we may find that tomorrow's concerns to be of much
greater importance. Yet, because we have stated in the policy
a set of concerns, then we are sort of caught in having to give
them some weight. The alternate is that we have to seek the
re-approval of the document every time the concerns change to
better reflect what threats we are facing today.

If Mozilla reaches say 25% of the browser market, then don't
for a moment think that you will be able to do what you want
just because it is right. You will be hounded by all sorts
of journos being paid or induced by people who want your
policy to be their policy.

Clause 4 gives the power that is needed to resolve any question
over particular CA root certs. From there, it really becomes
an issue of who the director of this policy is on the day. If
it's Frank, we get "result F." If it's Nelson, "result N."
Whatever goes in the policy, whichever examples are highlighted,
the effect will be that the implementing director will be bending
the policy to suit their judgment call.

(Which is their job, to make the call.)

The end effect of these examples will be simply a shackle
around his neck in adroitly dealing with what he sees are
today's issues. Far better I think to have the director
manage a guidance file where he expresses his judgement calls.
If he gets it wrong, he changes the file and takes a hit.
But if it's in the policy, he can't change it. Then, all
of Mozilla has to take a hit, and so do the users.

> This includes (but is not limited to) cases where we believe that
> including a CA certificate (or setting its "trust bits" in a
> particular way) might cause undue risks to users' security, for
> example, with CAs that

> - knowingly issue certificates without the knowledge of the
> entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for
> fraudulent use

Err... (I see you've picked up the flaw below!)

> This also includes (but again is not limited to) cases where we
> believe that including a CA certificate (or setting its "trust bits"
> in a particular way) might cause technical problems with the
> operation of our software or be at variance with relevant
> standards, recommendations, and industry best practices, for example,
> with CAs that issue certificates that have

> - duplicate issuer names and serial numbers;
> - invalid public keys (e.g., DSA certificates with 2048-bit primes,
> or RSA certificates with public exponent equal to 1);
> - incorrect extensions (e.g., SSL certificates that exclude SSL
> usage, or authority key IDs that include both the key ID and the
> issuer's issuer name and serial number);
> - invalid dates; or
> - ASN.1 DER encoding errors.

> I'm proposing including this language in clause 4 rather than clause 6
> (requirements on CAs) for a couple of reasons.

(I'm going to leave the 'where' aside for now and
concentrate on the 'what' and the 'whether'.)

> Second, IMO at least some of the example reasons to reject/remove CAs
> could be problematic when interpreted as strict requirements per clause
> 6. For example, it's quite possible that a CA might knowingly issue a CA
> with false information in response to a legitimate request from a law
> enforcement agency or other government entity. If we happened to find
> out about this I wouldn't want the policy (as strictly interpreted) to
> always force us to remove the CA.

OK. So the way it works *today* is that if a CA is
instructed to issue a false certificate to a user,
then likely there will be a gag order. In this case,
you should not find out about the circumstances
behind the false issue in any formal sense.

Now you have a dilemma. Let's say a big CA issues
a false certificate. It is found out accidentally
and causes a net scandal. The CA is under gag orders,
and the victim looks clean. You'll now get some people
saying that the CA has to be dropped and some people
saying, wait a minute, maybe there was a government
order?

In fact, likely the Director will get hints that this
is the case.

If the Director accepts the premise that a CA might
have issued a cert pursuent to a government order,
he has just emasculated not only the policy but the
entire PKI. Consider the recent discussion on the
Chinese root proxy MITM. Let's say a dodgy ISP in
mainstreen America is doing proxy attacks. Let's
say they're aggressively sucking up the data info
on online banking and passing it across to a data
broker who's selling it to a mate who's selling it
to a phishing farm out in deepest darkest Klapistan.

"Nobody's doing anything wrong..."

Then they get found out... but the ISP whispers in the
ear of the Director that actually the proxying they
are doing is pursuant to a government order, and it's
under gag. And, he whispers fearfully, that he
himself could go to jail for even mentioning this
and breaking the gag order.....

> As another example, in some cases CAs might issue "confusing" certs for
> reasonably legitimate reasons, e.g., as in the "First Bank" example I
> previously gave. In other cases there might be a pattern of behavior
> indicating real problems, e.g., with a CA that appears to have been set
> up as mainly as a way for phishers to get certs for "paypa1.com",
> "micr0soft.com", etc. IMO the policy needs to provide us the freedom to
> make subjective judgements as to what indicates a real problem and what
> does not. The point of clause 4 is to provide that needed "wiggle room",
> which again is why I think the new language should go into clause 4.

As an alternate notion. If you are going to include
examples in the policy then we should all think up
what examples we would like to see there.

I think this is an inferior path. But if the set of
concerns is going to be spelt out so that people like
the press and CAs can in the future can badger the
Director to implement the ones the Board agreed to,
then we owe it to the muggins in the hot seat - the
director implementing the policy - to make the examples
as useful to Mozilla's average users as possible.

So we should put our thinking caps on and all work
on a list of examples.

> * To address the concern about certificates of different assurance
> levels being issued under the same CA root (or intermediate), I'm
> proposing adding a new clause 13 as follows:

> 13. In addition to the requirements outlined above, we also recommend
> that CAs use different root CAs (or different intermediate CAs under

in 2,3 "CAs" above don't you mean "certificates" ?

> a single root) when issuing certificates according to different
> Certificate Policies, so that we or others may selectively enable or
> disable acceptance of certificates issued according to a particular
> policy, or may otherwise treat such certificates differently (e.g.,
> in our products' user interfaces). We reserve the right to make this
> a requirement in the future, and to not include a particular CA
> certificate in our software products, to discontinue including a
> particular CA certificate, or to modify the "trust bits" for a
> particular CA certificate, based on the CA's practices in this regard.

Again, I see this as guidance and today's working
concerns.

> I'm proposing this as a recommendation (at present) rather than a
> requirement for the reasons I've previously stated: I don't think we
> should mandate this until it's clear how much of a problem this really
> is, how much it would affect the existing set of CAs already included in
> the products, and whether we're going to make UI and other changes that
> would depend on this. However I do think it's reasonable to put CAs on
> notice that we're thinking about this issue and may take stronger action
> at some point.

Again, the director has the power to mandate this any
time he likes simply because of clause 4. He doesn't
need any additional support in the policy. The policy
gives him wide ranging powers to craft procedure to
implement the concerns of the day. Which is good.

> Also, note that I sidestepped the tricky issue of defining and
> determining certificate "assurance levels". I think a better approach
> (at least for now) is simply to recommend that all certs issued under a
> single CA (whether issued directly by a root CA or by an intermediate CA
> under a root CA) be issued according to the same policy.

Certainly, as an interim step, to see whether the
CAs can craft for themselves any commonality in
assurance, and express it in root certs, it would
seem wise to encourage use of different root certs.
But I'd do it in the guidance file. It's strategy
by the director, not policy, and won't be policy
until it is proven and so good that the board is
prepared to sign onto it.

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

Reply to author Forward