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<r...@sleevi.com<mailto:r...@sleevi.com>> 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 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 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 
<g...@mozilla.org<mailto:g...@mozilla.org><mailto:g...@mozilla.org<mailto:g...@mozilla.org>>>
 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
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
              • Re:... Jonathan Rudenberg via dev-security-policy
              • Re:... identrust--- via dev-security-policy
              • Re:... identrust--- via dev-security-policy
              • Re:... Jonathan Rudenberg via dev-security-policy
              • Re:... identrust--- via dev-security-policy
              • Re:... identrust--- via dev-security-policy
              • Re:... Jeremy Rowley via dev-security-policy
              • Re:... Gervase Markham via dev-security-policy
              • Re:... Jeremy Rowley via dev-security-policy
              • Re:... Ryan Sleevi via dev-security-policy
              • Re:... Jeremy Rowley via dev-security-policy
              • Re:... Ryan Sleevi via dev-security-policy
              • Re:... identrust--- via dev-security-policy
      • Re: Certificates iss... identrust--- via dev-security-policy
  • Re: Certificates issued with ... identrust--- via dev-security-policy
  • Re: Certificates issued with ... branden.dickerson--- via dev-security-policy

Reply via email to