Gervase Markham <g...@mozilla.org> wrote:
> On 10/12/16 21:25, Brian Smith wrote:
>> Again, it doesn't make sense to say that the forms of names matter for
>> name constraints, but don't matter for end-entity certificates. If an
>> end-entity certificate doesn't contain any names of the forms dNSName,
>> iPAddress, SRVName, rfc822Name, then it shouldn't be in scope.
>
> Why would it have id-kp-serverAuth or id-kp-emailProtection and not have
> any names of those forms?

I'm more thinking of certificates that don't have an EKU extension but
do have names of those forms. Such certificates should be in scope.

Otherwise, A CA can easily issue just a certificate that is trusted
for every browser except Firefox, which is out of scope for Mozilla's
CA program. A CA might do this, for example, if Mozilla were being
more difficult than other root stores and/or the customer in question
doesn't care if the site works in Firefox or not.

>> Also, the way that the text is worded the above means that an
>> intermediate certificate that contains anyExtendedKeyUsage in its EKU
>> would be considered out of scope of Mozilla's policy. However, you
>> need to have such certificates be in scope so that you can forbid them
>> from using anyExtendedKeyUsage.
>
> Well, there are two responses to that.
>
> Firstly, no. The certs in scope are: "Intermediate certificates ...
> which are not technically constrained such that they are unable to issue
> working server or email certificates." If an intermediate certificate
> has an EKU with anyEKU, it is able to issue working server or email
> certificates. So it's in scope. (This utilises my use of "working"
> rather than "trusted", as noted in my previous email.)

What does "working" mean? If I were a CA I would interpret "working"
to mean "works in Firefox" which would then allow me to issue
certificates that violate Mozilla's CA policies by issuing them from
an intermediate that has (only) anyExtendedKeyUsage, so that they work
in every browser except Firefox and are out of scope of your policy.

> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
> trust cert chains that rely on it, so there's no need to ban it. Is there?

Again, the reason for banning anyEKU is to prevent, through policy,
CAs from using/issuing intermediate certificates that work in every
browser except Firefox, for whatever reason (most likely, to work
around a CA policy disagreement).

Cheers,
Brian
-- 
https://briansmith.org/
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to