Mozilla Communication: Immediate action requested
Kathleen Wilson
I have sent the following communication to CAs with root certificates in
NSS.
Kathleen
==
Dear Certification Authority,
This note requests a set of immediate actions on your behalf, as a
participant in the Mozilla root program.
Mozilla recently removed the DigiNotar root certificate in response to
their failure to promptly detect, contain, and notify Mozilla of a
security breach regarding their root and subordinate certificates
(https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up).
If you ever have reason to suspect a security breach or mis-issuance has
occurred at your CA or elsewhere, please contact secu...@mozilla.org
immediately.
Please confirm completion of the following actions or state when these
actions will be completed, and provide the requested information no
later than September 16, 2011:
1) Audit your PKI and review your systems to check for intrusion or
compromise. This includes all third party CAs and RAs.
2) Send a complete list of CA certificates from other roots in our
program that your roots (including third party CAs and RAs) have
cross-signed. A listing of all root certificates in Mozilla's products
is here: http://www.mozilla.org/projects/security/certs/included
3) Confirm that multi-factor authentication is required for all accounts
capable of directly causing certificate issuance.
4) Confirm that you have automatic blocks in place for high-profile
domain names (including those targeted in the DigiNotar and Comodo
attacks this year). Please further confirm your process for manually
verifying such requests, when blocked.
5) For each external third party (CAs and RAs) that issues certificates
or can directly cause the issuance of certificates within the hierarchy
of the root certificate(s) that you have included in Mozilla products,
either:
a) Implement technical controls to restrict issuance to a specific set
of domain names which you have confirmed that the third party has
registered or has been authorized to act for (e.g. RFC5280 x509 dNSName
name constraints, marked critical)
OR
b) Send a complete list of all third parties along with links to each of
their corresponding Certificate Policy and/or Certification Practice
Statement and provide public attestation of their conformance to the
stated verification requirements and other operational criteria by a
competent independent party or parties with access to details of the
subordinate CA's internal operations.
Each action requested above applies both to your root and to these third
parties.
Participation in Mozilla's root program is at our sole discretion, and
we will take whatever steps are necessary to keep our users safe.
Nevertheless, we believe that the best approach to safeguard that
security is to work with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to improve. Thank
you for your participation in this pursuit.
Regards,
Kathleen Wilson
Module Owner of Mozilla's CA Certificates Module
===
David E. Ross
* Maintain effective anti-virus software with current and constantly
updating virus databases.
* Have distinct passwords or passphrases for each distinct login to
servers, private keys, applications, etc, with only a limited number of
different personnel having knowledge of each.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Ralph Holz (TUM)
Are these BR requirements? Or does this mean Mozilla has taken the step of liberating itself from the need for consensus in the CABForum, and will now pursue what might be a tougher stance?
Ralph
Kathleen Wilson
We are in full support of the CA/Browser Forum's work on the Baseline
Requirements. However, Mozilla has, and will continue to have our own
policies and requirements for CAs with root certificates in Mozilla's
root program.
Kathleen
Kathleen Wilson
communications to CAs.
https://wiki.mozilla.org/CA:Communications
Kathleen
Ian G
Thanks for that. Some questions. I do not think they demand answers this week, in the heat of the crisis.
Firstly, is there a coordinated response among vendors? Some of these points cry out for it.
On 09/09/2011, at 3:12, Kathleen Wilson <kathle...@yahoo.com> wrote:
> Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact secu...@mozilla.org immediately.
> 1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.
> 2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included
(I'm not opposed, just want it noted so, if so.)
> 3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.
> Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe.
"module owner maintains a register of detailed requirements that implement the policy, and distributes change requests as required to maintain or improve security, in mozilla's sole determination."
Iang
Kathleen Wilson
> Some DigiNotar issues that you failed to address include:
>
> * Maintain effective anti-virus software with current and constantly
> updating virus databases.
>
> * Have distinct passwords or passphrases for each distinct login to
> servers, private keys, applications, etc, with only a limited number of
> different personnel having knowledge of each.
>
should protect their network and servers. The communication also does
not provide specifics about password best practices.
To date, the Mozilla CA Certificate Policy has been focused on
operations and process regarding certificate issuance and revocation.
The annual WebTrust/ETSI audits that we require are also along the same
lines. Perhaps we should consider requiring audits more along the lines
of network security by experts in intrusion detection? Just a thought...
Kathleen
Stephen Schultze
> 5) For each external third party (CAs and RAs) that issues certificates
> or can directly cause the issuance of certificates within the hierarchy
> of the root certificate(s) that you have included in Mozilla products,
> either:
>
> a) Implement technical controls to restrict issuance to a specific set
> of domain names which you have confirmed that the third party has
> registered or has been authorized to act for (e.g. RFC5280 x509 dNSName
> name constraints, marked critical)
I presume that this is intended to communicate that "RFC5280 x509
dNSName name constraints, marked critical" is the only approved
approach, short of separate proposal and approval via this list.
> OR
>
> b) Send a complete list of all third parties along with links to each of
> their corresponding Certificate Policy and/or Certification Practice
> Statement
Send where? If not this list, will it be forwarded to this list?
> and provide public attestation of their conformance to the
> stated verification requirements and other operational criteria by a
> competent independent party or parties with access to details of the
> subordinate CA's internal operations.
This seems like a clear (and welcome) change in policy, requiring that
RAs and SubCAs be audited. Is this a correct interpretation?
Steve
Kathleen Wilson
> On 9/8/11 1:12 PM, Kathleen Wilson wrote:
>> 5) For each external third party (CAs and RAs) that issues certificates
>> or can directly cause the issuance of certificates within the hierarchy
>> of the root certificate(s) that you have included in Mozilla products,
>> either:
>>
>> a) Implement technical controls to restrict issuance to a specific set
>> of domain names which you have confirmed that the third party has
>> registered or has been authorized to act for (e.g. RFC5280 x509 dNSName
>> name constraints, marked critical)
>
> I presume that this is intended to communicate that "RFC5280 x509
> dNSName name constraints, marked critical" is the only approved
> approach, short of separate proposal and approval via this list.
>
issuance to a specific set of domain names. "RFC5280 x509 dNSName name
constraints, marked critical" is the recommended approach, but there are
other valid ways this requirement may be met.
>> OR
>>
>> b) Send a complete list of all third parties along with links to each of
>> their corresponding Certificate Policy and/or Certification Practice
>> Statement
>
> Send where? If not this list, will it be forwarded to this list?
>
send to me in response to this communication will not be forwarded to
this list unless they specifically give me permission to do so.
>> and provide public attestation of their conformance to the
>> stated verification requirements and other operational criteria by a
>> competent independent party or parties with access to details of the
>> subordinate CA's internal operations.
>
> This seems like a clear (and welcome) change in policy, requiring that
> RAs and SubCAs be audited. Is this a correct interpretation?
>
certificates must either constrained or audited.
Kathleen
Kathleen Wilson
>> to their failure to promptly detect, contain, and notify Mozilla of
>> a security breach regarding their root and subordinate certificates
>> (https://blog.mozilla.com/security/2011/09/02/diginotar-removal
>> mis-issuance has occurred at your CA or elsewhere, please contact
>> secu...@mozilla.org immediately.
>
> There is wide-spread skepticism that such an act would have been
> taken with a medium or large CA. In order to clarify this, can we
> confirm the nature of the process? Eg is this a clear cut cause,
> above? Or is it case-by-case? I could ask more questions, but I'm
> sure the drift is clear (I'll take further comments offlist).
>
seriously. In my opinion, the reasons for distrusting the DigiNotar root
and intermediate certs are clear and well known. I do not believe that
the size of their business would have changed the outcome that resulted
from their failure to detect, respond, and communicate in a timely manner.
>> 1) Audit your PKI and review your systems to check for intrusion or
>> compromise. This includes all third party CAs and RAs.
>
> (I'm guessing this means internal review according to documented
> incident investigation standards. Not external review unless new
> evidence located.)
>
compromise. If that happens, then the CA should seek external, expert help.
CA's are requested to:
- Check for mis-issuance of certs.
- Review network infrastructure, monitoring, passwords, etc.
- Ensure IDS and other monitoring software is up-to-date, best practices
are in place, etc.
- Also perform these checks for all third-parties who can directly cause
the issuance of certificates.
>> 2) Send a complete list of CA certificates from other roots in our
>> program that your roots (including third party CAs and RAs) have
>> cross-signed. A listing of all root certificates in Mozilla's
>> products is here:
>> http://www.mozilla.org/projects/security/certs/included
>
> Points 2,4,5 previously discussed on policy list, but concensus not
> reached? Are we saying here that it is now moved forward to policy
> status?
>
Mozilla CA Certificate Policy; sections 6, 9, and 10 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
These updates to the policy are still under discussion. I will re-ignite
the policy discussions soon.
The action items in the communication are required of all CAs with root
certificates currently in NSS, and will be required of all CAs
requesting root inclusion. I'm planning to update
https://wiki.mozilla.org/CA:Information_checklist to include these
action items. I will also followup with CAs currently in the inclusion
process.
>> 3) Confirm that multi-factor authentication is required for all
>> accounts capable of directly causing certificate issuance.
>
> What standard of multiple-factor? This can be as simple as two
> passwords, or it can be SecureId fob, or multiple-channel phone SMS
> transactional confirmations.
>
have responded already have stated the manner in which this is implemented.
>> Participation in Mozilla's root program is at our sole discretion,
>> and we will take whatever steps are necessary to keep our users safe.
>
> Here, you have established the authority according to policy.
> However, I think people may be surprised at this interpretation. For
> avoidance of doubt, is it time to add a line to policy to effect,
>
> "module owner maintains a register of detailed requirements that
> implement the policy, and distributes change requests as required to
> maintain or improve security, in mozilla's sole determination."
>
Kathleen
Stephen Schultze
> On 9/10/11 8:26 AM, Stephen Schultze wrote:
>> On 9/8/11 1:12 PM, Kathleen Wilson wrote:
>>> 5) For each external third party (CAs and RAs) that issues certificates
>>> or can directly cause the issuance of certificates within the hierarchy
>>> of the root certificate(s) that you have included in Mozilla products,
>>> either:
>>>
>>> a) Implement technical controls to restrict issuance to a specific set
>>> of domain names which you have confirmed that the third party has
>>> registered or has been authorized to act for (e.g. RFC5280 x509 dNSName
>>> name constraints, marked critical)
>>
>> I presume that this is intended to communicate that "RFC5280 x509
>> dNSName name constraints, marked critical" is the only approved
>> approach, short of separate proposal and approval via this list.
>>
>
> It means that technical controls must be implemented to restrict
> issuance to a specific set of domain names. "RFC5280 x509 dNSName name
> constraints, marked critical" is the recommended approach, but there are
> other valid ways this requirement may be met.
using some other approach?
>>> OR
>>>
>>> b) Send a complete list of all third parties along with links to each of
>>> their corresponding Certificate Policy and/or Certification Practice
>>> Statement
>>
>> Send where? If not this list, will it be forwarded to this list?
>>
>
> CAs are to respond to my Mozilla email address. The information that CAs
> send to me in response to this communication will not be forwarded to
> this list unless they specifically give me permission to do so.
spirit of this list?
>>> and provide public attestation of their conformance to the
>>> stated verification requirements and other operational criteria by a
>>> competent independent party or parties with access to details of the
>>> subordinate CA's internal operations.
>>
>> This seems like a clear (and welcome) change in policy, requiring that
>> RAs and SubCAs be audited. Is this a correct interpretation?
>>
>
> Third-party organizations that can directly cause the issuance of
> certificates must either constrained or audited.
SubCAs must be constrained or publicly disclosed. As I said, I welcome
the audit requirement. However, I don't want to lose the disclosure
requirement along the way.
Kathleen Wilson
>>> dNSName name constraints, marked critical" is the only approved
>>> approach, short of separate proposal and approval via this list.
>>>
>>
>> It means that technical controls must be implemented to restrict
>> issuance to a specific set of domain names. "RFC5280 x509 dNSName name
>> constraints, marked critical" is the recommended approach, but there are
>> other valid ways this requirement may be met.
>
> What is an example of another approach? Have any CAs claimed to be using
> some other approach?
>
Some CAs have implemented software that checks constraints on name (not
marked critical), key usage, and/or enhanced key usage. The CA's
software won't issue a certificate for a request that violates the
constraints. For instance, some CAs have sub-CAs who are not allowed to
issue SSL certs, so they have implemented their own software to check
key usage.
>> CAs are to respond to my Mozilla email address. The information that CAs
>> send to me in response to this communication will not be forwarded to
>> this list unless they specifically give me permission to do so.
>
> Doesn't this defeat the purpose of disclosure and work against the
> spirit of this list?
Mozilla's CA Certificate Policy has not yet been updated to require CAs
to publicly disclose their sub-CAs. Those updates to the policy are
still in draft form and under discussion.
There are some CAs with current contractual obligations that prevent
them from meeting the drafted/proposed updates to Mozilla's CA
Certificate Policy.
The action items in our communication require prompt response that will
not wait until contracts and Mozilla's CA Certificate Policy can be updated.
>>>> and provide public attestation of their conformance to the
>>>> stated verification requirements and other operational criteria by a
>>>> competent independent party or parties with access to details of the
>>>> subordinate CA's internal operations.
>>>
>>> This seems like a clear (and welcome) change in policy, requiring that
>>> RAs and SubCAs be audited. Is this a correct interpretation?
>>>
>>
>> Third-party organizations that can directly cause the issuance of
>> certificates must either constrained or audited.
>
> This differs from WorkInProgress InclusionPolicy #9, which says that
> SubCAs must be constrained or publicly disclosed. As I said, I welcome
> the audit requirement. However, I don't want to lose the disclosure
> requirement along the way.
See above. The disclosure discussion will continue later when we resume
discussions about updating Mozilla's CA Certificate Policy.
Kathleen
Kathleen Wilson
> 3) Confirm that multi-factor authentication is required for all accounts
> capable of directly causing certificate issuance.
>
> 4) Confirm that you have automatic blocks in place for high-profile
> domain names (including those targeted in the DigiNotar and Comodo
> attacks this year). Please further confirm your process for manually
> verifying such requests, when blocked.
>
Several CAs have responded to action #4 by saying that they have no
automated cert issuance -- all their SSL cert approval and issuance is
manual.
It is my opinion that the concern that #4 was meant to address can also
be met with the combination of multi-factor auth (#3) and having no
automated cert issuance.
Kathleen
Ian G
On 16/09/2011, at 4:06, Kathleen Wilson <kathle...@yahoo.com> wrote:
>>
>> 3) Confirm that multi-factor authentication is required for all accounts
>> capable of directly causing certificate issuance.
>>
>> 4) Confirm that you have automatic blocks in place for high-profile
>> domain names (including those targeted in the DigiNotar and Comodo
>> attacks this year). Please further confirm your process for manually
>> verifying such requests, when blocked.
>>
>
>
>
> Several CAs have responded to action #4 by saying that they have no
> automated cert issuance -- all their SSL cert approval and issuance is
> manual.
>
> It is my opinion that the concern that #4 was meant to address can also be met with the combination of multi-factor auth (#3) and having no automated cert issuance.
I see where you are going, and I'd be somewhat supportive of that position.
What holds me back from wholesale agreement is this: the websites were hacked, and most (all?) controls were bypassed. Typically dual factor and manual checks would fall into that bucket - bypassable by hacks.
But, as I say, hard.
Also, imposing multi-factor and manual checking on all CAs is likely to raise costs dramatically. Which will shrink SSL usage as dramatically. Which will reduce security, as overall security is still almost perfectly proportional to number of certs in use.
Iang