Intermediate certificate disclosure deadline in 2 weeks

[Rob Stradling]

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://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
...explains which types of intermediate certificate qualify for the
Salesforce disclosure requirement.

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.

(P.S. If you have any qualifying intermediate certificates that are not
yet known to CT, don't forget to disclose them to Salesforce!)

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

[Peter Bowen]

On Fri, Jun 17, 2016 at 4:12 AM, Rob Stradling <rob.st...@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

[Rob Stradling]

If a CA key/DN has been cross-certified by a root in the Mozilla root
store, then I'd say that a self-signed cert for that CA key/DN does
chain back to a root in the Mozilla trust store. (The Issuer field in
the self-signed cert matches the Subject field in the trusted root cert,
and the signature on the self-signed cert can be verified by the public
key in the trusted root cert).

Of course it would be rather pointless to include a self-signed cert in
the middle of a trusted chain, but it would still be a chain.

> Thanks,
> Peter

[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=digice...@lists.mozilla.org] On
> Behalf Of Peter Bowen
> Sent: Monday, June 20, 2016 11:59 AM
> To: Rob Stradling <rob.st...@comodo.com>
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Intermediate certificate disclosure deadline in 2 weeks
>
> On Fri, Jun 17, 2016 at 4:12 AM, Rob Stradling <rob.st...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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.

[林維聰(robin.lin)]

Hello Rob,

What if the CA is no longer issue certificate?

Thanks,
Robin Lin (Wei Tsong Lin)
CSSLPR
Project Manager
Research and Developing Department
TAIWAN-CA INC.
TEL：+886-2-2370-8886 ext. 721
FAX：+886-2-2370-0728
E-mail：robi...@twca.com.tw

10th Floor, 85 Yenping South Road, 10043 Taipei, Taiwan
http://www.twca.com.tw

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+robin.lin=twca....@lists.mozilla.org] On Behalf Of Rob Stradling
Sent: Friday, June 17, 2016 7:12 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Intermediate certificate disclosure deadline in 2 weeks

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://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
...explains which types of intermediate certificate qualify for the Salesforce disclosure requirement.

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.

