[cabfpub] 17.5 Audit of Delegated Functions

[Ryan Hurst]

My understanding is the same as Robs.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst at globalsign.com
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Dec 21, 2012, at 1:15 PM, Rob Stradling <rob.stradling at comodo.com> wrote:

> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public