Re: Intermediate certificate disclosure deadline was 2 weeks ago!! (was Re: Salesforce offline Tuesday, June 28, for data import)

[Nick Lamb]

Hello again Rob,

"ISRG Root X1" is listed as "Unconstrained id-kp-serverAuth Trust: Disclosure 
is required!"

I believe this root is now (or shortly will be) trusted directly by NSS, and so 
isn't an intermediate and shouldn't appear on the list.

Before it was added to NSS, it simply wasn't trusted at all, although it is 
seen in some CT logs. So I think under either circumstance it shouldn't be 
listed as "disclosure is required".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediate certificate disclosure deadline was 2 weeks ago!! (was Re: Salesforce offline Tuesday, June 28, for data import)

[Rob Stradling]

On 09/08/16 00:16, Kathleen Wilson wrote:


It seems to me that as long as a revoked intermediate certificate has
been disclosed (i.e. in Salesforce) that the certificates that it signed
do not need to be disclosed.


I've just changed "Probably!" to "Unknown" (for the "Unconstrained, but 
all unexpired observed paths Revoked" group on 
https://crt.sh/mozilla-disclosures).


"Unknown" is appropriate because crt.sh cannot know whether or not it 
has observed all of the paths that exist.




--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Intermediate certificate disclosure deadline was 2 weeks ago!! (was Re: Salesforce offline Tuesday, June 28, for data import)

[Rob Stradling]

On 08/08/16 10:25, Rob Stradling wrote:


Nick, Peter,

I looked at https://crt.sh/mozilla-disclosures immediately after the
Symantec cross-cert expired, and I was surprised to see no change.  I
was on holiday all last week, so I'm only just investigating it properly
now.

I suspect crt.sh is getting confused by the combination of the expired
Symantec cross-cert and the revoked Identrust cross-cert.  If they'd
both expired or both been revoked, I suspect this (presumed) bug would
not have been discovered.

I'm going to try changing
  "Unconstrained, but all observed paths Revoked"
to
  "Unconstrained, but all unexpired observed paths Revoked"


Bug fixed.

All of the FPKI intermediates now show up in this group:
https://crt.sh/mozilla-disclosures#trustrevoked

Note that crt.sh says "Disclosure is probably required!" for this group, 
as per Richard's suggestion to "err on the side of disclosing 
subordinates under a revoked certificate, with exceptions..." [1].


Richard did say he'd "be willing to make an exception for this specific 
case, since the Federal Bridge is a known issue" [2].


Kathleen,
Would it be possible to add a field (to Salesforce and to 
https://mozillacaprogram.secure.force.com/CA/PublicIntermediateCertsRevokedCSVFormat) 
so that crt.sh can track these exceptions?



[1] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg03468.html


[2] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg03476.html


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Intermediate certificate disclosure deadline was 2 weeks ago!! (was Re: Salesforce offline Tuesday, June 28, for data import)

[Rob Stradling]

On 02/08/16 14:46, Peter Bowen wrote:

On Tue, Aug 2, 2016 at 5:11 AM, Nick Lamb  wrote:

Rob, today I examined https://crt.sh/mozilla-disclosures because I was interested to see if the now 
expired signature from Symantec's "VeriSign Class 3 SSP Intermediate CA - G2" of 
"Federal Bridge CA 2013" had the expected effect.

I understand that traversing a network with known and potentially unknown loops in it is 
tricky to do correctly, so I am not sure whether the fact that a large number of "US 
Government" CAs are still listed as Unconstrained id-kp-serverAuth Trust reflects a 
problem with that traversal or a real, previously undetected trust relationship that I 
wasn't able to spot by eye.


Nick,

I believe this to be a bug in crt.sh. I have a local copy of all the
cross-certificates and the US Federal PKI and subordinate CAs from
there do not appear in the current trust graph.

Thanks,
Peter


Nick, Peter,

I looked at https://crt.sh/mozilla-disclosures immediately after the 
Symantec cross-cert expired, and I was surprised to see no change.  I 
was on holiday all last week, so I'm only just investigating it properly 
now.


I suspect crt.sh is getting confused by the combination of the expired 
Symantec cross-cert and the revoked Identrust cross-cert.  If they'd 
both expired or both been revoked, I suspect this (presumed) bug would 
not have been discovered.


I'm going to try changing
  "Unconstrained, but all observed paths Revoked"
to
  "Unconstrained, but all unexpired observed paths Revoked"

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Nick Lamb]

On Saturday, 9 July 2016 00:21:27 UTC+1, Rick Andrews  wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way 
> cross-certification with the FBCA and to remove the cross-certificate from 
> the Symantec CA to the FBCA. The cross certificate is expiring on June 31, 
> 2016 and Symantec does not intend to renew the certificate going forward.

Thank you Rick. That should make a big dent in the known undisclosed list just 
over three weeks from now and, thus hopefully eliminate the (presumably small 
but unknown) risk from mistakes within the FPKI contaminating the web PKI.
___
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

[Rick Andrews]

On Friday, July 8, 2016 at 4:21:27 PM UTC-7, Rick Andrews wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way 
> cross-certification with the FBCA and to remove the cross-certificate from 
> the Symantec CA to the FBCA. The cross certificate is expiring on June 31, 
> 2016 and Symantec does not intend to renew the certificate going forward.

Correction - it's expiring on July 31, 2016.
___
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

[Rick Andrews]

GSA which governs FPKI recently approved Symantec’s proposal for one-way 
cross-certification with the FBCA and to remove the cross-certificate from the 
Symantec CA to the FBCA. The cross certificate is expiring on June 31, 2016 and 
Symantec does not intend to renew the certificate going forward.

___
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

[Nick Lamb]

On Thursday, 30 June 2016 09:29:15 UTC+1, Rob Stradling  wrote:
> The cross-certificate issued by Symantec to "Federal Bridge CA 2013" 
> (https://crt.sh/?id=12638543) expires in 1 month.  I'm wondering if 
> there's any point in revoking this intermediate or the two other 
> intermediates that Peter mentioned.

Have we seen _anything_ from Symantec, even informally to say they intend for 
this to expire and not be replaced ?

Historically the experience has been that CAs are very happy to pretend they 
didn't even realise there was a problem right up until trust stores threaten to 
remove their roots and then they suddenly remember that they'd been intending 
to voluntarily comply very soon and just forgot to mention it.

So if we don't have a promise from Symantec that they won't renew this, it 
makes sense to assume they will and for Mozilla to behave accordingly.
___
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

[Rob Stradling]

On 30/06/16 06:34, Peter Bowen wrote:

I think there is confusion over the generic term “Symantec”.  There is no issue 
for Symantec (the company) to be an affiliate of the USG FPKI and to operate 
CAs mutually cross-certified with the USG FPKI.  Additionally there is no issue 
with Symantec (or anyone else) to operate CAs included in the Mozilla trust 
anchor list.

Where there is a problem, as Richard pointed out, is when a CA in the Mozilla 
trust anchor list issues a cross-certificate to a CA mutually cross-certified 
by the USG FPKI.  The Mozilla policy is that every CA that is the subject of a 
cross issued by a CA in the Mozilla trust anchor list must comply with Mozilla 
policy.  This is recursively true as well — “grandchild”, “great-grandchild”, 
etc CAs must comply with Mozilla policy.

Instead of revoking the Symantec SSP to Federal Bridge certificate, Symantec 
could instead revoke these two certificates to separate the USG FPKI from their 
Mozilla trusted CAs:
https://crt.sh/?id=2733031
https://crt.sh/?id=12722020


After a CA has disclosed an intermediate cert as revoked, how long does 
it take for that revocation to be added to OneCRL and for the majority 
of Firefox clients to pick up that updated OneCRL?


The cross-certificate issued by Symantec to "Federal Bridge CA 2013" 
(https://crt.sh/?id=12638543) expires in 1 month.  I'm wondering if 
there's any point in revoking this intermediate or the two other 
intermediates that Peter mentioned.



This is probably a better option and would avoid the issues you raised before.

Thanks,
Peter


On Jun 29, 2016, at 10:18 PM, Myers, Kenneth (10421) 
 wrote:

Thanks Eric.


1)  Mutual trust is dependent on an exchange of certificates as outlined in 
the MOA and not the receipt. If one is removed, both must be removed per the 
MOA. It is currently being discussed to allow only a certificate receipt 
because mutual trust is a fundamental principle of the Federal Bridge. Revoking 
the certificate breaches the agreement. The IdenTrust CA is operated under a 
different program which coincidentally removed the certificate exchange 
requirement around the same time it was brought up in the forum and in the FPKI 
SSL testing.

2)  The federal bridge is an identity hub and not an anchor. Trust is 
established through the cert chain to Federal Common Policy and not through a 
trust bundle or a trust store. Its purpose is to connect organizational PKIs so 
an affiliate or federal agency can continue to use their root CA as a trust 
anchor without the need to install other roots. By entering into an agreement 
with the Federal Bridge, all affiliates (Symantec included) recognize they 
trust certificates issued by other affiliates of the Federal Bridge based on 
the policy mapping in certificate exchange. All certificates are issued against 
the same criteria as outlined in the Federal Bridge CP and mapped to affiliate 
CPs.

