Draft 2.1 of Mozilla CA Cert Policy

[Kathleen Wilson]

All,

Here is a summary of the changes that are currently proposed for version
2.1 of Mozilla’s CA Certificate Policy. Please refer to the links below
for full context.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

-- In item #4 delete “, DSA certificates with 2048-bit primes, or”

-- In item #6, add to bullet points:
“- enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance;
- maintain a certificate hierarchy such that the included certificate
signs intermediate certificates for the issuance of end-entity
certificates to customers;”

-- Delete item #8, because it is redundant with the CA/Browser Forum BR
#11.1

-- Add new item #9 to state that externally-operated subCAs must be
technically controlled or audited/disclosed.

-- Add new item #10: “When an external third party verifies certificate
subscriber information on behalf of the CA, the CA must perform
appropriate additional due diligence, including at least domain name
verification, before the CA may issue the certificate.”

-- Add new item #12: “CA operations and issuance of certificates to be
used for SSL-enabled servers must also conform to the current version of
the CA/Browser Forum Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates. In the event of
inconsistency between Mozilla's CA Certificate Policy requirements and
the Baseline Requirements, Mozilla's CA Certificate Policy takes
precedence.”

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html

-- No changes

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html

-- Minor changes to add clarification to items #2 and #3 (see the red text).


Let’s have one more round of discussion about these changes, and then I
plan to create the bug to summarize the changes that we are proposing
for this update.
https://wiki.mozilla.org/CA:CertPolicyUpdates#Process_for_Updating_the_Policy

I will appreciate thoughtful and constructive input into this discussion.

Kathleen

[Kathleen Wilson]

>
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

>
> -- Add new item #9 to state that externally-operated subCAs must be
> technically controlled or audited/disclosed.

Here’s the currently proposed text for the new item #9 of the Inclusion
Policy…
--
“9. The CA must do one of the following for each external third party
that issues certificates. (Any external third party that can directly
cause the issuance of a certificate must be treated as a subordinate CA,
meeting one of the following two requirements.)

- Implement technical controls to restrict the subordinate CA to
only issue certificates within a specific set of domain names which the
CA has confirmed that the subordinate CA has registered or has been
authorized by the domain registrant to act on the registrant's behalf.
Such technical controls must be documented in the CA's Certificate
Policy or Certification Practice Statement, and reviewed by a competent
independent party as part of the CA's annual audit. Acceptable technical
controls include but are not limited to X.509 dNSName Name Constraints
as specified in RFC 5280, which are marked as critical.

- Publicly disclose the subordinate CA along with the subordinate
CA's corresponding Certificate Policy and/or Certification Practice
Statement and provide public attestation of the subordinate CA's
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. The
subordinate CA's verification requirements and operational criteria must
satisfy the requirements of the Mozilla CA Certificate Policy. The CA's
Certificate Policy or Certification Practice Statement must indicate
where the list of publicly disclosed subordinate CAs may be found on the
CA's website.”
--

Mozilla’s CA Certificate Policy applies to certificates that are used
for SSL/TLS, S/MIME, and Code Signing, as per the trust bits that can be
set.

Should this new requirement apply only to externally-operated subCAs
that can issue certificates to be used for SSL-enabled servers?

If yes…
- Should we tighten the statement about what technical controls can be
used?
E.g. Can the technical controls be anything other than name constraints?
- What about externally-operated subCAs that can issue certs for S/MIME
and Code Signing? Do we address them by adding a separate line item to
the policy? Or do we postpone that for a later policy update?

If no…
- Does the statement about technical controls appropriately apply to
externally-operated subCAs that can issue S/MIME and Code Signing
certificates?
- What technical controls would be sufficient regarding issuance of
S/MIME and Code Signing certificates? e.g. Have some sort of technical
constraint in place to make sure that those subCAs cannot sign SSL
certificates? Make sure that they can only issue S/MIME certs containing
email address within a certain domain?

Kathleen

[Stephen Schultze]

