[cabfpub] Revocation Information

[Ryan Sleevi]

Gerv,

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.

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.

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.

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.

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 example.com, then issues an ICA (ICA2)
constrained to corp.example.com, serves a CRL via CRL.corp.example.com, and
issues an ICA (ICA3) constrained to dallas.corp.example.com, which issues
an EE to finance.dallas.corp.example.com

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.

OCSP MultiStaple is an option, but are you sure you want to negotiate that
with all clients - including the public internet?
On Sep 23, 2014 9:54 AM, "Gervase Markham" <gerv at mozilla.org> wrote:

> On 23/09/14 16:47, Erwann Abalea wrote:
> >> 3) Would you need some of that set of URLs to be secret (i.e. revealed
> >> to Mozilla, but you would prefer Mozilla not to reveal them to others)?
> >> If so, why?
> >
> > Secrecy of these URLs/CAs is permitted by Mozilla CA policy, for
> > technically constrained CAs.
>
> Exactly where technically constrained CAs fit into this is a very good
> question. For now, assume they are included, so the question is: do the
> reasons which might require a technically constrained subCA to be kept
> confidential apply to the URL and data of the CRL which may one day
> contain that subCA?
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140923/6b48dd81/attachment-0003.html>