<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>The majority of customers are ones we've had from the last decade+ who need to augment fairly high volume client certificate needs with SSL and as you know, the most effective client auth is a unique custom CA. NC offers the best way of keeping those CAs running safely for all parties. NC does not fit all needs but it's the best technology we have in our arsenal.</div><div><br></div><div>I'll make some amendments to the ballot over the next 36 hours to correct points you raised with your feedback.<br><br>Sent from my iPhone</div><div><br>On 15 Jul 2013, at 20:50, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 12 (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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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";}
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;}
p
{mso-style-priority:99;
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.line867, li.line867, div.line867
{mso-style-name:line867;
mso-style-priority:99;
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-style-priority:99;
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.line891, li.line891, div.line891
{mso-style-name:line891;
mso-style-priority:99;
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.line862, li.line862, div.line862
{mso-style-name:line862;
mso-style-priority:99;
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";}
span.anchor
{mso-style-name:anchor;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{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;}
--></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]--><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Steve, yes that’s more clear. I appreciate the info because I can’t devote my labs to test NC unless and until we issue constrained CAs. We don’t today.<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">Can you answer a more fundamental question? I believe you have a fair number of customers whose CA certs you would like to constrain. Why do many customers choose this solution? Why do they feel they need their own intermediate CA? Is it because they want their branding in the intermediate CA? (I doubt that) Is it because they want speed of issuance? I doubt that too. To be honest, we haven’t seen much demand for external SubCAs, so I’m curious about why you have a significant number of customers choosing that option.<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">-Rick<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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Steve Roylance [<a href="mailto:steve.roylance@globalsign.com">mailto:steve.roylance@globalsign.com</a>] <br><b>Sent:</b> Saturday, July 13, 2013 6:50 AM<br><b>To:</b> Rick Andrews<br><b>Cc:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a>; Stephen Davidson<br><b>Subject:</b> Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p> </o:p></p><div><p class="MsoNormal">Hi Rick. (Forgive any typos etc)<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Thanks for the in-depth review. <o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">I'll discuss with the endorsers on Monday/Tuesday and amend accordingly. (If there are no other comments to fold in).<o:p></o:p></p></div><div><p class="MsoNormal">I suggest that you get your labs to test aspects of NC as this will help you appreciate better some of the points we've asked for in the ballot and the example.<o:p></o:p></p></div><div><p class="MsoNormal">I can answer 2 points now and they are related to each other..<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">1) "Will end entity certs be rejected"( if they don't have all the same RDN elements in the same order as the NC DirectoryName) . Yes, this is how it works. You can add additional OU fields after the NC have been satisfied by the end entity Subject RDN. Effectively, through the use of NC the Root CA proxies the vetting they perform on behalf of SubCA to the Sub CA via the domain/rfc/otherName & directoryname constraints. It's only suitable therefore for one or two enterprise/affiliated companies and their combined domain space(s). I tend to think of this as key material constrained by rules making it an enterprise account and therefore I argue that auditing rules don't apply today hence the clarifications in the ballot.<o:p></o:p></p></div><div><p class="MsoNormal">2) We've worked with a number of organisations, and therefore models/requirements over the past year and found that ideally you need at least one Directory NC that matches exactly to the Subject RDN of the SubCA. This is because some CA systems cut their own certs for internal use like Key Recovery. These internal use certs base their Subject RDN on the Subject RDN of the issuing SubCA, so if you name the SubCA following only the advice in the current BR you'll be able to use a Trademark (or non misleading information) ie following the issuer subject rules, where as you actually need to follow CPS best practice and name the SubCA correctly (a real organisation name) as you can't include trademark names in the DirectoryName NC. Please have your labs test. The net result is that the SubCA should be created with accurate information following the rules the CA has in their CPS. Note that this is completely different than the needs a Root CA has for an internal hierarchy with no NC where SubCAs can meet BR rules for Issuing CA names.<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Hopefully clearer?<br><br>Sent from my iPhone<o:p></o:p></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>On 13 Jul 2013, at 01:32, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<o:p></o:p></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Steve,</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Some feedback:</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Section 1: (Grammatical nit) You added a statement including “Root CA” and “Subordinate CA”. The document defines Root CA and Subordinate CA as the Certification Authority (the company). I think here (and maybe elsewhere) you want to say “Root CA certificate” and “Subordinate CA certificate”. For example, elsewhere in Section 13.2.6 you carve out an exception for “CAs which are not Technically Constrained”. I’m pretty sure you mean “CA certificates” there, because a given CA might have some certificates that are Technically Constrained and some that are not. Ditto for Section 17 and 17.9 (I haven’t checked everywhere; there may be other cases.)</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">“9.2.7 Subject Information – Subordinate CA Certificates</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Policy and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Information was accurate.”</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I don’t understand why you added this, since it seems obvious to me. A CA would always follow the procedure in its CPS or else it would fail an audit. And what CA would knowingly issue a subordinate CA with inaccurate information?</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Minor nit – the above is in Section 9.2.7, and you updated the title of Section 9.2 to indicate that it applied to End Entity Certificates. So why would you have a section on Subordinate CAs inside a section on End Entity Certs?</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Section 9.7: A question about DirName in your example:</span><o:p></o:p></p><p class="MsoNormal" style="text-indent:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">X509v3 Name Constraints: </span><o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in;text-indent:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Permitted:</span><o:p></o:p></p><p class="MsoNormal" style="margin-left:1.0in;text-indent:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">DNS:example.com</span><o:p></o:p></p><p class="MsoNormal" style="margin-left:1.0in;text-indent:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">DirName: C=US, ST=MA, L=Boston, O=Example LLC</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If a Subordinate CA contains this in its Name Constraints extension, does that mean that compliant browsers will reject any end entity certificate issued by this Subordinate CA unless the DN of the end entity cert is “C=US, ST=MA, L=Boston, O=Example LLC, CN=<zero or more labels>.<a href="http://example.com">example.com</a>”?</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Section 17.9: Should you add that if the CA’s monitoring uncovers certificates for which the BRs are not met, those certificates must be immediately revoked?</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Appendix (B) 2. G.: You don’t say whether this extension should be critical or non-critical. I suggest the same language as in nameConstraints in the paragraph above it. Also, you list this extension as optional (just as the nameConstraints are optional) but in Section 9.7 you say that to be Technically Constrained, both extensions must be present.</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Rick</span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Steve Roylance<br><b>Sent:</b> Friday, July 12, 2013 9:25 AM<br><b>To:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br><b>Cc:</b> Stephen Davidson<br><b>Subject:</b> [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.</span><o:p></o:p></p></div></div><p class="MsoNormal"> <o:p></o:p></p><div><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Dear all.</span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">PDF and Word versions attached based on an update to 1.1.3 (As an example). </span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Please note I'm out for the next week but will try to answer where possible any questions. Responses may therefore be delayed</span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Steve</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Ballot 105 – Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.</span></strong><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Steve Roylance made the following motion, and Gervase Markham from Mozilla and Stephen Davidson from Quovadis endorsed it:</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Motion Begins</span></strong><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">EFFECTIVE IMMEDIATELY, this ballot provides clarity to the language covering external audits for Subordinate CAs, removing ambiguity as well as providing better alignment of the Baseline Requirements to the Mozilla CA Root program where the subject is already covered and accepted by the wider PKI community. In addition, the proposal sets out to aid wider and broader PKI adoption by Subordinate CAs by defining the use of Technical Constraints and highlighting how additional barriers to adoption within the guidelines can be optional when using Name Constraints, specifically the requirement for ‘OCSP Good’ responses originally proposed in Ballot 100. We propose amending the Baseline Requirements Guidelines as follows:</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 1 – Scope</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Adding scope)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">These Requirements are applicable to all Certification Authorities within a chain of trust starting at the Root CA and flowing down through successive Subordinate CAs.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 4 – Definitions</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Additional Definition)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Technically Constrained Subordinate CA: A Subordinate CA that uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which a Subordinate CA may issue Certificates.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 9.2 Subject Information</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Amending the section title)</span></i></strong></span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.2 Subject Information – End Entity Certificates</span></strong><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 9.2.7 Other Subject Attributes</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Moving to 9.2.8)</span></i></strong></span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 9.2.7 Subject Information – Subordinate CA Certificates</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Adding a new section)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject Information was accurate.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 9.4 Validity Period</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Clarifying the Validity Period for Subscriber Certificates)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Was:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.4 Validity Period</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months. Except as provided for below, Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months. Beyond 1 April 2015, CAs MAY continue to issue Certificates with a Validity Period greater than 39 months but not greater than 60 months provided that the CA documents that the Certificate is for a system or software that:</span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Amended to:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.4 Validity Period</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><span style="font-family:"Arial","sans-serif"">9.4.1 Subscriber Certificates</span></strong> Subscriber Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months. Except as provided for below, Subscriber Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months. Beyond 1 April 2015, CAs MAY continue to issue Subscriber Certificates with a Validity Period greater than 39 months but not greater than 60 months provided that the CA documents that the Certificate is for a system or software that:</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.5 Subscriber Public Key</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Alignment of Key checking for all certificates)</span></i></strong></span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.5 Public Key</span></strong><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.7 Additional Technical Requirement</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Moving to Section 9.8)</span></i></strong></span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.7 Technical Constraints in Subordinate CAs via Name Constraints & EKU</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(New section)</span></i></strong></span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">9.7 Technical Constraints in Subordinate CAs via Name Constraints & EKU</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> For a Subordinate CA certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension. If the Subordinate CA certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:-</span><o:p></o:p></p><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 11.1 </span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf.</span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or Subsidiary’s Organizational name and location such that end entity certificates issued from the subordinate CA will be in compliancy with section 9.2.4 and 9.2.5.</span><o:p></o:p></p></blockquote><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">If the Subordinate CA is not allowed to issue certificates with an iPAddress, then the Subordinate CA certificate MUST specify the entire IPv4 and IPv6 address ranges in excludedSubtrees. The Subordinate CA certificate MUST include within excludedSubtrees an iPAddress GeneralName of 8 zero octets (covering the IPv4 address range of 0.0.0.0/0). The Subordinate CA certificate MUST also include within excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of ::0/0). Otherwise, the subordinate CA certificate MUST include at least one iPAddress in permittedSubtrees.</span><o:p></o:p></p><p class="line867" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">A decoded example for issuance to the domain and sub domains of <a href="http://example.com">example.com</a> by organization :- Example LLC, Boston, Massachusetts, US would be:-</span><o:p></o:p></p><p class="line867" style="background:white"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">X509v3 Name Constraints:</span><o:p></o:p></p><p class="line867" style="background:white"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Permitted:</span><o:p></o:p></p><p class="line867" style="background:white"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">DNS:example.com </span><o:p></o:p></p><p class="line867" style="background:white"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">DirName: C=US, ST=MA, L=Boston, O=Example LLC</span><o:p></o:p></p><p class="line867"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Excluded:</span><o:p></o:p></p><div><div><p class="line891" style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">IP:0.0.0.0/0.0.0.0 </span><o:p></o:p></p><p class="line891" style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in"><span class="apple-tab-span"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> </span></span><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0</span><o:p></o:p></p></div></div><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">If the Subordinate CA is not allowed to issue certificates with dNSNames, then the subordinate CA certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the subordinate CA certificate MUST include at least one dNSName in permittedSubtrees.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 11.1.1 Authorization by Domain Name Registrant</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Adding clarification)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 11.1.2 Authorization for an IP Address</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Adding clarification)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Note: IPAddresses may be listed in Subscriber Certificates using IPAddress in the subjectAltName extension or in Subordinate CA Certificates via IPAddress in permittedSubtrees within the Name Constraints extension.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 13.2.6 Response for non-issued certificates</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Amending applicability)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Was:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">13.2.6 Response for non-issued certificates</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures. Effective 1 August 2013, OCSP responders MUST NOT respond with a "good" status for such certificates.</span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Amended to:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">13.2.6 Response for non-issued certificates</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures. Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 9.7 MUST NOT respond with a "good" status for such certificates.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 17 Audit</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Clarification notes added to the section heading)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 9.7 and audited in line with section 17.9 only, or Unconstrained and fully audited in line with all remaining requirements from section 17. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA or a Subordinate CA.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Section 17.9 Regular Quality Assessment of Technically Constrained Subordinate CAs</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(New Section)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable Baseline Requirements are met.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Appendix B - Certificate Extensions (Normative)</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> <strong><i><span style="font-family:"Arial","sans-serif"">(Clarify F and add G)</span></i></strong></span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Was:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">F. nameConstraints (optional)</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> If present, this extension SHOULD be marked critical*. * Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide.</span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Amended to:-</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">F. nameConstraints (optional)</span></strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black"> If present, this extension SHOULD be marked critical*. * Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide. <strong><span style="font-family:"Arial","sans-serif"">G. extkeyUsage (optional)</span></strong> For Subordinate CA Certificates to be Technically constrained in line with section 9.8, then either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present**. Other values MAY be present. ** Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide.</span><o:p></o:p></p><p class="line874" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">The review period for this ballot shall commence on July 15th, 2013 and will close on July 22nd, 2013. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at July 29, 2013. Votes must be cast by posting an on-list reply to this thread.</span><o:p></o:p></p><p class="line867" style="background:white"><strong><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Motion Ends</span></strong><o:p></o:p></p><p class="line862" style="background:white"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">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="http://www.cabforum.org/forum.html"><span style="border:none windowtext 1.0pt;padding:0in;text-decoration:none">http://www.cabforum.org/forum.html</span></a> In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and one half or more of the votes cast by members in the browser category must be in favor. Also, at least seven members must participate in the ballot, either by voting in favor, voting against, or abstaining.</span><o:p></o:p></p></div></div></div></blockquote></div></div></div></blockquote></body></html>