<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix"><br>
      <br>
      On 30/6/2020 9:23 π.μ., Ryan Sleevi wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACvaWvZu4AY58KRjUmsFSmtkejbsd5pmnU_mbjvDjvK9kM-MXQ@mail.gmail.com">Equally,
      it's unfortunate that you'd wear the Chair Hat while offering your
      own personal, and unfortunately, inaccurate view of audits,
      particularly when they're so clearly dismissive of these concerns.</blockquote>
    <br>
    I tried to separate the "hats" by sending two separate emails. I
    asked several CA representatives before adding this issue in my
    response and they all confirmed that what is stated in a CP/CPS is
    audited. Therefore, I'm not sure what was inaccurate or personal.
    This is common knowledge.<br>
    <br>
    On the topics mentioned on a personal capacity, it was really hard
    to reply to your points because your responses shifted the
    discussion to other areas which were never intended in my initial
    email. Here is an attempt to respond to some of your statements.<br>
    <ul>
      <li>The burden of proof for proposed ballots has historically
        rested upon the proposer, regardless of the voting category.</li>
      <li>In this SCWG (under the CA/Browser Forum Bylaws), CAs don't
        "prefer to dictate the terms on browsers" and neither should the
        Certificate Consumers (in the SCWG case, "the Browsers").
        Browsers already "dictate" anything they choose via their Root
        programs in addition to the Baseline Requirements.</li>
      <li>Your analogy was not very accurate. A more appropriate analogy
        would be "The customer wants 2lt bottles of milk but the State
        forces giving them 1lt bottles of milk. The customer is
        frustrated, asking for the security reasons why 2-lt bottles are
        problematic, and the State is giving reasons that the customer
        doesn't understand or feels they are not adequately justified or
        founded. The customer will try to get 2-lt bottles but after
        some time, stores that want to abide by the State laws will only
        be selling 1lt bottles of milk (or risk being put
        out-of-business). If this customer went to another State,
        perhaps there would not be a ban for 2-lt bottles."</li>
      <li>I also believe it's worth pointing out that ballots
        occasionally do fail due to the way they are presented rather
        than the substance of the changes in them. This is something
        that should not happen.<br>
      </li>
    </ul>
    HARICA supports the ballot including the 398-day limit, but I fully
    understand and respect the position of other CAs which "in
    principle" don't support this to be included in the BRs. In
    practice, Browsers shouldn't need this to be included in the BRs or
    rely on audits. With Certificate Transparency, they can technically
    detect whether a certificate has been issued with validity more than
    398 days and discover a possible Root Program policy violation. So,
    from my perspective I don't understand why such extreme language is
    used, for a topic that Browsers already have full technical control
    and don't need to rely on audits or the BRs.<br>
    <br>
    HARICA also has some minor concerns about forcing revocation reasons
    for end-entity certificates without good rules and common
    expectations, which is what standards are trying to achieve. Rushing
    this requirement in will possibly create confusion. We believe a
    more focused discussion on the end-entity revocation reasons is
    necessary to better explain the expectations, corner cases and find
    common interpretations on the existing X.509 descriptions. Things
    seem to be more "mature" on the keyCompromise revocation reason and
    perhaps we could use this as a first step and prepare rules and
    expectations for that (e.g. if a Certificate is marked as
    keyCompromise, any other non-expired, non-revoked Certificate that
    uses the same associated Public Key that the CA has issued, must
    also be revoked with the same reason).<br>
    <br>
    <br>
    Dimitris.<br>
  </body>
</html>