Ken


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Peter Bowen]

I think there is confusion over the generic term “Symantec”.  There is no issue 
for Symantec (the company) to be an affiliate of the USG FPKI and to operate 
CAs mutually cross-certified with the USG FPKI.  Additionally there is no issue 
with Symantec (or anyone else) to operate CAs included in the Mozilla trust 
anchor list.

Where there is a problem, as Richard pointed out, is when a CA in the Mozilla 
trust anchor list issues a cross-certificate to a CA mutually cross-certified 
by the USG FPKI.  The Mozilla policy is that every CA that is the subject of a 
cross issued by a CA in the Mozilla trust anchor list must comply with Mozilla 
policy.  This is recursively true as well — “grandchild”, “great-grandchild”, 
etc CAs must comply with Mozilla policy.

Instead of revoking the Symantec SSP to Federal Bridge certificate, Symantec 
could instead revoke these two certificates to separate the USG FPKI from their 
Mozilla trusted CAs:
https://crt.sh/?id=2733031
https://crt.sh/?id=12722020

This is probably a better option and would avoid the issues you raised before.

Thanks,
Peter

> On Jun 29, 2016, at 10:18 PM, Myers, Kenneth (10421) 
>  wrote:
> 
> Thanks Eric.
> 
> 
> 1)  Mutual trust is dependent on an exchange of certificates as outlined 
> in the MOA and not the receipt. If one is removed, both must be removed per 
> the MOA. It is currently being discussed to allow only a certificate receipt 
> because mutual trust is a fundamental principle of the Federal Bridge. 
> Revoking the certificate breaches the agreement. The IdenTrust CA is operated 
> under a different program which coincidentally removed the certificate 
> exchange requirement around the same time it was brought up in the forum and 
> in the FPKI SSL testing.
> 
> 2)  The federal bridge is an identity hub and not an anchor. Trust is 
> established through the cert chain to Federal Common Policy and not through a 
> trust bundle or a trust store. Its purpose is to connect organizational PKIs 
> so an affiliate or federal agency can continue to use their root CA as a 
> trust anchor without the need to install other roots. By entering into an 
> agreement with the Federal Bridge, all affiliates (Symantec included) 
> recognize they trust certificates issued by other affiliates of the Federal 
> Bridge based on the policy mapping in certificate exchange. All certificates 
> are issued against the same criteria as outlined in the Federal Bridge CP and 
> mapped to affiliate CPs.
> 
> Ken

___
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

[Rob Stradling]

On 27/06/16 12:13, Myers, Kenneth (10421) wrote:

The Federal PKI has a tool to help identify trust paths, 
FPKI-graph.fpki-lab.gov<http://fpki-graph.fpki-lab.gov>.

I can do a true-up between the Mozilla CA list and FPKI trust paths to help 
identify which path may be causing the issue.


Hi Kenneth.  It would be great if you could do that, especially if there 
are any trust paths that are not yet known to CT / crt.sh.


I've just run some analysis on the crt.sh DB.  It's the following 2 
cross-certificates that are of interest:


https://crt.sh/?id=9114292
  Issuer: IdenTrust ACES CA 1
  Subject: Federal Bridge CA 2013
  OneCRL: Already revoked.
  Salesforce: Not yet disclosed.

https://crt.sh/?id=12638543
  Issuer: VeriSign Class 3 SSP Intermediate CA - G2
  Subject: Federal Bridge CA 2013
  OneCRL: Not yet revoked.
  Salesforce: Not yet disclosed.

If/when both of these intermediates are disclosed to Salesforce as 
"revoked", crt.sh should (once Mozilla have updated the CSV reports) 
detect the FPKI trust paths as "revoked".


Richard Barnes wrote on 23rd:
"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"


That Symantec cross-cert has not yet even been revoked via CRL!


Kenneth Myers
Supporting the GSA Federal PKI Management Authority
Protiviti | Government Solutions | Manager
Alexandria | +1 571-366-6120<tel:+1%20571-366-6120> | 
kenneth.my...@protiviti.com<mailto:kenneth.my...@protiviti.com>
Connect: LinkedIn<https://www.linkedin.com/in/kennethmy> | Thought Leadership: 
Protiviti.com<http://www.protiviti.it/en-US/Pages/Insights.aspx>

On Jun 24, 2016, at 08:01, 
"dev-security-policy-requ...@lists.mozilla.org<mailto:dev-security-policy-requ...@lists.mozilla.org>"
 
<dev-security-policy-requ...@lists.mozilla.org<mailto:dev-security-policy-requ...@lists.mozilla.org>>
 wrote:

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 3:35 PM
To: Eric Mill <e...@konklone.com<mailto:e...@konklone.com>>
Cc: Ben Wilson <ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>; Kurt Roeckx <k...@roeckx.be<mailto:k...@roeckx.be>>; Richard Barnes 
<rbar...@mozilla.com<mailto:rbar...@mozilla.com>>; Jeremy Rowley <jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Steve 
<steve.me...@gmail.com<mailto:steve.me...@gmail.com>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; Kathleen Wilson 
<kwil...@mozilla.com<mailto:kwil...@mozilla.com>>; Rob Stradling <rob.stradl...@comodo.com<mailto:rob.stradl...@comodo.com>>
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 
<e...@konklone.com<mailto:e...@konklone.com>> 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 
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>> wrote:

That's correct.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson <ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>
Cc: Eric Mill <e...@konklone.com<mailto:e...@konklone.com>>; Kurt Roeckx 
<k...@roeckx.be<mailto:k...@roeckx.be>>;
Richard Barnes <rbar...@mozilla.com<mailto:rbar...@mozilla.com>>; Jeremy Rowley
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Steve 
<steve.me...@gmail.com<mailto:steve.me...@gmail.com>>;
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>;
 Kathleen Wilson
