<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"Segoe Script";
panose-1:3 11 5 4 2 0 0 0 0 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>> Seems there may still be a residual small risk if a new CRL shard is started before CCADB is updated any certificate that should be covered in that new shard gets revoked prior to the CCADB update. But maybe people perceive that timing issue as too small to be a concern.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I agree this is a risk and I think this is an area that should be clarified, especially since the CCADB and Root Program policies are silent on the order in which new sharded CRLs can be populated with entries and when those new shards need to be disclosed, or the relevant time frame in which such updates must occur. Hopefully CAs are updating CCADB with new CRL shard URIs prior to populating them with entries but clarifying this would eliminate any risk from certificate revocations not being processed due to those shards not being timely disclosed in CCADB.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> <b>On Behalf Of </b>Wendy Brown - QT3LB-C via Servercert-wg<br><b>Sent:</b> Friday, October 14, 2022 3:58 PM<br><b>To:</b> Aaron Gable <aaron@letsencrypt.org><br><b>Cc:</b> CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Subject:</b> Re: [Servercert-wg] Ballot proposal: require distributionPoint in sharded CRLs<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>So just to be clear, this change proposal is only trying to address the ability of a browser relying on CRL disclosures in CCADB to be able to ensure they have the complete set of CRLs disclosed there, not to address the potential risk to any given revoked certificate not being seen as revoked because the RP is looking at a CRL that does not have that certificate in scope due to sharding?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Seems there may still be a residual small risk if a new CRL shard is started before CCADB is updated any certificate that should be covered in that new shard gets revoked prior to the CCADB update. But maybe people perceive that timing issue as too small to be a concern.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>thanks,<br clear=all><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Segoe Script"'>Wendy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Wendy Brown<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Supporting GSA<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FPKIMA Technical Liaison<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Protiviti Government Services<o:p></o:p></p><p class=MsoNormal>703-965-2990 (cell)<o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Oct 14, 2022 at 3:48 PM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>On Fri, Oct 14, 2022 at 12:34 PM Wendy Brown - QT3LB-C <<a href="mailto:wendy.brown@gsa.gov" target="_blank">wendy.brown@gsa.gov</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal>Just a question - <o:p></o:p></p><div><p class=MsoNormal>if a certificate that is being checked for revocation does not contain a cDP, how will requiring iDP in the CRL assist in preventing a CRL substitution attack? If you don't have the correct cDP for a given certificate how will the iDP in that sharded CRL provide assurance that the RP is looking at the correct CRL?<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In the case of the CRLs disclosed in CCADB's JSON Array of Partitioned CRLs field, the relying party (e.g. Mozilla or Apple) can verify that the distributionPoint contained within the CRL matches the URL disclosed in CCADB.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>On Fri, Oct 14, 2022 at 11:14 AM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I don’t believe the profiles ballot modifies section 7.2 at all, so there should be no conflict in having a separate proposal.<o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The current profiles ballot lightly modifies Section 7.2.1 (<a href="https://github.com/cabforum/servercert/pull/373/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR3118" target="_blank">https://github.com/cabforum/servercert/pull/373/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR3118</a>), but not in a way that would lead to a merge conflict with this ballot.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron <o:p></o:p></p></div></div></div></div></blockquote></div></div></body></html>