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. 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 <mailto: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 <http://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 <http://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 <https://konklone.com> | @konklone <https://twitter.com/konklone>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
