[cabfpub] Name Constraints, Auditing and EKU

Sat Apr 6 02:08:49 UTC 2013

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
>