(P.S. If you have any qualifying intermediate certificates that are not yet known to CT, don't forget to disclose them to Salesforce!)

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

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

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/

[Peter Bowen]

On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling <rob.st...@comodo.com> 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

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

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

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

<snip>

+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

[Eric Mill]

On Tue, Jun 21, 2016 at 12:10 PM, Peter Bowen <pzb...@gmail.com> wrote:

> On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling <rob.st...@comodo.com>
> 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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
konklone.com | @konklone <https://twitter.com/konklone>

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

[Ryan Sleevi]

On Wed, Jun 22, 2016 at 8:21 AM, Ben Wilson <ben.w...@digicert.com> 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.

[Peter Bowen]

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?

[Richard Barnes]

Perhaps we could err on the side of disclosing subordinates under a revoked
certificate, with exceptions allowed for these cases.

--Richard

[Kurt Roeckx]

On Wed, Jun 22, 2016 at 06:18:51PM +0000, 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

[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...@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=digice...@lists.mozilla
> .org] On Behalf Of Kurt Roeckx
> Sent: Wednesday, June 22, 2016 2:31 PM
> To: Steve <steve...@gmail.com>
> Cc: mozilla-dev-s...@lists.mozilla.org; Eric Mill
> <er...@konklone.com>; Kathleen Wilson <kwi...@mozilla.com>; Rob Stradling
> <rob.st...@comodo.com>; Peter Bowen <pzb...@gmail.com>; Ben Wilson
> <ben.w...@digicert.com>
> Subject: 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

[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

[Eric Mill]

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

[Richard Barnes]

On Thu, Jun 23, 2016 at 2:45 PM, Ben Wilson <ben.w...@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:er...@konklone.com]
> *Sent:* Wednesday, June 22, 2016 9:19 PM
> *To:* Kurt Roeckx <ku...@roeckx.be>
> *Cc:* Peter Bowen <pzb...@gmail.com>; Richard Barnes <rba...@mozilla.com>;
> Jeremy Rowley <jeremy...@digicert.com>; Steve <steve...@gmail.com>;
> mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson <
> kwi...@mozilla.com>; Rob Stradling <rob.st...@comodo.com>; Ben
> Wilson <ben.w...@digicert.com>
> *Subject:* Re: Intermediate certificate disclosure deadline in 2 weeks

[Peter Bowen]

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

[Peter Bowen]

Given that is correct, I would say it is not DigiCert's responsibility
to disclose to Mozilla. Rather it is your responsibility to disclose
to Federal PKI, and they need to disclose to whoever subordinated them
from a Mozilla root.

On Thu, Jun 23, 2016 at 1:39 PM, Ben Wilson <ben.w...@digicert.com> wrote:
> That's correct.

[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

[Peter Bowen]

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.

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

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

[Kathleen Wilson]

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

[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 "&opt=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:pzb...@gmail.com]
>> Sent: Thursday, June 23, 2016 3:35 PM
>> To: Eric Mill <er...@konklone.com>
>> Cc: Ben Wilson <ben.w...@digicert.com>; Kurt Roeckx
>> <ku...@roeckx.be>; Richard Barnes <rba...@mozilla.com>; Jeremy Rowley
>> <jeremy...@digicert.com>; Steve <steve...@gmail.com>;
>> mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson
>> <kwi...@mozilla.com>; Rob Stradling <rob.st...@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.
>>

[Ben Laurie]

On 25 June 2016 at 00:56, Rob Stradling <rob.st...@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?

[Peter Bowen]

On Sat, Jun 25, 2016 at 3:50 AM, Ben Laurie <be...@google.com> wrote:
> On 25 June 2016 at 00:56, Rob Stradling <rob.st...@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?

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

[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."

[Ben Laurie]

On 25 June 2016 at 15:50, Peter Bowen <pzb...@gmail.com> wrote:
> On Sat, Jun 25, 2016 at 3:50 AM, Ben Laurie <be...@google.com> wrote:
>> On 25 June 2016 at 00:56, Rob Stradling <rob.st...@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?
>
> It is not the CA that is revoked, it is the path from the trust anchor
> to the CA that is revoked.

In practice, what does this mean? How does one revoke the path from
the trust anchor to the CA?

[Nick Lamb]

On Saturday, 25 June 2016 21:55:46 UTC+1, Ben Laurie wrote:
> In practice, what does this mean? How does one revoke the path from
> the trust anchor to the CA?

This path will involve one or more certificates and the certificates can be revoked in the usual manner by their serial number. For most modern intermediates this will mean adding them to a CRL signed by the trust anchor and listed in the original certificate itself.

You seem to be focused on the idea that since the issuer is identified by DN whereas the revocation list works on serial numbers this is a disconnect, but both these facts are present in the issuer's _certificate_. If you don't have that certificate then you have no reason to believe there was ever a trust path, let alone that it's still good and unrevoked. If you DO have it, then you can see the serial number and other information to determine if it's revoked. If I have mistaken what your concern is, please spell it out.

Revoking specific certificates (by serial number) rather than DNs means it's possible for a CA to revoke any certificate and then immediately issue a new certificate (with a different serial) for the same DN with different contents. You'd like to hope that a well-run CA would scarcely ever need to do that, but scarcely ever isn't the same as never, and we do not have an ecosystem of well-run CAs yet, if we ever will.

[Ben Laurie]

On 26 June 2016 at 10:56, Nick Lamb <tiala...@gmail.com> wrote:
> On Saturday, 25 June 2016 21:55:46 UTC+1, Ben Laurie wrote:

>> In practice, what does this mean? How does one revoke the path from
>> the trust anchor to the CA?
>

> This path will involve one or more certificates and the certificates can be revoked in the usual manner by their serial number. For most modern intermediates this will mean adding them to a CRL signed by the trust anchor and listed in the original certificate itself.
>
> You seem to be focused on the idea that since the issuer is identified by DN whereas the revocation list works on serial numbers this is a disconnect, but both these facts are present in the issuer's _certificate_. If you don't have that certificate then you have no reason to believe there was ever a trust path, let alone that it's still good and unrevoked. If you DO have it, then you can see the serial number and other information to determine if it's revoked. If I have mistaken what your concern is, please spell it out.

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

> Revoking specific certificates (by serial number) rather than DNs means it's possible for a CA to revoke any certificate and then immediately issue a new certificate (with a different serial) for the same DN with different contents. You'd like to hope that a well-run CA would scarcely ever need to do that, but scarcely ever isn't the same as never, and we do not have an ecosystem of well-run CAs yet, if we ever will.

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

[Myers, Kenneth (10421)]

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.

Kenneth Myers
Supporting the GSA Federal PKI Management Authority
Protiviti | Government Solutions | Manager
Alexandria | +1 571-366-6120<tel:+1%20571-366-6120> | Kennet...@Protiviti.com<mailto:Kennet...@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-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>" <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> wrote:

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Thursday, June 23, 2016 3:35 PM
To: Eric Mill <er...@konklone.com<mailto:er...@konklone.com>>
Cc: Ben Wilson <ben.w...@digicert.com<mailto:ben.w...@digicert.com>>; Kurt Roeckx <ku...@roeckx.be<mailto:ku...@roeckx.be>>; Richard Barnes <rba...@mozilla.com<mailto:rba...@mozilla.com>>; Jeremy Rowley <jeremy...@digicert.com<mailto:jeremy...@digicert.com>>; Steve <steve...@gmail.com<mailto:steve...@gmail.com>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>; Kathleen Wilson <kwi...@mozilla.com<mailto:kwi...@mozilla.com>>; Rob Stradling <rob.st...@comodo.com<mailto:rob.st...@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 <er...@konklone.com<mailto:er...@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.w...@digicert.com<mailto:ben.w...@digicert.com>> wrote:

That's correct.

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson <ben.w...@digicert.com<mailto:ben.w...@digicert.com>>
Cc: Eric Mill <er...@konklone.com<mailto:er...@konklone.com>>; Kurt Roeckx <ku...@roeckx.be<mailto:ku...@roeckx.be>>;
Richard Barnes <rba...@mozilla.com<mailto:rba...@mozilla.com>>; Jeremy Rowley
<jeremy...@digicert.com<mailto:jeremy...@digicert.com>>; Steve <steve...@gmail.com<mailto:steve...@gmail.com>>;
mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>; Kathleen Wilson
<kwi...@mozilla.com<mailto:kwi...@mozilla.com>>; Rob Stradling <rob.st...@comodo.com<mailto:rob.st...@comodo.com>>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

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

<ben.w...@digicert.com<mailto:ben.w...@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://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_mozilla-2Ddisclosures&d=CwICAg&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=1UjPfxX9IFMWqfbTaQcpveBJs1JYI4p_EuZaqww5tuQ&s=uEywlyUMGlYbep6vFNZz0xasu6IojurxbFc_8QrcDW0&e= ) 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<http://konklone.com> | @konklone
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

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

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!

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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.

[Myers, Kenneth (10421)]

Thanks Rob. I came to the same conclusion.

I am a contractor supporting the Federal PKI and do not speak on their behalf, but would like to help clear up some misconceptions around the Federal PKI.

1) The Symantec Cross Cert has not been revoked.
The Federal PKI is an identity federation based on mutual trust of people. Multiple federal and non-federal organizations coming together based on common identity assurances for the benefit of G2G, C2G, and B2G digital transactions. Every affiliate within the Federal PKI adheres to the Federal Bridge CP which is based off NIST and international standards and other federal laws around identity management and information security to establish trusted operations and the criteria for a level of assurance. Multiple federal mandates and laws exist for the use of the Federal Bridge to accept commercial PKI credentials for electronic authentication and digital signature (mentioned below). Participating PKIs enter into a legal agreement (MOA) with the federal government to establish that trust and define the requirements around mutual recognition (Application for cross certification, https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNS6AAO&field=File__Body__s). This is evidenced through the exchange of certificates between organizational PKIs (In this case between the Federal Bridge and the Symantec CA) after a passing audit report. The FPKI audit requirements are based on a direct CP to CPS analysis with annual core requirements which provides improved assurance that affiliates continue to operate according to the Federal Bridge CP (https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNYYAA4&field=File__Body__s). Without the exchange, there is no mutual trust. Symantec is a valued partner within the Federal PKI supporting nine non-federal organizations with 33 operational CAs under the Federal PKI non-federal issuer program. To revoke the Symantec certificate, the certificates issued by organizations under Symantec would no longer be trusted by federal relying parties. Symantec is resolving the issue with the Federal PKI Policy Authority, but the risk to revoking the certificate is still uncertain.

2) It is not acceptable for CAs trusted by the Mozilla Program to cross-sign with the Federal Bridge (From Richard Barnes) There is a fundamental and growing philosophical difference between the Federal PKI (based on strong assurance of people identities for general use) and the PKI industry (assurance of device identities for specific uses). The Federal PKI continues to work to update our requirements to meet Mozilla program acceptance, but it is a difficult path. The Federal PKI is a heavily regulated environment governed by its members, federal regulations, and operated according to NIST and international standards. The Federal PKI is composed of:
- 19 affiliates
- 254 CAs
- 71 issuing partners
- 93 federal agencies
- >five million users
- >22 million active certificates issued to both people and devices

This does not include the federal relying party and commercial applications which accept FPKI certificates for authentication or other purposes. It is important to the Federal PKI that theses certificates are trusted to meet multiple federal drivers around electronic authentication/digital signature (Digital Signature and Electronic Authentication Act, Electronic Signatures in Global and National Commerce Act, and Government Paperwork Elimination Act) as well as PKI interoperability (E-Government Act) and strong authentication (Homeland Security Presidential Directive-12, White House Cybersecurity Strategy and Implementation Plan, and White House Cybersecurity National Action Plan) requirements. In some cases it is not a simple process to update the Federal PKI Certificate Policies, but we are very close to meeting the last two Mozilla requirements for our application which include incorporating CAB Forum BR and Mozilla CP requirements and publicly posting CP, CPS, and audit letters for the Shared Service Providers. Even small changes have a lasting impact to both federal budget and operational practices and must be understand.

If you're interested in a closer look, I've attached a white paper of the FPKI Infrastructure and Architecture (https://www.idmanagement.gov/IDM/s/document_detail?Id=kA0t0000000KyroCAC).

Ken

-----Original Message-----
From: Rob Stradling [mailto:rob.st...@comodo.com]
Sent: Monday, June 27, 2016 09:01
To: Myers, Kenneth (10421) <kennet...@protiviti.com>; dev-secur...@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__fpki-2Dgraph.fpki-2Dlab.gov&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=pqUpzJZnt7pQ1HsJr6dBrqifrxrdjl-iFkah0G685TY&e= >.

>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_-3Fid-3D9114292&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=diEBbsWTZ7Zo0d_TwT8WGR-3EwDoH469HqxCqlif53k&e=

Issuer: IdenTrust ACES CA 1
Subject: Federal Bridge CA 2013
OneCRL: Already revoked.
Salesforce: Not yet disclosed.

https://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_-3Fid-3D12638543&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=JB_38bUAYT_Hl4B58oExVy_P8sXMISQGtZhyoyoSx2U&e=

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> |
> Kennet...@Protiviti.com<mailto:Kennet...@Protiviti.com>
> Connect:

> LinkedIn<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.link
> edin.com_in_kennethmy&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAt
> E256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7K
> t-304vEDqF9fDGX8jfPq5RnStn50&s=yxnEOhIxqEJxYCndopgWxHD8FxhHFsjtBlvztmv
> whhM&e= > | Thought Leadership:

> Protiviti.com<http://www.protiviti.it/en-US/Pages/Insights.aspx>
>
> On Jun 24, 2016, at 08:01, "dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>" <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> wrote:
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb...@gmail.com]
> Sent: Thursday, June 23, 2016 3:35 PM
> To: Eric Mill <er...@konklone.com<mailto:er...@konklone.com>>
> Cc: Ben Wilson
> <ben.w...@digicert.com<mailto:ben.w...@digicert.com>>; Kurt Roeckx
> <ku...@roeckx.be<mailto:ku...@roeckx.be>>; Richard Barnes
> <rba...@mozilla.com<mailto:rba...@mozilla.com>>; Jeremy Rowley
> <jeremy...@digicert.com<mailto:jeremy...@digicert.com>>; Steve
> <steve...@gmail.com<mailto:steve...@gmail.com>>;

> mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-secur
> ity-p...@lists.mozilla.org>; Kathleen Wilson

> mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-secur
> ity-p...@lists.mozilla.org>; Kathleen Wilson

> konklone.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__konkl
> one.com&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfM
> BgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDG
> X8jfPq5RnStn50&s=c1rqzKNHVjlgTVwNLW7gmcTVRl_FBL23W8HwCSj5YQ4&e= > |

> @konklone
> NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mozilla.org
> _listinfo_dev-2Dsecurity-2Dpolicy&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXl
> bGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlN
> VTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=Us3UaVYVbznpkZ1j73y7EA6kkrF
> wQVLbqsrIXxgTQFs&e=

[Rob Stradling]

Thanks Kenneth. Sounds complicated. ;-)

Are "federal relying parties" impacted by Mozilla's OneCRL?
If not, then is it worth considering revoking the Symantec
cross-certificate via OneCRL but _not_ revoking it via CRL/OCSP?

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

[Kurt Roeckx]

So my understanding of this is that Symantec knowns that the
other CAs have not been audited as required under the Mozilla
policy, that they shouldn't have signed those certs, but refuse to
revoke it because they're being paid for it. This is in my
opinion just not acceptable.

Either Symantec's CP/CPS is not compatible with the Mozilla
Policy in which case the Symantec root should be removed,
or they're not following it in which case they should revoke that
certificate.


Kurt

[Eric Mill]

On Tue, Jun 28, 2016 at 5:48 PM, Myers, Kenneth (10421) <
kennet...@protiviti.com> wrote:

>
> To revoke the Symantec certificate, the certificates issued by
> organizations under Symantec would no longer be trusted by federal relying
> parties.

No, I don't believe this is accurate. If Symantec revokes their
cross-signature of the Federal Bridge, then entities which trust Symantec
will no longer also automatically trust the Federal Bridge.

It's *only* if the Federal Bridge revokes their cross-signature of Symantec
that certificates issued by organizations under Symantec would no longer be
trusted by relying parties.

Each of those cross-signatures can be independently revoked, and the only
thing that's being discussed here is the cross-signature that Symantec made
(using its Mozilla-trusted root) of the Federal Bridge. That should not
have a drastic impact on federal relying parties.

Symantec is resolving the issue with the Federal PKI Policy Authority, but
> the risk to revoking the certificate is still uncertain.
>

As I said above, the technical impact of revoking the certificate was
misstated, so the risk should be assessed with the understanding that only
one direction of the relationship is under request to be revoked.

> 2) It is not acceptable for CAs trusted by the Mozilla Program to
> cross-sign with the Federal Bridge (From Richard Barnes)

...

This does not include the federal relying party and commercial applications
> which accept FPKI certificates for authentication or other purposes. It is

> important to the Federal PKI that theses certificates are trusted ...
>

To be clear though, the Federal Bridge (anyone, really) could choose to
cross-sign roots trusted by the Mozilla trusted root program. I could spin
up a new CA on my laptop and cross-sign Symantec's root myself. That
wouldn't add any risk to the Mozilla root program. It's the other way
around that matters.

-- Eric

[Myers, Kenneth (10421)]

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

[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

[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) <kennet...@protiviti.com> 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

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

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

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

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