On 5/6/14, 12:58 PM, Brian Smith wrote:
> On Mon, May 5, 2014 at 4:45 PM, Kathleen Wilson <[email protected]>
wrote:
>
> OK. Changed to the following.
>
>
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> --
> 1. For all new intermediate certificate issuance, use the "TLS
> Web Server Authentication (1.3.6.1.5.5.7.3.1)" (serverAuth) EKU if
> that intermediate certificate will be signing SSL certificates.
> Mozilla will stop recognizing the "Netscape Server Gated Crypto
> (2.16.840.1.113730.4.1)" EKU.
>
> That isn't quite right either. It is OK for the intermediate
> certificate to omit the EKU extension entirely. But, if an
> intermediate does include an EKU extension then it must include id-kp-
> serverAuth (1.3.6.1.5.5.7.3.1).
OK. I'll make that more clear.
> Additionally, no certificates should contain the Netscape Server
> Gated Crypto (2.16.840.1.113730.4.1) EKU, which is already no longer
> recognized for end-entity certificates and which will be no longer
> supported for intermediate certificates soon.
So, I need to add that the SGC EKU is not recognized in end-entity certs?
Is that new in mozilla::pkix?
Does it matter if the certs have the Netscape SGC?
We'll just ignore it, right?
> New externally-operated subordinate CA certificates should/must
> include an EKU extension that does NOT contain id-kp-serverAuth
> (1.3.6.1.5.5.7.3.1) or anyExtendedKeyPurpose (2.5.29.37.0) if the
> subordinate CA is not authorized to issue TLS server certificates.
That is required for technically-constrained intermediates.
But item #10 of
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
allows for non-technically-constrained intermediates that are publicly
disclosed and audited -- those would be intermediate certs without an
EKU extension. Correct?
> Conversely, new externally-operated subordinate CA certificates
> should/must include an EKU extension with id-kp-serverAuth
> (1.3.6.1.5.5.7.3.1) if they are allowed to issue TLS certificates.
Again, that applies to technically-constrained intermediates. But item
#10 of Mozilla's CA Inclusion Policy allows for
non-technically-constrained intermediates that are publicly disclosed
and audited -- intermediate certs without an EKU extension.
> Remember that we added the new enforcement of EKU in intermediates in
> mozilla::pkix in order to enhance the ability of CAs to technically
> constrain externally-operated sub-CAs.
Yes. If an EKU extension is included in the intermediate cert, then the
specified usages should be enforced down the chain, meaning that only
the specified usages will be allowed. However, Mozilla only recognizes
id-kp-serverAuth, id-kp-emailProtection, and id-kp-codeSigning. All
other EKUs are simply ignored. Correct?
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