<kwil...@mozilla.com<mailto:kwil...@mozilla.com>>; Rob Stradling 
<rob.stradl...@comodo.com<mailto:rob.stradl...@comodo.com>>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson
<

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rob Stradling]

On 27/06/16 01:07, Nick Lamb wrote:

On Sunday, 26 June 2016 21:26:06 UTC+1, Ben Laurie  wrote:

My concern is that is is trivial to demonstrate an intermediate is
revoked, yet still validate a chain that includes that "revoked"
certificate.


Sure. If you decide not to check for revocation, then you won't know if it's 
revoked. I don't think there's any surprise there. If your revocation check 
depends on, say, Mozilla compiling a list of revoked intermediates, then you 
won't know about revocations unless they're on that list.

I'm still hesitant as I wait for the other shoe to drop, surely you already 
knew all this?


Just to reiterate: https://crt.sh/mozilla-disclosures is only 
considering an intermediate to be "revoked" if it has been disclosed to 
Salesforce as "revoked".


Mozilla have said that they intend to generate OneCRL from the 
Salesforce data.  OneCRL is an effective revocation mechanism in Firefox.


https://crt.sh/mozilla-disclosures is *not* considering CRLs and/or OCSP.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Nick Lamb]

On Sunday, 26 June 2016 21:26:06 UTC+1, Ben Laurie  wrote:
> My concern is that is is trivial to demonstrate an intermediate is
> revoked, yet still validate a chain that includes that "revoked"
> certificate.

Sure. If you decide not to check for revocation, then you won't know if it's 
revoked. I don't think there's any surprise there. If your revocation check 
depends on, say, Mozilla compiling a list of revoked intermediates, then you 
won't know about revocations unless they're on that list. 

I'm still hesitant as I wait for the other shoe to drop, surely you already 
knew all this?
___
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]

And for the benefit of readers of the thread not already familiar with
this, below are the two documented browser approaches to revocation of
intermediates that I'm aware of, for Firefox and Chrome.

Both require browser-maintained (not CA-maintained) lists of revoked
certificates to be updated with the intermediate, in order for clients to
enforce an intermediate's revocation.

-

Firefox: https://wiki.mozilla.org/CA:RevocationPlan

"Revocation of intermediate certificates is only checked during EV
validation."

"The main focus of OneCRL is to cover intermediate CA certificates."

-

Chrome: https://dev.chromium.org/Home/chromium-security/crlsets

"Online (i.e. OCSP and CRL) checks are not, generally, performed by Chrome.
They can be enabled in the options and, in some cases, the underlying
system certificate library always performs these checks no matter what
Chromium does. Otherwise they are only performed when verifying an EV
certificate that is not covered by a fresh CRLSet."

"For size reasons, the list doesn't include all CRLs - EV CRLs and CRLs
with good reason codes are taken in preference. CRLs which cover
intermediates are typically small and valuable so we try to take as many as
possible."

On Sat, Jun 25, 2016 at 10:50 AM, Peter Bowen  wrote:

> On Sat, Jun 25, 2016 at 3:50 AM, Ben Laurie  wrote:
> > On 25 June 2016 at 00:56, Rob Stradling 
> wrote:
> >> On 24/06/16 14:38, Rob Stradling wrote:
> >>>
> >>> I've just updated https://crt.sh/mozilla-disclosures.
> >>>
> >>> There's now a separate grouping for undisclosed intermediates for which
> >>> all observed paths to a trusted root have been "revoked".
> >>>
> >>> A path is considered to be "revoked" if at least one intermediate in
> the
> >>> path has been 1) disclosed to Salesforce AND 2) marked as Revoked in
> >>> Salesforce and/or OneCRL.
> >
> > I am curious how this is supposed to work. The issuer is identified by
> > the Issuer DN. Revoked certificates are identified by serial number
> > (in CRLs). So ... how is an intermediate ever revoked, in reality?
>
> It is not the CA that is revoked, it is the path from the trust anchor
> to the CA that is revoked.  The Mozilla requirement is not disclosure
> of Issuers, it is the disclosure of CA certificates. Given this,
> revocation is a reasonable check.
>
> 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

[Peter Bowen]

On Sat, Jun 25, 2016 at 3:50 AM, Ben Laurie  wrote:
> On 25 June 2016 at 00:56, Rob Stradling  wrote:
>> On 24/06/16 14:38, Rob Stradling wrote:
>>>
>>> I've just updated https://crt.sh/mozilla-disclosures.
>>>
>>> There's now a separate grouping for undisclosed intermediates for which
>>> all observed paths to a trusted root have been "revoked".
>>>
>>> A path is considered to be "revoked" if at least one intermediate in the
>>> path has been 1) disclosed to Salesforce AND 2) marked as Revoked in
>>> Salesforce and/or OneCRL.
>
> I am curious how this is supposed to work. The issuer is identified by
> the Issuer DN. Revoked certificates are identified by serial number
> (in CRLs). So ... how is an intermediate ever revoked, in reality?

It is not the CA that is revoked, it is the path from the trust anchor
to the CA that is revoked.  The Mozilla requirement is not disclosure
of Issuers, it is the disclosure of CA certificates. Given this,
revocation is a reasonable check.

Thanks,
Peter
___
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 Laurie]

On 25 June 2016 at 00:56, Rob Stradling <rob.stradl...@comodo.com> wrote:
> On 24/06/16 14:38, Rob Stradling wrote:
>>
>> I've just updated https://crt.sh/mozilla-disclosures.
>>
>> There's now a separate grouping for undisclosed intermediates for which
>> all observed paths to a trusted root have been "revoked".
>>
>> A path is considered to be "revoked" if at least one intermediate in the
>> path has been 1) disclosed to Salesforce AND 2) marked as Revoked in
>> Salesforce and/or OneCRL.

I am curious how this is supposed to work. The issuer is identified by
the Issuer DN. Revoked certificates are identified by serial number
(in CRLs). So ... how is an intermediate ever revoked, in reality?

>>
>> I'm working on the problem of how to uncover which trust paths exist but
>> have not (yet) been revoked...
>
>
> crt.sh now shows more info.  Go to https://crt.sh/mozilla-disclosures, then
> click on a cert's SHA-1 thumbprint, then click the "Subject" link to go to
> the relevant "?caid=" page.
>
> (Alternatively, append "=mozilladisclosure" to any "?caid=" URL).
>
> The list of "Certificates" issued to the CA will have a "Mozilla Trust
> (id-kp-serverAuth)" column.
>
>
>> On 23/06/16 22:42, Ben Wilson wrote:
>>>
>>> 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 <e...@konklone.com>
>>> Cc: Ben Wilson <ben.wil...@digicert.com>; Kurt Roeckx
>>> <k...@roeckx.be>; 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>
>>> 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 <e...@konklone.com> 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 <ben.wil...@digicert.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> That's correct.
>>>>>
>>>>> -Original Message-
>>>>> From: Peter Bowen [mailto:pzbo...@gmail.com]
>>>>> Sent: Thursday, June 23, 2016 2:39 PM
>>>>> To: Ben Wilson <ben.wil...@digicert.com>
>>>>> Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>;
>>>>> Richard Barnes <rbar...@mozilla.com>; Jeremy

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rob Stradling]

On 24/06/16 14:38, Rob Stradling wrote:

I've just updated https://crt.sh/mozilla-disclosures.

