[cabfpub] 17.5 Audit of Delegated Functions

[Rob Stradling]

On 21/12/12 18:43, Rick Andrews wrote:
> CABF members,
> It’s come to our attention that several people are interpreting this
> section of BR:
> *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.
> to mean that a Delegated Third Party that runs an External SubCA can
> avoid audit indefinitely if it simply has a name constraint in the SubCA
> limiting the domain names that it can issue to. The CA would be
> complying with “(2) performing the domain control validation itself”
> before it put the name constraint in the SubCA.
> This seems like a loophole to us, because without an audit, there’s no
> way to be sure that the Delegated Third Party is putting properly vetted
> info in the Subject DN field

The Sub-CA certificate could include directoryName constraints as well 
as dNSName constraints (and iPAddress constraints).  If the 
directoryName constraint permits only the full organization name and 
address of the Delegated Third Party, then I'd say that this would 
effectively force them to put "properly vetted info in the Subject DN 
field".

(Mozilla's draft CA policy v2.1 currently requires a directoryName 
constraint for name-constrained Code Signing CAs, but not for 
name-constrained SSL Server CAs.  Perhaps this is a loophole that should 
be fixed).

> , and populating certs with the required extensions.

True, but is this really enough to justify demanding that the 
name-constrained Delegated Third Party undergo a WebTrust or ETSI audit?

Even an audited CA might fail to populate certs with the required 
extensions, and (IINM) their auditor might not notice for months.

There are other ways for the PKI community to spot CAs that are failing 
to include required extensions in the certificates they issue: the EFF 
SSL Observatory highlighted some of these sorts of issues; Certificate 
Transparency will make it impossible for a public cert with missing 
required extensions to remain undetected (assuming somebody writes some 
code to monitor and analyze all certs that CT logs).

> I doubt this was the intent, because I had the impression that most
> people thought External SubCAs were a risky practice that needed to be
> more tightly controlled.

IINM, the main "loophole" that "most people" have regarded as "risky" is 
that unaudited External SubCAs have been able to issue certs to any 
domain name.  If an audited Issuing CA limits the permitted domain names 
and performs the domain control validation for each one, then  this 
loophole is closed.

> This seems to allow them to be less tightly controlled. Comments?

I don't understand how you can reach this conclusion.

> -Rick

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online