RE: Intermediate certificate disclosure deadline in 2 weeks

[Ben Wilson]

Peter is right, but the  problem is similar to what's in the Identrust thread 
mentioned by Richard.  "Cross-certifying a subordinated CA has been standard 
practice by not only IdenTrust, but other large CAs such as Symantec for more 
than a decade ..."

Trouble is, I can't tell by looking at https://crt.sh/mozilla-disclosures who 
it was that cross-certified the Federal Bridge.   If I could, then I could 
reach out to them and have them update the CA hierarchy in Salesforce.  

I am taking Richard's comment ,"I would be willing to make an exception for 
this specific case, since the Federal Bridge is a known issue," as an 
indication that  I do not need to disclose the DigiCert Federated ID CA-1 in 
the Salesforce database.


-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, June 23, 2016 3:35 PM
To: Eric Mill 
Cc: Ben Wilson ; Kurt Roeckx ; Richard 
Barnes ; Jeremy Rowley ; Steve 
; mozilla-dev-security-pol...@lists.mozilla.org; 
Kathleen Wilson ; Rob Stradling 
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

DigiCert didn't cross-sign the Federal PKI with their Mozilla trusted CAs.

I'm sure Ben will tell me I have my terminology wrong, but DigiCert basically 
operates two PKIs:
- DigiCert Public WebPKI
- DigiCert Shared FederatedPKI

The first is a set of CAs that are in the Mozilla program and CAs signed by the 
Mozilla program.  The second is a set of CAs that are signed by the US Federal 
PKI; they are not in the Mozilla program.

The problem is that some non-DigiCert CA int he Mozilla program signed the US 
Federal PKI.  The DigiCert Shared FederatedPKI is now brought in via that 
signature, with which they had nothing to do.

On Thu, Jun 23, 2016 at 1:41 PM, Eric Mill  wrote:
> Peter, I think I get what you're saying about this being a different 
> category of cross-sign, but could you spell out explicitly how this 
> differs from e.g. the Identrust cross-sign issue that Richard linked to?
>
> -- Eric
>
> On Thu, Jun 23, 2016 at 4:39 PM, Ben Wilson  wrote:
>>
>> That's correct.
>>
>> -Original Message-
>> From: Peter Bowen [mailto:pzbo...@gmail.com]
>> Sent: Thursday, June 23, 2016 2:39 PM
>> To: Ben Wilson 
>> Cc: Eric Mill ; Kurt Roeckx ; 
>> Richard Barnes ; Jeremy Rowley 
>> ; Steve ; 
>> mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson 
>> ; Rob Stradling 
>> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>>
>> On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson 
>> 
>> 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.   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.
>>
>> Ben,
>>
>> Correct me if I'm wrong, but the DigiCert CA you mention is part of a 
>> different PKI from the DigiCert public roots in Mozilla, right?  The 
>> only reason that it is showing in the list is because a non-DigiCert 
>> CA cross-signed the Federal PKI and the Federal PKI cross-signed the 
>> DigiCert CA in question, correct?
>>
>> Thanks,
>> Peter
>
>
>
>
> --
> konklone.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

RE: Intermediate certificate disclosure deadline in 2 weeks

[Jeremy Rowley]

Fed Root (not trusted) signs DigiCert Fed CA (not trusted)

A third CA (trusted) signs Fed Root (now trusted)

DigiCert Fed CA all of a sudden trusted but not through DigiCert. This CA now 
shows up on the list although it wasn’t DigiCert who signed it.

 

From: Eric Mill [mailto:e...@konklone.com] 
Sent: Thursday, June 23, 2016 2:41 PM
To: Ben Wilson 
Cc: Peter Bowen ; Kurt Roeckx ; Richard 
Barnes ; Jeremy Rowley ; Steve 
; mozilla-dev-security-pol...@lists.mozilla.org; 
Kathleen Wilson ; Rob Stradling 
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

 

Peter, I think I get what you're saying about this being a different category 
of cross-sign, but could you spell out explicitly how this differs from e.g. 
the Identrust cross-sign issue that Richard linked to?

 

-- Eric

 

On Thu, Jun 23, 2016 at 4:39 PM, Ben Wilson  > wrote:

That's correct.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com  ]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson  >
Cc: Eric Mill  >; Kurt Roeckx 
 >; Richard Barnes  >; Jeremy Rowley  >; Steve  >; mozilla-dev-security-pol...@lists.mozilla.org 
 ; Kathleen Wilson 
 >; Rob Stradling 
 >
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson  > 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.   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.

Ben,

Correct me if I'm wrong, but the DigiCert CA you mention is part of a different 
PKI from the DigiCert public roots in Mozilla, right?  The only reason that it 
is showing in the list is because a non-DigiCert CA cross-signed the Federal 
PKI and the Federal PKI cross-signed the DigiCert CA in question, correct?

Thanks,
Peter





 

-- 

konklone.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

Re: Intermediate certificate disclosure deadline in 2 weeks

[Eric Mill]

Peter, I think I get what you're saying about this being a different
category of cross-sign, but could you spell out explicitly how this differs
from e.g. the Identrust cross-sign issue that Richard linked to?

-- Eric

On Thu, Jun 23, 2016 at 4:39 PM, Ben Wilson  wrote:

> That's correct.
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, June 23, 2016 2:39 PM
> To: Ben Wilson 
> Cc: Eric Mill ; Kurt Roeckx ; Richard
> Barnes ; Jeremy Rowley ;
> Steve ;
> mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson <
> kwil...@mozilla.com>; Rob Stradling 
> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>
> On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson 
> 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.   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.
>
> Ben,
>
> Correct me if I'm wrong, but the DigiCert CA you mention is part of a
> different PKI from the DigiCert public roots in Mozilla, right?  The only
> reason that it is showing in the list is because a non-DigiCert CA
> cross-signed the Federal PKI and the Federal PKI cross-signed the DigiCert
> CA in question, correct?
>
> Thanks,
> Peter
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediate certificate disclosure deadline in 2 weeks

[Richard Barnes]

On Thu, Jun 23, 2016 at 2:45 PM, Ben Wilson  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 
> *Cc:* Peter Bowen ; Richard Barnes ;
> Jeremy Rowley ; Steve ;
> mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson <
> kwil...@mozilla.com>; Rob Stradling ; Ben
> Wilson 
> *Subject:* Re: Intermediate certificate disclosure deadline in 2 weeks
>
>
>
>
>
>
>
> On Wed, Jun 22, 2016 at 6:11 PM, Kurt Roeckx  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 
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Intermediate certificate disclosure deadline in 2 weeks

[Ben Wilson]

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 
Cc: Peter Bowen ; Richard Barnes ; 
Jeremy Rowley ; Steve ; 
mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson 
; Rob Stradling ; Ben Wilson 

Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

 

 

 

On Wed, Jun 22, 2016 at 6:11 PM, Kurt Roeckx  > 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  



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