Re-starting discussions to update Mozilla's CA Certificate Policy
Kathleen Wilson
Certificate Policy.
The current proposed changes are here:
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/
I would like to make sure that the action items in the recent CA
Communication are appropriately addressed in version 2.1 of Mozilla’s CA
Certificate Policy.
-- Action #1) Audit your PKI and review your systems to check for
intrusion or compromise. This includes all third party CAs and RAs.
Does it make sense to add a separate line item to Mozilla’s CA
Certificate Policy to state requirements regarding network security
audits, penetration testing, and/or infrastructure best practices?
Is it enough to assume that this is covered in the ETSI and WebTrust
audits? Or do we need to specifically call out a few things in Mozilla’s
CA Certificate Policy?
-- Action #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.
I now have a current list that I should regularly update. I’m not sure
if anything regarding this item should be added to Mozilla’s CA
Certificate Policy.
-- Action #3) Confirm that multi-factor authentication is required for
all accounts capable of directly causing certificate issuance.
This is already in the proposed updates in item #6 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
Question: Does this requirement in the policy need to apply to all
certificate issuance? Or could it only apply to accounts capable of
directly causing SSL certificate issuance?
-- Action #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.
I think we had discussed this before, but didn’t get to the point of
proposing text to add to Mozilla’s CA Certificate Policy. I seem to
recall that it raised too many questions and it was difficult to phrase
the requirement in an enforceable way in a policy.
There was recently a different proposal: Before a request for a non-EV
SSL certificate may be approved, a check must be run to look up the
certificate of the secure https website corresponding to that domain
name to see if there is an existing SSL certificate with a policy OID
that is in a list of EV Policy OIDs provided by Mozilla. If such a
request is found then the CA must manually review the request.
Would this be relatively easy to implement in an automated manner?
I think we should phrase the policy in a way that requires some type of
check regarding high-profile domains and/or domains currently associated
with EV certs, but leave the details to recommended practices.
-- Action #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.
There is proposed text to this effect in #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
However, I think that the proposal to require either technical controls
or public disclosure may not be productive, nor what we actually want.
I agree that the sub-CAs should be technically constrained or audited
either by the CA or a third-party, depending on the scope of certificate
issuance. I also believe that someone, such as myself, will have to
maintain a list of sub-CAs that are externally operated and not
technically constrained, and regularly review the relevant audit
statements and make sure they are current. However, I am no longer
convinced that all of the non-technically-constrained sub-CAs should be
publicly disclosed.
-- Other – Requiring CAs to report certain incidents to Mozilla within a
certain amount of time.
As many have said in the past, we need to improve and strengthen item #1 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html
to require CAs to promptly report certain types of incidents to
Mozilla’s security team. I would like to update this section in v2.1 of
the policy.
I know that many of you want to require public disclosure of CA security
incidents, but I think that is a separate discussion that may not reach
consensus. I propose (for now) sticking with the section called
“Disclosure of security vulnerabilities” in
http://www.mozilla.org/projects/security/security-bugs-policy.html
-- Other – Requiring the CA to do domain name verification
Current proposed text is in item #10 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
There are situations where the sub-CA or RA has direct access to the
domain Registry information, so requiring the CA to do the domain name
verification again doesn’t really make sense. Perhaps this requirement
can be better phrased to require that the CA do additional due
diligence, but allow that the additional due diligence may involve
certain automated checks to flag domains of concern.
Kathleen
Stephen Schultze
> -- Action #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.
>
> I now have a current list that I should regularly update. I’m not sure
> if anything regarding this item should be added to Mozilla’s CA
> Certificate Policy.
program (which I assume to mean, "included in the Mozilla Root CA
list")? Isn't the point to have them disclose who they have delegated
trust to, regardless of whether they are already in the Moz root list?
(Isn't it even more important if they aren't?) What's more, are CAs
expected to keep track of who is and who is not in the list?
2. Is this disclosed just to you, or to the public?
"audit" even mean in this context?
2. What "scope of certificate issuance" would change this requirement?
3. What has changed your opinion on external third party disclosure?
> -- Other – Requiring the CA to do domain name verification
> Current proposed text is in item #10 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> There are situations where the sub-CA or RA has direct access to the
> domain Registry information, so requiring the CA to do the domain name
> verification again doesn’t really make sense. Perhaps this requirement
> can be better phrased to require that the CA do additional due
> diligence, but allow that the additional due diligence may involve
> certain automated checks to flag domains of concern.
information" would mean, or how that would compensate for the need to
confirm that whoever is requesting the cert is the person referred to in
DNS. Are you talking about a company like GoDaddy that does both?
Steve
ianG
Some remarks... Very long! Might be easier to discuss under separate
Subjects?
On 7/10/11 10:31 AM, Kathleen Wilson wrote:
> I would like to re-start discussions regarding updating Mozilla’s CA
> Certificate Policy.
>
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/
>
> I would like to make sure that the action items in the recent CA
> CA Certificate Policy.
>
> intrusion or compromise. This includes all third party CAs and RAs.
>
> Does it make sense to add a separate line item to Mozilla’s CA
> Certificate Policy to state requirements regarding network security
> audits, penetration testing, and/or infrastructure best practices?
"best" but the minimum one can get away with, by showing that you do the
minimum that everyone else does. Or, even more minimum if such a term
makes sense, something a regulator approves of. Best practices is herd
mentality, liability avoidance.
Instead, we really have to decide this question:
*is security our core business* ?
If it is, that means that security is our DNA, not anyone elses.
Which also means by logical deduction that it can't be minimum
standard. It has to be done internally and to own prescription, own
risk management, own chioce, own design. Own liability.
Also, by way of further example and deduction, it can't be outsourced.
And therefore, while any component might be outsourced at the choice of
the business, that outsourcing cannot be mandated without taking away
the core business from the organisation. So, can't mandate pen testing.
Getting back to what we can do, about the only broad-brush thing that
seems to work is to disclose. BR goes some way to this by including a
first stab at risk management approach.
> Is it enough to assume that this is covered in the ETSI and WebTrust
> audits? Or do we need to specifically call out a few things in
> Mozilla’s CA Certificate Policy?
contrast, network security audit is really part of security audit which
is .. part of audit in general. Looking at DRC, it has a bunch of
criteria that seem to cover it [1].
(A good audit process seeks to disclose more than to mandate.)
> -- Action #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.
>
> I now have a current list that I should regularly update. I’m not sure
> if anything regarding this item should be added to Mozilla’s CA
> Certificate Policy.
applies? Or both or only Bob's?
Does the end-user get anything positive? Can the end-user / relying
party hold Alice as well as Bob liable? Or only twice the liability
dump, so double negative?
Or, no change, in which case, why allow it?
> -- Action #3) Confirm that multi-factor authentication is required for
> all accounts capable of directly causing certificate issuance.
>
> This is already in the proposed updates in item #6 in
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
>
> Question: Does this requirement in the policy need to apply to all
> certificate issuance? Or could it only apply to accounts capable of
> directly causing SSL certificate issuance?
have [2] is capable of issuing certificates directly. Each of the
certificates issued is limited to the names that are authorised under
various other practices and policies. E.g., my account is the only one
authorised to issue certs over iang.org.
Maybe "directly" is the problem word?
Also, it's worth pointing out that the term "multi-factor" is probably
derived from American banking practice as mandated by FDIC (or some
other agency who's name I forget). It is a response to phishing on a
whole-of-nation basis, and it is a fantastically good example of the
trap of "best practices". It is also a program that is considered
laughable in other countries that take phishing seriously, as they have
moved on many years since to what might be called multi-channel [3]. In
part this is because the American (and other anglo) markets are
dominated by SecureId product archtype, so the rules are written to push
the product (so a criticism might have it) whereas a proper security
risk analysis clearly shows (and history confirms) that SecureID falls
to MITM, so other countries have moved on....
Which all can be distilled to: history has shown that mandating
multi-factor doesn't work.
> -- Action #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.
>
> I think we had discussed this before, but didn’t get to the point of
> proposing text to add to Mozilla’s CA Certificate Policy. I seem to
> recall that it raised too many questions and it was difficult to
> phrase the requirement in an enforceable way in a policy.
>
> There was recently a different proposal: Before a request for a non-EV
> SSL certificate may be approved, a check must be run to look up the
> certificate of the secure https website corresponding to that domain
> name to see if there is an existing SSL certificate with a policy OID
> that is in a list of EV Policy OIDs provided by Mozilla. If such a
> request is found then the CA must manually review the request.
>
> Would this be relatively easy to implement in an automated manner?
> I think we should phrase the policy in a way that requires some type
> of check regarding high-profile domains and/or domains currently
> associated with EV certs, but leave the details to recommended practices.
following:
Disclose practices and policy with regard to high-profile domain
names.
If an Iranian CA were on the list, would they include google? If an
Israeli CA were on the list, would they include the Bushehr nuclear reactor?
What are the implications of being sucked into Uncle Sam's cyberwar?
What are the ramifications of declaring for one side and not the other?
Are we asking for Uncle Sam's protection or ComodoHacker's friendship?
Who are we serving?
All by way of saying: the current high-profile list is not worth
spitting on. If this is the best that Mozilla can do, it is proof that
they cannot do security.
> -- Action #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.
>
> There is proposed text to this effect in #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> However, I think that the proposal to require either technical
> controls or public disclosure may not be productive, nor what we
> actually want.
have a choice though? Musing about it ...
This area has to be cleaned up, which is what Steve was barracking for
last year.
And if the CAs aren't helping, then what?
The thing is, everything's changed. As of 6 months back, we were still
in the "peace in our time" mode of PKI thinking that goes back to the
year dot. The iranian attack on 4 CAs has changed all that. The Threat
Scenario now needs to be updated to be "real attacks". APTs if you like
cyberwar political buzzwords.
So the pendulum must now swing, and the backdoors have to be cleaned
up. It's pretty clear that the external sub-CAs, cross-signing and
external RAs are, or have aspects of, backdoors created for commercial
benefit. Now they have to be cleaned up.
The CAs have had their chance to have their backroom discussions, to
lobby Kathleen to not do much, and all that. That's all over now.
> I agree that the sub-CAs should be technically constrained or audited
> either by the CA or a third-party, depending on the scope of
> certificate issuance.
regime is clearly disclosed within the CPS, etc, which amounts to the
same thing.
That has to be the starting point?
> I also believe that someone, such as myself, will have to maintain a
> list of sub-CAs that are externally operated and not technically
> constrained, and regularly review the relevant audit statements and
> make sure they are current.
be a valuable stepping stone along the road to some better place.
> However, I am no longer convinced that all of the
> non-technically-constrained sub-CAs should be publicly disclosed.
full answer.
On the other hand, I am convinced that liability is the answer. If (by
way of rhetorical) you gained from each of the CAs engaged in this
practice the following contractual statement:
I, .....TrustedCA... of ....1 Trust St, Trustvillle....
assume all the liability for all the sub-CAs and
cross-signed CAs and any similar derivative
product under my roots.
/TrustedCA/
Then for me the answer is clear. Go for it. (That's just a thought
experiment, folks!)
However. Failing liability, then disclosure may be the best we get. As
nobody takes liability seriously, then I suppose I must argue for
disclosure.
> -- Other – Requiring CAs to report certain incidents to Mozilla within
> a certain amount of time.
happen. At a minimum.
> As many have said in the past, we need to improve and strengthen item
> #1 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html
>
> to require CAs to promptly report certain types of incidents to
> Mozilla’s security team. I would like to update this section in v2.1
> of the policy.
2., suggest "Mozilla will /by way of example/ disable or remove..." or
words to effect.
4., at end, suggest adding ", /or in other ways it deems fit/. " or WTE.
> I know that many of you want to require public disclosure of CA
> security incidents, but I think that is a separate discussion that may
> not reach consensus.
But, the credibility of all CAs has shrunk so far that I'm not sure they
have a voice anymore. They have to re-prove themselves. How are they
going to do that?
Obviously, the more they fight for their commercial interests, the more
their credibility shrinks. Are CAs part of the consensus? Who do we serve?
So we're going to have to think out of the box here. Can the disclosure
be delivered via the vendors, and then to the relying public? To what
extent can we rely upon the vendors to distance themselves from the CAs?
How are we going to cope with the failure of audit? Is it a failure of
audit per se, or a failure in expectations?
> I propose (for now) sticking with the section called “Disclosure of
> security vulnerabilities” in
> http://www.mozilla.org/projects/security/security-bugs-policy.html
taking on the liability for getting it right, for 250 million users.
The threat scenario is now changed. We're now no longer dealing with a
zero liability expectation. We had a chance to establish this in the
past, but that window is now closed.
> -- Other – Requiring the CA to do domain name verification
> Current proposed text is in item #10 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> There are situations where the sub-CA or RA has direct access to the
> domain Registry information, so requiring the CA to do the domain name
> verification again doesn’t really make sense. Perhaps this requirement
> can be better phrased to require that the CA do additional due
> diligence, but allow that the additional due diligence may involve
> certain automated checks to flag domains of concern.
controls" means, and what "reasonable" means, and what "due diligence"
means. Also, the difference between policy and practices.
By way of example, due diligence is the diligence that is due to the
situation. So, additional due diligence is a semantically flawed
statement, a nonsense. If there is anything additional that it is due,
it is already included, it's part of due.
And by way of definition, due diligence cannot be simply mandated as "do
domain name verification" as that becomes mandated diligence or
compliance diligence, and not due diligence.
This whole gordian knot might be sliced by simply disclosing the
diligence practices and policy of the CA.
iang
[0] IMHO, see a paper on the failure of best practices here:
http://iang.org/papers/market_for_silver_bullets.html
[1] By way of (mandating) example:
C.2.b The CA maintains current protection against:
* being infected by computer viruses and other "malware"
* distributing computer viruses and other "malware"
C.2.c The CA maintains current protection against "hacking", snooping,
and other electronic intrusions into its computer systems (see §A.5.f).
[2] some disclosure:
http://www.cacert.org/stats.php
[3] but this is only to distinguish if from
multi-factor-secureId-think. The real essence is that it is
transactional not sessional. But now we're drifting too far into
security analysis.
Eddy Nigg
> audits? Or do we need to specifically call out a few things in
> Mozilla’s CA Certificate Policy?
>
(nicely packaged, but there is something to learn in this document):
http://www.aicpa.org/interestareas/informationtechnology/resources/trustservices/downloadabledocuments/10957-378%20soc%20whitepaper.pdf
But I believe that additional requirements can be placed upon CAs if
necessary.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Stephen Schultze
> On 10/07/2011 01:31 AM, From Kathleen Wilson:
>> Is it enough to assume that this is covered in the ETSI and WebTrust
>> audits? Or do we need to specifically call out a few things in
>> Mozilla’s CA Certificate Policy?
>>
>
> This might be of interest in respect to audit methodology for WebTrust
> (nicely packaged, but there is something to learn in this document):
>
> http://www.aicpa.org/interestareas/informationtechnology/resources/trustservices/downloadabledocuments/10957-378%20soc%20whitepaper.pdf
and "Trust Services" which are different regimes from "WebTrust for CAs"
and exist for a different purpose.
http://www.webtrust.org/
Stephen Schultze
>> However, I am no longer convinced that all of the
>> non-technically-constrained sub-CAs should be publicly disclosed.
>
> To repeat long discussions, I also am not convinced that disclosure is a
> full answer.
>
> On the other hand, I am convinced that liability is the answer. If (by
> way of rhetorical) you gained from each of the CAs engaged in this
> practice the following contractual statement:
>
> I, .....TrustedCA... of ....1 Trust St, Trustvillle....
> assume all the liability for all the sub-CAs and
> cross-signed CAs and any similar derivative
> product under my roots.
> /TrustedCA/
>
> Then for me the answer is clear. Go for it. (That's just a thought
> experiment, folks!)
>
> However. Failing liability, then disclosure may be the best we get. As
> nobody takes liability seriously, then I suppose I must argue for
> disclosure.
does a liability clause by a CA located in a foreign jurisdiction
trigger anything when that CA voluntarily grants rogue certificates to
the government, or when that CA or its delegates is compromised? Whose
law governs? What are the damages if the harm is "just" surveillance?
As we saw in the DigiNotar case, the removal from the root list can
easily mean bankruptcy for the company, which is on the contrary a very
clear penalty (and can also nullify any liability that is in place).
Maybe disclosure and active policing by the browsers and end-users is
actually a more comprehensive approach?
But, as you say, this is repeating long discussions.
Kathleen Wilson
> On 10/6/11 7:31 PM, Kathleen Wilson wrote:
>> -- Action #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.
>>
>> I now have a current list that I should regularly update. I’m not sure
>> if anything regarding this item should be added to Mozilla’s CA
>> Certificate Policy.
>
> 1. Why require only cross-signatures of others that are already in our
> program (which I assume to mean, "included in the Mozilla Root CA
> list")? Isn't the point to have them disclose who they have delegated
> trust to, regardless of whether they are already in the Moz root list?
> (Isn't it even more important if they aren't?) What's more, are CAs
> expected to keep track of who is and who is not in the list?
> 2. Is this disclosed just to you, or to the public?
>
list of cross-signers in Mozilla's CA Certificate program so that we
don't have to hunt for that information while trying to resolve a future
security incident. The information may influence the direction that we
take to respond to an incident.
During the Information Gathering phase of the root inclusion process, I
ask for cross-signing information, and that is provided in the
Information Gathering Document that I attach to the bug. However, that
information gets out of date when a root has been included for a while.
https://wiki.mozilla.org/CA:Information_checklist#CA_Hierarchy_information_for_each_root_certificate
"3. Cross-Signing
-- List all other root certificates for which this root certificate has
issued cross-signing certificates.
-- List all other root certificates that have issued cross-signing
certificates for this root certificate.
-- If any such cross-signing relationships exist, it is important to
note whether the cross-signing CAs' certificates are already included in
the Mozilla root store or not."
>> -- Action #5) For each external third party (CAs and RAs) that issues
>> However, I think that the proposal to require either technical controls
>> or public disclosure may not be productive, nor what we actually want.
>>
>> I agree that the sub-CAs should be technically constrained or audited
>> either by the CA or a third-party, depending on the scope of certificate
>> issuance. I also believe that someone, such as myself, will have to
>> maintain a list of sub-CAs that are externally operated and not
>> technically constrained, and regularly review the relevant audit
>> statements and make sure they are current. However, I am no longer
>> convinced that all of the non-technically-constrained sub-CAs should be
>> publicly disclosed.
>
> 1. Why would subCA auditing by the CA be sufficient, and what does
> "audit" even mean in this context?
> 2. What "scope of certificate issuance" would change this requirement?
> 3. What has changed your opinion on external third party disclosure?
>
sub-CAs. I agree that sub-CAs who act as CSPs (Third-party public
subordinate CAs) must be audited according to Mozilla's CA Certificate
Policy, and their CP/CPS and audit statements must be publicly posted.
Then there is the "Third-party private enterprise subordinate CAs" which
are companies who operate their own PKI for internal use, but chain up
to a root that is included in NSS for interoperability with their
customers and business partners. Based on what I've seen, these are very
big companies; like large banks and credit card companies, phone and
utility services, and very large technical corporations. These sub-CAs
are bound by contract and significant financial penalty to only issue
certificates for internal use. These sub-CAs will not agree to publish
their CP/CPS/audits. In response to the recent CA Communication I
received audit reports for many of these in-premise enterprise sub-CAs,
but these documents are considered to be confidential.
I see your point about a CA-performed audit not being defined. I don't
yet have an answer for this, other than it would obviously have to
included periodic review of the issued certificates and network security
reports. Some of these in-premise enterprise sub-CAs are currently
operated under threat of external audit in the event that evidence
warrants it, and according to contract such an audit could lead to
suspension and revocation, which means big financial penalties and
significant impact to their business operations.
>> -- Other – Requiring the CA to do domain name verification
>> Current proposed text is in item #10 of
>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>
>>
>> There are situations where the sub-CA or RA has direct access to the
>> domain Registry information, so requiring the CA to do the domain name
>> verification again doesn’t really make sense. Perhaps this requirement
>> can be better phrased to require that the CA do additional due
>> diligence, but allow that the additional due diligence may involve
>> certain automated checks to flag domains of concern.
>
> I don't understand what "direct access to the domain Registry
> information" would mean, or how that would compensate for the need to
> confirm that whoever is requesting the cert is the person referred to in
> DNS. Are you talking about a company like GoDaddy that does both?
>
Kathleen
Brian Smith
> Does it make sense to add a separate line item to Mozilla’s CA
> Certificate Policy to state requirements regarding network security
> audits, penetration testing, and/or infrastructure best practices?
>
> Mozilla’s CA Certificate Policy?
We definitely cannot rely on ETSI or WebTrust audits. But, also, it is good for these new requirements to take effect ASAP, so we shouldn't delay them while we develop specific security requirements.
> -- Action #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.
>
> I now have a current list that I should regularly update. I’m not sure
> if anything regarding this item should be added to Mozilla’s CA
> Certificate Policy.
> -- Action #3) Confirm that multi-factor authentication is required for
> all accounts capable of directly causing certificate issuance.
>
> This is already in the proposed updates in item #6 in
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> Question: Does this requirement in the policy need to apply to all
> certificate issuance? Or could it only apply to accounts capable of
> directly causing SSL certificate issuance?
> There was recently a different proposal: Before a request for a non-EV
> SSL certificate may be approved, a check must be run to look up the
> certificate of the secure https website corresponding to that domain
> name to see if there is an existing SSL certificate with a policy OID
> that is in a list of EV Policy OIDs provided by Mozilla. If such a
> request is found then the CA must manually review the request.
>
> Would this be relatively easy to implement in an automated manner?
> I think we should phrase the policy in a way that requires some
> type of check regarding high-profile domains and/or domains
> currently associated with EV certs, but leave the details to
> recommended practices.
> 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.
>
> There is proposed text to this effect in #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> controls
> or public disclosure may not be productive, nor what we actually want.
>
> I agree that the sub-CAs should be technically constrained or audited
> either by the CA or a third-party, depending on the scope of
> certificate
> issuance. I also believe that someone, such as myself, will have to
> maintain a list of sub-CAs that are externally operated and not
> technically constrained, and regularly review the relevant audit
> statements and make sure they are current. However, I am no longer
> convinced that all of the non-technically-constrained sub-CAs should
> be publicly disclosed.
> -- Other – Requiring the CA to do domain name verification
> Current proposed text is in item #10 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
> There are situations where the sub-CA or RA has direct access to the
> domain Registry information, so requiring the CA to do the domain name
> verification again doesn’t really make sense. Perhaps this requirement
> can be better phrased to require that the CA do additional due
> diligence, but allow that the additional due diligence may involve
> certain automated checks to flag domains of concern.
- Brian
Eddy Nigg
the alternatives.
Brian Smith
> On 10/07/2011 08:39 PM, From Brian Smith:
> > We definitely cannot rely on ETSI or WebTrust audits.
>
> I would like to learn more about this statement. Why not and what are
> the alternatives.
- Brian
Stephen Schultze
> On 10/6/11 6:51 PM, Stephen Schultze wrote:
>> On 10/6/11 7:31 PM, Kathleen Wilson wrote:
>>> -- Action #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.
>>>
>>> I now have a current list that I should regularly update. I’m not sure
>>> if anything regarding this item should be added to Mozilla’s CA
>>> Certificate Policy.
>>
>> 1. Why require only cross-signatures of others that are already in our
>> program (which I assume to mean, "included in the Mozilla Root CA
>> list")? Isn't the point to have them disclose who they have delegated
>> trust to, regardless of whether they are already in the Moz root list?
>> (Isn't it even more important if they aren't?) What's more, are CAs
>> expected to keep track of who is and who is not in the list?
>> 2. Is this disclosed just to you, or to the public?
>>
>
> The purpose of action #2 was that we (Mozilla) want to have a current
> list of cross-signers in Mozilla's CA Certificate program so that we
> don't have to hunt for that information while trying to resolve a future
> security incident. The information may influence the direction that we
> take to respond to an incident.
disclosure of *all* cross signed certs issued by that root, or *just*
those that sign other roots in the program. What motivation could there
be for the security loophole that goes with the latter?
>>> -- Action #5) For each external third party (CAs and RAs) that issues
>>> ...
>>>
>>> However, I think that the proposal to require either technical controls
>>> or public disclosure may not be productive, nor what we actually want.
>>>
>>> I agree that the sub-CAs should be technically constrained or audited
>>> either by the CA or a third-party, depending on the scope of certificate
>>> issuance. I also believe that someone, such as myself, will have to
>>> maintain a list of sub-CAs that are externally operated and not
>>> technically constrained, and regularly review the relevant audit
>>> statements and make sure they are current. However, I am no longer
>>> convinced that all of the non-technically-constrained sub-CAs should be
>>> publicly disclosed.
>>
>> 1. Why would subCA auditing by the CA be sufficient, and what does
>> "audit" even mean in this context?
>> 2. What "scope of certificate issuance" would change this requirement?
>> 3. What has changed your opinion on external third party disclosure?
>>
>
> First, I think we will have to make distinction between types of
> sub-CAs. I agree that sub-CAs who act as CSPs (Third-party public
> subordinate CAs) must be audited according to Mozilla's CA Certificate
> Policy, and their CP/CPS and audit statements must be publicly posted.
believe it is defined in any public CA documentation.
> Then there is the "Third-party private enterprise subordinate CAs" which
> are companies who operate their own PKI for internal use, but chain up
> to a root that is included in NSS for interoperability with their
> customers and business partners. Based on what I've seen, these are very
> big companies; like large banks and credit card companies, phone and
> utility services, and very large technical corporations. These sub-CAs
> are bound by contract and significant financial penalty to only issue
> certificates for internal use.
> These sub-CAs will not agree to publish
> their CP/CPS/audits. In response to the recent CA Communication I
> received audit reports for many of these in-premise enterprise sub-CAs,
> but these documents are considered to be confidential.
certificates working in the browsers. They can domain-constrain them,
work out a domain-limited RA-type relationship with a CA, or proactively
manage their client software to include their root CA. Why Mozilla
would go out of its way to preserve security vulnerabilities here is
beyond me.
> I see your point about a CA-performed audit not being defined. I don't
> yet have an answer for this, other than it would obviously have to
> included periodic review of the issued certificates and network security
> reports. Some of these in-premise enterprise sub-CAs are currently
> operated under threat of external audit in the event that evidence
> warrants it, and according to contract such an audit could lead to
> suspension and revocation, which means big financial penalties and
> significant impact to their business operations.
it just because some enterprises don't feel like disclosing the fact
that they hold the keys to the kingdom?
Brian seems to have a far clearer idea of how you (Mozilla) should do
this: "all sub-CAs will have to be technically constrained *and*
publicly disclosed."
ianG
> However, we have no NDA and we never should have one,
have an NDA, in that there is a lot of stuff that communicated to
Kathleen in confidence. It might not look like a standard NDA, and we
might not like it .. but it is definitely in place.
> so this seems like the same as public disclosure to me.
Eddy Nigg
> have a better alternative. But, we shouldn't place to much faith in
> these audits actually preventing mis-issuance.
and to certain criterion set forth by the respective audit criteria and
regime.
Now, in respect to your original statement and my question back, I
expected to hear some argument why [quote:] "we definitely cannot rely
on ETSI or WebTrust audits". You might be right, maybe not, but maybe if
you explain why and the argument is reasonable, we can understand also
what has to change and what to improve. Or what the alternatives could
be. Or what Mozilla could do. Or that it has nothing to do with the
audit, who knows...
ianG
> On 10/07/2011 10:26 PM, From Brian Smith:
>> have a better alternative. But, we shouldn't place to much faith in
>> these audits actually preventing mis-issuance.
>
> and to certain criterion set forth by the respective audit criteria
> and regime.
auditor is that the CA is in compliance, etc, to a reasonable degree.
> Now, in respect to your original statement and my question back, I
> on ETSI or WebTrust audits". ....
"Rely" is always within a context. What is the context? Do you mean
Kathleen's question, since elided?
Is it enough to assume that [network security audits,
penetration testing, and/or infrastructure best practices]
My call: Pen testing - no, should be clear. Best practices - no,
equally clear. Network security audits - yes, we should be able to rely
on the audits to cover this.
Or, are you taking the original statement by Brian out of context and
applying a general question: "can we rely on audits *at all* ? "
Or some other context?
iang
Eddy Nigg
> auditor is that the CA is in compliance, etc, to a reasonable degree.
to a reasonable degree if you want. They can't detect everything, but a
good audit would/should discover issues.
>
> "Rely" is always within a context. What is the context? Do you mean
> Kathleen's question, since elided?
>
> Is it enough to assume that [network security audits,
> penetration testing, and/or infrastructure best practices]
> is covered in the ETSI and WebTrust audits?
>
not, but may be implied by "sufficient controls" etc. This probably has
to be spelled out before you can rely on it.
Peter Gutmann
>we (Mozilla) want to have a current list of cross-signers in Mozilla's CA
>Certificate program so that we don't have to hunt for that information while
>trying to resolve a future security incident. The information may influence
>the direction that we take to respond to an incident.
actually have serious legal exposure from all the cross-signing that we've
been doing, and rescinded all cross-certification that they'd done. As
lawyers wake up to this issue, there may be a lot less cross-signing present.
Peter.
Brian Smith
> Now, in respect to your original statement and my question back, I
> expected to hear some argument why [quote:] "we definitely cannot rely
> if you explain why and the argument is reasonable, we can understand
> also what has to change and what to improve. Or what the alternatives
> could be. Or what Mozilla could do. Or that it has nothing to do with
> the audit, who knows...
- Brian
Brian Smith
> Then there is the "Third-party private enterprise subordinate CAs"
> which are companies who operate their own PKI for internal use,
> but chain up to a root that is included in NSS for interoperability
The goal of this proposed change is specifically to prevent this. Either stop chaining to a trusted root, or fully disclose the information. Or both. But, not neither.
> In response to the recent CA Communication I received audit reports
> for many of these in-premise enterprise sub-CAs, but these documents
> are considered to be confidential.
By whom are they considered confidential? We (Mozilla) should not be agreeing to non-disclosure of this information. In fact, I was expecting that we will publish all of this information publicly and/or share it with others that will publish it.
> I see your point about a CA-performed audit not being defined. I don't
> yet have an answer for this, other than it would obviously have to
> included periodic review of the issued certificates and network
> security reports.
We already have standards for auditing. These sub-CAs must adhere to the auditing requirements for CAs we already have. No CA is considered to be an acceptable auditor. (Or, in other words, there must not be any distinction between root and sub-CA as far as our policy is concerned.)
- Brian
Eddy Nigg
> is to say that we have no reason to think that these audits offer
> sufficient assurance of the security of a CA, especially given the
> recent evidence to the contrary, so we will have to go beyond what
> these audits (currently) require.
while ago into this direction.
> But, I do not have any concrete proposal yet.
Eddy Nigg
> the auditing requirements for CAs we already have. No CA is considered
> to be an acceptable auditor. (Or, in other words, there must not be
> any distinction between root and sub-CA as far as our policy is
> concerned.)
Kathleen Wilson
>> -- Action #1) Audit your PKI and review your systems to check for
>> intrusion or compromise. This includes all third party CAs and RAs.
>>
>> Does it make sense to add a separate line item to Mozilla’s CA
>> Certificate Policy to state requirements regarding network security
>> audits, penetration testing, and/or infrastructure best practices?
>
> Not really, IMHO [0]. Best practices is really a misnomer. It is not
> "best" but the minimum one can get away with, by showing that you do the
> minimum that everyone else does. Or, even more minimum if such a term
> makes sense, something a regulator approves of. Best practices is herd
> mentality, liability avoidance.
> Getting back to what we can do, about the only broad-brush thing that
> seems to work is to disclose. BR goes some way to this by including a
> first stab at risk management approach.
>
text. I'm thinking that we should add something along these lines to
Mozilla's CA Certificate Policy in v2.1. (When the time comes that the
BRs are officially published and required by Mozilla's CA Certificate
Policy, then we can remove duplicate requirements.)
16.2 Risk Assessment
The CA’s security program MUST include an annual Risk Assessment that:
1. Identifies reasonably foreseeable internal and external threats that
could result in unauthorized access, disclosure, misuse, alteration, or
destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking
into consideration the sensitivity of the Certificate Data and
Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information
systems, technology, and other arrangements that the CA has in place to
counter such threats.
16.5 System Security
The Certificate Management Process SHALL consist of:
• physical security and environmental controls to prevent equipment
tampering;
• system integrity controls, including configuration management,
integrity maintenance of trusted code, and malware detection/prevention;
• network security and firewall management, including port restrictions
and IP address filtering;
• user management, separate trusted-role assignments, education,
awareness, and training; and
• logical access controls, activity logging, and inactivity time-outs
to provide individual accountability.
>> -- Action #3) Confirm that multi-factor authentication is required for
>> all accounts capable of directly causing certificate issuance.
>>
>> This is already in the proposed updates in item #6 in
>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>
>>
>> Question: Does this requirement in the policy need to apply to all
>> certificate issuance? Or could it only apply to accounts capable of
>> directly causing SSL certificate issuance?
>
> From the perspective of my CA, it makes no sense. Every account we have
> [2] is capable of issuing certificates directly. Each of the
> certificates issued is limited to the names that are authorised under
> various other practices and policies. E.g., my account is the only one
> authorised to issue certs over iang.org.
>
> Maybe "directly" is the problem word?
> Also, it's worth pointing out that the term "multi-factor" is probably
> derived from American banking practice as mandated by FDIC (or some
> other agency who's name I forget). It is a response to phishing on a
> whole-of-nation basis, and it is a fantastically good example of the
> trap of "best practices". It is also a program that is considered
> laughable in other countries that take phishing seriously, as they have
> moved on many years since to what might be called multi-channel [3]. In
> part this is because the American (and other anglo) markets are
> dominated by SecureId product archtype, so the rules are written to push
> the product (so a criticism might have it) whereas a proper security
> risk analysis clearly shows (and history confirms) that SecureID falls
> to MITM, so other countries have moved on....
>
seen I think that most people understand that "multi-factor auth" means
something in addition to username/password.
Responses to this action item included smartcards, tokens,
one-time-passwords, interactive voice response system.
Related question: What if there is an in-premise enterprise sub-CA who
has created an auto-enrollment system to issue certificates to employees
in their Active Directory? The employee logging into this system causes
the issuance of a certificate. Technically to meet the proposed
multi-factor auth requirement the employee would have to use something
in addition to username/password to login to this system to get their
certificate. However, this seems overkill to me, because this
certificate issuance system is basically white-listed.
>> -- Action #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.
>>
>> of check regarding high-profile domains and/or domains currently
>> associated with EV certs, but leave the details to recommended practices.
>
> Following on from my comments above, I would suggest something like the
> following:
>
> Disclose practices and policy with regard to high-profile domain names.
>
CABForum BRs:
11.4 High Risk Requests
The CA or RA MUST endeavor to identify high risk Certificate Requests,
and conduct such additional verification activity, and take such
additional precautions, as are reasonably necessary to ensure that such
requests are properly verified under these Requirements.
The CA or RA MAY identify high risk requests by checking appropriate
lists of organization names that are most commonly targeted in phishing
and other fraudulent schemes, and by automatically flagging Certificate
Requests that match these lists for further scrutiny before issuance.
Examples of such lists include: internal databases maintained by the CA
or RA that include previously revoked Certificates and previously
rejected Certificate Requests due to suspected phishing or other
fraudulent usage.
The information MUST then be used to flag suspicious Certificate
Requests. If a Certificate Request is flagged as suspicious, the CA or
RA MUST perform reasonably appropriate additional authentication and
verification.
>> -- Other – Requiring CAs to report certain incidents to Mozilla within
>> a certain amount of time.
>
> As vendors are the relying parties in effect, I agree this has to
> happen. At a minimum.
>
>> As many have said in the past, we need to improve and strengthen item
>> #1 of
>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html
>>
>> to require CAs to promptly report certain types of incidents to
>> Mozilla’s security team. I would like to update this section in v2.1
>> of the policy.
>
> OK.
>
> 2., suggest "Mozilla will /by way of example/ disable or remove..." or
> words to effect.
> 4., at end, suggest adding ", /or in other ways it deems fit/. " or WTE.
>
"4. If Mozilla disables or removes a CA's certificate(s) from Mozilla's
products based on a CA's actions (or failure to act) that are contrary
to the Mozilla CA Certificate Policy, Mozilla shall publicize that fact
in newsgroups on the news.mozilla.org server, on Web pages in the
www.mozilla.org and www.mozilla.com domains, in news releases sent to
organizations specializing in computer and Internet news, as an alert to
the US-CERT organization of the U.S. Department of Homeland Security, or
in other ways it deems fit."
>
>> -- Other – Requiring the CA to do domain name verification
>> Current proposed text is in item #10 of
>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>
>> There are situations where the sub-CA or RA has direct access to the
>> domain Registry information, so requiring the CA to do the domain name
>> verification again doesn’t really make sense. Perhaps this requirement
>> can be better phrased to require that the CA do additional due
>> diligence, but allow that the additional due diligence may involve
>> certain automated checks to flag domains of concern.
>
> Right. This is the old geek-v-business war, as to what "owns or
> controls" means, and what "reasonable" means, and what "due diligence"
> means. Also, the difference between policy and practices.
>
> By way of example, due diligence is the diligence that is due to the
> situation. So, additional due diligence is a semantically flawed
> statement, a nonsense. If there is anything additional that it is due,
> it is already included, it's part of due.
>
> And by way of definition, due diligence cannot be simply mandated as "do
> domain name verification" as that becomes mandated diligence or
> compliance diligence, and not due diligence.
>
> This whole gordian knot might be sliced by simply disclosing the
> diligence practices and policy of the CA.
>
"10. When an external third party verifies certificate subscriber
information on behalf of the CA, the CA must perform due diligence, as
documented in the CA's Certificate Policy or Certification Practice
Statement, before the CA may issue the certificate."
Kathleen
Kathleen Wilson
> Kathleen Wilson wrote:
>> Then there is the "Third-party private enterprise subordinate CAs"
>> which are companies who operate their own PKI for internal use,
>> but chain up to a root that is included in NSS for interoperability
>> [...]. These sub-CAs will not agree to publish their CP/CPS/audits.
>
> The goal of this proposed change is specifically to prevent this. Either stop chaining to a trusted root, or fully disclose the information. Or both. But, not neither.
>
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
The current proposal was to either technically constrain or to publicly
disclose.
However, based on the information I have collected the past several
weeks I am now convinced that there are still three situations that we
need to continue to account for. And historically these have been
accounted for.
https://wiki.mozilla.org/CA:SubordinateCA_checklist
1) sub-CAs that can be technically constrained
2) Third-party public subordinate CAs that act as Certificate Service
Providers (CSPs)
3) Third-party private (or enterprise) subordinate CAs
I see the direction that you want Mozilla's CA Certificate program to go
in the future, but it's not something you can instantly change. We need
to keep taking steps in the right direction, but it will take time to
get to the end goal.
>> In response to the recent CA Communication I received audit reports
>> for many of these in-premise enterprise sub-CAs, but these documents
>> are considered to be confidential.
>
> By whom are they considered confidential? We (Mozilla) should not be agreeing to non-disclosure of this information. In fact, I was expecting that we will publish all of this information publicly and/or share it with others that will publish it.
>
will not disclose it.
>> I see your point about a CA-performed audit not being defined. I don't
>> yet have an answer for this, other than it would obviously have to
>> included periodic review of the issued certificates and network
>> security reports.
>
> We already have standards for auditing. These sub-CAs must adhere to the auditing requirements for CAs we already have. No CA is considered to be an acceptable auditor. (Or, in other words, there must not be any distinction between root and sub-CA as far as our policy is concerned.)
>
that the "third-party private (or enterprise) subordinate CAs" be
externally audited.
Kathleen
Stephen Schultze
> However, based on the information I have collected the past several
> weeks I am now convinced that there are still three situations that we
> need to continue to account for. And historically these have been
By "account for" you mean "not require disclosure"?
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
> 1) sub-CAs that can be technically constrained
I obviously vote for disclosure, but some people have argued against it.
> 2) Third-party public subordinate CAs that act as Certificate Service
> Providers (CSPs)
Should be audited through normal mechanisms and disclosed. What
argument is there against this?
Really, they should probably be required to go through the root approval
process themselves (ie: SubCAs would be essentially prohibited), given
that we all seem to agree that the current audit regime is insufficient
(hence the additional Moz requirements). But, as an interim measure
perhaps we should allow them to exist as long as they are audited and
disclosed.
> 3) Third-party private (or enterprise) subordinate CAs
And I have yet to hear any argument against disclosure other than "they
don't want to."
> I see the direction that you want Mozilla's CA Certificate program to go
> in the future, but it's not something you can instantly change. We need
> to keep taking steps in the right direction, but it will take time to
> get to the end goal.
Of course, but what's reasonable in the short term? Let's hear the
arguments for why audit and disclosure are not reasonable.
ianG
> On 10/7/11 3:09 PM, Brian Smith wrote:
>>> I see your point about a CA-performed audit not being defined. I don't
>>> yet have an answer for this, other than it would obviously have to
>>> included periodic review of the issued certificates and network
>>> security reports.
To address the above question about the sub-CA audit, as performed by
the CA as an "internal audit" or other variations:
*Subsidiary audits are already incorporated into the audit process* :
the auditor opines over the whole, and writes his report to incorporate
any subsidiary audits, /however they are done/ . The auditor uses
something called the audit risk model to evaluate all the info brought
to her, and an internal audit or an SAS70 or similar done over an
external sub-CA is just more grist for the mill (more info into the
calculations).
In other words, it's already there. If the auditor is unhappy with the
results, exclusions will appear in the report. E.g., from memory, there
were exclusions in Thawte's audit of a couple of years back [0], and
also Comodo's before their first incident.
>> We already have standards for auditing. These sub-CAs must adhere to
>> the auditing requirements for CAs we already have.
Right.
>> No CA is considered to be an acceptable auditor.
I beg to differ -- if the lead auditor decides to lean on an internal
audit, as done by the CA or any other outsourced party, then so be it.
It's her opinion.
>> (Or, in other words, there must not be any distinction between root
>> and sub-CA as far as our policy is concerned.)
>>
>
> Fair enough. However, there has not ever been official policy
> requiring that the "third-party private (or enterprise) subordinate
> CAs" be externally audited.
I demur!
9. We consider the criteria for CA operations published
in any of the following documents to be acceptable.....
There is no exclusion in there. Everything is covered. It makes no
difference if there is outsourcing, insourcing or hotchillisaucing ...
it's covered.
iang
[0] CAcert used to rely on Thawte certificates for their "notaries".
However when I went back and read the Thawte audit of the time, there
was a specific exclusion: the Thawte notaries weren't audited at all.
Long and short of it is that CAcert went through a painful process to
drop reliance on those certificates. Shortly after that audit (while I
was forcing CAcert to deal with the absence of any reliable info) Thawte
shut down the notary network.
Which is all by way of saying: the system is there, and it works .. at
least sometimes :)
Stephen Schultze
> On 8/10/11 09:56 AM, Kathleen Wilson wrote:
>> On 10/7/11 3:09 PM, Brian Smith wrote:
>>>> I see your point about a CA-performed audit not being defined. I don't
>>>> yet have an answer for this, other than it would obviously have to
>>>> included periodic review of the issued certificates and network
>>>> security reports.
>
> To address the above question about the sub-CA audit, as performed by
> the CA as an "internal audit" or other variations:
>
> *Subsidiary audits are already incorporated into the audit process* :
> the auditor opines over the whole, and writes his report to incorporate
> any subsidiary audits, /however they are done/ . The auditor uses
> something called the audit risk model to evaluate all the info brought
> to her, and an internal audit or an SAS70 or similar done over an
> external sub-CA is just more grist for the mill (more info into the
> calculations).
1. Where is it stated that auditors must include subsidiary "audits"?
2. Why would SAS 70 or something be an appropriate audit tool, vs a
WebTrust/ETSI/etc audit that's required of root CAs?
WebTrust doesn't mention auditing or reviewing audits of SubCAs.
WebTrust assumes no review of cross-signed entities.
WebTrust explicitly exempts any review of RAs.
So it seems clear that subsidiary audits are not necessarily already
incorporated into the audit process.
ianG
> On 10/8/11 6:27 AM, ianG wrote:
>>> On 10/7/11 3:09 PM, Brian Smith wrote:
>>>>> I see your point about a CA-performed audit not being defined. I
>>>>> don't
>>>>> yet have an answer for this, other than it would obviously have to
>>>>> included periodic review of the issued certificates and network
>>>>> security reports.
>>
>> To address the above question about the sub-CA audit, as performed by
>> the CA as an "internal audit" or other variations:
>>
>> *Subsidiary audits are already incorporated into the audit process* :
>> the auditor opines over the whole, and writes his report to incorporate
>> any subsidiary audits, /however they are done/ . The auditor uses
>> something called the audit risk model to evaluate all the info brought
>> to her, and an internal audit or an SAS70 or similar done over an
>> external sub-CA is just more grist for the mill (more info into the
>> calculations).
>
The don't have to. They choose whether to.
> 2. Why would SAS 70 or something be an appropriate audit tool, vs a
> WebTrust/ETSI/etc audit that's required of root CAs?
It's what is available. If an SAS70 is available on a company that has
a sub-CA, well, it's evidence for the model. If it doesn't work, then
more work to be done. An SAS70 has the benefit that the american market
understands them well.
> WebTrust doesn't mention auditing or reviewing audits of SubCAs.
> WebTrust assumes no review of cross-signed entities.
> WebTrust explicitly exempts any review of RAs.
Yup. One wonders what they were thinking when they wrote that last
exemption...
> So it seems clear that subsidiary audits are not necessarily already
> incorporated into the audit process.
Yes, correct. Not necessarily, but the auditor uses what he can.
To some extent, an SAS70 is designed to be shared in this way. (OK, I
don't know a lot about SAS70s...)
Where this becomes more interesting is that the CA should put in place
an internal auditing regime over the sub-CAs or remote RAs. This should
then be reviewed by the auditor, with intent to rely. Then, comments
fly back and forth, some changes are made, and hopefully it works out.
So in this sense, the lead auditor reviews the audit process of the
internal auditor over the subs, not the subs themselves.
iang
Stephen Schultze
> On 9/10/11 01:30 AM, Stephen Schultze wrote:
>> On 10/8/11 6:27 AM, ianG wrote:
>>> On 8/10/11 09:56 AM, Kathleen Wilson wrote:
>>>> On 10/7/11 3:09 PM, Brian Smith wrote:
>>>>>> I see your point about a CA-performed audit not being defined. I
>>>>>> don't
>>>>>> yet have an answer for this, other than it would obviously have to
>>>>>> included periodic review of the issued certificates and network
>>>>>> security reports.
>>>
>>> To address the above question about the sub-CA audit, as performed by
>>> the CA as an "internal audit" or other variations:
>>>
>>> *Subsidiary audits are already incorporated into the audit process* :
>>> the auditor opines over the whole, and writes his report to incorporate
>>> any subsidiary audits, /however they are done/ . The auditor uses
>>> something called the audit risk model to evaluate all the info brought
>>> to her, and an internal audit or an SAS70 or similar done over an
>>> external sub-CA is just more grist for the mill (more info into the
>>> calculations).
>>
>> 1. Where is it stated that auditors must include subsidiary "audits"?
>
> The don't have to. They choose whether to.
....and we can stop here.
The auditor isn't required or even asked to even "opine" over
subsidiaries, and there is no accountability if they don't. The
statement that "Subsidiary audits are already incorporated into the
audit process" is not true.
Why would an auditor do a bunch of extra work on something that they're
not even responsible for?
The solution is not to try to create some step-removed audit by bringing
this within the ambit of the auditor by requiring them to consider the
process of the internal "auditor" (should such an entity exist) but
rather to treat all CAs the same... whether they chain through a root or
whether they are seeking root status.
Kathleen Wilson
> On 10/7/11 6:56 PM, Kathleen Wilson wrote:
>> However, based on the information I have collected the past several
>> weeks I am now convinced that there are still three situations that we
>> need to continue to account for. And historically these have been
>
> By "account for" you mean "not require disclosure"?
>
>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>>
>> 1) sub-CAs that can be technically constrained
>
> I obviously vote for disclosure, but some people have argued against it.
>
We've discussed this before and reached a compromise that the sub-CA
could be technically constrained, and the technical constraints would be
documented in the CA's CP/CPS, and therefore included in the audit.
>> 2) Third-party public subordinate CAs that act as Certificate Service
>> Providers (CSPs)
>
> Should be audited through normal mechanisms and disclosed. What argument
> is there against this?
>
There is no argument in this case. Such sub-CAs should have public
CP/CPS and audit statements, and be disclosed by the CA.
> Really, they should probably be required to go through the root approval
> process themselves (ie: SubCAs would be essentially prohibited), given
> that we all seem to agree that the current audit regime is insufficient
> (hence the additional Moz requirements). But, as an interim measure
> perhaps we should allow them to exist as long as they are audited and
> disclosed.
>
We do review them during the root inclusion process.
https://wiki.mozilla.org/CA:SubordinateCA_checklist
The information is listed in the information gathering documents and
attached to the CA's root inclusion request bug.
>> 3) Third-party private (or enterprise) subordinate CAs
>
> And I have yet to hear any argument against disclosure other than "they
> don't want to."
>
Since it is for internal use only, the enterprise considers their
CP/CPS/audit to be proprietary information. For instance, consider a
bank who has a certificate issuance program for their employees. Banks
tend to be very cautious about the information that they post publicly
regarding security.
CAs consider their relationship with these enterprise customers to be
proprietary information. There's the obvious concern that other CAs
would directly market their large enterprise customers. There's also
confidentiality agreements between CAs and their large enterprise
customers -- for instance the bank who considers even the relationship
to be sensitive information about their security infrastructure.
>> I see the direction that you want Mozilla's CA Certificate program to go
>> in the future, but it's not something you can instantly change. We need
>> to keep taking steps in the right direction, but it will take time to
>> get to the end goal.
>
> Of course, but what's reasonable in the short term? Let's hear the
> arguments for why audit and disclosure are not reasonable.
As per other discussions, there is a need to have technical solutions in
place to make it easier for these enterprise customers to not need to
chain up to roots in NSS.
For example: https://bugzilla.mozilla.org/show_bug.cgi?id=692248
When there is reasonable technical support in place for in-premise
enterprise customers, then I agree we should re-look at updating
Mozilla's CA Certificate Policy.
However for the large in-premise enterprise customers I think there will
continue to be the need for interoperability with their customers and
business partners. But, perhaps over time good technical solutions will
be implemented that will also solve this need.
Kathleen
ianG
> On 10/8/11 10:56 AM, ianG wrote:
>>> On 10/8/11 6:27 AM, ianG wrote:
>>>> On 8/10/11 09:56 AM, Kathleen Wilson wrote:
>>>>> On 10/7/11 3:09 PM, Brian Smith wrote:
>>>>>>> I see your point about a CA-performed audit not being defined. I
>>>>>>> don't
>>>>>>> yet have an answer for this, other than it would obviously have to
>>>>>>> included periodic review of the issued certificates and network
>>>>>>> security reports.
>>>>
>>>> To address the above question about the sub-CA audit, as performed by
>>>> the CA as an "internal audit" or other variations:
>>>>
>>>> *Subsidiary audits are already incorporated into the audit process* :
>>>> the auditor opines over the whole, and writes his report to
>>>> incorporate
>>>> any subsidiary audits, /however they are done/ . The auditor uses
>>>> something called the audit risk model to evaluate all the info brought
>>>> to her, and an internal audit or an SAS70 or similar done over an
>>>> external sub-CA is just more grist for the mill (more info into the
>>>> calculations).
>>>
>>> 1. Where is it stated that auditors must include subsidiary "audits"?
>>
>> The don't have to. They choose whether to.
>
>
> The auditor isn't required or even asked to even "opine" over
> subsidiaries,
He isn't asked or required to opine over much of the mechanics at all,
except as per the criteria; it's a high level thing where typically the
formula is "the documentation published by the CA is an accurate
representation of the operations."
Whether there is outsourcing or other mechanical componentry is a matter
of detail.
> and there is no accountability if they don't.
If the CA has subsidiaries, and the auditor doesn't consider them, then
he has failed. This is why the audit reports often include explicit
exclusions, so that you as relying party can know the limitations.
E.g., here is a comment from one CA's current filed audit:
"For the [CA's personal email service], [CA] makes use of external
registration authorities for the specific subscriber registration
activities as disclosed in the [CA's] CPS on [CA's] website. Our
examination did not extend to the controls of external registration
authorities."
and earlier, it said "Subscriber information was properly authenticated
for the registration activities performed by [the CA] and..."
So it's pretty clear.
> The statement that "Subsidiary audits are already incorporated into
> the audit process" is not true.
No, it is included in the *process of audit* not every particular
audit. Which is to say, the methodology that audits are conducted under
includes this possibility. It is routine for an auditor to rely on the
work of another auditor, if appropriate.
> Why would an auditor do a bunch of extra work on something that
> they're not even responsible for?
>
> The solution is not to try to create some step-removed audit by
> bringing this within the ambit of the auditor by requiring them to
> consider the process of the internal "auditor" (should such an entity
> exist) but rather to treat all CAs the same... whether they chain
> through a root or whether they are seeking root status.
Yes, the auditor is required to treat the whole thing, to a reasonable
standardised degree. There is no artificial barrier created just
because a company outsources some component to another company. If that
outsourced component is critical to the operations, then it must be
covered; either by an exception in the report as above, or by being
examined to the extent needed.
No auditor worth his salt is going to leave out the other company just
because it is a company.
iang
Stephen Schultze
the common case that the entities in question are not in fact examined,
and are simply disclaimed in the audit report.
That doesn't engender a great deal of confidence.
I know that if I were an auditor under this regime, I would simply
disclaim anything I didn't have to do and collect my paycheck... which
is, it seems, common practice.
Stephen Schultze
> On 10/7/11 7:28 PM, Stephen Schultze wrote:
>> On 10/7/11 6:56 PM, Kathleen Wilson wrote:
>>> However, based on the information I have collected the past several
>>> weeks I am now convinced that there are still three situations that we
>>> need to continue to account for. And historically these have been
>>
>> By "account for" you mean "not require disclosure"?
>>
>>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>>>
>>> 1) sub-CAs that can be technically constrained
>>
>> I obviously vote for disclosure, but some people have argued against it.
>>
>
> We've discussed this before and reached a compromise that the sub-CA
> could be technically constrained, and the technical constraints would be
> documented in the CA's CP/CPS, and therefore included in the audit.
Right. I didn't prefer that solution, but given the resistance to
disclosure, it seemed like a viable compromise. It was a compromise
that applied to *all* types of SubCAs, but you appear to wish to
reconsider this compromise, so it's on the table again.
So far, Brian and I have made good arguments for audit and disclosure.
The argument against this seems to continue to be, "they don't want to."
Technically, all SubCAs can be considered to be those "that can be
technically constrained" because such mechanisms exist today. I think
that the distinctions below are superfluous in light of this, but let's
proceed to the analysis.
>>> 2) Third-party public subordinate CAs that act as Certificate Service
>>> Providers (CSPs)
>>
>> Should be audited through normal mechanisms and disclosed. What argument
>> is there against this?
>>
>
> There is no argument in this case. Such sub-CAs should have public
> CP/CPS and audit statements, and be disclosed by the CA.
>
>
>> Really, they should probably be required to go through the root approval
>> process themselves (ie: SubCAs would be essentially prohibited), given
>> that we all seem to agree that the current audit regime is insufficient
>> (hence the additional Moz requirements). But, as an interim measure
>> perhaps we should allow them to exist as long as they are audited and
>> disclosed.
>>
>
> We do review them during the root inclusion process.
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
> The information is listed in the information gathering documents and
> attached to the CA's root inclusion request bug.
Yes, I see that these are requested in the checklist (although the
checklist refers to the cert policy audit requirements by number, and
the numbers refer to an out-of-date version of the cert policy).
Can you point to a CA that has fulfilled these requirements?
>>> 3) Third-party private (or enterprise) subordinate CAs
>>
>> And I have yet to hear any argument against disclosure other than "they
>> don't want to."
>
> Since it is for internal use only, the enterprise considers their
> CP/CPS/audit to be proprietary information. For instance, consider a
> bank who has a certificate issuance program for their employees. Banks
> tend to be very cautious about the information that they post publicly
> regarding security.
>
> CAs consider their relationship with these enterprise customers to be
> proprietary information. There's the obvious concern that other CAs
> would directly market their large enterprise customers. There's also
> confidentiality agreements between CAs and their large enterprise
> customers -- for instance the bank who considers even the relationship
> to be sensitive information about their security infrastructure.
Right. Translation: "they don't want to."
It's not that they can't implement them, or that they can't find
solutions for keeping their so-called proprietary data private, it's
that they don't want to.
>>> I see the direction that you want Mozilla's CA Certificate program to go
>>> in the future, but it's not something you can instantly change. We need
>>> to keep taking steps in the right direction, but it will take time to
>>> get to the end goal.
>>
>> Of course, but what's reasonable in the short term? Let's hear the
>> arguments for why audit and disclosure are not reasonable.
>
> As per other discussions, there is a need to have technical solutions in
> place to make it easier for these enterprise customers to not need to
> chain up to roots in NSS.
> For example: https://bugzilla.mozilla.org/show_bug.cgi?id=692248
>
> When there is reasonable technical support in place for in-premise
> enterprise customers, then I agree we should re-look at updating
> Mozilla's CA Certificate Policy.
Enterprises *today* have several solutions (as I listed earlier). They
just don't want to go through the effort to adopt them.
> However for the large in-premise enterprise customers I think there will
> continue to be the need for interoperability with their customers and
> business partners. But, perhaps over time good technical solutions will
> be implemented that will also solve this need.
Conditioning Mozilla certificate policy on unknown future technical
enhancements is a recipe for another decade of security failures.
Peter Gutmann
>> WebTrust/ETSI/etc audit that's required of root CAs?
>
>It's what is available. If an SAS70 is available on a company that has a
>sub-CA, well, it's evidence for the model. If it doesn't work, then more
>work to be done. An SAS70 has the benefit that the american market
>understands them well.
Another way of looking at this is that if you argue over what colour to make
the arbitrary line in the sand then you don't have to think about where and
why you're drawing the arbitrary line in the sand in the first place.
>> WebTrust doesn't mention auditing or reviewing audits of SubCAs.
>> WebTrust assumes no review of cross-signed entities.
>> WebTrust explicitly exempts any review of RAs.
>
>One wonders what they were thinking when they wrote that last exemption...
Oh, I know that one, it was "we can save ourselves a lot of work if we exclude
RAs (and cross-signed CAs, and sub-CAs) and other stuff".
Where do I collect my biscuit?
Peter.
ianG
> On 10/7/11 7:29 AM, ianG wrote:
>>> However, I am no longer convinced that all of the
>>> non-technically-constrained sub-CAs should be publicly disclosed.
>>
>> full answer.
>>
>> On the other hand, I am convinced that liability is the answer. If (by
>> way of rhetorical) you gained from each of the CAs engaged in this
>> practice the following contractual statement:
>>
>> I, .....TrustedCA... of ....1 Trust St, Trustvillle....
>> assume all the liability for all the sub-CAs and
>> cross-signed CAs and any similar derivative
>> product under my roots.
>> /TrustedCA/
>>
>> Then for me the answer is clear. Go for it. (That's just a thought
>> experiment, folks!)
>>
>> However. Failing liability, then disclosure may be the best we get. As
>> nobody takes liability seriously, then I suppose I must argue for
>> disclosure.
>
> But does liability account for some of the known threat vectors? How
> does a liability clause by a CA located in a foreign jurisdiction
> trigger anything when that CA voluntarily grants rogue certificates to
> the government, or when that CA or its delegates is compromised?
> Whose law governs? What are the damages if the harm is "just"
> surveillance?
Right. Some liabilities are hard to mitigate. However, this isn't a
justification for ignoring them, or ignoring liabilities in general.
So, I think the answer is probably in two parts. Firstly, map those
liabilities. Second, deal with them [0].
> As we saw in the DigiNotar case, the removal from the root list can
> easily mean bankruptcy for the company, which is on the contrary a
> very clear penalty (and can also nullify any liability that is in place).
Right, stick not carrot. Or, punishment, not transfers.
But systems built on punishment do not work as well as systems built on
incentives. Because the only step available here is so ... terminal,
the result will be non-optimal, and we could probably show through
standard finance calculations that bankruptcy as the only punishment
results in an increase in bad behaviour. At a minimum, there will be
over expenditure in one area, under expenditure in another, driven by
fear of removal.
> Maybe disclosure and active policing by the browsers and end-users is
> actually a more comprehensive approach?
As I indicated above, I'd see disclosure is a survivable or short-term
compromise or stepping stone.
But comprehensive? No chance. For one, disclosure creates excessive
attention to headline scandal and inattention to boring risks (c.f., SSL
and phishing, "5 ways to be secure this summer" in News of the World,
etc etc).
Also, although the open source community contends that disclosure is
good for security, I personally have never seen any empirical evidence
of that hypothesis. Yes, there's lots of noise about fixing bugs, but
little comparison of alternatives. E.g., there are some secret security
systems that are good, that serve us well.
Whereas, if a supplier was sued for phishing -- liabilities allocated --
I'm sure the priorities would change.
> But, as you say, this is repeating long discussions.
Yeah. But it'll be back. The problem hasn't gone away. Patience :)
iang
[0] Mitigation: eliminate the ones we can, accept the ones we can't.
More sophisticated is ESIEAP or Eliminate, substitute, isolate,
engineering controls, administrative controls, and protective gear.
ianG
On 9/10/11 06:01 AM, Stephen Schultze wrote:
> So the standard of being "incorporated into the audit process"
> includes the common case that the entities in question are not in fact
> examined, and are simply disclaimed in the audit report.
measured. This is one objective of the audit risk model, which seeks to
drop things that we can get away without measuring. To use Peter's
words, auditor draws a line in the sand.
It seems to be common practice to disclaim the external RAs at least.
To be fair, external or remote RAs can be tricky to audit, if only
because of the scale of them, and typically CAs will ask the Auditor not
to examine them. It was something we wrestled with at CAcert for years,
until we cracked it.
I don't know what happens with sub-CAs. If you know a CA that does
them, look in the audit report and see what it says...
> That doesn't engender a great deal of confidence.
accepted at face value, yet they have these exclusions in them that seem
to be truck-sized holes.
I suppose we can ask: Has any audit ever been rejected by Mozilla?
> I know that if I were an auditor under this regime, I would simply
> disclaim anything I didn't have to do and collect my paycheck... which
> is, it seems, common practice.
That could be one of the criticisms made, there are more:
* the examinations is based on a reasonable standard. So, what is
reasonable? Well, whatever it is, there is a lot of wiggle room there.
* it's always a snapshot over some time, likely the order of a month.
Which month? Who's on best behaviour?
* the report is written in rather brief terms, so a lot goes unsaid.
* if something needs to be said, it can be done in audit-speak, which
is interpretable by other auditors, but maybe not by anyone else...
* Criteria have a lot of wiggle room. WebTrust is particularly
"outdated" in many respects.
* Later generation criteria like ETSI and EV are much more detailed.
But they are a reflection of "what we can do / charge for" as much as
"what an end-user needs." And, as they were written by auditors, this
is unlikely to change.
* Indeed, end-users aren't present in any of this. The audits are
commissioned by the CA direct to the Auditor with a letter of engagement.
* Nor does Mozilla. Hence e.g., Mozilla's policy is not covered by audit.
... I could go on. Indeed, I did, in 7 long blog posts last year [0].
The main summary is that while audits might do a great job, we can't
rely on them to tell us what we need to know. Unfortunately, any
alternates that exist are hated even more, so it's probably a case of
the devil that we know :)
iang
[0] Iang's Long Audit cycle starts here:
http://financialcryptography.com/mt/archives/001126.html
Stephen Schultze
means would be useful. However, I think that "liability" *to the
browsers* for actions that harm users (whether fiscally or otherwise)
could be both more effective and comprehensive. There are two necessary
conditions for this:
1. CAs must disclose (to the public, so that the public can help notify
browsers of violations)
2. Browsers must enforce
Brian has mentioned his plan to implement intermediate enforcement
mechanisms against badly behaving CAs such that the "big stick" of root
removal is not the only option. I think that this is a great idea.
Steve
Stephen Schultze
"*Subsidiary audits are already incorporated into the audit process*",
I'm not sure what the point was. Perhaps you can do some contortions to
read an exclusion as an inclusion, but at the end of the day it's clear
that auditors are not today required to look at the
process/policy/practice of third-party entities that have been granted
cert issuing authority.
As for what the audit reports look like for CAs that grant SubCA certs:
https://www.globalsign.com/certificate-authority-root-signing/
https://cert.webtrust.org/SealFile?seal=928&file=pdf
"GlobalSign SA/NV makes uses of external registration authorities for
specific subscriber registration activities as disclosed in GlobalSign
SA/NV�s business practice disclosures. Our examination did not extend to
the control of external registration authorities."
"This report does not include any representation as to the quality of
GlobalSign SA/NV�s services beyond those covered by the WebTrust for
Certification Authorities Criteria..." [which does not include SubCAs]
GlobalSign's CP permits GlobalSign to do a one-time "PKI Infrastructure
review" of "Trusted Root" customers, which is described in 5 bullet points.
Steve
Eddy Nigg
> Infrastructure review" of "Trusted Root" customers, which is described
> in 5 bullet points.
>
is even a CA that sends the private key of the (sub) CA via Internet
download for installation on an MSCA.
ianG
> On 10/6/11 6:51 PM, Stephen Schultze wrote:
>> On 10/6/11 7:31 PM, Kathleen Wilson wrote:
>>> I agree that the sub-CAs should be technically constrained or audited
>>> either by the CA or a third-party, ...
>>
>> 1. Why would subCA auditing by the CA be sufficient, and what does
>> "audit" even mean in this context? ...
>>
> ...
> I see your point about a CA-performed audit not being defined. I don't
Just to summarise a threadlet with Steve & Kathleen: the above
question(s) is well understood in the profession of auditing. The lead
auditor simply reviews the internal (CA) audit process and decides
whether to rely on it or not. Internal audit, and the relationship
between it and external audit, is well understood in the biz-world.
As to whether it is sufficient -- that's the auditor's call. She is far
better placed to make that call. Indeed, she is expert. We (in
general) are not, and we have none of the information to make that call.
iang
ianG
> Re-reading our exchange in light of your original statement that
> "*Subsidiary audits are already incorporated into the audit process*",
> I'm not sure what the point was.
See immediately preceeding post.
> Perhaps you can do some contortions to read an exclusion as an
> inclusion, but at the end of the day it's clear that auditors are not
> today required to look at the process/policy/practice of third-party
> entities that have been granted cert issuing authority.
We're talking at cross purposes here, perhaps.... It is them that make
that decision, not us. Us telling the auditors how to interpret the
third party entities would be like them telling us the difference
between object oriented programming and functional programming... They
have to cover it if it is relevant to the subject matter, how they cover
it is up to them.
(We could write a criteria instructing them ... but that doesn't change
how facile it would be.)
> As for what the audit reports look like for CAs that grant SubCA certs:
>
> https://www.globalsign.com/certificate-authority-root-signing/
>
> https://cert.webtrust.org/SealFile?seal=928&file=pdf
> "GlobalSign SA/NV makes uses of external registration authorities for
> specific subscriber registration activities as disclosed in GlobalSign
> SA/NV�s business practice disclosures. Our examination did not extend
> to the control of external registration authorities."
> "This report does not include any representation as to the quality of
> GlobalSign SA/NV�s services beyond those covered by the WebTrust for
> Certification Authorities Criteria..." [which does not include SubCAs]
OK, so it's quite common.
> GlobalSign's CP permits GlobalSign to do a one-time "PKI
> Infrastructure review" of "Trusted Root" customers, which is described
> in 5 bullet points.
Which, as it was in the CP, and as the Auditor reviewed those
disclosures, was therefore OK by the Auditor.
(Maybe he was wrong, maybe right. That's another issue.)
iang
Stephen Schultze
audit reports, and CA CPs that third-parties of all types (RAs, SubCAs,
and cross-signed CAs) are routinely exempted from any consideration by
auditors whatsoever. I'm afraid that your wishful thinking about how
auditors behave isn't backed up by any evidence.
The question is not whether we detail what a SubCA audit consists of
(although guidance might be in order), but whether we require them at
all. Clearly the current regime does not.
1. SubCAs are CAs with all the authority of root CAs
2. SubCAs are not audited the same as root CAs
3. There is a major loophole in the regime
I don't have any more to say on the matter. The above should be clear
to anyone following this thread, and I don't see much point in
continuing to talk past each other.
Kathleen Wilson
>>>> 2) Third-party public subordinate CAs that act as Certificate Service
>>>> Providers (CSPs)
>>>
>>> Should be audited through normal mechanisms and disclosed. What argument
>>> is there against this?
>>>
>>
>> There is no argument in this case. Such sub-CAs should have public
>> CP/CPS and audit statements, and be disclosed by the CA.
>>
>>
>>> Really, they should probably be required to go through the root approval
>>> process themselves (ie: SubCAs would be essentially prohibited), given
>>> that we all seem to agree that the current audit regime is insufficient
>>> (hence the additional Moz requirements). But, as an interim measure
>>> perhaps we should allow them to exist as long as they are audited and
>>> disclosed.
>>>
>>
>> We do review them during the root inclusion process.
>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>>
>> The information is listed in the information gathering documents and
>> attached to the CA's root inclusion request bug.
>
> Yes, I see that these are requested in the checklist (although the
> checklist refers to the cert policy audit requirements by number, and
> the numbers refer to an out-of-date version of the cert policy).
>
> Can you point to a CA that has fulfilled these requirements?
>
https://bugzilla.mozilla.org/show_bug.cgi?id=436056#c29
https://bugzilla.mozilla.org/attachment.cgi?id=407385
https://bugzilla.mozilla.org/show_bug.cgi?id=551399#c31
https://bugzilla.mozilla.org/show_bug.cgi?id=551399#c34
Fortunately there are very few root inclusion requests for roots that
have third-party public subordinate CAs. This type of root inclusion
request requires a lot of extra work on my part.
>>>> 3) Third-party private (or enterprise) subordinate CAs
>>>
>
> Conditioning Mozilla certificate policy on unknown future technical
> enhancements is a recipe for another decade of security failures.
Currently Mozilla's CA Certificate Policy does not mention
externally-operated subordinate CAs at all. In practice, we have been
addressing externally-operated subordinate CAs, but I would like to at
least get our current practices stated in the policy.
Our current practices were summarized by Frank Hecker here:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc#
and have been documented on our wiki pages here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
While adding support for our practices regarding externally-operated
sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
some minor (less contentious) improvements such as adding the proposed
text about technical constraints, and requiring that third-party public
subordinate CAs and their CP/CPS/audits be publicly disclosed.
However, the proposed change to require public disclosure of third-party
private (or enterprise) subordinate CAs is still too contentious.
Quote from Frank in 2010: "I'm willing to give CAs and their
<enterprise> customers a greater "presumption of innocence", and allow
them to continue the current practice of engaging in private business
transactions without disclosure of customer identities, as long as the
activities associated with those transactions are private in nature (as
they would be for third-party private CAs as defined above) and as long
as we have reasonable assurances that legal and audit frameworks are in
place to ensure that those activities don't impact typical Mozilla users
on the public Internet."
I have not seen any data indicating that these third-party private (or
enterprise) subordinate CAs are engaging in activities that impact
typical Mozilla users on the public Internet.
Kathleen
Stephen Schultze
> While adding support for our practices regarding externally-operated
> sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
> some minor (less contentious) improvements such as adding the proposed
> text about technical constraints, and requiring that third-party public
> subordinate CAs and their CP/CPS/audits be publicly disclosed.
>
> However, the proposed change to require public disclosure of third-party
> private (or enterprise) subordinate CAs is still too contentious.
Nobody is contending that they should not be disclosed other than you.
You are citing some backchannel conversations with CAs, but how can we
evaluate those?
> Quote from Frank in 2010: "I'm willing to give CAs and their
> <enterprise> customers a greater "presumption of innocence", and allow
> them to continue the current practice of engaging in private business
> transactions without disclosure of customer identities, as long as the
> activities associated with those transactions are private in nature (as
> they would be for third-party private CAs as defined above) and as long
> as we have reasonable assurances that legal and audit frameworks are in
> place to ensure that those activities don't impact typical Mozilla users
> on the public Internet."
>
> I have not seen any data indicating that these third-party private (or
> enterprise) subordinate CAs are engaging in activities that impact
> typical Mozilla users on the public Internet.
Yes, I remember Frank's post, to which I replied:
"What I hear you saying is that there is no potential benefit to Mozilla
users, but if the trust is violated there is potential harm. If that's
the case, why wouldn't we want to curtail the practice of undisclosed
private Sub-CAs? It's all upside from the perspective of the users."
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#5a209af015067cb4
And then the other folks on the thread agreed:
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#6a3af87d8821e0b0
I like Frank, and he is a smart guy, but his word isn't law...
particularly his word from before the recent spate of exploits.
His statement also assumes "reasonable assurances that legal and audit
frameworks are in place..." which has been cast into doubt.
Kathleen Wilson
The "recent spate of exploits" did not involve any third-party private
(enterprise) sub-CAs.
>
> His statement also assumes "reasonable assurances that legal and audit
> frameworks are in place..." which has been cast into doubt.
What is new that has cast this in doubt?
Stephen Schultze
highlights the vulnerability of third-party delegation in general. Must
we have a demonstrated failure of each flavor of delegation before we
decide to clean it up?
In any case, I'd be interested to know how you think that so-called
"third-party private (enterprise) sub-CAs" provide benefit to typical
Mozilla users of the public internet given that, by Franks own
description, "activities associated with those transactions are private
in nature."
>> His statement also assumes "reasonable assurances that legal and audit
>> frameworks are in place..." which has been cast into doubt.
>
>
> What is new that has cast this in doubt?
demonstrated that audits are clearly not required of third-parties.
Kathleen Wilson
>> While adding support for our practices regarding externally-operated
>> sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
>> some minor (less contentious) improvements such as adding the proposed
>> text about technical constraints, and requiring that third-party public
>> subordinate CAs and their CP/CPS/audits be publicly disclosed.
>>
>> However, the proposed change to require public disclosure of third-party
>> private (or enterprise) subordinate CAs is still too contentious.
>
> Nobody is contending that they should not be disclosed other than you.
> You are citing some backchannel conversations with CAs, but how can we
> evaluate those?
>
Some reasons:
1) The representatives for some of these CAs have to get approval from
their employer before they can post a comment in a public discussion forum.
2) The representatives of these CAs are not allowed to publicly disclose
information about these customers -- it could mean loosing their jobs.
3) The representatives of these CAs don't want to get publicly singled
out in this particular discussion topic.
>> Quote from Frank in 2010: "I'm willing to give CAs and their
>> <enterprise> customers a greater "presumption of innocence", and allow
>> them to continue the current practice of engaging in private business
>> transactions without disclosure of customer identities, as long as the
>> activities associated with those transactions are private in nature (as
>> they would be for third-party private CAs as defined above) and as long
>> as we have reasonable assurances that legal and audit frameworks are in
>> place to ensure that those activities don't impact typical Mozilla users
>> on the public Internet."
>>
>> I have not seen any data indicating that these third-party private (or
>> enterprise) subordinate CAs are engaging in activities that impact
>> typical Mozilla users on the public Internet.
>
> Yes, I remember Frank's post, to which I replied:
> "What I hear you saying is that there is no potential benefit to Mozilla
> users, but if the trust is violated there is potential harm. If that's
> the case, why wouldn't we want to curtail the practice of undisclosed
> private Sub-CAs? It's all upside from the perspective of the users."
> https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#5a209af015067cb4
>
>
> And then the other folks on the thread agreed:
> https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#6a3af87d8821e0b0
>
>
> I like Frank, and he is a smart guy, but his word isn't law...
Frank is still the owner of Mozilla's CA Certificate Policy.
https://wiki.mozilla.org/Module_Owners_Activities_Modules#Governance_Submodule:_Mozilla_CA_Certificate_Policy
> particularly his word from before the recent spate of exploits.
Which, again did not have to do with third-party private subCAs.
> His statement also assumes "reasonable assurances that legal and audit
> frameworks are in place..." which has been cast into doubt.
Cast into doubt by what events? The recent CA Communication required
that the network security review and intrusion detection be performed
for all CAs and their sub-CAs and RAs. While irregular activity was
reported for some of these, I have yet to hear of a CA finding irregular
activity regarding a third-party private subCA.
Frank's comments did not say that the reasonable assurances had to be
publicly disclosed. If they are not publicly disclosed then I guess that
means that the CA Certificates Module owner needs to have the reasonable
assurances.
Kathleen
Stephen Schultze
> On 10/10/11 12:50 PM, Stephen Schultze wrote:
>> On 10/10/11 2:55 PM, Kathleen Wilson wrote:
>>> While adding support for our practices regarding externally-operated
>>> sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
>>> some minor (less contentious) improvements such as adding the proposed
>>> text about technical constraints, and requiring that third-party public
>>> subordinate CAs and their CP/CPS/audits be publicly disclosed.
>>>
>>> However, the proposed change to require public disclosure of third-party
>>> private (or enterprise) subordinate CAs is still too contentious.
>>
>> Nobody is contending that they should not be disclosed other than you.
>> You are citing some backchannel conversations with CAs, but how can we
>> evaluate those?
>>
>
> Some reasons:
> 1) The representatives for some of these CAs have to get approval from
> their employer before they can post a comment in a public discussion forum.
> 2) The representatives of these CAs are not allowed to publicly disclose
> information about these customers -- it could mean loosing their jobs.
> 3) The representatives of these CAs don't want to get publicly singled
> out in this particular discussion topic.
of the larger problem with allowing public policy decisions to be based
on private conversations. I suppose you can change that culture (you
have that power) or bow to it.
>>> Quote from Frank in 2010: "I'm willing to give CAs and their
>>> <enterprise> customers a greater "presumption of innocence", and allow
>>> them to continue the current practice of engaging in private business
>>> transactions without disclosure of customer identities, as long as the
>>> activities associated with those transactions are private in nature (as
>>> they would be for third-party private CAs as defined above) and as long
>>> as we have reasonable assurances that legal and audit frameworks are in
>>> place to ensure that those activities don't impact typical Mozilla users
>>> on the public Internet."
>>>
>>> I have not seen any data indicating that these third-party private (or
>>> enterprise) subordinate CAs are engaging in activities that impact
>>> typical Mozilla users on the public Internet.
>>
>> Yes, I remember Frank's post, to which I replied:
>> "What I hear you saying is that there is no potential benefit to Mozilla
>> users, but if the trust is violated there is potential harm. If that's
>> the case, why wouldn't we want to curtail the practice of undisclosed
>> private Sub-CAs? It's all upside from the perspective of the users."
>> https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#5a209af015067cb4
>>
>>
>>
>> And then the other folks on the thread agreed:
>> https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc/0e8ef7ea5ceee714#6a3af87d8821e0b0
>>
>>
>>
>> I like Frank, and he is a smart guy, but his word isn't law...
>
>
> Frank is still the owner of Mozilla's CA Certificate Policy.
> https://wiki.mozilla.org/Module_Owners_Activities_Modules#Governance_Submodule:_Mozilla_CA_Certificate_Policy
>> particularly his word from before the recent spate of exploits.
>
> Which, again did not have to do with third-party private subCAs.
failed to address:
===
highlights the vulnerability of third-party delegation in general. Must
we have a demonstrated failure of each flavor of delegation before we
decide to clean it up?
In any case, I'd be interested to know how you think that so-called
"third-party private (enterprise) sub-CAs" provide benefit to typical
Mozilla users of the public internet given that, by Franks own
in nature."
===
>> His statement also assumes "reasonable assurances that legal and audit
>> frameworks are in place..." which has been cast into doubt.
>
> Cast into doubt by what events? The recent CA Communication required
> that the network security review and intrusion detection be performed
> for all CAs and their sub-CAs and RAs. While irregular activity was
> reported for some of these, I have yet to hear of a CA finding irregular
> activity regarding a third-party private subCA.
and legal frameworks*, is in doubt. I suppose that if he believes,
against all evidence, that this is the case, there's not much to be
done. Even if it were true, I'm of the opinion that not disclosing them
simply because CAs don't want to is irresponsible.
> Frank's comments did not say that the reasonable assurances had to be
> publicly disclosed. If they are not publicly disclosed then I guess that
> means that the CA Certificates Module owner needs to have the reasonable
> assurances.
with enabling internal private enterprise transactions is worth exposing
Mozilla users to the risk of undisclosed SubCAs that have no technical
constraints.
When I first got involved with m.d.s.p, Frank told me that one of its
chronic problems was that eventually the serious security folks leave
because they get fed up with the slow progress on fixing the system. I
am beginning to understand what he meant.
Steve
ianG
> I don't dispute that clearer fiscal liability via legally enforceable
> means would be useful. However, I think that "liability" *to the
> browsers* for actions that harm users (whether fiscally or otherwise)
> could be both more effective and comprehensive. There are two
> necessary conditions for this:
>
> 1. CAs must disclose (to the public, so that the public can help
> notify browsers of violations)
I think we're all agreed on this. Including, we're all agreed that CAs
won't agree :)
It was pointed out by some CAs that they would agree if everyone else
agreed. The problem with this is that the CAs will sit back and do
nothing. Including not agree. (Stuff might happen in the backrooms, of
course.)
So we are in a bit of a constitutional crisis. There is no effective
regulation over the CAs, as they simply decline to be regulated. As
they are part of the "consensus" they simply need say nothing.
Time to break the consensus?
> 2. Browsers must enforce
I am cautious of throwing that role on to vendors only. It is quite
traumatic, and it also raises fiscal liabilities, in that once they've
asserted responsibility, then they'll be held to it.
But, I guess I'm trying to stop the tide here. Assuming that it's going
to happen, here are some notes I wrote a while back on one way to do it:
https://wiki.mozilla.org/CA:Dispute_resolution
> Brian has mentioned his plan to implement intermediate enforcement
> mechanisms against badly behaving CAs such that the "big stick" of
> root removal is not the only option. I think that this is a great idea.
Probably, all ideas need to be on the table. We need to solve the CA
crisis somehow.
Or maybe we don't. Does the Mozilla end-user get effected one way or
another?
iang
ianG
> In any case, I'd be interested to know how you think that so-called
> "third-party private (enterprise) sub-CAs" provide benefit to typical
> Mozilla users of the public internet given that, by Franks own
> private in nature."
Just on this point: The assumption here is that Mozilla serves the
public internet, only. I don't think this is the case, and we've
established it before. Mozilla users are on both the public internet,
and on private intranets [0].
>>> His statement also assumes "reasonable assurances that legal and audit
>>> frameworks are in place..." which has been cast into doubt.
>>
>> Cast into doubt by what events? The recent CA Communication required
>> that the network security review and intrusion detection be performed
>> for all CAs and their sub-CAs and RAs. While irregular activity was
>> reported for some of these, I have yet to hear of a CA finding irregular
>> activity regarding a third-party private subCA.
>
> audits and legal frameworks*, is in doubt. I suppose that if he
> believes, against all evidence, that this is the case, there's not
> much to be done. Even if it were true, I'm of the opinion that not
I don't see how this:
"reasonable assurances that legal and audit frameworks are in
place..."
whether audits and legal frameworks exist over sub-CAs, etc?
Specifically, it appears to be in doubt as to whether audit is done over
sub-CAs that are outsourced or otherwise external. I don't see this
exception myself in the policy, but it appears there may be an exception
in effect to this extent.
So if this is the case, there must be something else that "audit and
legal frameworks" is asserted, somehow. Something that we don't know
about. Or, it's not covered.
>> Frank's comments did not say that the reasonable assurances had to be
>> publicly disclosed. If they are not publicly disclosed then I guess that
>> means that the CA Certificates Module owner needs to have the reasonable
>> assurances.
>
> with enabling internal private enterprise transactions is worth
> exposing Mozilla users to the risk of undisclosed SubCAs that have no
> technical constraints.
> When I first got involved with m.d.s.p, Frank told me that one of its
> chronic problems was that eventually the serious security folks leave
> because they get fed up with the slow progress on fixing the system.
> I am beginning to understand what he meant.
security folk :)
iang
[0] This is part of the rationale behind accepting non-routable domains
such as "mailer.local" in certs -- they are serving a need inside local
nets.
Jeffrey Walton
> On 10/10/11 03:13 AM, Stephen Schultze wrote:
>
> > I don't dispute that clearer fiscal liability via legally enforceable
> > means would be useful. However, I think that "liability" *to the
> > browsers* for actions that harm users (whether fiscally or otherwise)
> > could be both more effective and comprehensive. There are two
> > necessary conditions for this:
>
> > 1. CAs must disclose (to the public, so that the public can help
> > notify browsers of violations)
>
> I think we're all agreed on this. Including, we're all agreed that CAs
> won't agree :)
>
> It was pointed out by some CAs that they would agree if everyone else
> agreed. The problem with this is that the CAs will sit back and do
> nothing. Including not agree. (Stuff might happen in the backrooms, of
> course.)
>
> So we are in a bit of a constitutional crisis. There is no effective
> regulation over the CAs, as they simply decline to be regulated. As
> they are part of the "consensus" they simply need say nothing.
>
> Time to break the consensus?
need the CAs.
> > 2. Browsers must enforce
>
> I am cautious of throwing that role on to vendors only. It is quite
> traumatic, and it also raises fiscal liabilities, in that once they've
> asserted responsibility, then they'll be held to it.
>
> But, I guess I'm trying to stop the tide here. Assuming that it's going
> to happen, here are some notes I wrote a while back on one way to do it:
>
> https://wiki.mozilla.org/CA:Dispute_resolution
>
> > Brian has mentioned his plan to implement intermediate enforcement
> > mechanisms against badly behaving CAs such that the "big stick" of
> > root removal is not the only option. I think that this is a great idea.
>
> Probably, all ideas need to be on the table. We need to solve the CA
> crisis somehow.
>
> Or maybe we don't. Does the Mozilla end-user get effected one way or
> another?
It seems to me the folks in Iran have the most experience with
consequences of a failed CA (I don't believe the government did it to
launch a massive phishing campaign). Perhaps it would be a good idea
to ask the people whose lives depend on privacy and the system. Fiscal
liability is probably the least of their worries.
Jeff
Eddy Nigg
> It seems to me the folks in Iran have the most experience with
> consequences of a failed CA (I don't believe the government did it to
> launch a massive phishing campaign). Perhaps it would be a good idea
> to ask the people whose lives depend on privacy and the system. Fiscal
> liability is probably the least of their worries.
Just a thought, but CAs ought to exclude such cases from their
liabilities and purpose. For example I've seen CAs that explicitly
prohibit using their digital certificate for use with flight
communications, atomic power stations and all kind of similar critical
systems that could potentially threaten the lives of people.
PKI in use at the Internet wasn't probably meant to protect for such
live-threatening situations, but really just to provide a certain degree
of privacy for financial and private communications. I've also written
up some more thoughts in my blog about this subject:
https://blog.startcom.org/?p=229
As a community we might not necessarily have to agree to provide
protection for such purposes, as software may have vulnerabilities too
that could lead to similar attacks on communications with the same
result, such as also the SSL protocol itself was subject to such flaws
recently already. Probably there is a limit to what can be reasonable
achieved and provided and what is beyond.
ianG
> On 10/12/2011 10:01 AM, From Jeffrey Walton:
>> consequences of a failed CA (I don't believe the government did it to
>> launch a massive phishing campaign). Perhaps it would be a good idea
>> to ask the people whose lives depend on privacy and the system.
>> Fiscal liability is probably the least of their worries.
>
> liabilities and purpose. For example I've seen CAs that explicitly
> prohibit using their digital certificate for use with flight
> communications, atomic power stations and all kind of similar critical
> systems that could potentially threaten the lives of people.
That's fine in concept, but implementation has issues.
You might exclude loss of life in your contract. But if your CA wrongly
issues gmail's cert, you not only have to contend with your CPS being
breached and repo trashed ... but also a tort of some form from whoever
gmail's provider is.
If gmail's provider is nailed for contributory manslaughter in Southern
District NY court, then they turn around and take you for damages. Your
contract means nothing because you haven't got a contract with them.
Problem #1: All CAs need to agree on the line in the sand; universal
implicit cross-certification claims scalp again.
Problem #2: Where do we draw that line in the sand? A year ago it
would have been non-controversial, but that window of liability
management is closed. The Iranians (allegedly) are still smarting from
their nuclear power hack from the Israelis (allegedly) ... and they've
(allegedly) attacked an email provider for revenge...
So, draw a line from hotmail to hot reactors. Pick any point in between :)
> PKI in use at the Internet wasn't probably meant to protect for such
> live-threatening situations, but really just to provide a certain
> degree of privacy for financial and private communications. I've also
> written up some more thoughts in my blog about this subject:
> https://blog.startcom.org/?p=229
>
> As a community we might not necessarily have to agree to provide
> protection for such purposes, as software may have vulnerabilities too
> that could lead to similar attacks on communications with the same
> result, such as also the SSL protocol itself was subject to such flaws
> recently already. Probably there is a limit to what can be reasonable
> achieved and provided and what is beyond.
>
If you can get other CAs to tell vendors that, we might have a hope.
Taher Elgamal called it, as did RSA [0].
iang
[0] links in this post:
http://financialcryptography.com/mt/archives/001337.html
Eddy Nigg
> So, draw a line from hotmail to hot reactors. Pick any point in
> between :)
Perhaps not - which means, when using a browser even with SSL for
certain purpose you do on your own risk because it's not covered. We are
talking about software used on personal computers (and friends) here,
not flight controllers.
Tom Lowenthal
> On 10/10/11 6:58 PM, Kathleen Wilson wrote:
>>> On 10/10/11 2:55 PM, Kathleen Wilson wrote:
>>>> While adding support for our practices regarding externally-operated
>>>> sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
>>>> some minor (less contentious) improvements such as adding the proposed
>>>> text about technical constraints, and requiring that third-party public
>>>> subordinate CAs and their CP/CPS/audits be publicly disclosed.
>>>>
>>>> However, the proposed change to require public disclosure of
>>>> third-party
>>>> private (or enterprise) subordinate CAs is still too contentious.
>>>
>>> Nobody is contending that they should not be disclosed other than you.
>>> You are citing some backchannel conversations with CAs, but how can we
>>> evaluate those?
>>>
>>
>> Some reasons:
>> 1) The representatives for some of these CAs have to get approval from
>> their employer before they can post a comment in a public discussion
>> forum.
>> 2) The representatives of these CAs are not allowed to publicly disclose
>> information about these customers -- it could mean loosing their jobs.
>> 3) The representatives of these CAs don't want to get publicly singled
>> out in this particular discussion topic.
>
> of the larger problem with allowing public policy decisions to be based
> on private conversations. I suppose you can change that culture (you
> have that power) or bow to it.
Mozilla is accountable to our users, and we achieve this by making
everything as public as possible as soon as is safe.
If CAs have a policy that prevents them from participating in this open
process, their voices should not be considered. If they want to be
trusted by Mozilla, or to influence the process by which we decide who
gets we trust they *must* speak out in a public forum. Anything else is
just not Mozilla.
Kyle Hamilton
> -- Action #3) Confirm that multi-factor authentication is required for all
> accounts capable of directly causing certificate issuance.
>
> Question: Does this requirement in the policy need to apply to all
> certificate issuance? Or could it only apply to accounts capable of directly
> causing SSL certificate issuance?
This should apply to:
1) any account capable of causing issuance for any principal other than itself and/or its terminal (to account for auto-enrollment methods)
2) any account capable of creating enrollment records (Human Resources, administrators, etc)
3) any account capable of erasing the logs (administrator, manager)
4) any account capable of directly querying the database used by the CA and its software (dba, application)
5) any account capable of backing up or restoring the CA (administrator, backup operator)
catch-all: any account which is able to affect the way that the CA technically operates, makes trust decisions, or provides evidentiary value
I'm not worried about information disclosure from the CA, because we are looking at ways to improve the security of issuance processes, not auditing processes. (I think we need a baseline risk analysis for audits and auditors to revisit this.) Requiring auditors to have multi-factor authentication would in most circumstances also require the auditors' enrollment in the PKI they're auditing, which would cast doubt on their independence and impartiality.
There exist good (in my opinion) reasons to not mandate for the following:
1) any account capable of auditing enrollment records (corporate governance, auditor)
2) any account capable of reading the logs (administrator, manager, auditor)
3) any account capable only of requesting/causing credential issuance for itself and/or its terminal (auto-enrollment), as long as none of the Distinguished Name or subjectAltNames information is in any manner set by the account itself without at least one administrative eyeball vetting it before immortalization in a certificate.
The alternative: every certificate issuance held and evaluated by the CA's manager, who then releases the signature.
The latter is what StartCom does, from my understanding, and its effectiveness is unmatched. It is how The Attacker was prevented from issuing bad certs.
It may only be effective when it's part of the normal everyday workflow. If it were only a once-in-a-while thing, it might be much easier to subvert.
-Kyle H
Kyle Hamilton
On Wed, Oct 19, 2011 at 12:55 PM, Tom Lowenthal <t...@mozilla.com> wrote:
> Our process for deciding CA policy and inclusion is and must be public.
> Mozilla is accountable to our users, and we achieve this by making
> everything as public as possible as soon as is safe.
The fact that decisions can be made by people who have been exposed to more information than the public has -- which has always been the case -- means that apparently-valid vetos (based upon private information) will *always* be suspicious to the people who Mozilla is supposed to be accountable to.
> If CAs have a policy that prevents them from participating in this open
> process, their voices should not be considered. If they want to be
> trusted by Mozilla, or to influence the process by which we decide who
> gets we trust they *must* speak out in a public forum. Anything else is
> just not Mozilla.
-Kyle H
Benjamin T. Wilson
On Oct 19, 2011, at 3:55 PM, Tom Lowenthal <t...@mozilla.com> wrote:
> On 10/10/2011 05:17 PM, Stephen Schultze wrote:
>> On 10/10/11 6:58 PM, Kathleen Wilson wrote:
>>>> On 10/10/11 2:55 PM, Kathleen Wilson wrote:
>>>>> While adding support for our practices regarding externally-operated
>>>>> sub-CAs to Mozilla's CA Certificate Policy, I think we can also make
>>>>> some minor (less contentious) improvements such as adding the proposed
>>>>> text about technical constraints, and requiring that third-party public
>>>>> subordinate CAs and their CP/CPS/audits be publicly disclosed.
>>>>>
>>>>> However, the proposed change to require public disclosure of
>>>>> third-party
>>>>> private (or enterprise) subordinate CAs is still too contentious.
>>>>
>>>> Nobody is contending that they should not be disclosed other than you.
>>>> You are citing some backchannel conversations with CAs, but how can we
>>>> evaluate those?
>>>>
>>>
>>> Some reasons:
>>> 1) The representatives for some of these CAs have to get approval from
>>> their employer before they can post a comment in a public discussion
>>> forum.
>>> 2) The representatives of these CAs are not allowed to publicly disclose
>>> information about these customers -- it could mean loosing their jobs.
>>> 3) The representatives of these CAs don't want to get publicly singled
>>> out in this particular discussion topic.
>>
>> of the larger problem with allowing public policy decisions to be based
>> on private conversations. I suppose you can change that culture (you
>> have that power) or bow to it.
>
> Mozilla is accountable to our users, and we achieve this by making
> everything as public as possible as soon as is safe.
>
> process, their voices should not be considered. If they want to be
> trusted by Mozilla, or to influence the process by which we decide who
> gets we trust they *must* speak out in a public forum. Anything else is
> just not Mozilla.
>
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
ianG
> On Thu, Oct 6, 2011 at 4:31 PM, Kathleen Wilson
> <kathle...@yahoo.com> wrote:
>> -- Action #3) Confirm that multi-factor authentication is required
>> for all
>> accounts capable of directly causing certificate issuance.
>>
>> Question: Does this requirement in the policy need to apply to all
>> certificate issuance? Or could it only apply to accounts capable of
>> directly
>> causing SSL certificate issuance?
>
> This should apply to:
your long description shows elegantly how simply mandating dual factor
is a throwaway line of little value.
It will simply make things more complex, and will likely backfire, as it
has done in banking. This mechanism is simple: "We do what we were
told to do, therefore we do not have the liability for not doing
anything else."
[long involved suggestions, elided!]
>
> I'm not worried about information disclosure from the CA, because we
> are looking at ways to improve the security of issuance processes, not
> auditing processes. (I think we need a baseline risk analysis for
> audits and auditors to revisit this.)
BR. We'll have to do that anyway.
But, even that is hard, as shown below:
> The alternative: every certificate issuance held and evaluated by the
> CA's manager, who then releases the signature.
>
> The latter is what StartCom does, from my understanding, and its
> effectiveness is unmatched. It is how The Attacker was prevented from
> issuing bad certs.
won't help us do risk analysis. In order to deliver a policy response
at Mozilla's forum, only first class evidence should be used.
Otherwise, we'll be taking our policy from _News of the World_ articles
on 10 top tips.
iang
Tom Lowenthal
2.0)](https://www.mozilla.org/projects/security/certs/policy/) is very
clear that our processes should be public. The last line of the overall
policy reads:
> "We reserve the right to change this policy in the future. We will do
> so **only after consulting with the public Mozilla community**, in
> order to ensure that all views are taken into account."
(emphasis added). In the *Applying for Inclusion of Root Certificates in
Mozilla Products* section, point two reads:
> "We will make such decisions through a public process, based on
> objective and verifiable criteria as described below.",
and point six reads:
> "We require that all CAs whose certificates are distributed with our
> software products... publicly disclose information about their
> policies and business practices".
These points are not unique to our CA policy. The [Mozilla
Manifesto](https://www.mozilla.org/about/manifesto.en.html) makes it
clear that Mozilla is an open project. We should only ever be keeping
information secret for a short while and when it's needed to keep users
safe.
If we're not following our clearly-stated and community-agreed policy,
we need to resolve that, and sooner rather than later.
On 10/19/2011 10:39 PM, Kyle Hamilton wrote:
>
> On Wed, Oct 19, 2011 at 12:55 PM, Tom Lowenthal <t...@mozilla.com> wrote:
>> Our process for deciding CA policy and inclusion is and must be public.
>> Mozilla is accountable to our users, and we achieve this by making
>> everything as public as possible as soon as is safe.
>
> policy or inclusion discussion.
>
> The fact that decisions can be made by people who have been exposed to
> more information than the public has -- which has always been the case
> -- means that apparently-valid vetos (based upon private information)
> will *always* be suspicious to the people who Mozilla is supposed to be
> accountable to.
>
>> process, their voices should not be considered. If they want to be
>> trusted by Mozilla, or to influence the process by which we decide who
>> gets we trust they *must* speak out in a public forum. Anything else is
>> just not Mozilla.
>
ianG
> The [*Mozilla CA Certificate Policy* (Version
> 2.0)](https://www.mozilla.org/projects/security/certs/policy/) is very
> clear that our processes should be public. The last line of the overall
> policy reads:
>
>> "We reserve the right to change this policy in the future. We will do
>> so **only after consulting with the public Mozilla community**, in
>> order to ensure that all views are taken into account."
> (emphasis added).
> In the *Applying for Inclusion of Root Certificates in
> Mozilla Products* section, point two reads:
>
>> "We will make such decisions through a public process, based on
>> objective and verifiable criteria as described below.",
accept private CA representations. It was a surprise to me when I
figured it out by triangulation about a year back.
I know that certain important decisions have been made by Mozilla after
some discussion on these lists, but heavily informed by confidential CA
representations to which the users & public were not privy, and did not
know even know were being conducted. There is no review of these, no
policy, no procedure. Likely there isn't even a record.
>> and point six reads:
>>
>> "We require that all CAs whose certificates are distributed with our
>> software products... publicly disclose information about their
>> policies and business practices".
To be fair, CAs typically get audited; the simple description of
audit's review is "say what you do, do what you say."
There are enough loopholes in there to keep more than a few
off-balance-sheet accountants busy for a while. E.g., it transpires
sub-CAs and remote RAs do not necessarily get audited or documented at
all, and this has apparently been an unwritten exemption to the policy.
But, to be fair, efforts to re-define what is sufficient information are
typically doomed to failure here as this is mostly in the auditor's
court, and most efforts have shown little pizazz in improving the lot of
the users as far as disclosure goes.
>> These points are not unique to our CA policy. The [Mozilla
>> Manifesto](https://www.mozilla.org/about/manifesto.en.html) makes it
>> clear that Mozilla is an open project. We should only ever be keeping
>> information secret for a short while and when it's needed to keep users
>> safe.
wraps. Mozilla runs an invite-only in-confidence security group, and
there is a policy somewhere to reflect that. There are other policies &
practices...
>> If we're not following our clearly-stated and community-agreed policy,
>> we need to resolve that, and sooner rather than later.
iang