<div dir="ltr">Sure, I have no objection to incorporating it into the profiles ballot.<div><br></div><div>I admit I haven't looked carefully at the whole profiles ballot myself yet, and I'm slightly trepidatious that getting it passed will be a protracted process, but this change definitely falls within its purview. I'm happy to go either way on this one!</div><div><br></div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 14, 2022 at 10:32 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Hi Aaron,</span>
    <br>
    <br>
    <span dir="ltr" style="margin-top:0px;margin-bottom:0px">If there are
      no objections from others, would it be ok if we add this proposal
      to the upcoming profiles ballot which will be discussed at the
      F2F, and merge your PR in the profiles branch? I would just set
      the date to whatever effective date we decide, other than Jan 1 :)</span>
    <br>
    <br>
    <span dir="ltr" style="margin-top:0px;margin-bottom:0px">The change
      seems rather uncontroversial. I'd be willing to endorse a separate
      ballot if the group decides not to include it in the profiles
      ballot.</span> <br>
    <br>
    <br>
    <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Thanks,</span>
    <br>
    <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Dimitris.<br>
      <br>
      <br>
    </span><br>
    <br>
    <div>On 14/10/2022 8:04 μ.μ., Aaron Gable
      via Servercert-wg wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi all,
        <div><br>
        </div>
        <div>Based on a long discussion[1] on MDSP, I've come to the
          conclusion that it would be good for the BRs to specifically
          mandate that sharded/partitioned CRLs include the Issuing
          Distribution Point extension and its distributionPoint field.
          This is both because the field is important to defend against
          replacement attacks, and because RFC 5280's language seems to
          actually say something different and has led to a long
          discussion on interpretation.</div>
        <div><br>
        </div>
        <div>To this end, I would like to propose a ballot to include
          explicit language to this effect in the BRs:</div>
        <div><br>
        </div>
        <div><a href="https://github.com/cabforum/servercert/pull/396" target="_blank">https://github.com/cabforum/servercert/pull/396</a><br>
        </div>
        <div><br>
        </div>
        <div>Clint Wilson at Mozilla has kindly agreed to endorse; I'm
          seeking a second endorser (and any thoughts and opinions on
          the ballot text itself, of course!) so that it can be assigned
          a ballot number and officially open the discussion period.</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Aaron</div>
        <div><br>
        </div>
        <div>[1] <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU" target="_blank">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU</a></div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Servercert-wg mailing list
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div>