[cabfpub] 17.5 Audit of Delegated Functions

[Steve Roylance]

Hi Rick,

I'd agree with you if a CA only placed dNSNames or rfc822Names into the
permitted constraints but adding directoryNames as Rob said, means that
audits are not required as the CA has already done the work to close the
holes.

e.g.
Permitted Subtrees =
> dnsNames
> example.com
> rfc822names
> example.com
> directoryName
> O=Example Inc
> L= Locality
> S= State
> C=Country

I don't think you were in the Forum when we met in Paris and discussed the
best way to cover all the possibilities of how a certificate could be issued
and therefore mis issued.  Please see attached PPT which shows these.  Each
case was later reflected in Base Requirements 1.0.  Admittedly we didn't
pare this down further into dNSNames and directoryNames but that would have
been most peoples understanding to remove many of the loop holes in letting
third parties have a hand in validation processes.

I'm happy to work with you to ensure there's language in the BRs to make
sure this is clear.

Oh and if anyone wants anything explaining in my diagrams (As they may be a
little confusing the first time around) then let me know.

Happy holidays!!

Steve
 



From:  Rick Andrews <Rick_Andrews at symantec.com>
Date:  Friday, 21 December 2012 18:43
To:  "public at cabforum.org" <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
 
 
_______________________________________________ Public mailing list
Public at cabforum.orghttps://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121222/64d725fa/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: What was discussed in Paris.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1015149 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121222/64d725fa/attachment-0002.pptx>