[cabfpub] Name Constraints, Auditing and EKU

Sun Apr 7 06:40:45 MST 2013

Hi Ryan 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've have to
involve Ryan Hurst if we dive into any specific technical Name Constraint
discussions on this thread.)

Hi Rick. 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
(here <http://unmitigatedrisk.com/?p=201> )) 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.

> 17.5 Audit of Delegated Functions.
> If a Delegated Third Party is *not currently audited in accordance with
> Section 17* and is not an Enterprise RA, then prior to certificate issuance
> the *CA SHALL* 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) *performing the domain control
> validation process itself*.

Taking the items between the *'s 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.

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.

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.

Kind Regards

Steve Roylance
Business Development Director

On 06/04/2013 03:08, "Ryan Sleevi" <sleevi at google.com> wrote:

> On Fri, Apr 5, 2013 at 6:35 PM, Rick Andrews <Rick_Andrews at symantec.com>
> wrote:
>>  Steve,
>> 
>> 
>> 
>>  The last time we discussed this on the CABF call, I expressed concern about
>>  the idea of technically-constrained certs not needing a third-party audit.
>>  We may be putting ourselves in a situation where we¹ll have to answer some
>>  tough questions:
>> 
>> 
>> 
>>  -           If a CA is qualified to perform audits on its Delegated Third
>>  Parties, why can¹t the CA audit itself? Why require a third party for the CA
>>  but not its delegates? All certs chain to the same trusted roots, and have
>>  the capability to do the same damage.
>> 
>>  -          What about the conflict of interest created by that business
>>  arrangement? What¹s to keep CAs from rubber stamping audits of delegates
>>  because they stand to lose money if they don¹t?
>> 
>>  -          Does this create a moral hazard where the Delegate might
>>  intentionally violate the BRs because they won¹t bear much of the cost?
>>  (their certificate(s) will get revoked, but the CA may have its roots
>>  untrusted as a result).
>> 
>>  -          The BRs are only as strong as their weakest link, and isn¹t this
>>  a weak link?
>> 
>> 
>> 
>>  I¹d feel better about this if we had good answers to these questions.
> 
> Hi Rick,
> 
> Hopefully I can provide some answers on Steve's behalf.
> 
> I think the questions may be stemming from a misunderstanding of what
> we're talking about here. If we were talking about unconstrained
> subordinate certificates (or cross-signing), I would absolutely share
> your concerns.
> 
> However, we're not. We're talking about certificates that are
> constrained to be limited in scope. This means that they are
> fundamentally NOT the same as the CA certificates that require
> auditing, as your first question suggests.
> 
> It's important to realize that the constraints reduce the risk from
> "The entire Internet" (the CA certificates for which root stores do
> require third-party audits) to "A specific organization whose names
> have been verified according to well-defined practices (eg: the BRs)".
> As such, the risk of misissuance, deviation from the BRs, or other
> failures - such as failures to include CDPs or AIA/OCSP - are entirely
> limited in scope to the single domain or set of domains that have had
> the constrained intermediate issued for.
> 
> Because this risk is so limited, the needs are vastly different. Quite
> frankly, I'm not sure how strongly I feel about the audit requirements
> in general - the technical constraint should be and likely is
> sufficiently robust that the remaining elements are only affecting the
> security of the site operator - not the web at large.
> 
> To put it in perspective, the requirement for auditing the technically
> constrained sub-CA is, in many ways, akin to requiring that the CA
> inspect each server that will be installing a certificate and making
> sure they're "secure" (for some definition of secure). While nice, and
> perhaps may highlight areas of customer misconfiguration, it's
> unnecessary to the overall security of the CA ecosystem.
> 
> If a Delegate misbehaves, provided the CA properly issued technical
> constraints, then their ability to do damage is limited to that scope.
> Same as a wildcard cert, for example.
> 
> 
> 
> All of this said, I'm still quite mixed about Steve's proposal for
> incorporating this language into the BRs. It was drafted by and for
> Mozilla within a very specific context - of NSS using applications -
> and the considerations, concerns, and security trade-offs may or may
> not be broadly applicable for all applications and CAs. For example,
> nameConstraints only apply to the naming types specifically enumerated
> - meaning such constrained intermediates may be valid for any name
> types not enumerated (XMPP names, for example). For Mozilla/NSS, this
> is perfectly acceptable, but is it for the CA ecosystem at large? I'm
> sure Microsoft may be able to find other name types or key usages that
> may be applicable to their root store, given the broader set of
> applications beyond just browsers that use it.
> 
> Cheers,
> Ryan
> 
>> 
>> 
>> 
>>  -Rick
>> 
>> 
>> 
>>  From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
>>  Behalf Of Steve Roylance
>>  Sent: Wednesday, March 27, 2013 6:50 AM
>>  To: public at cabforum.org
>>  Subject: [cabfpub] Name Constraints, Auditing and EKU
>> 
>> 
>> 
>>  Dear all,
>> 
>> 
>> 
>>  (Thanks Ben Wilson for helping me remove the minor mistakes in my initial
>>  draft)
>> 
>> 
>> 
>>  Please see the attached (Word and PDF versions) as a suggested update to the
>>  BRs to address the gaps we saw when viewing the guidelines with multiple
>>  parties over the last couple of months.
>> 
>> 
>> 
>>  My 10,000 ft view (Which I hope is expressed clearly by the changes
>>  proposed)
>> 
>>   All CAs are Audited or Technically constrained  (as Mozilla's Rev 2.1
>>  Policy now States so in reality it's applicable to everyone already)
>>  There's no ability to opt out as BRs as they apply to all Roots and
>>  Subordinate CAs whether or not they are owned/run by the root authority or
>>  another Subordinate Authority lower down the chain.  i.e. no gaps as it's
>>  the weak points that will hurt the industry.
>>  The only exception in section 17 is that Technically constrained or not, the
>>  quarterly self audits should be done as that checks compliance to the other
>>  areas.
>> 
>>  Note that I added the section on SubCA subject naming as although it could
>>  be inferred from the issuer logic that section seemed to be more focused on
>>  Roots.
>> 
>> 
>> 
>>  I'm looking for a couple of volunteers to whip this into shape.  Any takers?
>> 
>> 
>> 
>>  Steve
>> 
>> 
>>  _______________________________________________
>>  Public mailing list
>>  Public at cabforum.org
>>  https://cabforum.org/mailman/listinfo/public
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130407/8e108cb9/attachment.html 