Announcing Version 2.1 of Mozilla's CA Certificate Policy

[Kathleen Wilson]

Announcement:
https://blog.mozilla.org/security/2013/02/15/announcing-version-2-1-of-mozilla-ca-certificate-policy/

Mozilla CA Certificate Policy Version 2.1:
http://www.mozilla.org/projects/security/certs/policy/

About the new version:
https://wiki.mozilla.org/CA:CertificatePolicyV2.1


Thanks again to all of you for your input and contributions to this new
version!

Kathleen

[Erwann Abalea]

That's an old thread, I know.

Talking about technically constrained subordinate CAs, when has the constraint about domains used in email addresses been removed?
In draft versions, it was required that the domains be set as rfc822Name in the permittedSubTrees field of the NC extension. On the published one, there's no technical constraint of that kind.

Can't Thunderbird enforce such a constraint? Is it useless? Is there any reason I missed for that constraint to have been deleted?

[Kathleen Wilson]

On 4/3/13 9:18 AM, Erwann Abalea wrote:
> That's an old thread, I know.
>
> Talking about technically constrained subordinate CAs, when has the constraint about domains used in email addresses been removed?
> In draft versions, it was required that the domains be set as rfc822Name in the permittedSubTrees field of the NC extension. On the published one, there's no technical constraint of that kind.
>
> Can't Thunderbird enforce such a constraint? Is it useless? Is there any reason I missed for that constraint to have been deleted?
>

> Le samedi 16 f�vrier 2013 01:55:13 UTC+1, Kathleen Wilson a �crit :

>> Announcement:
>> https://blog.mozilla.org/security/2013/02/15/announcing-version-2-1-of-mozilla-ca-certificate-policy/
>>
>> Mozilla CA Certificate Policy Version 2.1:
>> http://www.mozilla.org/projects/security/certs/policy/
>>
>> About the new version:
>> https://wiki.mozilla.org/CA:CertificatePolicyV2.1

To see change history of the drafts...
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
then select "Last modified..." at bottom of page.

http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html?revision=109374&view=markup
(Sep 24, 2012)
<li>
252 If certificates chaining up to a technically constrained subordinate
253 CA certificate may be used for email protection, then the EKU of the
254 subordinate CA's intermediate certificate(s) must include
id-kp-emailProtection. Additionally, the
255 subordinate CA's intermediate certificate(s) must also include
256 X.509 rfc822Name Name Constraints,
257 and the Name Constraints must only permit email
258 addresses or mailboxes for which the CA has confirmed that the
subordinate CA is authorized to use.
259 </li>



http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html?revision=110096&view=markup
(Oct 18, 2012)
<li>
249 If the certificate includes the id-kp-emailProtection extended key
usage, then all
250 end-entity certificates MUST only include e-mail addresses or
mailboxes that the
251 issuing CA has confirmed (via technical and/or business controls)
that the
252 subordinate CA is authorized to use.
253 </li>



I don't recall the details, but I remember that some CAs need to use
business controls to constrain the email addresses to be used in S/MIME
certs, because the technical control (e.g. name constraints in the
subCA) was not feasible/reasonable for large enterprise customers.

I think we also discussed that the amount of damage that someone can do
with a mis-issued email cert is significantly less than the amount of
damage that someone can do with a mis-issued ssl cert. So the
cost/benefit analysis resulted in it being OK to use business controls
for email certs.

Kathleen

[Rob Stradling]

On 04/04/13 02:25, Kathleen Wilson wrote:
> On 4/3/13 9:18 AM, Erwann Abalea wrote:

>> That's an old thread, I know.
>>
>> Talking about technically constrained subordinate CAs, when has the
>> constraint about domains used in email addresses been removed?
>> In draft versions, it was required that the domains be set as
>> rfc822Name in the permittedSubTrees field of the NC extension. On the
>> published one, there's no technical constraint of that kind.
>>
>> Can't Thunderbird enforce such a constraint? Is it useless? Is there
>> any reason I missed for that constraint to have been deleted?

<snip>

> I don't recall the details, but I remember that some CAs need to use
> business controls to constrain the email addresses to be used in S/MIME
> certs, because the technical control (e.g. name constraints in the
> subCA) was not feasible/reasonable for large enterprise customers.

Hi Erwann. FYI, here's the thread where this issue was discussed:

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/l1BAEHjKe8Q

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Erwann Abalea]

Thanks to both of you.

The thread switched to update mechanism, timeframe, and CT support, and I missed the interesting part (I'm not saying the other topics aren't interesting, not at all).

Am I right in my understanding:
- it's not easy to technically constrain a subordinate CA which will issue email certificates to business partners, and the cost of such constraints isn't balanced by an equivalent benefit (I'm talking about risk, not money)
- code to verify the technical constraints will be added to Firefox and Thunderbird first, then migrated to NSS when successful
- there's much more pressure (more risk) on TLS certs, so this use-case has been prefered

[Kathleen Wilson]

On 4/4/13 3:19 AM, Erwann Abalea wrote:
> Le jeudi 4 avril 2013 11:29:22 UTC+2, Rob Stradling a �crit :

>> On 04/04/13 02:25, Kathleen Wilson wrote:
>>> On 4/3/13 9:18 AM, Erwann Abalea wrote:
>>>> That's an old thread, I know.
>>>>
>>>> Talking about technically constrained subordinate CAs, when has the
>>>> constraint about domains used in email addresses been removed?
>>>> In draft versions, it was required that the domains be set as
>>>> rfc822Name in the permittedSubTrees field of the NC extension. On the
>>>> published one, there's no technical constraint of that kind.
>>>>
>>>> Can't Thunderbird enforce such a constraint? Is it useless? Is there
>>>> any reason I missed for that constraint to have been deleted?
>> <snip>
>>
>>> I don't recall the details, but I remember that some CAs need to use
>>> business controls to constrain the email addresses to be used in S/MIME
>>> certs, because the technical control (e.g. name constraints in the
>>> subCA) was not feasible/reasonable for large enterprise customers.
>>
>> Hi Erwann. FYI, here's the thread where this issue was discussed:
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/l1BAEHjKe8Q
>
> Thanks to both of you.
>
> The thread switched to update mechanism, timeframe, and CT support, and I missed the interesting part (I'm not saying the other topics aren't interesting, not at all).
>
> Am I right in my understanding:
> - it's not easy to technically constrain a subordinate CA
> which will issue email certificates to business partners, and the
> cost of such constraints isn't balanced by an equivalent benefit
> (I'm talking about risk, not money)

That is my understanding too.

> - code to verify the technical constraints will be added to
> Firefox and Thunderbird first, then migrated to NSS when successful

Actually, the code to verify the technical constraints will be (or is
already) in NSS, which is used by Mozilla products.

NSS already supports Name Constraints in intermediate certs.

My understanding is that NSS already supports the use of EKU in
intermediate certs too, but test cases may need to be added.
https://bugzilla.mozilla.org/show_bug.cgi?id=725351#c2

> - there's much more pressure (more risk) on TLS certs, so this
> use-case has been prefered

Well, that is the way my work is prioritized.


Kathleen