New drafts of CA certificate policy proposals
Frank Hecker
do a revised draft of the CA certificate policy and related documents;
in particular we have the core policy proposal:
http://www.hecker.org/mozilla/ca-certificate-policy/
the proposed details of the policy and how it would be implemented:
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/
and (for good measure) an HTML version of the metapolicy I posted earlier:
http://www.hecker.org/mozilla/ca-certificate-metapolicy/
Note that the URLs are different than the URLs I used earlier, as I
decided to change the names of the documents slightly.
At this point I think the most important thing missing is a detailed
discussion of the threat model and the assessment criteria that flow
from it. I'm sorry I haven't had time to digest all the postings that
discussed threat models and to try to synthesize a proposed consensus
model; that will be my next task when I find time for it.
I also apologize if there were comments and suggested revisions
submitted that were not reflected in these new versions. I also need to
go back and review those submissions to see if there's anything I'd like
to incorporate in the next draft.
And finally, a big "I'm sorry" to all the CAs out there who've sent in
requests thus far, requests which have gone unanswered and (in many
cases) unacknowledged. I'm really not in a position right now to approve
or deny requests -- and in any case I may need to confine my activities
to getting the policy written, and then turn the duties of evaluating
requests over to someone else who has the time and knowledge to do a
better job of it.
Frank
--
Frank Hecker
hec...@hecker.org
David Ross
In the proposed policy, I consider the lack of objective,
verifiable criteria for including or removing a certificate to be
a very serious deficiency. I know this is somewhat addressed in
the meta-policy, but I don't know what standing that will have
relative to the policy itself.
Proposed policy item #5 should be revised to require a bug report
rather than an E-mail message. This would formalize the addition
of a certificate to the database and allow public review of the
request. It would also facilitate tracking such requests. For
this purpose, a new bug database component should be created for
the Browser product: CA Certs.
In the FAQ, several questions deal with certificates with
restricted or limited audiences. The FAQ should make clear that
users can indeed import CA certificates of their own choice.
--
David E. Ross
<http://www.rossde.com/>
I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <http://www.mozilla.org/>.
Frank Hecker
> In the proposed policy, I consider the lack of objective,
> verifiable criteria for including or removing a certificate to be
> a very serious deficiency. I know this is somewhat addressed in
> the meta-policy, but I don't know what standing that will have
> relative to the policy itself.
The meta-policy is intended to "drive" the policy and related documents
(e.g., the FAQ); if something is in the meta-policy then that something
should be addressed somewhere in some form or other in the other documents.
Now, as to the question of criteria, what I will do is to revise the
policy document to specify that decisions made re CA certs will be based
on documented, objective, verifiable criteria. However I am not going to
put a criteria list in the policy itself, since I want to keep it short.
I think a better place would be the policy details section of the FAQ.
(And BTW, note that the new version of the FAQ does mention some general
criteria as to why certs might be removed.)
> Proposed policy item #5 should be revised to require a bug report
> rather than an E-mail message. This would formalize the addition
> of a certificate to the database and allow public review of the
> request. It would also facilitate tracking such requests. For
> this purpose, a new bug database component should be created for
> the Browser product: CA Certs.
I agree that requests should be entered into bugzilla and tracked that
way. I also believe that we should allow CAs to enter requests directly
into bugzilla (as opposed to sending an email message), and I am
revising the policy to state that explicitly.
However I do not agree that we should require CAs to use bugzilla
instead of email to submit the original requests. Not everybody knows
how to use bugzilla, and there's a little bit of overhead to get
yourself a login before you can submit a bug report. I think it would be
better to allow CAs to just send an email if they don't want to deal
with bugzilla; the "module owner" for certs (i.e., the person getting
the certif...@mozilla.org emails) would then enter the bug report on
behalf of the CA, and add the CA contact person to the CC list for the bug.
Note that this is essentially the same policy we handle for reports of
security vulnerabilities: you can enter a security-sensitive bug
yourself, or just email your report to secu...@mozilla.org.
(Reminder to myself: I need to ask the appropriate mozilla.org person to
add a new component "CA certificates" to the "mozilla.org" product in
bugzilla. This will make it easier to track requests and ensure that
requests submitted via bugzilla will get to the right owner.)
> In the FAQ, several questions deal with certificates with
> restricted or limited audiences. The FAQ should make clear that
> users can indeed import CA certificates of their own choice.
Agreed. I was going to address that in the "background information"
section of the FAQ, which is primarily directed at end users.
Frank
P.S. I uploaded a new version of the policy document to
http://www.hecker.org/mozilla/ca-certificate-policy/
with the revisions mentioned above; the changes are in items 1 and 5.
--
Frank Hecker
hec...@hecker.org
Nelson B
> I agree that requests should be entered into bugzilla and tracked that
> way. I also believe that we should allow CAs to enter requests directly
> into bugzilla (as opposed to sending an email message), and I am
> revising the policy to state that explicitly.
>
> However I do not agree that we should require CAs to use bugzilla
> instead of email to submit the original requests. Not everybody knows
> how to use bugzilla, and there's a little bit of overhead to get
> yourself a login before you can submit a bug report. I think it would be
> better to allow CAs to just send an email if they don't want to deal
> with bugzilla; the "module owner" for certs (i.e., the person getting
> the certif...@mozilla.org emails) would then enter the bug report on
> behalf of the CA, and add the CA contact person to the CC list for the bug.
I agree, except ...
The primary reason for the CA champion to register with bugzilla and
file his/her own bug is to receive email notices when the bug is updated.
If s/he lets someone else enter the bug, then s/he will not be notified
quickly when comments/questions are added to the bug.
So, while I agree that we don't necessarily want to REQUIRE the CA
champion to register, I think we must disclose that if they do not
there is a much greater chance that they will miss out on timely
notifications to which responses may be helpful to their cause.
> Note that this is essentially the same policy we handle for reports of
> security vulnerabilities: you can enter a security-sensitive bug
> yourself, or just email your report to secu...@mozilla.org.
Yes, but most folks who report such bugs don't really stick around to
wait for the outcome. CA champions are in a different position in that
respect.
> (Reminder to myself: I need to ask the appropriate mozilla.org person to
> add a new component "CA certificates" to the "mozilla.org" product in
> bugzilla. This will make it easier to track requests and ensure that
> requests submitted via bugzilla will get to the right owner.)
Please do. It may also help avoid insults to the NSS module owner, like
the ones that happened today.
--
Nelson B
Nelson B
> As promised in my previous message I managed to find some spare time and
> do a revised draft of the CA certificate policy and related documents;
> in particular we have the core policy proposal:
>
> http://www.hecker.org/mozilla/ca-certificate-policy/
>
> the proposed details of the policy and how it would be implemented:
>
> http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/
I just started to read this, and need to read it more tomorrow.
One initial point. I think we're sending mixed signals to readers
about where is the appropriatre place for them to add comments about
individual CA applications.
I've been telling people to disucss it in the newsgroup, NOT in bugzilla.
I believe bugzilla is NOT the place for general advocacy discussions.
I believe the comments in bugzilla about a particular application should
be limited to
a) the sole champion of the CA
b) the "module owner" of the certificates module
c) any developers specifically tasked with doing the jobs of making source
changes.
d) mozilla foundation members.
IMO, we do NOT want any more bugs with hundreds of people on the cc list
and hundreds of comments in them.
Yet your new policy details doc says:
"The module owner and other interested parties will discuss the
request in Bugzilla (not in the newsgroup and mailing list)."
Maybe if you define "interested parties" to include only the folks I named
above, I'd agree.
> And finally, a big "I'm sorry" to all the CAs out there who've sent in
> requests thus far, requests which have gone unanswered and (in many
> cases) unacknowledged.
I have just one question about this. Are there any outstanding trusted
CA applications that are NOT yet represented by bugs that are blocked by
bug http://bugzilla.mozilla.org/show_bug.cgi?id=233453 ?
Do we know who all the current applicants are?
--
Nelson B
David Ross
>
> I've been telling people to disucss it in the newsgroup, NOT in bugzilla.
> I believe bugzilla is NOT the place for general advocacy discussions.
> I believe the comments in bugzilla about a particular application should
> be limited to
> a) the sole champion of the CA
> b) the "module owner" of the certificates module
> c) any developers specifically tasked with doing the jobs of making source
> changes.
> d) mozilla foundation members.
>
> IMO, we do NOT want any more bugs with hundreds of people on the cc list
> and hundreds of comments in them.
>
> Yet your new policy details doc says:
>
> "The module owner and other interested parties will discuss the
> request in Bugzilla (not in the newsgroup and mailing list)."
>
> Maybe if you define "interested parties" to include only the folks I named
> above, I'd agree.
Changes to the CA certificate database are changes to the
configuration. Proper configuration management processes require
that a formal bug be opened before work begins on implementing
such a change. Once that occurs, Bugzilla becomes the proper
forum where decisions are made whether to correct or reject the
bug and where comments are made that affect those decisions.
If an outsider (e.g., me) sees a problem with what is requested in
a bug report or with a proposed implementation, I should not
remain silent and allow a discrepant implementation to occur. As
someone who uses Mozilla to do my banking and investing, I have a
strong vested interest in ensuring that Mozilla's CA certificate
database retains integrity. Thus, I am as much an "interested
party" as those who are implementing or testing the change.
Frank Hecker
> The primary reason for the CA champion to register with bugzilla and
> file his/her own bug is to receive email notices when the bug is updated.
> If s/he lets someone else enter the bug, then s/he will not be notified
> quickly when comments/questions are added to the bug.
Thats why I explicitly noted in the message you quoted that the person
entering the bug should add the CA contact person to the bug CC list.
However I noticed that I did not make this explicitly in the policy
details FAQ where I describe the process; I have remedied this oversight:
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#request-process
Frank Hecker
> I just started to read this, and need to read it more tomorrow.
> One initial point. I think we're sending mixed signals to readers
> about where is the appropriatre place for them to add comments about
> individual CA applications.
>
> I've been telling people to disucss it in the newsgroup, NOT in bugzilla.
> I believe bugzilla is NOT the place for general advocacy discussions.
> I believe the comments in bugzilla about a particular application should
> be limited to
> a) the sole champion of the CA
> b) the "module owner" of the certificates module
> c) any developers specifically tasked with doing the jobs of making source
> changes.
> d) mozilla foundation members.
I'm with David Ross on this one. This should be a public process (as the
policy explicitly specifies) and we can't and shouldn't limit who can
comment on bugs related to CA certificates.
Now what we *can* do is discourage off-topic comments if they are made,
and redirect people to the newsgroup for general advocacy comments. I
think this problem will lessen once we have a formal policy, as then we
will have a better guide as to what is off-topic and what is not.
> Are there any outstanding trusted
> CA applications that are NOT yet represented by bugs that are blocked by
> bug http://bugzilla.mozilla.org/show_bug.cgi?id=233453 ?
>
> Do we know who all the current applicants are?
I need to go through my inbox and match that up against the list of
bugs. Unfortunately I don't have time to do that tonight.
Gervase Markham
> However I do not agree that we should require CAs to use bugzilla
> instead of email to submit the original requests. Not everybody knows
> how to use bugzilla, and there's a little bit of overhead to get
> yourself a login before you can submit a bug report. I think it would be
> better to allow CAs to just send an email if they don't want to deal
> with bugzilla; the "module owner" for certs (i.e., the person getting
> the certif...@mozilla.org emails) would then enter the bug report on
> behalf of the CA, and add the CA contact person to the CC list for the bug.
That wouldn't work unless the person had a Bugzilla account; in which
case they could file a bug anyway.
They are asking a lot from us - the least they can do is take three
minutes to get a Bugzilla account and then click on the "File CA Cert
Bug" link in the policy.
> Note that this is essentially the same policy we handle for reports of
> security vulnerabilities: you can enter a security-sensitive bug
> yourself, or just email your report to secu...@mozilla.org.
This is different. The person submitting such a report is doing us a
favour, rather than the other way around.
> (Reminder to myself: I need to ask the appropriate mozilla.org person to
> add a new component "CA certificates" to the "mozilla.org" product in
> bugzilla. This will make it easier to track requests and ensure that
> requests submitted via bugzilla will get to the right owner.)
Done. Initial description: "For Certificate Authorities to file requests
asking for their certificates to be included in the default certificate
store." Tell me if that's wrong.
I've made you "initial owner", although I expect that someone else will
fill that role in due time.
Gerv
David Ross
>
> Frank Hecker wrote [also in part]:
>
> > (Reminder to myself: I need to ask the appropriate mozilla.org person to
> > add a new component "CA certificates" to the "mozilla.org" product in
> > bugzilla. This will make it easier to track requests and ensure that
> > requests submitted via bugzilla will get to the right owner.)
>
> Done. Initial description: "For Certificate Authorities to file requests
> asking for their certificates to be included in the default certificate
> store." Tell me if that's wrong.
>
> I've made you "initial owner", although I expect that someone else will
> fill that role in due time.
Already, bug #239408 has been submitted as Product: mozilla.org
and Component: CA Certificates. Someone should now change the
Component to CA Certificates for bug #233453 (mozilla.org needs a
public policy on root CA certs) and the other seven open bugs that
it blocks.
Frank Hecker
> Already, bug #239408 has been submitted as Product: mozilla.org
> and Component: CA Certificates. Someone should now change the
> Component to CA Certificates for bug #233453 (mozilla.org needs a
> public policy on root CA certs) and the other seven open bugs that
> it blocks.
Note that I can't make that change, because I am neither the assignee or
the submitter for those other bugs, nor do I have sufficient privileges
to override bugzilla and change the bugs anyway.
Ideally what should happen is that the assignees for those bugs (Wah-Teh
Chang, Stephane Saux, Mitchell Baker, etc.) should re-assign them to me
(hec...@hecker.org), and then I can change them as necessary.
Frank Hecker
> Frank Hecker wrote:
>> However I do not agree that we should require CAs to use bugzilla
>> instead of email to submit the original requests. Not everybody knows
>> how to use bugzilla, and there's a little bit of overhead to get
>> yourself a login before you can submit a bug report. I think it would
>> be better to allow CAs to just send an email if they don't want to
>> deal with bugzilla; the "module owner" for certs (i.e., the person
>> getting the certif...@mozilla.org emails) would then enter the bug
>> report on behalf of the CA, and add the CA contact person to the CC
>> list for the bug.
>
> That wouldn't work unless the person had a Bugzilla account; in which
> case they could file a bug anyway.
Hmmm, I thought one could add arbitrary email addresses to the CC list,
but I guess not -- I just tested this.
> They are asking a lot from us - the least they can do is take three
> minutes to get a Bugzilla account and then click on the "File CA Cert
> Bug" link in the policy.
>
>> Note that this is essentially the same policy we handle for reports of
>> security vulnerabilities: you can enter a security-sensitive bug
>> yourself, or just email your report to secu...@mozilla.org.
>
> This is different. The person submitting such a report is doing us a
> favour, rather than the other way around.
OK, I understand and concede your point. However since the
certif...@mozilla.org address already exists and is known, I don't
think it would be a good idea to discontinue it entirely.
I think what I might do is to write the policy so that entering a bug
report is the preferred way to submit a request, and then either include
certif...@mozilla.org as a deprecated method or just not mention it
at all.
>> (Reminder to myself: I need to ask the appropriate mozilla.org person
>> to add a new component "CA certificates" to the "mozilla.org" product
>> in bugzilla. This will make it easier to track requests and ensure
>> that requests submitted via bugzilla will get to the right owner.)
>
> Done. Initial description: "For Certificate Authorities to file requests
> asking for their certificates to be included in the default certificate
> store." Tell me if that's wrong.
No, that sounds good. Thanks for adding this; I have only one nit to
pick, see below.
> I've made you "initial owner", although I expect that someone else will
> fill that role in due time.
Could you change the initial owner to be "hec...@hecker.org", not
"hec...@mozilla.org"? Since I'm no longer a full mozilla.org staff
member (but just an associate member) I've discontinued using my
mozilla.org address and bugzilla account in favor of my personal address
and account. Thanks in advance.
Nelson B
> David Ross wrote:
>
>> Already, bug #239408 has been submitted as Product: mozilla.org
>> and Component: CA Certificates. Someone should now change the
>> Component to CA Certificates for bug #233453 (mozilla.org needs a
>> public policy on root CA certs) and the other seven open bugs that
>> it blocks.
> Note that I can't make that change, because I am neither the assignee or
> the submitter for those other bugs, nor do I have sufficient privileges
> to override bugzilla and change the bugs anyway.
Hmm. "taking" bugs (reasigning them to one's self) is a long standing
practice in mozilla/bugzilla. In fact, any time you add an attachment
to a bug report, bugzilla offers to let you take the bug (er, it does
that for me). Bug asignees seldom dislike someone offering to do work
for them. :) If bugzilla is treating you as a second class citizen,
maybe we should see how to get that fixed!
> Ideally what should happen is that the assignees for those bugs (Wah-Teh
> Chang, Stephane Saux, Mitchell Baker, etc.) should re-assign them to me
> (hec...@hecker.org), and then I can change them as necessary.
I transferred all the "NSS" bugs about CA certs to you, except one that
I am investigating. It seems more like a real bug than the others.
--
Nelson B
Gervase Markham
> Note that I can't make that change, because I am neither the assignee or
> the submitter for those other bugs, nor do I have sufficient privileges
> to override bugzilla and change the bugs anyway.
You do now (as hec...@hecker.org). I've migrated the initial owner to
that account. Sorry for the delay.
Gerv
Nelson B
> Nelson B wrote:
>
>> I just started to read this, and need to read it more tomorrow.
>> One initial point. I think we're sending mixed signals to readers
>> about where is the appropriatre place for them to add comments about
>> individual CA applications.
>>
>> I've been telling people to disucss it in the newsgroup, NOT in bugzilla.
>> I believe bugzilla is NOT the place for general advocacy discussions.
>> I believe the comments in bugzilla about a particular application should
>> be limited to
>> a) the sole champion of the CA
>> b) the "module owner" of the certificates module
>> c) any developers specifically tasked with doing the jobs of making
>> source changes.
>> d) mozilla foundation members.
>
>
> I'm with David Ross on this one. This should be a public process (as the
> policy explicitly specifies) and we can't and shouldn't limit who can
> comment on bugs related to CA certificates.
My point is this. The BUG TRACKING system is not a place for advocacy
of any kind, on topic or off. It is a place for technical issues to
be disucssed. If there was a technical problem with adding one of
the proposed CA certs to the trust list, the bug would be the right place
for it to be discussed, because the discussion would help the assignee
of the bug to solve the technical problem. That's what the bug tracking
system is for. NOT FOR ADVOCACY.
Advocacy belongs in newsgroups. News servers as designed to handle lots
of load and high message traffic regardless of reason or merit. They
also drop traffic after a certain age. A news server can bound its
disk space arbitrarily.
The bug tracking system remembers every comment to every bug as long as
the bug tracking system survives. The bug server's disk space requirements
grow and grow. We don't want the bug system's disk filling up with
advocacy. And we don't want developers to have to sift through hundreds
of advocacy messages to find the few technical details needed to fix
the bug.
Developers inherently understand this. Non-developers do not. This is
why I advocate limiting the ability to add to BUGS in the BUG TRACKING
system to the people who need to use the bug tracking system (developers,
and bug submittors).
I'm all for open discussions, in the newsgroups, where they belong.
--
Nelson B
Frank Hecker
> My point is this. The BUG TRACKING system is not a place for advocacy
> of any kind, on topic or off. It is a place for technical issues to
> be disucssed. If there was a technical problem with adding one of
> the proposed CA certs to the trust list, the bug would be the right place
> for it to be discussed, because the discussion would help the assignee
> of the bug to solve the technical problem. That's what the bug tracking
> system is for. NOT FOR ADVOCACY.
I think your use of the "technical" vs. "advocacy" dichotomy is somewhat
misleading. Here is my personal opinion on which discussions should go
where (assuming we have an official policy in place):
1. Bugzilla is clearly the proper place for discussions as to whether to
include or not include a particular CA's certs, based on whether they
conform to the requirements in the policy as defined.
2. The newsgroup is clearly the proper place for general discussions
about the policy, issues that affect all CAs (e.g., whether or not to
enable CRL checking by default), issues relating to a particular CA that
are outside the scope of the policy (e.g., its sales practices, etc.),
and issues relating to the browser's security model in general as it
applies to SSL, S/MIME, and code signing.
If discussions of type 1 above start to evolve into discussions of type
2, then I or someone else can encourage people to continue discussions
in the proper forum.
Frank Hecker
> Nelson B wrote:
>> My point is this. The BUG TRACKING system is not a place for advocacy
>> of any kind, on topic or off. It is a place for technical issues to
>> be disucssed. If there was a technical problem with adding one of
>> the proposed CA certs to the trust list, the bug would be the right place
>> for it to be discussed, because the discussion would help the assignee
>> of the bug to solve the technical problem. That's what the bug tracking
>> system is for. NOT FOR ADVOCACY.
>
> I think your use of the "technical" vs. "advocacy" dichotomy is somewhat
> misleading.
After writing this I realize I did you a disservice by not explaining
exactly why I think the distinction between "technical" vs. "advocacy"
comments in Bugzilla is a misleading distinction in this context. My
apologies.
Here's what I meant: When you get assigned a bug about (for example)
Mozilla not properly recognizing a particular certificate, this really
is a technical issue for the most part; in all (or almost all) cases
this bug is ultimately resolvable into either a bug in Mozilla or a
problem in the certificate itself. There might be some side discussion
about where the certificate format is really correct or incorrect,
perhaps given some ambiguity in the relevant specification, but at heart
this is a technical issue and "advocacy" comments are for the most part
inappropriate and out of place.
However when I (or whomever) get assigned a bug about adding a
particular CA's root cert, then even if there's a defined policy the
decision is ultimately going to be (to a significant extent) a judgement
call based on perceptions of the risk/benefit tradeoffs for that
particular CA. These perceptions are a function of the opinions and
beliefs of the person who makes the decision and of the people who
participate in the discussion and provide input to the decision, and to
the extent that people put forth those opinions they're engaging in a
form of advocacy. So in this sense I think that "advocacy" is natural
and appropriate in this context, as long it's on topic as I noted
previously.
Now I guess we could try to remove this possibility for advocacy and try
to make decisions about CA cert inclusion more like decisions about
technical features, by arranging things so that there's a definitive
"right" answer. For example, we could make the decision very cut and
dried by automatically approving any CA with WebTrust endorsement and
automatically rejecting any CA without it. Not much need for judgement
there, at least on our part.
I don't happen to think that is the best approach for the Mozilla
project, for reasons I've discussed at length elsewhere. However I do
recognize that it makes decisions easier and quicker, and given the time
delays we've had here it's certainly tempting to employ it in certain
cases; see my next message.
Nelson B
> Here is my personal opinion on which discussions should go
> where (assuming we have an official policy in place):
>
> 1. Bugzilla is clearly the proper place for discussions as to whether to
> include or not include a particular CA's certs, based on whether they
> conform to the requirements in the policy as defined.
>
> 2. The newsgroup is clearly the proper place for general discussions
> about the policy, issues that affect all CAs (e.g., whether or not to
> enable CRL checking by default), issues relating to a particular CA that
> are outside the scope of the policy (e.g., its sales practices, etc.),
> and issues relating to the browser's security model in general as it
> applies to SSL, S/MIME, and code signing.
>
> If discussions of type 1 above start to evolve into discussions of type
> 2, then I or someone else can encourage people to continue discussions
> in the proper forum.
I suggest you correspond with one or more of the maintainers of b.m.o
about this. Bug 215243 has taxed b.m.o to its very limits, because of
the size of the CC list for that bug, and for the bugs that depend on it
and block it (all of which get notified whenever it changes). for weeks,
B.M.O's bug emailer was unable to finish distributing mail to the CC list
before the next comment was added, which caused all sorts of problems.
If the b.m.o maintainers are happy with the above policy, then I'm happy.
I would request one other detail. At the point if/when a bug in product
mozilla.org with component CA Certificates gets to the point where a
decision is made to add a ca cert, please do NOT turn that bug into an
NSS bug to do the actual addition. Rather, create a new NSS bug that is
free of all the advocacy that supplies the technical particulars (e.g. the
certs). Thanks.
--
Nelson B
Nelson B
I agree that b.m.o has different categories of bugs, some of which are
purely technical in nature, and others of which may not be. As long as
the maintainers of b.m.o have no problem with the potential volume of
traffic caused by advocacy comments in non-technical categories of
b.m.o, then I don't have any problem there either.
I would like it, though, if NSS bugs could be kept free of advocacy,
as much as possible, which is why I suggested not turning bugs that
contain such advocacy into NSS bugs. I'd guess that the owners of
most technical parts of mozilla would feel similarly.
I would also hope that the policy would ultimately be sufficiently
detailed detailed and objective that the process of determining whether
a given CA meets that criteria or not would be relatively cut-and-dried,
without a lot of room for advocacy.
In my copious free time, I am working on a questionare for CAs that I
hope will help us to formulate that policy, and may help CAs to provide
concise answers to help us determine if they meet it.
--
Nelson B
Frank Hecker
> I would request one other detail. At the point if/when a bug in product
> mozilla.org with component CA Certificates gets to the point where a
> decision is made to add a ca cert, please do NOT turn that bug into an
> NSS bug to do the actual addition. Rather, create a new NSS bug that is
> free of all the advocacy that supplies the technical particulars (e.g.
> the certs).
That's a reasonable request, and I'll do my best to follow it. (Please
complain to me if I forget.) What NSS component would you like such bugs
to be filed against?
Nelson B
Libraries, since the root list is in a library.
Thanks.
--
Nelson B
Doug Turner
Why do we need to add more CA's into Mozilla? It seams to me that most
of the CA's listed in Frank's posting are region specific. Will many of
the mozilla users ever come across certs from these CA's?
Thanks,
Doug
Duane
> Why do we need to add more CA's into Mozilla? It seams to me that most
> of the CA's listed in Frank's posting are region specific. Will many of
> the mozilla users ever come across certs from these CA's?
So you're implying there are no mozilla users in those regions then? :)
--
Best regards,
Duane
http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers
Ian Grigg
> Maybe this isn't the right newsgroup, but I just thought I toss this
> out....
>
> Why do we need to add more CA's into Mozilla?
The issue is that the set that is in place
derives from a long time ago (mostly, as set
up by Netscape, but that's only relevant by
way of history).
Since those days, things have changed. Some
of the roots are no longer in use, some might
be undesirable for some reason or another,
and some gaps might always have been in
there.
If the list isn't changed, what happens is
that the group of practical, available CAs
shrinks over time. This results in a slow
cartelisation of the space: fewer and more
costly CAs provide less and less of a service,
and new ideas are squashed. It's a process
of years, generally, but, years have passed!
By opening up the list to new providers, new
approaches and pressures for competition are
introduced, which helps the users. Examples
are QuoVadis which has a Bermudian aspect,
and CACert which has a "cheap certs for cheap
purposes" aspect.
From an economics point of view, opening up
the list is a vote towards competition, and
against franchise/cartelisation.
iang
Stephen Davidson
> of the CA's listed in Frank's posting are region specific. Will many of
> the mozilla users ever come across certs from these CA's?
Indeed most of the CAs are focussed on delivering certificates to a specific
region/government service/or industry.
However, our clients use those certificates to communicate with users around
the world. For example, QuoVadis routinely fields customer/user requests
from as far afield as Switzerland, the UK, Australia, Japan, and Venezuela.
As our clients' interactions are global, commercial CAs need to do
everything we can to provide ubiquity of our trust certificates.
Ben Bucksch
> Why do we need to add more CA's into Mozilla?
* The ones that are there probably shouldn't be there: E.g. AOL, and
IIRC I've never seen the rest in the wild, only VeriSign and
Thawte, but I didn't check often.
* The existing list doesn't serve large user groups
o Many servers should, but don't, offer SSL publically
o almost nobody has S/MIME certs
o nobody from mozdev signs his packages.
* There are a number of CAs which are just waiting to fill part of
the need.