<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Maybe not. I'm only aware of the Mozilla communities.  I sent one a
    PM asking them to chime in if there is a problem for their
    community.  They probably won't chime in but this gives awareness in
    what's going on. <br>
    <br>
    Where do you get that the items mentioned violate Mozilla's policy? 
    Mozilla expressly excluded the auditor requirements from the BRs,
    don't have a policy for key ceremonies, and  permit either CRLs or
    OCSP (while the BRs require both for intermediates). No violation if
    you weren't intending to issue SSL.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/13/2014 2:34 PM, Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACvaWvaVV045oxnKsgB_pDs9X0hwJMJtRPXyUH9fm=zwkJ1G0g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p dir="ltr"><br>
        On Nov 13, 2014 11:28 AM, "Jeremy Rowley" <<a
          moz-do-not-send="true"
          href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>
        wrote:<br>
        ><br>
        > That page was updated in October 2014. I don’t think we can
        imply knowledge to all communities who might have existed before
        then.  <br>
        ><br>
        >  </p>
      <p dir="ltr">Sure, but isn't that the point - Mozilla makes its
        decisions in the interest of its user community, and if you're
        forking the trust list from Mozilla (which is what it is), you
        should follow the fork.</p>
      <p dir="ltr">Again, I don't think this is something relevant to
        the discussion at hand or the Forum at large. If it was, why
        aren't we talking about communities who MIGHT have forked
        authroots.ctl or copied the roots from the Security.keychain
        services?</p>
      <p dir="ltr">If Mozilla requires all CAs in their program follow
        their policies, and if a CA can't follow Mozilla's policies
        (which currently go above and beyond the BRs), then that isn't a
        Forum issue - it is for Mozilla and those CAs to work out.</p>
      <p dir="ltr">><br>
        > I also don’t think the audit itself is a concern.  However,
        the requirements on key generation under Section 17.7 might not
        have been followed, the intermediate might not have CRLs or OCSP
        (depending on the community), and auditor qualifications might
        be bigger problems.<br>
        ></p>
      <p dir="ltr">And then they're in violation of Mozilla's inclusion
        policies already. Which is a matter for Mozilla to take up, but
        suggests they're already in trouble independent of the Forum
        requiring the same.</p>
      <p dir="ltr">>  <br>
        ><br>
        > From: Ryan Sleevi [mailto:<a moz-do-not-send="true"
          href="mailto:sleevi@google.com">sleevi@google.com</a>] <br>
        > Sent: Thursday, November 13, 2014 2:18 PM<br>
        > To: Jeremy Rowley<br>
        > Cc: Moudrick M. Dadashov; CABFPub<br>
        ><br>
        > Subject: Re: [cabfpub] (Eventually) requiring
        id-kpServerAuth for all certs in the chain?<br>
        ><br>
        >  <br>
        ><br>
        >  <br>
        ><br>
        > On Thu, Nov 13, 2014 at 1:13 PM, Jeremy Rowley <<a
          moz-do-not-send="true"
          href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>
        wrote:<br>
        ><br>
        > One other thought is that a lot of groups use NSS as their
        basis for a trust store.  Impairing all the communities relying
        on that trust store might negatively impact the usefulness of
        NSS, meaning the issue is not as simple as using a single CA for
        multiple purposes v. creating forum rules.<br>
        ><br>
        >  <br>
        ><br>
        > Can you please clarify what you mean by "impairing"? If
        you're using the Mozilla Trust Store to make decisions outside
        of the Mozilla purview. That is, it has three trust bits, only
        one of which has an audit requirement - namely, the Website bit
        requires BR AND Mozilla Policy compliance. The Mozilla Policy
        compliance ALREADY requires (effectively) that all certificates
        (transitively) be BR compliant. So if there is an
        incompatibility in schemes, these users are already "impaired"<br>
        ><br>
        >  <br>
        ><br>
        > And Mozilla's made it clear the risks these groups run if
        they're using the NSS trust store outside of NSS - <a
          moz-do-not-send="true"
href="https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F">https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F</a>
        - so I don't think that's a consideration the Forum should
        engage in, as Mozilla's already explicitly disclaimed it.</p>
    </blockquote>
    <br>
  </body>
</html>