<p dir="ltr"><br>
On Sep 25, 2014 2:20 AM, "Erwann Abalea" <<a href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>> wrote:<br>
><br>
> Bonjour Ryan,<br>
><br>
> Le 23/09/2014 19:04, Ryan Sleevi a écrit :<br>
>><br>
>> Isn't there two aspects at play here? The first is the CRL for the technically constrained subCA. Since that subCA has to be disclosed to Moz (as part of the Moz program + Audit requirements), revoking that subCA 'should' also be a public act and uncontroversially so.<br>
><br>
><br>
> Extract from Mozilla inclusion policy:<br>
> All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited.<br>
> Pretty clear.<br>
><br>
><br>
> CABForum BR only requires a regular quality assessment for technically constrained subordinate CAs, performed by the issuing CA. No disclosure of the CA is required.<br>
></p>
<p dir="ltr">You misunderstood.</p>
<p dir="ltr">The issuing CA of the first constrained CA is public, ergo its CRL is public, and revoking the constrained CA (ICA1) is, transitively, public. That's because the issuing/root CA must make its revocation information available in a 24x7 repository.</p>
<p dir="ltr">However, all certificates - including those in scope of Gerv's OneCRL plan (ICA2, ICA3) - issued from this contained CA are not guaranteed to be public, nor are their CRLs.</p>
<p dir="ltr">Put differently, it does not seem OneCRL has a mechanism to handle revocation for the certs issued by ICA2 (it relies on OCSP Stapling to handle those issued by ICA3).</p>
<p dir="ltr">I think we are in agreement of the facts, but I was highlighting for Gerv that, combined with his question, there is a gap of coverage for ICA2.</p>