There's now a separate grouping for undisclosed intermediates for which
all observed paths to a trusted root have been "revoked".

A path is considered to be "revoked" if at least one intermediate in the
path has been 1) disclosed to Salesforce AND 2) marked as Revoked in
Salesforce and/or OneCRL.

I'm working on the problem of how to uncover which trust paths exist but
have not (yet) been revoked...


crt.sh now shows more info.  Go to https://crt.sh/mozilla-disclosures, 
then click on a cert's SHA-1 thumbprint, then click the "Subject" link 
to go to the relevant "?caid=" page.


(Alternatively, append "=mozilladisclosure" to any "?caid=" URL).

The list of "Certificates" issued to the CA will have a "Mozilla Trust 
(id-kp-serverAuth)" column.



On 23/06/16 22:42, Ben Wilson wrote:

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 <e...@konklone.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; Kurt Roeckx
<k...@roeckx.be>; 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>
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 <e...@konklone.com> 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 <ben.wil...@digicert.com>
wrote:


That's correct.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>;
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>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

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

Re: Intermediate certificate disclosure deadline in 2 weeks

[Kathleen Wilson]

On 6/21/16 8:26 AM, Rob Stradling wrote:

On 21/06/16 15:55, Ben Wilson wrote:

Rob,


Ben, thanks for passing on the details.  My analysis is below...


So far they are -

https://crt.sh/?sha1=e12ba5aeb7613a72cc9652f1673017a5d8fc7479
  - technically constrained  warning

https://crt.sh/?sha1=8c6c7a20b48ef3bcb0fcb203008773846611486a
  - technically constrained  warning

https://crt.sh/?sha1=69bdbd7760f0fc58021c290c39243351914dadc5
  - technically constrained  warning

https://crt.sh/?sha1=107cce8b25af9b6cfabada125967aed4ef5bafe2
  - technically constrained  warning


Section 9 of the Inclusion Policy [1] says:
  "For a certificate to be considered technically constrained
   ...
   The subordinate CA certificate MUST also include within
   excludedSubtrees an iPAddress GeneralName of 32 zero octets
   (covering the IPv6 address range of ::0/0)."

These four intermediate certs only exclude the IPv4 address space, so I
would say that they don't qualify as "technically constrained".
Therefore, they need to be disclosed to Salesforce.

Kathleen, if you agree that Salesforce should not be showing the
"technically constrained warning" for these four intermediates, please
could you ask your Salesforce consultant to fix it?



I will look into this to see if the PEM->JSON tool (provided by David 
Keeler) needs to be updated to take this into account.






https://crt.sh/?sha1=d92b8d4859538692e435ad78dd876b03601eae96
  - PEM too long

https://crt.sh/?sha1=3948a71e4b39768a016fa3b13175e41197f8bf28
  - PEM too long


Kathleen, what's the size limit?  Can it be increased?



Size limit for PEM is 7,500 characters.

The two certs listed above have PEM character count greater than 29,800. 
Hopefully there are not a lot of intermediate certs that have PEM data 
that is larger than 7500 characters. So, I think those are exceptional 
cases that can be handled by entering the data manually (rather than 
supplying the PEM).


If there are no objections to this approach, then I will ask my 
consultant to update the error to indicate that the cert's data should 
be entered by hand when the PEM is too long, and I will also update the 
CA:SalesforceCommunity wiki page with this info.


Thanks,
Kathleen


___
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

[Adrian R.]

according to this:
https://test4.fpki.18f.gov/
https://github.com/18F/fpki-testing

Symantec is the second cross-signer of the Federal Bridge, with a root CA that 
was supposed to be dormant according to the description here:

https://www.symantec.com/theme/roots
Root 10

VeriSign Universal Root CA

Description: While this root is not being used today for Symantec's commercial 
certificate offerings, it is a SHA-256 root that will be used in the future to 
as the root of Trust for Class1, 2 and 3 certificates SHA-256 certificates and 
should be included in root stores.

Country = US
Organization = VeriSign, Inc.
Organizational Unit = VeriSign Trust Network
Organizational Unit = (c) 2008 VeriSign, Inc. - For authorized use only
Common Name = VeriSign Universal Root Certification Authority
Serial Number: 40 1a c4 64 21 b3 13 21 03 0e bb e4 12 1a c5 1d



signed a certificate for a Sub-CA:
Serial number= 31:6C:EB:69:1D:CB:2E:15:3D:9B:FA:8A:12:1B:D5:2D

CN = VeriSign Class 3 SSP Intermediate CA - G2
OU = VeriSign Trust Network
O = "VeriSign, Inc."
C = US

which in turn signed the Federal Bridge:
serial number= 10:81:BD:A3:47:84:D0:BB:C1:D4:D1:27:83:48:C5:FA
issuer:
CN = VeriSign Class 3 SSP Intermediate CA - G2
OU = VeriSign Trust Network
O = "VeriSign, Inc."
C = US

subject:
CN = Federal Bridge CA 2013
OU = FPKI
O = U.S. Government
C = US


Adrian R.


On Friday, 24 June 2016 00:35:33 UTC+3, Peter Bowen  wrote:
> 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.
> 
___
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

[Rob Stradling]

I've just updated https://crt.sh/mozilla-disclosures.

There's now a separate grouping for undisclosed intermediates for which 
all observed paths to a trusted root have been "revoked".


A path is considered to be "revoked" if at least one intermediate in the 
path has been 1) disclosed to Salesforce AND 2) marked as Revoked in 
Salesforce and/or OneCRL.


I'm working on the problem of how to uncover which trust paths exist but 
have not (yet) been revoked...


On 23/06/16 22:42, Ben Wilson wrote:

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 <e...@konklone.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; Kurt Roeckx <k...@roeckx.be>; 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>
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 <e...@konklone.com> 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 <ben.wil...@digicert.com> wrote:


That's correct.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>;
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>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

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


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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]

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 <e...@konklone.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; Kurt Roeckx <k...@roeckx.be>; 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>
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 <e...@konklone.com> 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 <ben.wil...@digicert.com> wrote:
>>
>> That's correct.
>>
>> -Original Message-
>> From: Peter Bowen [mailto:pzbo...@gmail.com]
>> Sent: Thursday, June 23, 2016 2:39 PM
>> To: Ben Wilson <ben.wil...@digicert.com>
>> Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>; 
>> 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>
>> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>>
>> On Thu, Jun 23, 2016 at 11:45 AM, 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.   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 <ben.wil...@digicert.com>
Cc: Peter Bowen <pzbo...@gmail.com>; Kurt Roeckx <k...@roeckx.be>; 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>
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 <ben.wil...@digicert.com 
<mailto:ben.wil...@digicert.com> > wrote:

That's correct.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com <mailto:pzbo...@gmail.com> ]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Cc: Eric Mill <e...@konklone.com <mailto:e...@konklone.com> >; Kurt Roeckx 
<k...@roeckx.be <mailto:k...@roeckx.be> >; Richard Barnes <rbar...@mozilla.com 
<mailto:rbar...@mozilla.com> >; Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; Steve <steve.me...@gmail.com 
<mailto:steve.me...@gmail.com> >; mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Kathleen Wilson 
<kwil...@mozilla.com <mailto:kwil...@mozilla.com> >; Rob Stradling 
<rob.stradl...@comodo.com <mailto:rob.stradl...@comodo.com> >
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson <ben.wil...@digicert.com 
<mailto: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.   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 <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

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 <ben.wil...@digicert.com> wrote:

