On 5/20/14, 11:08 AM, Kathleen Wilson wrote:
On 5/19/14, 9:40 AM, Rick Andrews wrote:
> Kathleen, that means we'll be disclosing a number of intermediates
> used to sign certificates that are not used for SSL, Code Signing or
> Mail (the three trust bits that Firefox lets me view/edit). For
> example, we issue a lot of client auth certs from our public roots.
>
> Based on your previous comments, I assume you expect those to be
> disclosed too, even though Mozilla products likely will never
> encounter them, or work with them if encountered. Please confirm.
I'm only interested in the intermediate certs that can be used to issue
certs for SSL, Code Signing, or Mail (the three trust bits that are set
in NSS).
Kathleen
To be clear, I agree with what Ryan said:
"Are these subordinate CAs technically constrained, according to the
terms of Mozilla's CA Certificate Policy? It sounds like they aren't.
That means that they are technically capable of issuing SSL
certificates, and that such certificates MAY be accepted as valid SSL
certificates within Mozilla products. If so, it does seem that they
should be disclosed."
My preference is that you use the EKU as described in section 9 of
Mozilla's CA Certificate Inclusion policy, so that you wouldn't need to
disclose them. So, for client auth, the intermediate cert would have an
EKU extension that does not include id-kp-serverAuth. Then it wouldn't
need to be disclosed.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
