[cabfpub] 17.5 Audit of Delegated Functions

Fri Dec 21 19:55:48 UTC 2012

Rick,

In looking at this more, I note that the definition uses the phrase "the CA"
rather than "a CA."  So it isn't as clear as I thought.  But here are a
couple of other considerations - 

1.  The BRs do not adequately distinguish between internal and external CAs.
The definition of a CA is "[a]n organization that is responsible for the
creation, issuance, revocation, and management of Certificates.  The term
applies equally to both Roots CAs and Subordinate CAs."  So strike one
(external CAs are within this definition and not excepted out).   

2.  Section 8.1 requires CAs to comply not just with the Requirements but
also with the audit requirements of Section 17.  Even assuming that there
was an exception to auditing, any CA still needs to comply with all of the
other requirements.  In other words, the contractual delegation of CA duties
from one CA to another CA still requires that ALL of the CA duties are
performed and that there are no gaps in the performance of those duties.
That would require that someone review them and that they are included in
one CA's or the other CA's audit.  Anyone with a CA that is publicly trusted
has to anticipate that there will be compliance costs in order to remain
publicly trusted-there is no "free ride."  So strike two.

3.  The closest that we got in mentioning external CAs during version 1.0 of
the BRs was in section 8.4 (Trust Model) where we say, "The CA SHALL
disclose all Cross Certificates that identify the CA as the Subject,
provided that the CA arranged for or accepted the establishment of the trust
relationship (i.e. the Cross Certificate at issue)."  Therefore, a publicly
trusted CA will disclose its external CAs, and that disclosure will lead to
an understanding of the trust model (e.g. SSL Observatory).  If it is a true
external sub CA, then maybe we should have defined external sub CA and
included them in section 8.4, since "Cross Certificate" is defined as "A
certificate that is used to establish a trust relationship between two Root
CAs."

4.   The BRs do not grant an exception for CAs that are technically
constrained.  This was something that was discussed in parallel on the
Mozilla list.  I would have to look through our minutes and mailing list
history to see what was said here about technical constraints.  However,
there was some discussion because we added a footnote in Section F of
Intermediate CAs in Appendix B that says, "Non-critical Name Constraints are
an exception to RFC 5280 that MAY be used until the Name Constraints
extension is supported by Application Software Suppliers whose software is
used by a substantial portion of Relying Parties worldwide."  There has,
however, been debate in PKIX about allowing non-critical Name Constraints
because in not breaking one thing we may be breaking another.  (Those who
use Name Constraints as a solution want it to work 100% of the time.)  So,
because there is no clear exception, I'd say strike three.

I'm sure there are other arguments for either side of this issue, so I won't
go through the BRs any more to spot more relevant provisions.

Cheers,

Ben

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Friday, December 21, 2012 12:12 PM
To: 'Rick Andrews'; public at cabforum.org
Subject: Re: [cabfpub] 17.5 Audit of Delegated Functions

That does not meet the definition of a Delegated Third Party.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
Sent: Friday, December 21, 2012 12:07 PM
To: ben at digicert.com; public at cabforum.org
Subject: RE: [cabfpub] 17.5 Audit of Delegated Functions

Right, I'm not talking about Enterprise CAs or RAs; external (to the CA)
parties that the CA has granted the right to sign their own certificates (by
way of the CA signing the  party's intermediate CA and including a name
constraint in that intermediate). I think that meets the definition of
Delegated Third Party. Is it the intent of the BRs not require them to be
audited?

-Rick

From: Ben Wilson [mailto:ben at digicert.com] 
Sent: Friday, December 21, 2012 10:53 AM
To: Rick Andrews; public at cabforum.org
Subject: RE: [cabfpub] 17.5 Audit of Delegated Functions

Rick, 

Just so I understand your question more fully, you're talking about an
external sub CA relying on name constraints and not an "Enterprise RA" or
internal sub CA that is technically constrained in other ways?   When the
BRs use the phrase "Delegated Third Party" (including in Section 11), that
term means "a natural person or Legal Entity that is not the CA."

Ben 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rick Andrews
Sent: Friday, December 21, 2012 11:43 AM
To: public at cabforum.org
Subject: [cabfpub] 17.5 Audit of Delegated Functions

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, and populating certs with the required extensions.

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. This seems to allow them to be less tightly controlled.
Comments?

-Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121221/0a0b80fa/attachment-0004.html>