<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.line874, li.line874, div.line874
{mso-style-name:line874;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
p.line862, li.line862, div.line862
{mso-style-name:line862;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.anchor
{mso-style-name:anchor;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:255674190;
mso-list-template-ids:-1778465032;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:405807697;
mso-list-template-ids:1378280698;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1429080230;
mso-list-template-ids:275538122;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3
{mso-list-id:1568297454;
mso-list-template-ids:-817180982;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I like your point about making a customer’s permission to bypass CAA for their service public, such as with name constraints. CAs can communicate customer-initiated CAA bypass with a dedicated CP OID in the end entity certs. Customer request passes through to browser visibility.</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'> Jeremy Rowley [mailto:jeremy.rowley@digicert.com] <br><b>Sent:</b> Thursday, November 10, 2016 1:23 PM<br><b>To:</b> Steve Medin <Steve_Medin@symantec.com>; CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Subject:</b> RE: [cabfpub] Draft CAA motion (2)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>Except that a key ceremony results in a VERY public result while a contact typically does not. With a technically constrained CA, the browsers can view that the technically constrained CA exists and, thus, is most likely exempt from CAA checking. Not so with a contract.<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'> Steve Medin [<a href="mailto:Steve_Medin@symantec.com">mailto:Steve_Medin@symantec.com</a>] <br><b>Sent:</b> Thursday, November 10, 2016 11:21 AM<br><b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Subject:</b> RE: [cabfpub] Draft CAA motion (2)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Fully agree with your points, however, zero difference in domain validation tasks performed and in most/all cases the same validation group is doing the work for software-based permit lists and domains added to name constraints.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>It’s not like you’re validating domains in an offline room with your auditor reviewing the domain validation for a key ceremony.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Yes, a key ceremony is a rigid thing, so is a contract.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'> Jeremy Rowley [<a href="mailto:jeremy.rowley@digicert.com">mailto:jeremy.rowley@digicert.com</a>] <br><b>Sent:</b> Thursday, November 10, 2016 1:08 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Cc:</b> Steve Medin <<a href="mailto:Steve_Medin@symantec.com">Steve_Medin@symantec.com</a>><br><b>Subject:</b> RE: [cabfpub] Draft CAA motion (2)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>Creating issuing CAs requires a key ceremony (Section 6.1.1.1), meaning there is a lot more preparation and process involved in creating a technically constrained CA. (admittedly, this depends on the CA’s interpretation of “generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA”). The nature of a root ceremony necessarily creates additional processes and rigor that confirms the identity of the key holder. There’s a lot more effort that goes into it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'> Public [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Steve Medin via Public<br><b>Sent:</b> Thursday, November 10, 2016 10:11 AM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Cc:</b> Steve Medin <<a href="mailto:Steve_Medin@symantec.com">Steve_Medin@symantec.com</a>><br><b>Subject:</b> Re: [cabfpub] Draft CAA motion (2)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>The same effort that goes into validating a domain to be placed into a name constraint can/does go into validating a domain to add it to a CA’s explicit permit list in their relationship account/portal/managed services software.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Given the dynamic name space of large organizations that all consume TLS certificates via relationship accounts, portals, and contracts, creating a name-constrained subordinate CA for each customer then keeping up with their domain realty is not a concession to my request.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Name-constrained subordinates have value when they leave CA premises for remote operation. When a customer has a managed services account, technical constraints can be implemented that do not require the rigidity of name constraints or the weekly subordinate CA regeneration activities that lead to far more frequent than necessary root private key events.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>For several CAs, contracts and software-constrained portals that routinely pass audits are the vast majority of their issuance. If we’re going to allow CAA bypass with technical constraints, then we should leave 7.1.5 as is but in the context of CAA expand to include software-enforced explicit permit domain lists resulting from adherence to the BR domain validation rules and successful audit review.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext'> Public [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Gervase Markham via Public<br><b>Sent:</b> Thursday, November 10, 2016 9:26 AM<br><b>To:</b> CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Cc:</b> Gervase Markham <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>><br><b>Subject:</b> [cabfpub] Draft CAA motion (2)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi everyone,<br><br>Here's a second version of the draft motion to make CAA mandatory. Changes are:<br><br>* Change "10 minutes" to "CAA record TTL, or 1 hour, whichever is greater". This allows CAs to request as much time as they like from subscribers (by setting the TTL), but sets a lower bound so they don't have to issue in 3 seconds if someone sets a silly TTL.<br><br>* Change "for all domains in the certificate" to "for each dNSName in the subjectAltName extension of the certificate to be issued".<br><br>* Remove "after all other validation has been completed, ".<br><br>* Allow opting-out of CAA checking for CT certs if the precert was checked.<br><br>* Allow opting-out of CAA checking for Technically Constrained sub-CAs where it's a contractual provision.<br><br>* Change the DNSSEC provision to be "the zone does not have a DNSSEC validation chain to the ICANN root".<br><br>* Remove "CAs MUST keep records of the responses to all CAA DNS requests.".<br><br>* Changed "log" to "document" in the section on feeding back to the CAB Forum.<br><br>* Clarify the sentence about Issuer Domain Names by adding 'in CAA "issue" or "issuewild" records'.<br><br>* Rejig the wording of section 2.2, as there are now exception possibilities.<br><br><br>Would anyone like to suggest the appropriate section of the BRs to which the first section of text should be added?<br><br>I also propose that the effective date of this change (written into the new section 2.2) should be six months after the voting period ends. I am proposing six months rather than three because it requires a reasonable amount of development work within a CA's infrastructure.<br><br>Gerv<o:p></o:p></p><p class=line874><b>Ballot XXX - Make CAA Checking Mandatory</b><o:p></o:p></p><p class=line862>The following motion has been proposed by Gervase Markham of Mozilla and endorsed by XXX of XXX and XXX of XXX: <o:p></o:p></p><p class=line874><b>Statement of Intent</b>: <o:p></o:p></p><p class=MsoNormal>Certificate Authority Authorization (CAA) is a DNS Resource Record defined in RFC 6844 - <a href="https://datatracker.ietf.org/doc/rfc6844/">https://datatracker.ietf.org/doc/rfc6844/</a> , published in January 2013. It allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain and, by consequence, that no other CAs are authorized.<br><br>The intent of this motion is to make it mandatory for CAs to check CAA records at issuance time for all certificates issued (except in one uncommon case), and to prevent issuance if a CAA record is found which does not permit issuance by that CA. This therefore allows domain owners to set an issuance policy which will be respected by all publicly-trusted CAs, and allows them to mitigate the problem that the public CA trust system is only as strong as its weakest CA.<br><br>Note that CAA is already a defined term in the BRs and so does not need definitional text to be provided by this motion. <o:p></o:p></p><p class=line874><b>-- MOTION BEGINS --</b> <o:p></o:p></p><p class=MsoNormal>Add the following text to section XXX ("XXX") of the Baseline Requirements:<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>As part of the issuance process, the CA must check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844, following the processing instructions set down in RFC 6844 for any records found. If the CA issues, they must do so within the TTL of the CAA record, or 1 hour, whichever is greater.<br><br>This stipulation does not prevent the CA from checking CAA records at other points in the issuance process.<br><br>RFC 6844 requires that CAs "MUST NOT issue a certificate unless either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:<o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo3'>CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo3'>CAA checking is optional for certificates issued by an Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.<o:p></o:p></li></ul><p class=MsoNormal>CAs are permitted to treat a record lookup failure as permission to issue if:<o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo6'>the failure is outside the CA's infrastructure; <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo6'>the lookup has been retried at least once; and <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo6'>the domain's zone does not have a DNSSEC validation chain to the ICANN root.<o:p></o:p></li></ul><p class=MsoNormal>CAs MUST document issuances that were prevented by an adverse CAA record in sufficient detail to provide feedback to the CAB Forum on the circumstances, and SHOULD report such requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:.<o:p></o:p></p></blockquote><p class=MsoNormal>Update section 2.2 ("Publication of Information") of the Baseline Requirements, to remove the following text:<o:p></o:p></p><pre> Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification <o:p></o:p></pre><pre> Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether <o:p></o:p></pre><pre> the CA reviews CAA Records, and if so, the CA’s policy or practice on processing CAA Records <o:p></o:p></pre><pre> for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with <o:p></o:p></pre><pre> its processing practice. <o:p></o:p></pre><p class=MsoNormal>and replace it with: <o:p></o:p></p><pre> Effective as of XXX, section 4.2 of a CA's Certificate Policy and/or Certification <o:p></o:p></pre><pre> Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state the CA’s policy or <o:p></o:p></pre><pre> practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent<o:p></o:p></pre><pre> with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA<o:p></o:p></pre><pre> recognises in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions <o:p></o:p></pre><pre> taken, if any, consistent with its processing practice. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Add the following text to the appropriate place in section 1.6.3 ("References"):<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>RFC6844, Request for Comments: 6844, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, January 2013. <o:p></o:p></p></blockquote><p class=MsoNormal><b>-- MOTION ENDS -- </b><o:p></o:p></p><p class=line874>The review period for this ballot shall commence at 2200 UTC on XXX, and will close at 2200 UTC on XXX. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at XXX. Votes must be cast by posting an on-list reply to this thread. <o:p></o:p></p><p class=line862>A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: <a href="https://cabforum.org/members/">https://cabforum.org/members/</a> <o:p></o:p></p><p class=MsoNormal>In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently XXX members – at least that many members must participate in the ballot, either by voting in favor, voting against, or abstaining. <o:p></o:p></p></div></div></div></div></body></html>