Doesn't RFC 5280 clearly indicate that already, through its normative description of the EKU?
That is, I can understand there being confusion or misinterpretation, but I'm not sure that the problem itself is rooted in the documents, and thus, may not be something the documents need to address. :) On Fri, Aug 18, 2017 at 10:49 AM, Jeremy Rowley <[email protected]> wrote: > I don't (as these are the exact type of cert I've been trying to kill for > years), but Identrust did based on their response. Looking at it from their > POV, the language could probably be clarified to state thar any cert with > no equipment, sever Auth, or anyEKU is considered a BR cert regardless of > other content. > > On Aug 18, 2017, at 8:26 AM, Ryan Sleevi vb<[email protected]> wrote: > > Do you believe https://github.com/mozilla/pkipolicy/blob/master/ > rootstore/policy.md#11-scope is ambiguous in this context? That is what > is referenced in the text. > > It sounds as if you're suggesting they're in scope, via 1.1, but that > they're out of scope, because the policy does not state that (id-kp-anyEKU > || id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU || > id-kp-emailProtection) are email certificates, even though this would > logically flow (from RFC 5280 https://tools.ietf.org/ > html/rfc5280#section-4.2.1.12) stating that anyEKU places no restrictions > on the subject key as to its purpose. Is that correct? > > On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy < > [email protected]> wrote: > >> Right, but can you call these SSL certs without an FQDN? >> >> >> * Insofar as the Baseline Requirements attempt to define their own >> scope, the scope of this policy (section 1.1) overrides that. Mozilla thus >> requires CA operations relating to issuance of all SSL certificates in the >> scope of this policy to conform to the Baseline Requirements. >> >> Is SSL certificate defined? >> >> On Aug 18, 2017, at 7:33 AM, Gervase Markham <[email protected]<mailto: >> [email protected]>> wrote: >> >> On 17/08/17 20:31, Jeremy Rowley wrote: >> Without an FQDN, I doubt they are in scope for the baseline requirements. >> >> Not according to the BRs themselves. However, the Mozilla Policy 2.5 >> specifically says: >> >> "Insofar as the Baseline Requirements attempt to define their own scope, >> the scope of this policy (section 1.1) overrides that. Mozilla thus >> requires CA operations relating to issuance of all SSL certificates in >> the scope of this policy to conform to the Baseline Requirements." >> >> Now, whether we are right to include anyEKU in scope, given that it >> pulls in certs such as those in question, is still something I am unsure >> about :-) But the current policy says what it says. >> >> They are in scope for the Mozilla policy. The BRs require the cert to >> be intended for web tls. These are not. >> >> But the Mozilla Policy re-scopes the BRs to remove the ambiguous >> language about "intent". >> >> The Mozilla policy covers client certs as well as tls. >> >> Er, no it doesn't (except insofar as we make anyEKU in scope)? Our >> policy covers server certs and email certs. >> >> Gerv >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
