Proposed CA policy change to require annual audits
Frank Hecker
certificate policy to require that CAs provide annual audit statements:
https://bugzilla.mozilla.org/show_bug.cgi?id=528303
This would make our policy consistent with that of other browser vendors.
The proposed policy change also requires that CAs notify us when they
make changes in their verification procedures. This would alert us to
cases where CAs get added under the assumption that they'll be issuing
one class of certificate and then later the CA decides to offer a
different class.
For the exact proposed changes see the patch attached to the bug; I've
also posted a copy of the proposed revised policy at
http://hecker.org/mozilla/ca-certificate-policy-1-3-draft
(This doesn't show the policy as it would look on the www.mozilla.org
site, but the text is the same.)
I'm now opening a public discussion period for this policy change.
Please post your comments in the mozilla.dev.security.policy forum or
the associated mailing list.
Also note that I'm willing to consider other suggested policy changes,
however I wanted to consider those separately. I'm doing this proposed
change first because it's pretty straightforward and Kathleen Wilson had
already drafted some new language that I could use as a starting point.
Once we get this proposed change addressed then we can consider some
other changes.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> I've just filed bug 528303 to propose an update to the Mozilla CA
> certificate policy to require that CAs provide annual audit statements:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=528303
A couple of other comments related to this.
First, regarding making this an annual requirement, vs. every 18 months
or 2 years or whatever: After reading past discussions, thinking about
it, and talking with Kathleen, my feeling is that it's simplest just to
make this an annual requirement, because that's the typical audit
schedule and that's what Microsoft already has as its policy.
At times there will be extenuating circumstances for a CA not being able
to meet this requirement -- maybe its auditor has not yet completed
work, maybe it's waiting for the report to be published on the WebTrust
site, maybe it's a government CA that by law is held to a different
schedule. We can make judgment calls on a case by case basis and make
exceptions to the policy where it's warranted.
Second, regarding tracking this: My proposal is to have Kathleen track
this as part of the general information she maintains for CAs, and to be
responsible for communicating with CAs as needed regarding getting the
updated audit reports.
David E. Ross
What are the consequences for violating Sections #13 and #14?
In general, the other sections relate primarily to how requests to add
new certificates are evaluated. For new certificates, the consequence
of not abiding by the policy is that the request can be denied.
Sections #13 and #14 relate to certificates already in the NSS database.
In declining order of severity, the consequences for violating Sections
#13 and #14 might be:
* Remove the certificates from the NSS database.
* Turn off all trust bits.
* Post an announcement of the violation (see below).
* Submit a bugzilla.mozilla.org bug report.
* Say "Tsk, tsk" to the CA and twiddle thumbs.
While the last item in the list above seems silly, that does seem to be
the current operating procedure with respect to CAs that have
certificates already in the NSS database and that fail to operate in an
appropriate manner. I also feel that a bug report is insufficient
because too few end users of Mozilla products and Mozilla-related
products look at bug reports; a bug report might be appropriate after a
more immediate consequence is implemented.
If there is a violation of either Sections #13 or #14, I feel that the
minimum acceptable action should be to post immediately a notice in the
following places: the home pages of mozilla.org and mozilla.com; the
newsgroups mozilla.general, mozilla.announce, and
mozilla.dev.security.policy; and the mozilla.support.* groups for
Camino, Firefox, SeaMonkey, and Thunderbird. The notice could be brief,
with a link to a Web page that more thoroughly describes not only the
problem but also how a user might disable the affected certificate. Not
only would such a notice allow users to protect themselves from a
non-compliant CA, but the public nature of the notice would motivate CAs
to comply with the policy.
If the violation were then remedied, a new notice could be posted (for
newsgroups, in the same thread as the original notice). Then, there
should be a link to a Web page that describes how a user might enable
the certificate.
While the details of the two paragraphs immediately above do not really
belong in the policy, a statement of consequences most definitely does
belong there.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg
>
> Second, regarding tracking this: My proposal is to have Kathleen track
> this as part of the general information she maintains for CAs, and to
> be responsible for communicating with CAs as needed regarding getting
> the updated audit reports.
>
Sounds good. However we should think upfront what it means if a CA fails
to provide the audit report. After which times happens what and how. I
think before making such a requirement Mozilla should know and establish
procedures and policies for the cases when, what, if, then...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
> The notice could be brief,
> with a link to a Web page that more thoroughly describes not only the
> problem but also how a user might disable the affected certificate.
>
> should be a link to a Web page that describes how a user might enable
> the certificate.
>
ROFL :-)
David, that's a good one!!!
Ian G
> I've just filed bug 528303 to propose an update to the Mozilla CA
> certificate policy to require that CAs provide annual audit statements:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=528303
>
> This would make our policy consistent with that of other browser vendors.
>
>
> The proposed policy change also requires that CAs notify us when they
> make changes in their verification procedures. This would alert us to
> cases where CAs get added under the assumption that they'll be issuing
> one class of certificate and then later the CA decides to offer a
> different class.
I feel there is a contradiction between these two proposed changes.
The verification procedures are primarily and foremost analysed by the
audit. This is the purpose of the audit, to analyse all procedures,
review the doco and procedures against some established (listed)
criteria, and test that they are being followed.
If you now require that CAs report to Mozilla whenever these procedures
change, you are now entering/interfering/overlapping with the audit process.
Particularly, if Mozilla enters the audit game, then *also* requiring
annual audits (and doing so fiercely as per other comments to name &
shame) is ... in some sense I've yet to vocalise ... contradictory.
I feel Mozilla has to make a decision. It has to take a stand, one way
or another.
Either Mozilla pursues the external auditor path, *and respects it*,
_OR_ Mozilla starts to replace it with something different.
I'm ok with either. People who read my blog will know I don't pull my
punches when dealing with the audit.
But somehow, doing both: requiring audit and requiring the CA to report
every little change for another audit ... seems to be troubling. It
feels like bureaucracy for bureaucracy's sake. It makes us feel good,
but achieves little for the end-user, and ultimately adds costs for the
CA. More audits, more checks, more more more.
The cost of this is security going down, because fewer people have fewer
certs.
As a concrete proposal; if Mozilla felt it preferable to rely on the
audit process, it is an easy matter for us to simply strip out the
quasi-criteria in the policy, and establish the "Mozilla criteria."
Then, simply instruct CAs to prepare an audit on this criteria, and
another one of their choice. It's "trivial" to do one audit over two
criteria, as long as the auditor and the CA know in advance.
> For the exact proposed changes see the patch attached to the bug; I've
> also posted a copy of the proposed revised policy at
>
> http://hecker.org/mozilla/ca-certificate-policy-1-3-draft
I looked at this, but it is the entire policy. What is the change to
text proposed? Is it possible to stick some <span color="red"> tags
around to signify each change?
> (This doesn't show the policy as it would look on the www.mozilla.org
> site, but the text is the same.)
(I also see a PHP error, first line?)
iang
Eddy Nigg
>
> The verification procedures are primarily and foremost analysed by the
> audit.
That's only partly correct! The audit mostly establishes the criteria
for disclosure and confirms adherence to the disclosed criteria.
> If you now require that CAs report to Mozilla whenever these
> procedures change, you are now entering/interfering/overlapping with
> the audit process.
Mozilla does that since the it published the Mozilla CA Policy. Mozilla
examines the CP/CPS which is confirmed by an auditor. Otherwise
Mozilla's only policy requirement could have been a valid audit. This
however is not the case, because Mozilla established very concrete
requirements - some of which are not part of the some audit schemes.
Incidentally other software vendors have their own requirements as well,
which might or might not be similar to those of Mozilla and not be part
of any audit criteria.
> I feel Mozilla has to make a decision. It has to take a stand, one
> way or another.
Yes, Mozilla does that all the time right here.
> Either Mozilla pursues the external auditor path, *and respects it*,
> _OR_ Mozilla starts to replace it with something different.
Mozilla doesn't perform audits, it relies on the audits to confirm
adherence to the published and disclosed policies and practices. Those
may or may not conform to the Mozilla CA policies requirements.
> But somehow, doing both: requiring audit and requiring the CA to
> report every little change for another audit ...
It's called compliance...your bank is also audited every year, so are
many other institutions. As you know, CP/CPS may change, so the quality
of operation of the CA.
> The cost of this is security going down, because fewer people have
> fewer certs.
Reports suggest that despite what you say, there are more and more web
sites using certificates, more people securing their emails. Since most
vendors already require a yearly audit report, it makes some sense to
also require it here. I think this is what Frank is proposing.
Ian G
> On 11/13/2009 02:44 AM, Ian G:
>>
>> The verification procedures are primarily and foremost analysed by the
>> audit.
>
> That's only partly correct!
That is indeed admitted, that's what "primarily and foremost" means.
> The audit mostly establishes the criteria
> for disclosure and confirms adherence to the disclosed criteria.
Simply put:
Say what you do, and do what you say.
If Mozilla feels that verification should be entered into that, then
that's what we should do.
>> If you now require that CAs report to Mozilla whenever these
>> procedures change, you are now entering/interfering/overlapping with
>> the audit process.
>
> Mozilla does that since the it published the Mozilla CA Policy. Mozilla
> examines the CP/CPS which is confirmed by an auditor. Otherwise
> Mozilla's only policy requirement could have been a valid audit. This
> however is not the case, because Mozilla established very concrete
> requirements - some of which are not part of the some audit schemes.
> Incidentally other software vendors have their own requirements as well,
> which might or might not be similar to those of Mozilla and not be part
> of any audit criteria.
None of this disagrees with the central point I make. If Mozilla wishes
to add criteria, it can and should.
>> I feel Mozilla has to make a decision. It has to take a stand, one way
>> or another.
>> Either Mozilla pursues the external auditor path, *and respects it*,
>> _OR_ Mozilla starts to replace it with something different.
>
> Mozilla doesn't perform audits, it relies on the audits to confirm
> adherence to the published and disclosed policies and practices. Those
> may or may not conform to the Mozilla CA policies requirements.
Alright, let's try with other words. Mozilla should decide whether it
is using an external auditor to do the job that it cannot do, *or*
decide to do itself what it feels auditors cannot do.
Demonstrably, checking verification is a job that auditors can do, and
do do, better than Mozilla can ever do.
All you gotta do is ask.
>> But somehow, doing both: requiring audit and requiring the CA to
>> report every little change for another audit ...
>
> It's called compliance...your bank is also audited every year, so are
> many other institutions. As you know, CP/CPS may change, so the quality
> of operation of the CA.
Sure, you can call it by whatever buzzword what you like. But any time
there are two audits required, covering overlap, there are complaints.
Is it not so hard for CAs to ask Mozilla to get its act together and
make things easier for CAs?
iang
Eddy Nigg
>> That's only partly correct!
>
> That is indeed admitted, that's what "primarily and foremost" means.
Interpretation...but I meant that even "primarily and foremost" is only
partly correct ;-)
>> The audit mostly establishes the criteria
>> for disclosure and confirms adherence to the disclosed criteria.
>
>
> Simply put:
>
> Say what you do, and do what you say.
Yes, that's pretty much the case until today. It isn't correct for EV,
because EV has established guidelines and audit criteria (at least for
WebTrust audits). This situation might change if and when the Basic SSL
guidelines are proposed.
>
> If Mozilla feels that verification should be entered into that, then
> that's what we should do.
I don't think it's really about verification, but about compliance. I'm
not aware that Mozilla EVER checked a CA if it does what it says -
that's the job of the auditors. However Mozilla checks the disclosed
policies and practices for compliance with the Mozilla requirements.
>>> Either Mozilla pursues the external auditor path, *and respects it*,
>>> _OR_ Mozilla starts to replace it with something different.
>>
>> Mozilla doesn't perform audits, it relies on the audits to confirm
>> adherence to the published and disclosed policies and practices. Those
>> may or may not conform to the Mozilla CA policies requirements.
>
>
> Alright, let's try with other words. Mozilla should decide whether it
> is using an external auditor to do the job that it cannot do, *or*
> decide to do itself what it feels auditors cannot do.
>
> Demonstrably, checking verification is a job that auditors can do, and
> do do, better than Mozilla can ever do.
Yes - obviously except in case Mozilla suspects that something isn't
quite in order with the audit. But that's a different story.
> Sure, you can call it by whatever buzzword what you like. But any
> time there are two audits required, covering overlap, there are
> complaints. Is it not so hard for CAs to ask Mozilla to get its act
> together and make things easier for CAs?
>
I didn't understand the first part...which two audits?
David E. Ross
> On 11/13/2009 12:11 AM, David E. Ross:
>> The notice could be brief,
>> with a link to a Web page that more thoroughly describes not only the
>> problem but also how a user might disable the affected certificate.
>>
>> Then, there
>> should be a link to a Web page that describes how a user might enable
>> the certificate.
>>
>
> ROFL :-)
>
> David, that's a good one!!!
>
Disable = turn off trust bits.
Enable = turn on trust bits.
David E. Ross
> On 13/11/2009 02:44, Eddy Nigg wrote [also in part]:
>
>
>> The audit mostly establishes the criteria
>> for disclosure and confirms adherence to the disclosed criteria.
>
>
> Simply put:
>
> Say what you do, and do what you say.
>
Actually, the mantra for ISO has three parts:
Say what you do, do what you say, and prove it.
This last part is quite important.
Kyle Hamilton
situation like what happened with Thawte's CPS version 1 to version 2
update, which allowed it to start issuing DV certs. I read and
accepted version 1, but I would not have willingly accepted version 2
without much more information presented in the UI.
-Kyle H
On Thu, Nov 12, 2009 at 6:03 PM, Ian G <ia...@iang.org> wrote:
> On 13/11/2009 02:44, Eddy Nigg wrote:
>>
>> On 11/13/2009 02:44 AM, Ian G:
>>>
>>> The verification procedures are primarily and foremost analysed by the
>>> audit.
>>
>> That's only partly correct!
>
>
> That is indeed admitted, that's what "primarily and foremost" means.
>
>
>> The audit mostly establishes the criteria
>> for disclosure and confirms adherence to the disclosed criteria.
>
>
> Simply put:
>
> Say what you do, and do what you say.
>
> If Mozilla feels that verification should be entered into that, then that's
> what we should do.
>
>
>>> If you now require that CAs report to Mozilla whenever these
>>> procedures change, you are now entering/interfering/overlapping with
>>> the audit process.
>>
>> Mozilla does that since the it published the Mozilla CA Policy. Mozilla
>> examines the CP/CPS which is confirmed by an auditor. Otherwise
>> Mozilla's only policy requirement could have been a valid audit. This
>> however is not the case, because Mozilla established very concrete
>> requirements - some of which are not part of the some audit schemes.
>> Incidentally other software vendors have their own requirements as well,
>> which might or might not be similar to those of Mozilla and not be part
>> of any audit criteria.
>
>
> None of this disagrees with the central point I make. If Mozilla wishes to
> add criteria, it can and should.
>
>
>>> I feel Mozilla has to make a decision. It has to take a stand, one way
>>> or another.
>
>
>
>>> Either Mozilla pursues the external auditor path, *and respects it*,
>>> _OR_ Mozilla starts to replace it with something different.
>>
>> Mozilla doesn't perform audits, it relies on the audits to confirm
>> adherence to the published and disclosed policies and practices. Those
>> may or may not conform to the Mozilla CA policies requirements.
>
>
> Alright, let's try with other words. Mozilla should decide whether it is
> using an external auditor to do the job that it cannot do, *or* decide to do
> itself what it feels auditors cannot do.
>
> Demonstrably, checking verification is a job that auditors can do, and do
> do, better than Mozilla can ever do.
>
> All you gotta do is ask.
>
>
>>> But somehow, doing both: requiring audit and requiring the CA to
>>> report every little change for another audit ...
>>
>> It's called compliance...your bank is also audited every year, so are
>> many other institutions. As you know, CP/CPS may change, so the quality
>> of operation of the CA.
>
>
> Sure, you can call it by whatever buzzword what you like. But any time
> there are two audits required, covering overlap, there are complaints. Is it
> not so hard for CAs to ask Mozilla to get its act together and make things
> easier for CAs?
>
>
> iang
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> On 11/12/2009 4:16 PM, Eddy Nigg wrote:
>
>> On 11/13/2009 12:11 AM, David E. Ross:
>>
>>> The notice could be brief,
>>> with a link to a Web page that more thoroughly describes not only the
>>> problem but also how a user might disable the affected certificate.
>>>
>>> Then, there
>>> should be a link to a Web page that describes how a user might enable
>>> the certificate.
>>>
>>>
>> ROFL :-)
>>
>> David, that's a good one!!!
>>
>>
> Disable = turn off trust bits.
>
> Enable = turn on trust bits.
>
>
Yes of course....the way you presented that was hilarious....I'm still
laughing! :-)
Frank Hecker
> What are the consequences for violating Sections #13 and #14?
>
> In general, the other sections relate primarily to how requests to add
> new certificates are evaluated.
Yes, and I should add that we may want to look at the overall way the
policy is structured, especially since we are also considering adding a
section that explicitly discusses certificate removal.
> For new certificates, the consequence
> of not abiding by the policy is that the request can be denied.
> Sections #13 and #14 relate to certificates already in the NSS database.
> In declining order of severity, the consequences for violating Sections
> #13 and #14 might be:
> * Remove the certificates from the NSS database.
> * Turn off all trust bits.
> * Post an announcement of the violation (see below).
> * Submit a bugzilla.mozilla.org bug report.
> * Say "Tsk, tsk" to the CA and twiddle thumbs.
My suggested approach is to let Kathleen follow up with the CA in
question and make a judgment call on the right action. The initial
action I'd suggest is simply talking to the CA and seeing what's going
on vis-a-vis the audit renewal. If there's a plausible reason for why
the report is delayed plus a commitment on the part of the CA to address
the issue, I don't see a problem with giving a CA a grace period, even
though this might smack of the "tsk tsk" approach.
If it becomes clear that the report is not going to be forthcoming and
the CA has no plausible reason (or is totally uncommunicative), then I
think your other actions make sense as potential escalations: put the CA
on formal notice by filing a bug report, make some sort of public
announcement, and eventually disabling or removing the CA. Exactly when
(or whether) those actions are taken I'd leave to Kathleen's judgment,
with input from me and all of you.
> If there is a violation of either Sections #13 or #14, I feel that the
> minimum acceptable action should be to post immediately a notice in the
> following places: the home pages of mozilla.org and mozilla.com; the
> newsgroups mozilla.general, mozilla.announce, and
> mozilla.dev.security.policy; and the mozilla.support.* groups for
> Camino, Firefox, SeaMonkey, and Thunderbird.
This is part of the general question of how we communicate
security-relevant changes to users, and would also apply to how we
handle disabling CAs for other reasons. I personally don't think putting
notices on the home pages is the right thing to do, it's not in line
with the purposes of those pages and most users don't encounter them in
the normal course of events in any case. There are other channels like
the "About:Mozilla" newsletter that might be more appropriate.
But here we're arguing implementation as opposed to policy. In general I
agree with the idea of giving some sort of public notice around issues
like this.
> While the details of the two paragraphs immediately above do not really
> belong in the policy, a statement of consequences most definitely does
> belong there.
This goes back to my point above about restructuring the policy. Maybe
we'd want to have the policy reorganized into at least two sections, one
regarding adding CAs and one regarding removal. The audit renewal
requirement could then go under the "removal" section, as one of a
number of possible reasons why we'd remove a CA or disable trust bits.
Note that the "adding" section could also address CA-initiated requests
to have additional trust bits enabled, and the "removal" section could
also address CA-initiated requests to remove certs or disable trust bits.
Frank Hecker
> Sounds good. However we should think upfront what it means if a CA fails
> to provide the audit report. After which times happens what and how. I
> think before making such a requirement Mozilla should know and establish
> procedures and policies for the cases when, what, if, then...
Not having an up-to-date audit is just another in the general list of
things that might cause a CA to be removed or have its trust bits
disabled. See my comment to David Ross about reorganizing the policy to
make this more clear, and about how to handle cases where we don't get
timely audit reports.
Frank Hecker
> I feel there is a contradiction between these two proposed changes.
>
> The verification procedures are primarily and foremost analysed by the
> audit. This is the purpose of the audit, to analyse all procedures,
> review the doco and procedures against some established (listed)
> criteria, and test that they are being followed.
>
> If you now require that CAs report to Mozilla whenever these procedures
> change, you are now entering/interfering/overlapping with the audit
> process.
As I recall, what motivated this language about notification was Kyle's
concerns about CAs making major changes that were inconsistent with the
CPS under which they were originally approved. (In the particular case
I'm thinking of it was a CA that introduced DV certs into a hierarchy
where the CPS didn't allow for that. (Perhaps Kyle can clarify this.)
The intent here is not really to replace the audit process. However
there's a general question of what to do when CAs change things in
between audits, in a way that has potential impact on Mozilla users.
>> For the exact proposed changes see the patch attached to the bug; I've
>> also posted a copy of the proposed revised policy at
>>
>> http://hecker.org/mozilla/ca-certificate-policy-1-3-draft
>
> I looked at this, but it is the entire policy. What is the change to
> text proposed? Is it possible to stick some <span color="red"> tags
> around to signify each change?
I did that, marking the changes by hand. However note that the patch
attached to the bug is the authoritative reference for what would be
changed.
I posted it the way I did because I wanted to post the exact new file as
it would be committed to the Subversion repository for www.mozilla.org.
Unfortunately the file won't display properly in all respects outside
the context of the www.mozilla.org (PHP-based) template system (which is
why you saw the PHP error). When I did the color changes I deleted the
PHP stuff as well.
Varga Viktor
1) will be there Mozilla trust list like in MS?
I think it is needed for the fast reactions, and much easier to publish the trust bit when there is some change int he trust bits.
2) Will be Kathleen overloaded with work when yearly audits were started? :)
Hundreds of CA documents can generate a lot of documents.
3) What are the dealines?
Sometimes, its hard to get an original document in english language from a govermental agency.
(In the EU much harder, because native language in a country is one of the 25 official language of the EU, and a document cannot be refused because its language. :) )
4) Will be there an exact checklist, what should be in an audit accepted by the Mozilla?
I think a some periodicaly checking script to find quickly bugs are more important. To detect bug like the OCSP bug at IPS.
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Frank Hecker
> I think the language that Frank's proposing is primarily to avoid the
> situation like what happened with Thawte's CPS version 1 to version 2
> update, which allowed it to start issuing DV certs.
Yes, thanks for chiming in here. Kathleen did indeed propose this
language with you in mind.
> I read and
> accepted version 1, but I would not have willingly accepted version 2
> without much more information presented in the UI.
Can you remind me how this change actually occurred in practice? There's
at least three general ways in which situations like this could occur:
* CA changes practices in a substantive way (substantive from our point
of view) but does not update the CP/CPS to reflect the changes.
* CA changes practices in a substantive way and updates the CP/CPS, but
it's in the middle of an audit cycle, so the most recent audit report
doesn't cover operation under the new CP/CPS.
* CA changes practices in a substantive way, updates the CP/CPS, and the
most recent audit report reflects the changes.
Also, as I recall your concern here was basically an issue of notifying
the user of the changes. (Sort of a "truth in advertising" concern.)
Such changes would not in and of themselves be cause for taking action
against a CA, it's more a matter of making sure our users have the most
up-to-date information about a CA and can then make their own decisions
about it.
In this regard, we don't really have a UI mechanism for making users
aware of things like this, but we could leverage Kathleen's CA
information database for this, along with the sort of public
notification mechanisms David was suggesting.
Ian G
I agree with that. I don't think it is possible to be "tough" about
this in advance. Whatever rule we make now will likely bring us grief
later on when we have to argue about breaking the rule or enforcing it.
In fact I'd go further. I don't think it is necessary to put such a
thing in the policy at all. What we could do in the policy is simply
refer to the problematic practices, *and* reserve the final word for
Mozilla.
This is why the original 1.0 policy had text in it such like "we reserve
the right / for whatever reason / to dump you." There are always going
to be new circumstances that cause anguish, and if it is not in the
rules, it can't be wrong.
Which is to say, move away from a "rules-based" approach and more to a
"judgement-based" approach, backed up by wiki pages listing our current
view.
iang
Frank Hecker
> 1) will be there Mozilla trust list like in MS?
> I think it is needed for the fast reactions, and much easier to publish the trust bit when there is some change int he trust bits.
Are you referring to the Root Update mechanism that Microsoft uses to
push CA-related changes out to end-users' copies of Windows?
Unfortunately we do not have a Mozilla update mechanism that is specific
to CAs and would allow us to distribute new roots and make trust bit
changes independent of other updates to Firefox, Thunderbird, etc. At
present the only way we can make CA-related changes is to distribute
those changes as part of general Firefox/Thunderbird updates that are
done for security problems or bug fixes. I do not expect this situation
will change in the foreseeable future; for now we are stuck with our
current update mechanism.
> 2) Will be Kathleen overloaded with work when yearly audits were started? :)
> Hundreds of CA documents can generate a lot of documents.
This is really a question for Kathleen to answer. In Microsoft's case
they proactively contact CAs three months before the annual period ends,
and ask them to submit new documentation. I don't know if it would make
sense for Kathleen to do that, or if it would be easier to do a monthly
check to see if any CAs are due for a new audit report in that month.
> 3) What are the dealines?
> Sometimes, its hard to get an original document in english language from a govermental agency.
> (In the EU much harder, because native language in a country is one of the 25 official language of the EU, and a document cannot be refused because its language. :) )
I would let Kathleen determine the exact deadlines. However we can
suggest some general guidelines.
> 4) Will be there an exact checklist, what should be in an audit accepted by the Mozilla?
The requirements for audits would be the same as what we have now. (We
will consider separate changes to the policy, for example to reference
the new ETSI documents; however that's a separate issue from this change.)
> I think a some periodicaly checking script to find quickly bugs are more important. To detect bug like the OCSP bug at IPS.
That is a good suggestion. However to do that we need to find someone
who can implement the necessary system to do such automated checking. I
don't have the technical knowledge to do that, nor does Kathleen (I think).
Eddy Nigg
> On 13/11/2009 17:01, Frank Hecker wrote:
>> Eddy Nigg wrote:
>>> Sounds good. However we should think upfront what it means if a CA
>>> fails to provide the audit report. After which times happens what and
>>> how. I think before making such a requirement Mozilla should know and
>>> establish procedures and policies for the cases when, what, if, then...
>>
>> Not having an up-to-date audit is just another in the general list of
>> things that might cause a CA to be removed or have its trust bits
>> disabled. See my comment to David Ross about reorganizing the policy to
>> make this more clear, and about how to handle cases where we don't get
>> timely audit reports.
>
>
> I agree with that. I don't think it is possible to be "tough" about
> this in advance. Whatever rule we make now will likely bring us grief
> later on when we have to argue about breaking the rule or enforcing it.
I look at it the other way around...I have no interest in arguing every
time a CA doesn't provide an audit report. Lets define and decide what
the limits are and which actions should be taken under which
circumstances. If we can't do that now, I'm not really supportive of the
policy change....
>
> In fact I'd go further. I don't think it is necessary to put such a
> thing in the policy at all. What we could do in the policy is simply
> refer to the problematic practices, *and* reserve the final word for
> Mozilla.
I don't think we need to define what happens in the policy, the policy
Frank suggested is fine. I don't want to have that in the PP pages
either, since every time an argument is made regarding compliance and
it's "only" on the PP pages, the argument is voided because it's NOT in
the policy (practice has been different, but the same argument was made
by a CA and even Gerv, just recently at a different discussion IIRC).
>
> This is why the original 1.0 policy had text in it such like "we
> reserve the right / for whatever reason / to dump you." There are
> always going to be new circumstances that cause anguish, and if it is
> not in the rules, it can't be wrong.
Yes, that one should remain there as is.
Moudrick M. Dadashov
> Varga Viktor wrote:
>> 3) What are the dealines?
>> Sometimes, its hard to get an original document in english language
>> from a govermental agency. (In the EU much harder, because native
>> language in a country is one of the 25 official language of the EU,
>> and a document cannot be refused because its language. :) )
>
> I would let Kathleen determine the exact deadlines. However we can
> suggest some general guidelines.
>
Thanks for this question.
The problem here is that many CAs don't maintain bilingual versions of
CP/CPS even though translations are offered here.
I think a clear list of what needs to be translated would be a good
start. Of course, Kathleen can request more clarifications/translations
if needed.
Today's "selective" approach doesn't work for Mozilla's user community's
interests.
Thanks,
M.D.
cell: +370-699-26662
Eddy Nigg
> The problem here is that many CAs don't maintain bilingual versions of
> CP/CPS even though translations are offered here.
>
> I think a clear list of what needs to be translated would be a good
> start. Of course, Kathleen can request more clarifications/translations
> if needed.
>
Perhaps only a diff from the previous policy and CPS? Or according to
the changes recorded.
> Today's "selective" approach doesn't work for Mozilla's user community's
> interests.
>
:S
Ian G
> Ian G wrote:
>> I feel there is a contradiction between these two proposed changes.
>>
>> The verification procedures are primarily and foremost analysed by the
>> audit. This is the purpose of the audit, to analyse all procedures,
>> review the doco and procedures against some established (listed)
>> criteria, and test that they are being followed.
>>
>> If you now require that CAs report to Mozilla whenever these
>> procedures change, you are now entering/interfering/overlapping with
>> the audit process.
>
> As I recall, what motivated this language about notification was Kyle's
> concerns about CAs making major changes that were inconsistent with the
> CPS under which they were originally approved. (In the particular case
> I'm thinking of it was a CA that introduced DV certs into a hierarchy
> where the CPS didn't allow for that. (Perhaps Kyle can clarify this.)
Right, he clarified it, thanks. I'm fine with the example, it's quite
clear. The bait-and-switch is always possible.
> The intent here is not really to replace the audit process. However
> there's a general question of what to do when CAs change things in
> between audits, in a way that has potential impact on Mozilla users.
This whole question exists anyway. Indeed, if we look closely at the
audit process, auditors are always very clear to say that an audit
report cannot be relied upon to predict the future. It is a "snapshot"
and should be seen as a vertical slice over time. E.g., a month, no
more, and definately not a record over the last year. (Notwithstanding
that they will also then suggest you not do business with a company that
hasn't got an audit, because being audited is a good predictor of future
performance ;) The philosophical clash between audit and other
possibilities is not a trivial one.
Back to the issue at hand: how to lock down CAs from doing something
that we don't like, in the future, *and* not presenting them with
shackles and chains....
Points:
1. We could ask for "material changes" rather than "any changes".
We don't want them to send us every line that changes. We don't want
them to tell us that they are now checking for 2 email addresses not 1,
or they've added another staff member, or ... Also, if we ask for all
changes, some will ignore it completely and some will bombard us, so the
effect will not be even. Therefore unfair on those who do the right thing.
Material covers Kyle's example, I think. The word "material" is well
understood by business, or should be (which is to say we can rely on CAs
knowing what is meant, even if they don't).
Of course there remains wiggle room, and we will have people disagreeing
over whether issue X is material or not, but I don't think we can avoid
that.
2. I don't think we should focus on verification. I could give a long
list of things I would want to know about before verification, starting
with contracts. Others will point to revocation, HSMs, key lengths, etc
etc.
(It is a sort of fascination that Mozilla policy group is strongly
focussed on DV-certs and domain checking. Verifying control of email
addresses is a persistent topic. But for CAs and users it is less than
1% of it, and that other work is for more important, just in its shear
bulk, even if we might accept that verification is #1.)
With that I would suggest:
========== MY MODS:
notify us when their policies and business practices (e.g., as
documented in a Certificate Policy or Certification Practice Statement)
change *in ways that are material to Mozilla and Mozilla's end-users.*
========== PROPOSED
notify us when their policies and business practices (e.g., as
documented in a Certificate Policy or Certification Practice Statement)
change _in regards to verification procedures for issuing certificates._
==========
iang, 2c, worth, minimum :)
Eddy Nigg
>
> Points:
>
> 1. We could ask for "material changes" rather than "any changes".
That sounds good.
> 2. I don't think we should focus on verification. I could give a long
> list of things I would want to know about before verification,
> starting with contracts. Others will point to revocation, HSMs, key
> lengths, etc etc.
>
> (It is a sort of fascination that Mozilla policy group is strongly
> focussed on DV-certs and domain checking. Verifying control of email
> addresses is a persistent topic. But for CAs and users it is less
> than 1% of it, and that other work is for more important, just in its
> shear bulk, even if we might accept that verification is #1.)
It's not a focus because we are all hooked up on DV, but simply because
those are the minimum requirements the Mozilla Policy puts forth.
Mozilla makes no requirements regarding other validations which may be
also performed with server certificates. The same is correct for emails
and IV/OV for code signing. We just focus on the least a CA must do.
> ========== MY MODS:
> notify us when their policies and business practices (e.g., as
> documented in a Certificate Policy or Certification Practice
> Statement) change *in ways that are material to Mozilla and Mozilla's
> end-users.*
This leaves it a bit open to interpretation, but it "sounds" better...
> ========== PROPOSED
> notify us when their policies and business practices (e.g., as
> documented in a Certificate Policy or Certification Practice
> Statement) change _in regards to verification procedures for issuing
> certificates._
This clearly boxes the above mentioned (e.g. minimum requirements)
David E. Ross
After more thought, I think this should be a new policy, separate from
"Mozilla CA Certificate Policy". After all, the removal of certificates
will aparently be a separate, distinct policy. I think inserting
post-installation issues into a policy that, for now, relates only to
approval and installation can be confusing.
This new policy could be "Mozilla Policy: Maintaining Trust of Installed
CA Certificates". The existing policy might be renamed "Mozilla Policy:
Approving CA Certificates for Installation".
Kyle Hamilton
checked the Thawte CPS history (at https://www.thawte.com/cps, which I
had to find by going to https://www.thawte.com/ and looking at their
certificate details to find the Certificate Policies extension, which
contains the reference I needed -- they certainly don't link to it
from the home page), and have found the specific change that riled me.
In Version 2.1 of the CPS (January 09, 2004), they had 4 types of
certificates, listed (with their associated authentication levels) as:
SSL Web Server Certificates, High
SGC SuperCerts, High
Code Signing Certificates, High
Personal E-mail Certificates, Low
In Version 2.2 (April 21, 2005) (which they passed off as a minor
change), the following are listed:
SSL Web Server Certificates, High
SGC SuperCerts, High
Code Signing Certificates, High
SSL123 Certificates, Medium
Personal E-mail Certificates, Low
I had originally based my trust of Thawte on the fact that their CPS
did not allow for domain-validated SSL certificates. I got a rude
awakening a few years later (I think in 2006 or so, when I first
brought it to the attention of the group on dev-tech-crypto) when I
browsed to look at their CPS, and saw SSL123 as "Medium Assurance"
(which wasn't even defined in version 2.1). So, I asked their support
for the name of the sub-CA certificate, so I could find it and
explicitly distrust it. I was floored when I was told "soon, they'll
be issued directly off the root".
That's a very, very substantive change. I'm not sure which version of
the CPS allowed for the SSL123 to be issued directly off the root --
I'm just explaining why I was so infuriated.
Since then, the landscape has changed -- VISA and MasterCard dropped
debit and credit card unauthorized activity liability to $0 for US
cardholders, eBay and PayPal have created an instant means of payment
(and a very cut-and-dry policy on payment disputes), and every CA and
their brother are issuing DV. My railing about this has not caused
any UI changes, either in branding the CA (especially since the blue
bar is gone) or stating that it's a "domain-validated" certificate.
The UI provided for OV and DV was precisely the same when the blue bar
was common -- it didn't (and still doesn't) print out the Subject of
the certificate if it wasn't EV. This, in my opinion, was a mistake
-- because all the CAs that issue DV certs put something there that
says it's a domain-validated certificate.
-Kyle H
Eddy Nigg
> My railing about this has not caused
> any UI changes, either in branding the CA (especially since the blue
> bar is gone) or stating that it's a "domain-validated" certificate.
> The UI provided for OV and DV was precisely the same when the blue bar
> was common -- it didn't (and still doesn't) print out the Subject of
> the certificate if it wasn't EV. This, in my opinion, was a mistake
> -- because all the CAs that issue DV certs put something there that
> says it's a domain-validated certificate.
>
You know that any efforts in respect for UI differences have been
unsuccessful (for more than three years I think).
Just one thing puzzles me....what is this "blue bar" which was common?
Which blue bar was and is gone now?
Kyle Hamilton
of the sitename, I think it (used to be) controlled by
browser.identity.ssl_domain_display. The one that said what the
expected hostname was supposed to be. It showed up in the same place
where the green EV bar does today.
-Kyle H
Kyle Hamilton
is now stating that it's "partially encrypted", rather than showing
the blue bar that I used to get. with google.com. What changed
between 3.3.4 and 3.3.5 related to SSL? I know that the change to
allow embedded data to not break SSL was included, but what else?
I'm not sure what I need to look at to figure out just what's using an
unencrypted method, but I'll get FireBug installed and try to figure
it out.
-Kyle H
Eddy Nigg
> The pre-3.0 multiple-click warning blue bar that showed up to the left
> of the sitename, I think it (used to be) controlled by
> browser.identity.ssl_domain_display. The one that said what the
> expected hostname was supposed to be. It showed up in the same place
> where the green EV bar does today.
>
I'm not aware that anything change - actually in 3.5 the default
behavior is now to show the blue bar in order to provide more "positive"
indicators, since plain text doesn't provide any.
Kyle Hamilton
https://blog.startcom.org/?p=86 , when 3.0 came out.
-Kyle H
Eddy Nigg
> Really? You were the one who pointed it out, on
> https://blog.startcom.org/?p=86 , when 3.0 came out.
>
Oh...you meant that little blueish hue behind the Favicon which was
present in FF3? I didn't counted that to be anything of significance to
even worth thinking about ;-)
Anyway, right now in FF3.5 browser.identity.ssl_domain_display should be
set by default to 1 and should be still there if nothing changed. I'm on
FF3.6 already and haven't noticed any difference in this respect. If you
don't see the blue bar with the domain in it, than this would indicate
some problem perhaps. So the blue bar isn't gone as you thought in an
earlier posting of yours.
Kyle Hamilton
http://kb.mozillazine.org/Browser.identity.ssl_domain_display
(it says that 1 is the default starting with 3.1b3, and it was 0 in 3.0)
-Kyle H
Eddy Nigg
> It was gone in 3.0:
> http://kb.mozillazine.org/Browser.identity.ssl_domain_display
>
> (it says that 1 is the default starting with 3.1b3, and it was 0 in 3.0)
>
This capability didn't exist before 3.0 at all, hence it couldn't have
been gone in 3.0 ;-)