Re: Expired Certificates Listed by Certificate Manager

[userwithuid via dev-security-policy]

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...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[Ryan Sleevi via dev-security-policy]

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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[Ryan Sleevi via dev-security-policy]

On Tue, Aug 15, 2017 at 8:31 AM, Gervase Markham via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[userwithuid via dev-security-policy]

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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Expired Certificates Listed by Certificate Manager

[David E. Ross via dev-security-policy]

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


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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy