[Servercert-wg] [cabfpub] Is the PITRA requirement applicable to DTPs

[Adriano Santoni]

Thank you for replying, Ryan.

Indeed the BR are not clear on this aspect.

Right now I am not sure what kind of amendment would be best. I will 
think it over before proposing any.

Rgds

Adriano


Il 04/11/2019 18:11, Ryan Sleevi via Servercert-wg ha scritto:
> (Redirecting this to the servercert-wg@, since this is a BRs question)
>
> On Mon, Nov 4, 2019 at 2:47 AM Adriano Santoni via Public 
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
>     All,
>
>     this is probably an old question, but I could not find the answer
>     in the mailing list archives, so please bear with me.
>
>     In reading the BR, it is not clear to me whether a DTP is allowed
>     to start "issuing" certificates (i.e. start requesting the CA to
>     issue certificates based on their vetting) before having ever been
>     audited. CAs are required to pass a PITRA, before issuing their
>     first Publicly-Trusted Certificates, but I am not sure if the same
>     holds for DTPs. It seems to me that this aspect is not very clear
>     in the BR.
>
>     Adriano
>
>
> I mean, the DTP isn't the one performing the issuance though, are 
> they? It's the CA performing issuance, using information verified by 
> the DTP.
>
> TL;DR answer: No CA ever got in trouble with browsers for having more 
> audits than necessary. Several have gotten in trouble for having fewer 
> audits than necessary.
>
> If I'm understanding your question about where the confusion is 
> rooted, this is the question about the relationship between the 
> Section 1.3.2 requirements placed on DTPs (e.g. the contractual 
> existence) and the Section 8.4 requirements placed on DTPs (e.g. the 
> audit requirements).
>
> I agree with you that it's not clear, and I'm curious if you have 
> suggestions (given that DTP requirements are sprinkled throughout the 
> BRs) on how to simplify that:
>
> 1) The permissive CA/"default allow" reader would read the closing 
> sentence of the paragraph in 8.4, with its use of "*continue 
> performing*", to read that it's implicitly allowed until proven otherwise:
>
>     If the opinion is that the Delegated Third Party does not comply,
>     then the CA SHALL not allow the Delegated Third Party to *continue
>     performing* delegated functions.
>
>
> In this reading, the CA is arguing that they can allow performance 
> before any audit whatsoever, and only have to discontinue of the DTP 
> doesn't get it (since adverse findings alone ostensibly still fulfill 
> the requirements of this section)
>
> 2) The "secure by default" CA/"default deny" reader would read the 
> requirements in 1.3.2 to require an audit before hand. This is because 
> 1.3.2 requires (*emphasis added*)
>
>     *Before the CA authorizes a Delegated Third Party* to perform a
>     delegated function, the CA SHALL contractually require the
>     Delegated Third Party to: 
>
>     (1) Meet the qualification requirements of Section 5.3.1, when
>     applicable to the delegated function; 
>
>     (2) Retain documentation in accordance with Section 5.5.2; 
>
>     (3) *Abide by the other provisions of these Requirements that are
>     applicable to the delegated function*; and 
>
>     (4) Comply with (a) the CA’s Certificate Policy/Certification
>     Practice Statement or (b) the Delegated Third Party’s practice
>     statement that the CA has verified complies with these Requirements.
>
>
> In this reading, prior to allowing a DTP, the DTP must be 
> contractually required to abide by the provisions, including the 
> demonstration of an audit (per 8.4)
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191106/c9b5df85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4105 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191106/c9b5df85/attachment.p7s>