> That's correct.
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, June 23, 2016 2:39 PM
> To: Ben Wilson <ben.wil...@digicert.com>
> Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>; 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>
> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>
> On Thu, Jun 23, 2016 at 11:45 AM, 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.   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 <https://twitter.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 <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

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

Re: Intermediate certificate disclosure deadline in 2 weeks

[Eric Mill]

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

[Kurt Roeckx]

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.


Kurt

___
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

[Peter Bowen]

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?

Thanks,
Peter

On Wed, Jun 22, 2016 at 2:12 PM, Richard Barnes  wrote:
> I think the vision is that in the long run, OneCRL would be based on
> the Salesforce data.
>
> Sent from my iPhone.  Please excuse brevity.
>
>> On Jun 22, 2016, at 16:56, Jeremy Rowley  wrote:
>>
>> That's why Mozilla has a policy to disclose all such CAs through OneCRL.
>> Seems like unnecessary information to disclose the CA as part of OneCRL and
>> as part of the Salesforce program.
___
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]

I think the vision is that in the long run, OneCRL would be based on
the Salesforce data.

Sent from my iPhone.  Please excuse brevity.

> On Jun 22, 2016, at 16:56, Jeremy Rowley <jeremy.row...@digicert.com> wrote:
>
> That's why Mozilla has a policy to disclose all such CAs through OneCRL.
> Seems like unnecessary information to disclose the CA as part of OneCRL and
> as part of the Salesforce program.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Kurt Roeckx
> Sent: Wednesday, June 22, 2016 2:31 PM
> To: Steve <steve.me...@gmail.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Eric Mill
> <e...@konklone.com>; Kathleen Wilson <kwil...@mozilla.com>; Rob Stradling
> <rob.stradl...@comodo.com>; Peter Bowen <pzbo...@gmail.com>; Ben Wilson
> <ben.wil...@digicert.com>
> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>
>> On Wed, Jun 22, 2016 at 06:18:51PM +, Steve wrote:
>> CAs are running OCSP responders up to the root tier.  Once a CA is
>> terminated in a standards-compliant and densely interoperable way from
>> participating in a trusted discovery path to an embedded root, it
>> should no longer be in the scope of business of root trust store owners.
>
> The BRs actually require both OCSP and CRL distribution point for
> subordinate CA certifiates.  But most CA certificates don't have OCSP
> information, most do have the CRL distribution point.
>
> But as far as I know nobody checks the OCSP reply of the intermediate CAs,
> only the subscriber certificate is checked.
>
> Most people don't download CRL information, and it's clearly going to give a
> worse user expierence if have to download it when we establish a connection.
>
> There are CA certificates that don't that have either OCSP or CRL
> information in it, so there really is no way to actually check them.
>
> It's clear that CA certificates do get revoked, so we need to have some way
> to check it.
>
> Since we don't even have a list of all CA certificates, we can't go and
> check all of them ourself to see if any of them are revoked.
> So we need to have at least all such certificates disclosed to start with,
> including the revoked ones.
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
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]

That's why Mozilla has a policy to disclose all such CAs through OneCRL.
Seems like unnecessary information to disclose the CA as part of OneCRL and
as part of the Salesforce program.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kurt Roeckx
Sent: Wednesday, June 22, 2016 2:31 PM
To: Steve <steve.me...@gmail.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Eric Mill
<e...@konklone.com>; Kathleen Wilson <kwil...@mozilla.com>; Rob Stradling
<rob.stradl...@comodo.com>; Peter Bowen <pzbo...@gmail.com>; Ben Wilson
<ben.wil...@digicert.com>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Wed, Jun 22, 2016 at 06:18:51PM +, Steve wrote:
> CAs are running OCSP responders up to the root tier.  Once a CA is 
> terminated in a standards-compliant and densely interoperable way from 
> participating in a trusted discovery path to an embedded root, it 
> should no longer be in the scope of business of root trust store owners.

The BRs actually require both OCSP and CRL distribution point for
subordinate CA certifiates.  But most CA certificates don't have OCSP
information, most do have the CRL distribution point.

But as far as I know nobody checks the OCSP reply of the intermediate CAs,
only the subscriber certificate is checked.

Most people don't download CRL information, and it's clearly going to give a
worse user expierence if have to download it when we establish a connection.

There are CA certificates that don't that have either OCSP or CRL
information in it, so there really is no way to actually check them.

It's clear that CA certificates do get revoked, so we need to have some way
to check it.

Since we don't even have a list of all CA certificates, we can't go and
check all of them ourself to see if any of them are revoked.
So we need to have at least all such certificates disclosed to start with,
including the revoked ones.


Kurt

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


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

[Peter Bowen]

On Wed, Jun 22, 2016 at 11:19 AM, Ryan Sleevi  wrote:
> On Wed, Jun 22, 2016 at 8:21 AM, Ben Wilson  wrote:
>> It seems to me that requiring the registration of these subordinate CAs 
>> bloats the Salesforce database unnecessarily.
>
> We've historically been at a chronic lack of data, rather than a
> chronic glut. I think we should definitely err on the side of too much
> - which would be a wonderful problem to have.
>
> As Eric (Mill) mentioned, revocation in practice is a complex and
> tricky thing. Having the data disclosed enables better tooling and
> better informs how best to handle revocation in practice. It also
> helps provide data for future bugs and incidents, by better informing
> scope of impact.

It might not be possible to get the data for subordinates under a
revoked certificate, as the CA may have terminated their relationship
with the organization they cross-signed.  It could even be that the
reason for the revocation was that the former sub failed to produce an
audit back when the rule that subs needed audits was phased in.  What
to do in this case?
___
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

[Ryan Sleevi]

On Wed, Jun 22, 2016 at 8:21 AM, Ben Wilson  wrote:
> It seems to me that requiring the registration of these subordinate CAs 
> bloats the Salesforce database unnecessarily.

We've historically been at a chronic lack of data, rather than a
chronic glut. I think we should definitely err on the side of too much
- which would be a wonderful problem to have.

As Eric (Mill) mentioned, revocation in practice is a complex and
tricky thing. Having the data disclosed enables better tooling and
better informs how best to handle revocation in practice. It also
helps provide data for future bugs and incidents, by better informing
scope of impact.
___
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

[Steve]

CAs are running OCSP responders up to the root tier.  Once a CA is
terminated in a standards-compliant and densely interoperable way from
participating in a trusted discovery path to an embedded root, it should no
longer be in the scope of business of root trust store owners.


On Wed, Jun 22, 2016 at 1:52 PM Eric Mill  wrote:

> On Tue, Jun 21, 2016 at 12:10 PM, Peter Bowen  wrote:
>
> > On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling  >
> > wrote:
> > > Revocation of a "parent intermediate" does not exempt "child
> > intermediates"
> > > from the disclosure requirement, AFAICT.  So I think the KBC Group CAs
> do
> > > need to be disclosed to Salesforce.
> >
> > If all paths from a trusted root to a given intermediate are revoked
> > or expired, then I don't think it "directly or transitively chain[s]
> > to a certificate included in Mozilla’s CA Certificate Program".  It
> > would be no different than a private CA which isn't part of the WebPKI
> > graph.
> >
>
> Expired makes sense. Revoked only makes sense if the certificates are
> revoked in practice. My understanding right now is that Chrome and Firefox
> only enforce revocations for intermediates if the revocation is distributed
> through CRLset or OneCRL, respectively.
>
> I don't know what Apple's or Microsoft's processes are, and I don't think
> that OneCRL alone would be sufficient to say that a certificate has been
> practically revoked in the web PI.
>
> Since this is being done in a comprehensive way, where we have some level
> of assurance that this is meaningfully closing off a category of weakness
> in the web PKI, perhaps we could get commitments from some or all of the
> major browsers to ensure that all undisclosed revoked intermediates are
> distributed through channels that make them actionable. Without something
> like that, I'm not sure any risk has been mitigated by revocation alone.
>
> -- Eric
>
>
> > Thanks,
> > Peter
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
>
>
>
> --
> konklone.com | @konklone 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
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]

