[cabfpub] Name Constraints, Auditing and EKU

Mon Apr 8 21:58:15 UTC 2013

Steve,

I wish I had been in Paris at the start of this discussion (I wish I were in Paris right now... :^). The Powerpoint slide you sent me is rather complex and doesn't really help me. But I think I see your point - that with technical constraints in place, an External SubCA can shoot themselves in the foot but not endanger anyone else. We're limiting the damage. I only hope that if that happens, the press and public see it as very limited, and not just another example of a CA messing up.

-Rick

From: Steve Roylance [mailto:steve.roylance at globalsign.com]
Sent: Sunday, April 07, 2013 6:41 AM
To: Ryan Sleevi; Rick Andrews
Cc: public at cabforum.org
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU

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<mailto:sleevi at google.com>> wrote:

On Fri, Apr 5, 2013 at 6:35 PM, Rick Andrews <Rick_Andrews at symantec.com<mailto: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> [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Wednesday, March 27, 2013 6:50 AM
To: public at cabforum.org<mailto: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<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130408/c1bd4f38/attachment-0003.html>