Expired Certificates Listed by Certificate Manager

[David E. Ross]

Under the Servers tab for Certificate Manager, I see several root
certificates whose expiration dates have passed. I believe these were
all marked untrusted at one time. For example, I see six DigiNotar
certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
others. Is it safe to delete these?

No, I would not delete DigiNotar Root CA or DigiNotar PKIoverheid CA
Organisatie, neither of which have yet reached their expiration dates.

--
David Ross

<http://www.rossde.com/>
President Trump now denies there are any tapes that
recorded his conversations with ex-FBI Director Comey.
Between when Trump hinted there might be such tapes
and his denial, there was sufficient time to destroy
any tapes.

[userwithuid]

On Wednesday, July 26, 2017 at 12:55:06 AM UTC, David E. Ross wrote:
> Under the Servers tab for Certificate Manager, I see several root
> certificates whose expiration dates have passed. I believe these were
> all marked untrusted at one time. For example, I see six DigiNotar
> certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
> others. Is it safe to delete these?

IIRC, Mozilla just likes to keep expired distrust around because it cannot be overridden in the UI, whereas expired or unknown certs might be something a regular user might consider not that big of a deal and click through.


In this context @Mozilla: Those additional distrust entries are coming from NSS, but they are all pre-OneCRL afaics. Is this coincidence (= there wasn't any "high-profile" enough distrust warranting nss addition) or has the certdata-based distrust been entirely obsoleted by OneCRL (= there will never be any new distrust entries in certdata)?

I'm asking because some/most linux distros consume certdata, and they usually do have some blacklist capability where they put the certdata based distrust, but I don't know of any that parses OneCRL. I guess they all should, right?

[Gervase Markham]

On 01/08/17 09:21, userwithuid wrote:
> In this context @Mozilla: Those additional distrust entries are
> coming from NSS, but they are all pre-OneCRL afaics. Is this
> coincidence (= there wasn't any "high-profile" enough distrust
> warranting nss addition) or has the certdata-based distrust been
> entirely obsoleted by OneCRL (= there will never be any new distrust
> entries in certdata)?

OneCRL does not obsolete certdata.txt-based distrust because not
everyone checks OneCRL. While we can't add every cert in OneCRL to
certdata.txt, we should add the big dis-trusts to it. Do you think
there's anything missing?

Gerv

[Ryan Sleevi]

On Tue, Aug 15, 2017 at 8:31 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 01/08/17 09:21, userwithuid wrote:

> > In this context @Mozilla: Those additional distrust entries are
> > coming from NSS, but they are all pre-OneCRL afaics. Is this
> > coincidence (= there wasn't any "high-profile" enough distrust
> > warranting nss addition) or has the certdata-based distrust been
> > entirely obsoleted by OneCRL (= there will never be any new distrust
> > entries in certdata)?
>

> OneCRL does not obsolete certdata.txt-based distrust because not
> everyone checks OneCRL. While we can't add every cert in OneCRL to
> certdata.txt, we should add the big dis-trusts to it. Do you think
> there's anything missing?
>

Note: adding to certdata.txt, at present, will have various undesirable
side-effects:

- Distrust records, without associated certs, can present UI issues when
viewing and editing (which is why the associated certs are included in
certdata.txt)
- Distrust records, without associated certs, creates issues for various
tools consuming certdata.txt
- Distrust records, _with_ associated certs, can present UI issues when
viewing and editing (yes, it's a no-win, and that's the point)
- Distrust records, _with_ associated certs, can present new challenges for
distributions that patch (failing to include a new root = things don't work
that should. failing to distrust an old certificate = things that shouldn't
work, do)

Could you indicate what you believe 'big' distrusts are versus 'little'
distrusts? Are we talking root vs subordinate CA? Something else?

Given that distrusting a certificate (whether because CA requested - such
as a cessation of operation - or imposed - such as compromised) presents
path building risks and challenges, the current approach of placing it
within OneCRL minimizes the risk to certdata.txt consumers, which are
fairly consistently poorly suited for path discovery, and generally only
possess limited path validation capabilities. That is, introducing distrust
records could 'break' legitimate chains, given the common path "building"
implementation, which is why it's useful to keep separate.

[Gervase Markham]

On 15/08/17 13:59, Ryan Sleevi wrote:
> Note: adding to certdata.txt, at present, will have various undesirable
> side-effects:
>
> - Distrust records, without associated certs, can present UI issues when
> viewing and editing (which is why the associated certs are included in
> certdata.txt)

The current distrust records do have associated certs, right?

> - Distrust records, _with_ associated certs, can present UI issues when
> viewing and editing (yes, it's a no-win, and that's the point)

I assume you mean UI issues in Firefox/Thunderbird specifically?

> - Distrust records, _with_ associated certs, can present new challenges for
> distributions that patch (failing to include a new root = things don't work
> that should. failing to distrust an old certificate = things that shouldn't
> work, do)

However, these are existing rather than new challenges, given that we
already have such certificates in the store.

> Could you indicate what you believe 'big' distrusts are versus 'little'
> distrusts? Are we talking root vs subordinate CA? Something else?

"Big" probably means Diginotar-scale Internet hoo-ha.

Gerv

[Ryan Sleevi]

On Tuesday, August 15, 2017 at 10:34:27 AM UTC-4, Gervase Markham wrote:
> On 15/08/17 13:59, Ryan Sleevi wrote:
> > Note: adding to certdata.txt, at present, will have various undesirable
> > side-effects:
> >
> > - Distrust records, without associated certs, can present UI issues when
> > viewing and editing (which is why the associated certs are included in
> > certdata.txt)
>
> The current distrust records do have associated certs, right?

Correct. This presents them in the UI (both expired and non-expired - hence this thread).

> > - Distrust records, _with_ associated certs, can present UI issues when
> > viewing and editing (yes, it's a no-win, and that's the point)
>
> I assume you mean UI issues in Firefox/Thunderbird specifically?

No, I actually mean the UI of any NSS-using application, since NSS itself does not ship with a UI. That's handled by PSM in Firefox/Thunderbird, a similar UI in Chrome, and my understanding is that several tools also exist in the Linux space.

We regularly see bugs from Chrome on Linux users (and Chrome on ChromeOS, where we've adopted a similar approach) complaining about confusion about certificates being listed in the UI but that explicitly aren't trusted (or the subtle change that these flags had depending on NSS version).

> > - Distrust records, _with_ associated certs, can present new challenges for
> > distributions that patch (failing to include a new root = things don't work
> > that should. failing to distrust an old certificate = things that shouldn't
> > work, do)
>
> However, these are existing rather than new challenges, given that we
> already have such certificates in the store.

Yup. But it's something to be aware of when folks propose, say, adding the OneCRL-set of distrust, which would be several hundred more certificates (463, it looks like)

[userwithuid]

On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote:
> OneCRL does not obsolete certdata.txt-based distrust because not
> everyone checks OneCRL. While we can't add every cert in OneCRL to
> certdata.txt, we should add the big dis-trusts to it. Do you think
> there's anything missing?

I'm not following this CA stuff for that long, but one thing that comes to mind is the us gov pki. The symantec cross-sign has expired by now and the identrust one only has 5 months left, so going by current public info this will resolve itself soon. Still, for 2 years now a huge, intransparent, complex subtree is (probably) blocked for OneCRL clients, but trusted for non-OneCRL (+non-OCSP) users. Imho this is/was a little more high-profile than most other entries.

Another situation: Old Wosign/StartCom roots are slated to be removed from certdata soon afaik. Finally, end of that story, right? But old WoSign has a revoked cross-signed by Certum until 2020. So Firefox and OCSP clients will get the expected result: No more old WoSign. "Just certdata"-consumers will still have it trusted and hardly anybody will know that this is happening or how. Candidate for addition?

In general: When I read the messages on this list, I get the following impression:

1. GOOD: Revocation alone is "not really enough", mis-issuance is still bad and it reflects badly on a CA if there are too many issues or their handling is poor.
2. HOWEVER: In practice, once a cert is revoked and added to OneCRL, both the CA and Mozilla consider that particular issue resolved. A revoked cert or subtree is considered "not in scope" any more (and understandably so, there isn't much more that can be done on the technical level save removing the entire root for really bad cases).

So to me it kinda felt like non-OneCRL is not taken into account by Mozilla any more. But since you said certdata distrust might still be used, a suggestion:

The Mozilla workflow seems to be missing a step that checks whether a revoked subCA will 1. keep issuing certs (e.g. I just read up on the Disney CA that was revoked, then started issuing non-compliant certs) and 2. whether exisiting certs at the time of revocation had critical issues (e.g. failed validation). In both cases certdata addition should be at least considered. Otoh, additions stemming from e.g. the recent reports seem to be good candidates for OneCRL-only distrust. Same if a subCA just moved roots or stopped operating and that was the reason for revocation.

Basically: Figure out/inquire why the revocation happened and classify as high or low risk. Maybe Mozilla's policy could be adjusted to require CAs to provide such an explanation on revocation? I'm aware that there is a "revocation reason" in OCSP already, but that is insufficient (e.g. "cessation of operation" for identrust federal bridge cross...).