On Tue, Jun 21, 2016 at 12:10 PM, Peter Bowen  wrote:

> On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling 
> wrote:
> > Revocation of a "parent intermediate" does not exempt "child
> intermediates"
> > from the disclosure requirement, AFAICT.  So I think the KBC Group CAs do
> > need to be disclosed to Salesforce.
>
> If all paths from a trusted root to a given intermediate are revoked
> or expired, then I don't think it "directly or transitively chain[s]
> to a certificate included in Mozilla’s CA Certificate Program".  It
> would be no different than a private CA which isn't part of the WebPKI
> graph.
>

Expired makes sense. Revoked only makes sense if the certificates are
revoked in practice. My understanding right now is that Chrome and Firefox
only enforce revocations for intermediates if the revocation is distributed
through CRLset or OneCRL, respectively.

I don't know what Apple's or Microsoft's processes are, and I don't think
that OneCRL alone would be sufficient to say that a certificate has been
practically revoked in the web PI.

Since this is being done in a comprehensive way, where we have some level
of assurance that this is meaningfully closing off a category of weakness
in the web PKI, perhaps we could get commitments from some or all of the
major browsers to ensure that all undisclosed revoked intermediates are
distributed through channels that make them actionable. Without something
like that, I'm not sure any risk has been mitigated by revocation alone.

-- Eric


> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
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]

It seems to me that requiring the registration of these subordinate CAs bloats 
the Salesforce database unnecessarily.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Rob Stradling
Sent: Wednesday, June 22, 2016 4:00 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On 21/06/16 17:56, Nick Lamb wrote:
> On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen  wrote:
>> If all paths from a trusted root to a given intermediate are revoked 
>> or expired, then I don't think it "directly or transitively chain[s] 
>> to a certificate included in Mozilla’s CA Certificate Program".  It 
>> would be no different than a private CA which isn't part of the 
>> WebPKI graph.
>
> It is actually different, but whether each case is different in an 
> _important_ way is a matter for Mozilla to decide.


+1

If certificate A's signature can be verified by certificate B's public key, and 
if certificate B has basicConstraints.CA=TRUE, then certificate B chains to 
certificate A.  Revocation, expiration, name constraints, EKU "constraints", 
etc, may affect whether or not that chain of certificates is trusted by 
Mozilla's software, but these things do not cause that chain of certificates to 
cease to be a chain a certificates.

Kathleen's "CAs should not add records for:" list [1] includes expired 
intermediates but does not include all-paths-revoked intermediates.


[1] 
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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


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

[Rob Stradling]

On 21/06/16 17:56, Nick Lamb wrote:

On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen  wrote:

If all paths from a trusted root to a given intermediate are revoked
or expired, then I don't think it "directly or transitively chain[s]
to a certificate included in Mozilla’s CA Certificate Program".  It
would be no different than a private CA which isn't part of the WebPKI
graph.


It is actually different, but whether each case is different in an _important_ 
way is a matter for Mozilla to decide.



+1

If certificate A's signature can be verified by certificate B's public 
key, and if certificate B has basicConstraints.CA=TRUE, then certificate 
B chains to certificate A.  Revocation, expiration, name constraints, 
EKU "constraints", etc, may affect whether or not that chain of 
certificates is trusted by Mozilla's software, but these things do not 
cause that chain of certificates to cease to be a chain a certificates.


Kathleen's "CAs should not add records for:" list [1] includes expired 
intermediates but does not include all-paths-revoked intermediates.



[1] 
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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]

* snip - since only OneCRL is relevant to Mozilla users with respect to 
intermediate certs*
>> OneCRL is intended to reduce the exposure of Mozilla's browser to the second 
>> category of problems, by burning a CRL for intermediates into the software 
>> itself, so that it will function even offline. But the reality is that CAs 
>> have not been as forthcoming as they should have with revocation information 
>> and OneCRL today can't function without either better co-operation on 
>> revocation by CAs or the exact type of disclosure that we're discussing here.
- Then those CAs are in violation of the Mozilla policy and should be treated 
accordingly. This seems like a *worse* infraction of the policy that failing to 
disclose an intermediate that is no longer trusted.

Consider a Firefox installed in July 2015 on a laptop which has deliberately 
been given no Internet access, but it does connect to a handful of systems over 
perhaps a dial-up or dedicated network. This Firefox thinks the Disney CA is 
good, it thinks the Verisign Class 3 Public Primary Certification Authority is 
good. It has no way to find out otherwise, except by being updated to a newer 
Firefox. Do the legal disclaimers from public CAs say this is the user's 
problem? Yes they do. Does that mean Mozilla should wave it away as 
unimportant? That is much less clear.
- Same thing as I mentioned. If they haven't updated the browser, how do they 
know which roots are no longer trusted? 

I suppose the real difference is one of control. Mozilla can enforce a policy 
to disclose revoked intermediates but can't force a disclosure of roots that 
are not part of the Mozilla program (as they are out of scope).

___

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb
Sent: Tuesday, June 21, 2016 10:56 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen  wrote:
> If all paths from a trusted root to a given intermediate are revoked 
> or expired, then I don't think it "directly or transitively chain[s] 
> to a certificate included in Mozilla’s CA Certificate Program".  It 
> would be no different than a private CA which isn't part of the WebPKI 
> graph.

It is actually different, but whether each case is different in an _important_ 
way is a matter for Mozilla to decide.

For the expiry case, relying parties may not implement expiry or may not have 
good local time information. A client which doesn't have a local clock or can't 
rely on it may not know that an intermediate has expired and still trust it. 
This is a _risk_ but it's a distinct risk from just accepting certificates 
which are signed by some untrusted entity and the two shouldn't be muddled.

For the revocation case relying parties may not have revocation information. 
There can be a variety of reasons for this, at one end of the scale they or the 
CA might be actively under attack, preventing OCSP or CRL downloads. But also 
the client software might have actively chosen not to implement the revocation 
mechanism used (e.g. CRLs are often unwieldy, if a CRL is the only revocation 
offered a client might choose to just not check) and at the far end of the 
scale the system may be off-line (or at least not connected to the public 
Internet) and thus unable to perform any revocation checks in real time anyway.

OCSP Stapling doesn't buy you much here for non-leaf certificates without 
multi-stapling, which I believe isn't implemented yet in NSS. And even when we 
have that, we're years away from OCSP Stapling becoming widespread enough for 
browsers to realistically reject TLS certificates when there's no stapled OCSP 
info and either no OCSP servers are listed or they are down.

OneCRL is intended to reduce the exposure of Mozilla's browser to the second 
category of problems, by burning a CRL for intermediates into the software 
itself, so that it will function even offline. But the reality is that CAs have 
not been as forthcoming as they should have with revocation information and 
OneCRL today can't function without either better co-operation on revocation by 
CAs or the exact type of disclosure that we're discussing here.