On 3/1/12 4:44 PM, Kathleen Wilson wrote:
> Mozilla’s CA Certificate Policy applies to certificates that are used
> for SSL/TLS, S/MIME, and Code Signing, as per the trust bits that can be
> set.
>
> Should this new requirement apply only to externally-operated subCAs
> that can issue certificates to be used for SSL-enabled servers?

No.

> If yes…
> - Should we tighten the statement about what technical controls can be
> used?
> E.g. Can the technical controls be anything other than name constraints?
> - What about externally-operated subCAs that can issue certs for S/MIME
> and Code Signing? Do we address them by adding a separate line item to
> the policy? Or do we postpone that for a later policy update?
>
> If no…
> - Does the statement about technical controls appropriately apply to
> externally-operated subCAs that can issue S/MIME and Code Signing
> certificates?
> - What technical controls would be sufficient regarding issuance of
> S/MIME and Code Signing certificates? e.g. Have some sort of technical
> constraint in place to make sure that those subCAs cannot sign SSL
> certificates? Make sure that they can only issue S/MIME certs containing
> email address within a certain domain?

I see no reason why to not close this loophole for all types of certs.
Is there some reason why name constraints wouldn't work for S/MIME and
Code Signing certs? Is there something fundamentally different about
their usage that prohibits this?

In any case, I think that #9 should explicitly limit the eligible
technical controls to name constraints (marked as critical) unless
otherwise explicitly approved after public review.

[Sid Stamm]

On 03/01/2012 01:54 PM, Stephen Schultze wrote:
>> If no…
>> - Does the statement about technical controls appropriately apply to
>> externally-operated subCAs that can issue S/MIME and Code Signing
>> certificates?
>> - What technical controls would be sufficient regarding issuance of
>> S/MIME and Code Signing certificates? e.g. Have some sort of technical
>> constraint in place to make sure that those subCAs cannot sign SSL
>> certificates? Make sure that they can only issue S/MIME certs containing
>> email address within a certain domain?
>
> I see no reason why to not close this loophole for all types of certs.
> Is there some reason why name constraints wouldn't work for S/MIME and
> Code Signing certs?

I don't understand how name constraints would work on code signing
certs. I can see how *maybe* that would work for S/MIME, but I'm not
sure I understand that well enough to say some global statement like
"name constraints will work for all types of trust".

-Sid

[Stephen Schultze]

Ah yes, good point. I forgot that Code Signing Certs don't validate a
particular domain (incidentally, the FF UI for them doesn't let you look
at the cert contents when, for example, you are installing a signed
Firefox extension -- leading to very little benefit to signing them --
but that's a topic for another day).

I too don't know S/MIME well enough to know exactly how domain
constraints apply. I care most about SSL, so if folks think that it
only makes sense for that, that's fine from my perspective.

I do think that limiting the acceptable technical constraints for SSL
certs to critical domain constraints (unless explicitly approved after
public review) makes sense.

[Eddy Nigg]

On 05/22/2012 07:27 PM, From Ben Wilson:
> Kathleen,
> On the Draft 2.1 inclusion policy, section 6's "multi-factor authentication"
> requirement ought to consider the situation where there is a technically
> constrained enterprise RA similar to the approach for technically constrained
> CAs in section 9. Could the third bullet of section 6 be revised so that it
> reads, "* enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance or implement technical controls that
> restrict certificate issuance through the account to a limited set of
> pre-approved domain names" or something to that effect?

Which might affect also any issuance procedure of CAs that issue
certificates on-the-fly of subscriber accounts that validated a
domain(s), if I read that correctly? E.g. any certificate that isn't
issued through an action by the CA should have a multi-factor
authentication in place?

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Eddy Nigg]

