<p dir="ltr">Gerv,</p>
<p dir="ltr">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.</p>
<p dir="ltr">This is similar, for example, to the work on RFC6962-bis that allows a CA to log the technically constrained intermediate in the CT log, but not the certs it issues.</p>
<p dir="ltr">However, of more meaningful discussion is what happens for the hierarchy beneath that CA? We assume it is all private - indistinguishable from a wildcard cert, for example.</p>
<p dir="ltr">How will Mozilla handle revocation for any intermediates _under_ that chain? The hierarchy is fully at the customer's discretion. Now, the public CA may prevent their customers from doing so (e.g. pathLenConstraint of 0), but there's no significantly compelling reason or requirement for this, and so it isn't a safe assumption.</p>
<p dir="ltr">These intermediates MAY only publish revocation information internally (not on the public network). For example, consider a publicly trusted ICA (ICA1) that is name constrained to <a href="http://example.com">example.com</a>, then issues an ICA (ICA2) constrained to <a href="http://corp.example.com">corp.example.com</a>, serves a CRL via <a href="http://CRL.corp.example.com">CRL.corp.example.com</a>, and issues an ICA (ICA3) constrained to <a href="http://dallas.corp.example.com">dallas.corp.example.com</a>, which issues an EE to <a href="http://finance.dallas.corp.example.com">finance.dallas.corp.example.com</a></p>
<p dir="ltr">Mozilla can crawl the CRL that contains ICA1. However, both ICA2 and ICA3's CRLs are only accessible internally. We can say ICA3's CRL doesn't matter, because EE needs to OCSP Staple, but that does nothing for ICA2.</p>
<p dir="ltr">OCSP MultiStaple is an option, but are you sure you want to negotiate that with all clients - including the public internet?</p>
<div class="gmail_quote">On Sep 23, 2014 9:54 AM, "Gervase Markham" <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23/09/14 16:47, Erwann Abalea wrote:<br>
>> 3) Would you need some of that set of URLs to be secret (i.e. revealed<br>
>> to Mozilla, but you would prefer Mozilla not to reveal them to others)?<br>
>> If so, why?<br>
><br>
> Secrecy of these URLs/CAs is permitted by Mozilla CA policy, for<br>
> technically constrained CAs.<br>
<br>
Exactly where technically constrained CAs fit into this is a very good<br>
question. For now, assume they are included, so the question is: do the<br>
reasons which might require a technically constrained subCA to be kept<br>
confidential apply to the URL and data of the CRL which may one day<br>
contain that subCA?<br>
<br>
Gerv<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div>