Consider a Firefox installed in July 2015 on a laptop which has deliberately 
been given no Internet access, but it does connect to a handful of systems over 
perhaps a dial-up or dedicated network. This Firefox thinks the Disney CA is 
good, it thinks the Verisign Class 3 Public Primary Certification Authority is 
good. It has no way to find out otherwise, except by being updated to a newer 
Firefox. Do the legal disclaimers from public CAs say this is the user's 
problem? Yes they do. Does that mean Mozilla should wave it away

Re: Intermediate certificate disclosure deadline in 2 weeks

[Nick Lamb]

On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen  wrote:
> If all paths from a trusted root to a given intermediate are revoked
> or expired, then I don't think it "directly or transitively chain[s]
> to a certificate included in Mozilla’s CA Certificate Program".  It
> would be no different than a private CA which isn't part of the WebPKI
> graph.

It is actually different, but whether each case is different in an _important_ 
way is a matter for Mozilla to decide.

For the expiry case, relying parties may not implement expiry or may not have 
good local time information. A client which doesn't have a local clock or can't 
rely on it may not know that an intermediate has expired and still trust it. 
This is a _risk_ but it's a distinct risk from just accepting certificates 
which are signed by some untrusted entity and the two shouldn't be muddled.

For the revocation case relying parties may not have revocation information. 
There can be a variety of reasons for this, at one end of the scale they or the 
CA might be actively under attack, preventing OCSP or CRL downloads. But also 
the client software might have actively chosen not to implement the revocation 
mechanism used (e.g. CRLs are often unwieldy, if a CRL is the only revocation 
offered a client might choose to just not check) and at the far end of the 
scale the system may be off-line (or at least not connected to the public 
Internet) and thus unable to perform any revocation checks in real time anyway.

OCSP Stapling doesn't buy you much here for non-leaf certificates without 
multi-stapling, which I believe isn't implemented yet in NSS. And even when we 
have that, we're years away from OCSP Stapling becoming widespread enough for 
browsers to realistically reject TLS certificates when there's no stapled OCSP 
info and either no OCSP servers are listed or they are down.

OneCRL is intended to reduce the exposure of Mozilla's browser to the second 
category of problems, by burning a CRL for intermediates into the software 
itself, so that it will function even offline. But the reality is that CAs have 
not been as forthcoming as they should have with revocation information and 
OneCRL today can't function without either better co-operation on revocation by 
CAs or the exact type of disclosure that we're discussing here.

Consider a Firefox installed in July 2015 on a laptop which has deliberately 
been given no Internet access, but it does connect to a handful of systems over 
perhaps a dial-up or dedicated network. This Firefox thinks the Disney CA is 
good, it thinks the Verisign Class 3 Public Primary Certification Authority is 
good. It has no way to find out otherwise, except by being updated to a newer 
Firefox. Do the legal disclaimers from public CAs say this is the user's 
problem? Yes they do. Does that mean Mozilla should wave it away as 
unimportant? That is much less clear.

Eventually, after we've got past the low bar of CAs actually disclosing all 
these strange unconstrained subCAs out there I would like to see CAs agree that 
_even after_ they seek removal of one of their roots they will take 
responsibility for its continued compliant operation (or safe dormancy) for a 
period, say 18 months, because in reality clients like Firefox will keep 
trusting it for some time and so will subsidiary users of the NSS trust store 
like the various Linux distributions. But that's a subject for another thread.
___
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]

Agreed. I don't see a reason to disclose anything where the parent is revoked. 
I think it's a similar  question as whether a CA has to disclose all the sub 
case under a root where removal from the root program was requested. In both 
cases the certs are not publicly trusted and don't affect the Mozilla community.

> On Jun 21, 2016, at 10:10 AM, Peter Bowen  wrote:
> 
>> On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling  
>> wrote:
>> Revocation of a "parent intermediate" does not exempt "child intermediates"
>> from the disclosure requirement, AFAICT.  So I think the KBC Group CAs do
>> need to be disclosed to Salesforce.
> 
> If all paths from a trusted root to a given intermediate are revoked
> or expired, then I don't think it "directly or transitively chain[s]
> to a certificate included in Mozilla’s CA Certificate Program".  It
> would be no different than a private CA which isn't part of the WebPKI
> graph.
> 
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
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

[Rob Stradling]

On 21/06/16 15:55, Ben Wilson wrote:

Rob,


Ben, thanks for passing on the details.  My analysis is below...


So far they are -

https://crt.sh/?sha1=e12ba5aeb7613a72cc9652f1673017a5d8fc7479
  - technically constrained  warning

https://crt.sh/?sha1=8c6c7a20b48ef3bcb0fcb203008773846611486a
  - technically constrained  warning

https://crt.sh/?sha1=69bdbd7760f0fc58021c290c39243351914dadc5
  - technically constrained  warning

https://crt.sh/?sha1=107cce8b25af9b6cfabada125967aed4ef5bafe2
  - technically constrained  warning


Section 9 of the Inclusion Policy [1] says:
  "For a certificate to be considered technically constrained
   ...
   The subordinate CA certificate MUST also include within
   excludedSubtrees an iPAddress GeneralName of 32 zero octets
   (covering the IPv6 address range of ::0/0)."

These four intermediate certs only exclude the IPv4 address space, so I 
would say that they don't qualify as "technically constrained". 
Therefore, they need to be disclosed to Salesforce.


Kathleen, if you agree that Salesforce should not be showing the 
"technically constrained warning" for these four intermediates, please 
could you ask your Salesforce consultant to fix it?



https://crt.sh/?sha1=d92b8d4859538692e435ad78dd876b03601eae96
  - PEM too long

https://crt.sh/?sha1=3948a71e4b39768a016fa3b13175e41197f8bf28
  - PEM too long


Kathleen, what's the size limit?  Can it be increased?