On 05/22/2012 08:39 PM, From Ben Wilson:
> Just so that I make sure I understand the first part of your sentence
> ("issuance procedure of CAs that issue certificates on-the-fly of subscriber
> accounts that validated a domain(s)")--you are referring to a subscriber
> account for a validated domain. But the second part I think depends on what
> is meant by "issued through an action by the CA," so I'm not sure what you
> are implying.

I thought that an account of a subscriber can cause the issuance of a
certificate without the intervention of the CA (as opposed to the
subscriber submits the request and the CA issues it manually after a
review), then a multi-factor authentication should be in place.

> So, while multi-factor authentication might be advisable for a large
> enterprise managing certificates within its own domain namespace, it should
> not be required, because the risk is technically controlled by domain name
> restrictions.

If the controls are naming constraints I think that's fair - the risk
would be mostly that of the entity. On the other hand, if that entity is
Google, not sure if reducing the requirement would be a good thing.

[Kathleen Wilson]

On 5/22/12 10:51 AM, Eddy Nigg wrote:
> On 05/22/2012 08:39 PM, From Ben Wilson:
>> Just so that I make sure I understand the first part of your sentence
>> ("issuance procedure of CAs that issue certificates on-the-fly of
>> subscriber
>> accounts that validated a domain(s)")--you are referring to a subscriber
>> account for a validated domain. But the second part I think depends on
>> what
>> is meant by "issued through an action by the CA," so I'm not sure what
>> you
>> are implying.
>
> I thought that an account of a subscriber can cause the issuance of a
> certificate without the intervention of the CA (as opposed to the
> subscriber submits the request and the CA issues it manually after a
> review), then a multi-factor authentication should be in place.
>
>> So, while multi-factor authentication might be advisable for a large
>> enterprise managing certificates within its own domain namespace, it
>> should
>> not be required, because the risk is technically controlled by domain
>> name
>> restrictions.
>
> If the controls are naming constraints I think that's fair - the risk
> would be mostly that of the entity. On the other hand, if that entity is
> Google, not sure if reducing the requirement would be a good thing.
>

Just to be clear, this requirement applies to CA accounts, RA accounts,
subCA accounts, etc... Any time a person can authenticate into an
interface and directly cause the issuance of a certificate.

I think it is OK to add text to allow for an account to not require
multi-factor auth if there are technical controls that are implemented
and run by the CA to restrict the account to only issue certs for
pre-approved domains.

I'm not sure how to phrase it. How about...

"* enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance or implement technical controls
operated by the CA to restrict certificate issuance through the account
to a limited set of pre-approved domain names."


Kathleen

[Kathleen Wilson]

In regards to item #6 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Bullet #3 currently says:
"enforce multi-factor authentication for all accounts capable of

directly causing certificate issuance;"

>
> I think it is OK to add text to allow for an account to not require
> multi-factor auth if there are technical controls that are implemented
> and run by the CA to restrict the account to only issue certs for
> pre-approved domains.
>

Are there any concerns about changing the text to:

"* enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance or implement technical controls
operated by the CA to restrict certificate issuance through the account

to a limited set of pre-approved domains or email addresses."


Kathleen

[ianG]

On 30/05/12 03:07 AM, Kathleen Wilson wrote:
> In regards to item #6 in
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
>
> Bullet #3 currently says:

> "enforce multi-factor authentication for all accounts capable of

> directly causing certificate issuance;"

>
>>
>> I think it is OK to add text to allow for an account to not require
>> multi-factor auth if there are technical controls that are implemented
>> and run by the CA to restrict the account to only issue certs for
>> pre-approved domains.
>>
>
>

> Are there any concerns about changing the text to:
>

> "* enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance or implement technical controls
> operated by the CA to restrict certificate issuance through the account

> to a limited set of pre-approved domains or email addresses."


The experience with US-style mandated multi-factor authentication is not
good. Two examples: some banks issue multiple passwords and claim that
is multi-factor. Who's to say? Secondly, many operators just sit back
into compliance mode and implement what they are told to do. Dusted,
done. Then they get hacked. And they turn around and say "we're
compliant, we did all we were told to do, no liability." The more you
tell them to do, the more you take on the liability.

Also, the above sentence is dancing around trying to make a perfect
statement when none is possible. My view of what we want to say is more
like this:

" * All accounts capable of directly causing certificate issuance must
be protected to a high level, appropriate to the liability the issuer
and the account operator take on to protect all users. Methods include
multi-factor controls, restricted issuance and pre-approved lists.
However this section does not mandate any particular protections because
of the dynamic threat environment and the dangers of compliance-thinking
a.k.a. moral hazard. "


Just my quick thoughts, noted that agreement is unlikely :)

iang