<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 12:08 PM, Ben Wilson <span dir="ltr"><<a href="mailto:ben@digicert.com" target="_blank">ben@digicert.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div>See question below:<br><br><br>-------- Original message --------<br>From: "Sheehy, Don (CA - Toronto)" <<a href="mailto:dosheehy@deloitte.ca" target="_blank">dosheehy@deloitte.ca</a>> <br>
Date: 01/21/2014  11:42 AM  (GMT-07:00) <br>To: <a href="mailto:ben@digicert.com" target="_blank">ben@digicert.com</a> <br>Subject: question on 17.9 of baseline <br> <br><br>
<font face="Calibri"><span style="font-size:11pt">
<div> </div>
<div> </div>
<div><font face="Arial"><span style="font-size:10pt">Can you pose this to the forum</span></font></div>
<div><font face="Arial"><span style="font-size:10pt"> </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">“17.9 Regular    Quality  Assessment       of       Technically      Constrained     Subordinate     CAs     </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">immediately after the previous audit sample was taken, the CA shall ensure all applicable Baseline Requirements are </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">met. </span></font></div>
<div> </div>
<ol style="margin:0;padding-left:36pt">
<font face="Arial"><span style="font-size:10pt">
<li>Has the Forum established how they will get evidence that the population the subordinate says have issued is accurate to choose the 3%</li></span></font></ol></span></font></div></div></div></blockquote><div><br></div>
<div>I'm not aware of any technical means by any root program member at this time. The closest that one can come is Certificate Transparency, although it's been suggested to not require certificates issued by a technically constrained sub-CA to be publicly logged.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div><font face="Calibri"><span style="font-size:11pt"><ol style="margin:0;padding-left:36pt">
<font face="Arial"><span style="font-size:10pt"><li>What specifically will be checked since the cert is technically constrained ? – ie what are the applicable baseline Requirements that will be tested ( this sould be agreed for consistency)</li>
</span></font></ol></span></font></div></div></div></blockquote><div><br></div><div>The Baseline Requirements do not presently establish this, unfortunately. The 'intent' of permitting technically constrained subordinate CAs was to absolve such subordinates of many of the auditing requirements found within the BRs.</div>
<div><br></div><div>My take is that the focus should be on the conformance to the technical profile - which can be automated - while de-emphasizing focus on some of the identity-related assertions, since the technical constraints restrict those.</div>
<div><br></div><div>We would need a BR amendment to clarify these requirements, I believe, as none of them should _need_ to be required, given the nature of the technical constraint.</div><div><br></div><div>1) subjectAltNames contains only names within the registered domain namespace of the technically constrained subordinate CA certificate and conforms with the technical requirements of 9.2.1.</div>
<div><br></div><div>[Note: This intentionally precludes internal server names, for which technically constrained subCAs should not be permitted, by virtue of both technical constraints and public trust.</div><div><br></div>
<div>This is also (arguably) a defense against clients that do not support NC, since NC is not marked critical. However, we may simply to decide to leave such clients "on their own", with respect to security, and either support NC or run the risk.]</div>
<div><br></div><div>2) Validity period conformance to 9.4.1 (although not critical, as the subordinate CA cert should be constrained)</div><div><br></div><div>[Note: The validity period constraint on the intermediate should prevent any long-lived end-entity certs from being valid, except in the case where a customer performs an intermediate re-issuance that extends the date of the intermediate, thus allowing EE certs to continue to be valid. Then again, the only ones harmed is themselves]</div>
<div><br></div><div>3) Conformance to the Cryptographic Algorithm / Key Requirements profile in Appendix A</div><div><br></div><div>[Note: It could be argued that by virtue of technical constraint, it's not necessary to require this conformance, since at worst, an organization that fails to comply is only affecting their own security]</div>
<div><br></div><div>4) Conformance to the Certificate Extensions profile in Appendix B</div><div><br></div><div>[Note: Again, it could be argued that by virtue of technical constraint, the only ones they're harming is themselves].</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div><font face="Calibri"><span style="font-size:11pt"><ol style="margin:0;padding-left:36pt">
<font face="Arial"><span style="font-size:10pt"><li>The evidence for the 3% checking will then need to be kept for the auditors for the baseline audit.</li></span></font>
</ol>
<div> </div>
<div> </div>
<div><font face="Arial"><span style="font-size:10pt">Thanks </span></font></div>
<div><font face="Arial"><span style="font-size:10pt"> </span></font></div>
<div><font face="Arial"><span style="font-size:10pt">Don</span></font></div>
<div><font face="Arial"><span style="font-size:10pt"> </span></font></div>
<div> </div>
<div> </div>
<div><font face="Arial" color="#000066"><span style="font-size:10pt"><b>Donald E. Sheehy, CPA, </b><font color="navy"><b>CA, CISA, CRISC, CIPP/C</b></font></span></font></div>
<div><font face="Verdana" size="1" color="#000066"><span style="font-size:8pt">Partner | Enterprise Risk </span></font></div>
<div><font face="Verdana" size="1" color="#000066"><span style="font-size:8pt">Deloitte  </span></font></div>
<div><font face="Arial" size="1" color="#004994"><span style="font-size:8pt">30 Wellington St Wt, PO Box 400, Stn Commerce Crt, Toronto, ON M5L 1B1</span></font></div>
<div><font face="Arial" size="1" color="#004994"><span style="font-size:8pt">Direct: <a href="tel:416-601-5863" value="+14166015863" target="_blank">416-601-5863</a> | Main: <a href="tel:416-601-6500" value="+14166016500" target="_blank">416-601-6500</a></span></font></div>

<div><font face="Arial" size="1" color="#004994"><span style="font-size:8pt">Fax: <a href="tel:416-601-6400" value="+14166016400" target="_blank">416-601-6400</a> | Mobile: <a href="tel:416-301-2350" value="+14163012350" target="_blank">416-301-2350</a></span></font></div>

<div><a href="mailto:name@deloitte.ca" target="_blank"><font face="Arial" size="1" color="blue"><span style="font-size:8pt"><u>dosheehy@deloitte.ca</u></span></font></a><font face="Arial" size="1" color="#004994"><span style="font-size:8pt"> | </span></font><a href="http://www.deloitte.ca/" target="_blank"><font face="Arial" size="1" color="blue"><span style="font-size:8pt"><u>www.deloitte.ca</u></span></font></a></div>

<div><font color="#004994"> </font></div>
<div><font face="Arial" size="1" color="#00A8E6"><span style="font-size:8pt">Deloitte is proud to be an Official Supplier </span></font></div>
<div><font face="Arial" size="1" color="#00A8E6"><span style="font-size:8pt">of the Canadian Olympic team  </span></font></div>
<div> </div>
<div><font face="Arial" size="1" color="#92D400"><span style="font-size:7.5pt">Please consider the environment before printing. </span></font></div>
<div> </div>
<div> </div>
<div> </div>
</span></font>


<p>Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. <br>

Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci.</p>
</div></div></div><br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div></div>