On Wed, Jun 22, 2016 at 6:11 PM, Kurt Roeckx <k...@roeckx.be> wrote: > On Wed, Jun 22, 2016 at 02:25:37PM -0700, Peter Bowen wrote: > > I think there are two things getting conflated here: > > > > 1) Disclosure of revoked unexpired CA certificates signed by a trusted CA > > > > 2) Disclosure of CA certificates signed by CAs that are the subject of #1 > > > > Imagine the following heirarchy: > > > > Univercert Root CA (in trust store) --(CA Cert A)--> Aperture Science > > Corporate Root --(CA Cert B)--> Aperture Science Server CA --(End > > Entity Cert)--> www.aperature.xa > > > > If CA Cert A is revoked, it goes in OneCRL. What about CA Cert B? > > Does it need to be disclosed? > > It's unclear to me what your example is, so I think what you meant > to say is that there are 4 certs in your case, each signing the > next one: > - Univercert Root CA (in trust store) > - Aperture Science (CA Cert A) > - Aperture Science Server CA (CA Cert B) > - www.aperature.xa (End Entity Cert) > > Before CA Cert A is revoked, CA Cert B needed to be disclosed. I > have no idea what the requirements currently list, but since there > no longer is a trust path from a root in trust store to CA Cert B > and it seems to me that we don't care that it's disclosed or not. >
Except that there *is* a trust path from a root in the trust store to CA Cert B, in practice. CA Cert A's revocation is completely meaningless if clients don't enforce that certificate's revocation. Peter's correctly pointing out a major issue, which is that all of these undisclosed intermediates may have themselves generated other intermediates, and they could be quite numerous. I'm not recommending a particular policy for dealing with them. I am saying that from a policy perspective, you have to treat revoked intermediates as entirely unrevoked, for at least Chrome and Firefox, without a commitment by those browsers to distribute the revocation data through their special channels. -- Eric > > Kurt > > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