And then the ones that aren't trusted, or shouldn't be trusted, were all of
the KBC Group CAs, because certificate that issued those (SHA-1 Fingerprint
CF:AA:D9:D6:31:4D:33:9F:A6:07:72:EB:61:FA:B5:F8:FD:DC:56:10; SHA-256
Fingerprint
AE:F2:6B:BB:CB:B7:07:06:76:2C:8B:E9:30:C4:1F:91:3D:D0:E2:34:0A:78:9E:8B:33:F
1:27:FB:6D:27:92:F0) was revoked on 1 July 2015.  (I don't know why NSS
can't just use the CRLs that CAs issue.)  I hadn't entered it previously
into SalesForce or in OneCRL because the  revocation had  happened so long
ago, but yesterday I went and did  that.


Revocation of a "parent intermediate" does not exempt "child 
intermediates" from the disclosure requirement, AFAICT.  So I think the 
KBC Group CAs do need to be disclosed to Salesforce.



[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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]

Rob,

 

So far they are - 

 

 <https://crt.sh/?sha1=e12ba5aeb7613a72cc9652f1673017a5d8fc7479>
E12BA5AEB7613A72CC9652F1673017A5D8FC7479 - technically constrained  warning

 

 <https://crt.sh/?sha1=8c6c7a20b48ef3bcb0fcb203008773846611486a>
8C6C7A20B48EF3BCB0FCB203008773846611486A - technically constrained  warning

 

 <https://crt.sh/?sha1=69bdbd7760f0fc58021c290c39243351914dadc5>
69BDBD7760F0FC58021C290C39243351914DADC5 - technically constrained  warning

 

 <https://crt.sh/?sha1=107cce8b25af9b6cfabada125967aed4ef5bafe2>
107CCE8B25AF9B6CFABADA125967AED4EF5BAFE2 - technically constrained  warning

 

 <https://crt.sh/?sha1=d92b8d4859538692e435ad78dd876b03601eae96>
D92B8D4859538692E435AD78DD876B03601EAE96 - PEM too long

 

 <https://crt.sh/?sha1=3948a71e4b39768a016fa3b13175e41197f8bf28>
3948A71E4B39768A016FA3B13175E41197F8BF28 - PEM too long

 

And then the ones that aren't trusted, or shouldn't be trusted, were all of
the KBC Group CAs, because certificate that issued those (SHA-1 Fingerprint
CF:AA:D9:D6:31:4D:33:9F:A6:07:72:EB:61:FA:B5:F8:FD:DC:56:10; SHA-256
Fingerprint
AE:F2:6B:BB:CB:B7:07:06:76:2C:8B:E9:30:C4:1F:91:3D:D0:E2:34:0A:78:9E:8B:33:F
1:27:FB:6D:27:92:F0) was revoked on 1 July 2015.  (I don't know why NSS
can't just use the CRLs that CAs issue.)  I hadn't entered it previously
into SalesForce or in OneCRL because the  revocation had  happened so long
ago, but yesterday I went and did  that.   

 

Cheers,

 

Ben

 

  

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Monday, June 20, 2016 4:17 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Peter Bowen <pzbo...@gmail.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

 

On 20/06/16 21:15, Ben Wilson wrote:

> When I try to upload some of these listed as "Unconstrained 

> id-kp-serverAuth Trust" undisclosed, I get a warning that says, "This 

> certificate is considered to be technically-constrained as per Mozilla 

> policy, so it does not need to be added to the CA Community in 

> Salesforce. All data that you enter into Salesforce will be publicly
available, so please make sure you do

> not enter sensitive information that should not be published.   ...I

> understand, proceed anyways."

 

Ben, would you mind telling me which certs you tried to upload?

 

I'd like to understand why there's a discrepancy.

 

> I also noticed that some on the list are not publicly trusted because 

> the root is not in the trust store or is not signed by a root that  is  

> in the trust store.

 

Which ones?

 

Thanks.

 

> Ben

> 

> -Original Message-

> From: dev-security-policy

> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org

> ] On Behalf Of Peter Bowen

> Sent: Monday, June 20, 2016 11:59 AM

> To: Rob Stradling < <mailto:rob.stradl...@comodo.com>
rob.stradl...@comodo.com>

> Cc:  <mailto:mozilla-dev-security-pol...@lists.mozilla.org>
mozilla-dev-security-pol...@lists.mozilla.org

> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

> 

> On Fri, Jun 17, 2016 at 4:12 AM, Rob Stradling 

> < <mailto:rob.stradl...@comodo.com> rob.stradl...@comodo.com>

> wrote:

>> Friendly reminder to all CA representatives:

>> 

>> Don't forget the June 30th deadline!  And don't leave it until the 

>> last minute if you have lots of intermediate certificates to disclose!

>> 

>>  <https://crt.sh/mozilla-disclosures> https://crt.sh/mozilla-disclosures

>> ...lists (under "Unconstrained id-kp-serverAuth Trust: Disclosure is

>> required!") the (many!) qualifying intermediate certificates that are 

>> known to CT and that have not yet been disclosed to Salesforce.

> 

> I found one bug in this list -- it is including self-signed 

> certificates, which are not subject to disclosure, as they clearly 

> don't chain back to a root in the Mozilla trust store.

> 

> Thanks,

> Peter

> ___

> dev-security-policy mailing list

>  <mailto:dev-security-policy@lists.mozilla.org>
dev-security-policy@lists.mozilla.org

>  <https://lists.mozilla.org/listinfo/dev-security-policy>
https://lists.mozilla.org/listinfo/dev-security-policy

> 

> 

> 

> ___

> dev-security-policy mailing list

>  <mailto:dev-security-policy@lists.mozilla.org>
dev-security-policy@lists.mozilla.org

>  <https://lists.mozilla.org/listinfo/dev-security-policy>
https://lists.mozilla.org/listinfo/dev-security-policy

> 

 

--

Rob Stradling

Senior Research & Development Scientist

COMODO - Creating Trust 

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rob Stradling]

On 21/06/16 04:03, Jeremy Rowley wrote:

Whether they are currently issuing is irrelevant.


Indeed.  Having no intent to issue certificates is not going to stop the 
sort of attack that DigiNotar experienced!


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Rob Stradling]

On 20/06/16 21:15, Ben Wilson wrote:

When I try to upload some of these listed as "Unconstrained id-kp-serverAuth
Trust" undisclosed, I get a warning that says, "This certificate is
considered to be technically-constrained as per Mozilla policy, so it does
not need to be added to the CA Community in Salesforce. All data that you
enter into Salesforce will be publicly available, so please make sure you do
not enter sensitive information that should not be published.   ...I
understand, proceed anyways."


Ben, would you mind telling me which certs you tried to upload?

I'd like to understand why there's a discrepancy.


I also noticed that some on the list are not publicly trusted because the
root is not in the trust store or is not signed by a root that  is  in the
trust store.


Which ones?

Thanks.


Ben

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Peter Bowen
Sent: Monday, June 20, 2016 11:59 AM
To: Rob Stradling <rob.stradl...@comodo.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Fri, Jun 17, 2016 at 4:12 AM, Rob Stradling <rob.stradl...@comodo.com>
wrote:

Friendly reminder to all CA representatives:

Don't forget the June 30th deadline!  And don't leave it until the
last minute if you have lots of intermediate certificates to disclose!

https://crt.sh/mozilla-disclosures
...lists (under "Unconstrained id-kp-serverAuth Trust: Disclosure is
required!") the (many!) qualifying intermediate certificates that are
known to CT and that have not yet been disclosed to Salesforce.


I found one bug in this list -- it is including self-signed certificates,
which are not subject to disclosure, as they clearly don't chain back to a
root in the Mozilla trust store.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

___
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]

When I try to upload some of these listed as "Unconstrained id-kp-serverAuth
Trust" undisclosed, I get a warning that says, "This certificate is
considered to be technically-constrained as per Mozilla policy, so it does
not need to be added to the CA Community in Salesforce. All data that you
enter into Salesforce will be publicly available, so please make sure you do
not enter sensitive information that should not be published.   ...I
understand, proceed anyways."  
I also noticed that some on the list are not publicly trusted because the
root is not in the trust store or is not signed by a root that  is  in the
trust store.
Ben

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Peter Bowen
Sent: Monday, June 20, 2016 11:59 AM
To: Rob Stradling <rob.stradl...@comodo.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Fri, Jun 17, 2016 at 4:12 AM, Rob Stradling <rob.stradl...@comodo.com>
wrote:
> Friendly reminder to all CA representatives:
>
> Don't forget the June 30th deadline!  And don't leave it until the 
> last minute if you have lots of intermediate certificates to disclose!
>
> https://crt.sh/mozilla-disclosures
> ...lists (under "Unconstrained id-kp-serverAuth Trust: Disclosure is
> required!") the (many!) qualifying intermediate certificates that are 
> known to CT and that have not yet been disclosed to Salesforce.

I found one bug in this list -- it is including self-signed certificates,
which are not subject to disclosure, as they clearly don't chain back to a
root in the Mozilla trust store.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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