On Thu, Jun 23, 2016 at 2:45 PM, Ben Wilson <ben.wil...@digicert.com> wrote:
> Another issue that needs to be resolved involves the Federal Bridge CA > 2013 (“Federal Bridge”). When a publicly trusted sub CA cross-certifies > the Federal Bridge, then all of the CAs cross-certified by the Federal > Bridge are trusted. > It should be clear by this point that it is not acceptable for CAs trusted by the Mozilla program to cross-sign the Federal Bridge, given that it has a number of non-WebTrust-audited subordinates. See, for example, the conversation with IdenTrust about their cross-signature. https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c27 So I would hope that by now, all of the cross-certificates for the Federal Bridge would have been expired or revoked. Certainly any that are still valid need to be revoked. Even if we do in general require subordinates with only revoked paths to be disclosed, I would be willing to make an exception for this specific case, since the Federal Bridge is a known issue. --Richard > The chart (https://crt.sh/mozilla-disclosures) then captures all > “non-publicly-trusted” sub CAs. For instance, the following CAs are now > caught up in the database, but there is no way to input them (or CAs > subordinate to them) into Salesforce because only the CA that > cross-certified the Federal Bridge has access to that certificate chain in > Salesforce. In otherwords, I don’t have access to input the DigiCert > Federated ID CA-1 or its sub CAs. > > > > CertiPath Bridge CA - G2 > > CT-CSSP-CA-A1 > > DigiCert Federated ID CA-1 > > DoD Interoperability Root CA 2 > > Entrust > > Exostar Federated Identity Service Root CA 2 > > Federal Bridge CA > > Federal Common Policy CA > > IdenTrust ACES CA 1 > > IdenTrust ACES CA 2 > > IdenTrust Global Common Root CA 1 > > ORC ACES 4 > > ORC NFI CA 2 > > ORC NFI CA 3 > > SAFE Bridge CA > > SAFE Bridge CA 02 > > State of Illinois > > STRAC Bridge Root Certification Authority > > Symantec Class 3 SSP Intermediate CA - G3 > > TSCP SHA256 Bridge CA > > USPTO_INTR_CA1 > > VeriSign Class 3 SSP Intermediate CA - G2 > > > > > > *From:* Eric Mill [mailto:e...@konklone.com] > *Sent:* Wednesday, June 22, 2016 9:19 PM > *To:* Kurt Roeckx <k...@roeckx.be> > *Cc:* Peter Bowen <pzbo...@gmail.com>; Richard Barnes <rbar...@mozilla.com>; > Jeremy Rowley <jeremy.row...@digicert.com>; Steve <steve.me...@gmail.com>; > mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson < > kwil...@mozilla.com>; Rob Stradling <rob.stradl...@comodo.com>; Ben > Wilson <ben.wil...@digicert.com> > *Subject:* Re: Intermediate certificate disclosure deadline in 2 weeks > > > > > > > > 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
