<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 12px; "><div><div style="color: rgb(0, 0, 0); "><font><b>Hi Ryan </b>thanks for stepping in. You covered my responses plus some items I'd have missed. For your information we use a combination of EKU and Name Constraints to arrive at a SubCA that's limited in scope from a domain name space perspective as well as key usage. There will always be minor improvements and modifications in best practice as we move forward but for now the use of Name Constraints and EKU offers a great way to maintain/increase the overall adoption of certificate usage. <i>(I've have to involve Ryan Hurst if we dive into any specific technical Name Constraint discussions on this thread.)</i></font></div><div style="color: rgb(0, 0, 0); "><br></div><div style="color: rgb(0, 0, 0); "><b>Hi Rick.</b> Just to be clear on our understanding of the BRs which dates back to June 2011 in Paris when the alternative models were discussed at length, we've always interpreted the wording of the BRs as allowing the technical constraints method. Since that time we've proceeded forward on this basis and over the last 18 months+ we've been moving our historical customer base over to Name Constraints (albeit slower than we would have liked). When requested, we've kept the browsers up to date on activities, posted blogs when we've discovered issues (Such as how XP handle constraints differently (<a href="http://unmitigatedrisk.com/?p=201">here</a>)) and where Name Constraints have been unworkable we've just had to either walk away from the opportunity or convert the customer to an alternative delivery platform. What we've found with 'new' opportunities who have not been exposed to the 18+ months of discussions (i.e. following the evolvement of the BRs and the maturing of the Mozilla Policy) is that the Base Requirements as currently written do not make the audit situation clear. </div><div style="color: rgb(0, 0, 0); "><br></div><div><blockquote style="margin:0 0 0 40px; border:none; padding:0px;"><div style="color: rgb(0, 0, 0); "><b><i>17.5 Audit of Delegated Functions.</i></b></div><div><i>If a Delegated Third Party is <font color="#ff0000">*not currently audited in accordance with Section 17*</font> and is not an Enterprise RA, then prior to certificate issuance the <font color="#ff0000">*CA SHALL*</font> ensure that the domain control validation process required under Section 11.1 has been properly performed by the Delegated Third Party by either (1) using an out-of-band mechanism involving at least one human who is acting either on behalf of the CA or on behalf of the Delegated Third Party to confirm the authenticity of the certificate request or the information supporting the certificate request or (2) <font color="#ff0000">*performing the domain control validation process itself*</font>.</i></div></blockquote><div style="color: rgb(0, 0, 0); "><br></div><div><span style="color: rgb(0, 0, 0); ">Taking the items between the </span><font color="#ff0000">*'s</font> then the Third Party doesn't need to be audited if the CA performs the domain control validation process prior to issuance. With Name constraints that's done so no audit is needed.</div></div><div style="color: rgb(0, 0, 0); "><br></div><div style="color: rgb(0, 0, 0); ">The hierarchical nature of chaining means that provisions are flowed down by either contract or technology between the various layers. In some ways an Enterprise RA with simple username/password access to certificate issuance as a web service is far more vulnerable to attack/compromise and therefore mis issuance under a set of domains than a SubCA with a firewalled issuance infrastructure that is Name Constrained. The latter will need to have invested in technology and manpower where as the former may simply have agreed to terms on conditions on a web page. All life cycles can be argued positively and negatively depending on your view point.</div><div style="color: rgb(0, 0, 0); "><br></div><div style="color: rgb(0, 0, 0); ">At the end of the day the BRs were created to raise the bar and they are doing that. All I'm asking is that we make the language easier for new entrants to clearly understand their obligations. The Audit language has been deemed unclear by many so I'm trying to improve the situation. Maybe I've gone to far by incorporating the Mozilla language, however it's only a starting point.</div><div style="color: rgb(0, 0, 0); "><br></div><div style="color: rgb(0, 0, 0); ">Kind Regards</div><div style="color: rgb(0, 0, 0); "><br></div><div style="color: rgb(0, 0, 0); ">Steve Roylance</div><div style="color: rgb(0, 0, 0); ">Business Development Director</div><div style="color: rgb(0, 0, 0); font-size: 12px; "><br></div></div><div style="color: rgb(0, 0, 0); font-family: Consolas, monospace; font-size: 12px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Consolas, monospace; font-size: 12px; ">On 06/04/2013 03:08, "Ryan Sleevi" <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:</div><div style="color: rgb(0, 0, 0); font-family: Consolas, monospace; font-size: 12px; "><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="color: rgb(0, 0, 0); font-family: Consolas, monospace; font-size: 12px; border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px; "><div>On Fri, Apr 5, 2013 at 6:35 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:</div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Steve,</div><div><br></div><div><br></div><div><br></div><div> The last time we discussed this on the CABF call, I expressed concern about</div><div> the idea of technically-constrained certs not needing a third-party audit.</div><div> We may be putting ourselves in a situation where we’ll have to answer some</div><div> tough questions:</div><div><br></div><div><br></div><div><br></div><div> - If a CA is qualified to perform audits on its Delegated Third</div><div> Parties, why can’t the CA audit itself? Why require a third party for the CA</div><div> but not its delegates? All certs chain to the same trusted roots, and have</div><div> the capability to do the same damage.</div><div><br></div><div> - What about the conflict of interest created by that business</div><div> arrangement? What’s to keep CAs from rubber stamping audits of delegates</div><div> because they stand to lose money if they don’t?</div><div><br></div><div> - Does this create a moral hazard where the Delegate might</div><div> intentionally violate the BRs because they won’t bear much of the cost?</div><div> (their certificate(s) will get revoked, but the CA may have its roots</div><div> untrusted as a result).</div><div><br></div><div> - The BRs are only as strong as their weakest link, and isn’t this</div><div> a weak link?</div><div><br></div><div><br></div><div><br></div><div> I’d feel better about this if we had good answers to these questions.</div></blockquote><div><br></div><div>Hi Rick,</div><div><br></div><div>Hopefully I can provide some answers on Steve's behalf.</div><div><br></div><div>I think the questions may be stemming from a misunderstanding of what</div><div>we're talking about here. If we were talking about unconstrained</div><div>subordinate certificates (or cross-signing), I would absolutely share</div><div>your concerns.</div><div><br></div><div>However, we're not. We're talking about certificates that are</div><div>constrained to be limited in scope. This means that they are</div><div>fundamentally NOT the same as the CA certificates that require</div><div>auditing, as your first question suggests.</div><div><br></div><div>It's important to realize that the constraints reduce the risk from</div><div>"The entire Internet" (the CA certificates for which root stores do</div><div>require third-party audits) to "A specific organization whose names</div><div>have been verified according to well-defined practices (eg: the BRs)".</div><div>As such, the risk of misissuance, deviation from the BRs, or other</div><div>failures - such as failures to include CDPs or AIA/OCSP - are entirely</div><div>limited in scope to the single domain or set of domains that have had</div><div>the constrained intermediate issued for.</div><div><br></div><div>Because this risk is so limited, the needs are vastly different. Quite</div><div>frankly, I'm not sure how strongly I feel about the audit requirements</div><div>in general - the technical constraint should be and likely is</div><div>sufficiently robust that the remaining elements are only affecting the</div><div>security of the site operator - not the web at large.</div><div><br></div><div>To put it in perspective, the requirement for auditing the technically</div><div>constrained sub-CA is, in many ways, akin to requiring that the CA</div><div>inspect each server that will be installing a certificate and making</div><div>sure they're "secure" (for some definition of secure). While nice, and</div><div>perhaps may highlight areas of customer misconfiguration, it's</div><div>unnecessary to the overall security of the CA ecosystem.</div><div><br></div><div>If a Delegate misbehaves, provided the CA properly issued technical</div><div>constraints, then their ability to do damage is limited to that scope.</div><div>Same as a wildcard cert, for example.</div><div><br></div><div><br></div><div><br></div><div>All of this said, I'm still quite mixed about Steve's proposal for</div><div>incorporating this language into the BRs. It was drafted by and for</div><div>Mozilla within a very specific context - of NSS using applications -</div><div>and the considerations, concerns, and security trade-offs may or may</div><div>not be broadly applicable for all applications and CAs. For example,</div><div>nameConstraints only apply to the naming types specifically enumerated</div><div>- meaning such constrained intermediates may be valid for any name</div><div>types not enumerated (XMPP names, for example). For Mozilla/NSS, this</div><div>is perfectly acceptable, but is it for the CA ecosystem at large? I'm</div><div>sure Microsoft may be able to find other name types or key usages that</div><div>may be applicable to their root store, given the broader set of</div><div>applications beyond just browsers that use it.</div><div><br></div><div>Cheers,</div><div>Ryan</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><div><br></div><div><br></div><div> -Rick</div><div><br></div><div><br></div><div><br></div><div> From: <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>] On</div><div> Behalf Of Steve Roylance</div><div> Sent: Wednesday, March 27, 2013 6:50 AM</div><div> To: <a href="mailto:public@cabforum.org">public@cabforum.org</a></div><div> Subject: [cabfpub] Name Constraints, Auditing and EKU</div><div><br></div><div><br></div><div><br></div><div> Dear all,</div><div><br></div><div><br></div><div><br></div><div> (Thanks Ben Wilson for helping me remove the minor mistakes in my initial</div><div> draft)</div><div><br></div><div><br></div><div><br></div><div> Please see the attached (Word and PDF versions) as a suggested update to the</div><div> BRs to address the gaps we saw when viewing the guidelines with multiple</div><div> parties over the last couple of months.</div><div><br></div><div><br></div><div><br></div><div> My 10,000 ft view (Which I hope is expressed clearly by the changes</div><div> proposed)</div><div><br></div><div> All CAs are Audited or Technically constrained (as Mozilla's Rev 2.1</div><div> Policy now States so in reality it's applicable to everyone already)</div><div> There's no ability to opt out as BRs as they apply to all Roots and</div><div> Subordinate CAs whether or not they are owned/run by the root authority or</div><div> another Subordinate Authority lower down the chain. i.e. no gaps as it's</div><div> the weak points that will hurt the industry.</div><div> The only exception in section 17 is that Technically constrained or not, the</div><div> quarterly self audits should be done as that checks compliance to the other</div><div> areas.</div><div><br></div><div> Note that I added the section on SubCA subject naming as although it could</div><div> be inferred from the issuer logic that section seemed to be more focused on</div><div> Roots.</div><div><br></div><div><br></div><div><br></div><div> I'm looking for a couple of volunteers to whip this into shape. Any takers?</div><div><br></div><div><br></div><div><br></div><div> Steve</div><div><br></div><div><br></div><div> _______________________________________________</div><div> Public mailing list</div><div> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a></div><div> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></div><div><br></div></blockquote><div><br></div></blockquote></body></html>