Re: Misissuance/non-compliance remediation timelines

[Paul Kehrer via dev-security-policy]

On February 9, 2018 at 1:24:12 AM, Wayne Thayer (wtha...@mozilla.com) wrote:

On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> So, how long is too long?
>

This is the crux of the issue for me. If a CA (that really should have
stopped responding 'good' for unknown certs back in 2013) needs to select,
purchase, and deploy an entirely new OCSP system, is 5 months a really long
time? From their perspective, probably not.

I agree that from their perspective that's a short period of time. However,
I strongly believe that asking the public to bear the burden of a CA's own
incompetence is, while historically what has been done, not tenable moving
forward. In the specific case of the OCSP issues I question why we should
give CAs half a year to remediate a fault that had already been a
requirement for 4 years when it was discovered. In many ways a CA's primary
job is knowing and following the rules, so why are we giving CAs who fail
in such colossal fashion a free pass?



I don't believe there is a standard answer to this question that can apply
to a whole class of issues, but I do think we could do a better job of
communicating our expectations when a situation like this arises by making
a statement such as 'being a CA that has been granted the public's trust,
Mozilla expects problem X to be resolved in Y days'. Responsible CAs will
meet the deadline and thus distinguish themselves from CAs that simply
aren't taking the problem seriously.

If Mozilla provides a deadline and a CA misses it, what's the penalty?

I believe a graduated notion of penalties and risk mitigation would make it
easier for Mozilla to push CAs. If the only penalty is distrust then
"little" things like a slow but steady trickle of misissued certificates,
operating your OCSP responder out of compliance for 4 years, or failing to
get a BR audit for 3 years after they became required never rise to the
level of a distrust conversation. If, on the other hand, there exists a set
of penalty tiers a CA can be placed on that path relatively quickly.
Instead of a "sudden" (from the perspective of the CA or subscribers who
aren't engaged with policy discussions on mdsp) distrust thread, there is
an escalation that makes everyone aware of a CA's need to shape up.


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

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wyane,
> resopnding to your notes:
>
> Section 4.9 states that in any case that Comsign is notified about a
> misissuance (no matter if it was notified by a subscriber or in any other
> way) Comsign shall revoke the certificate.
>
> I have re-read section 4.9 of the ComSign CPS and I still do not agree
with your interpretation. However, I also believe that your current
language complies with Mozilla policy and the BR's.

It is true that we didn’t update the version number and we have corrected
> it. Along with updating the CPS version management table as well.
>
> about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>
> To recap, this inclusion request is for the ComSign Global Root CA that
was created in 2011[1]. This root was first BR audited on 26-April 2015,
but 36 end-entity certificates were issued prior to that time [2] (all but
one has since expired). We also have some evidence [3] that ComSign
received an ETSI 101 456 audit in 2012. ComSign stated “Back then it seems
we didn’t have a WebTrust audit (I believe we started in 2015) but only
external CPA and governmental audits as are attached already.” However, I
am unable to locate any additional audit documentation covering 2011-2015.

about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>

ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
issue certificates. This version has not been supported since July 2013
[4]. This implies that all 36 certificates were issued using unsupported CA
software.

I’ve discovered that ComSign recently issued two new unconstrained
subordinate CAs [5] from this root that contain a non-critical
basicConstraints extension in violation of BR 7.1.2.2. Another
unconstrained subordinate CA has been used to issue email certificates that
contain encoding errors [6].

In addition, numerous problems with ComSign’s CPS have been discussed in
this thread.

So, like we mentioned earlier we would like to be approved in advance so we
> could start issuing as soon as the new system will be in use.
>

While I appreciate ComSign’s efforts to resolve issues that have been
identified, new ones continue to be found. I am not at all comfortable
recommending that this request proceed at this time, and I have also lost
confidence that trust can ever be established for this root given its
history. I support Ryan’s recommendation that this request be denied and
that ComSign be asked to submit a new root containing a new key pair that
has not been used with their outdated CA system.

I would appreciate your comments on this course of action.

Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=675060
[2] https://bugzilla.mozilla.org/attachment.cgi?id=8938861
[3] https://bug675060.bmoattachments.org/attachment.cgi?id=615121
[4] https://community.rsa.com/docs/DOC-73367
[5] https://crt.sh/?cablint=680=1631=2017-01-01
[6] https://crt.sh/?caid=14449=x509lint=2014-01-01
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 8, 2018 at 3:14 PM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 8 Feb 2018 15:50:08 +
> Gervase Markham via dev-security-policy
>  wrote:
>
> > In this case, the certificates are revoked in Firefox via OneCRL and
> > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
> > noticed.
>
> Hi Gerv,
>
> Independent of this specific case, which I guess is mostly harmless, I
> find this worrying.
>
> Let's assume something like this happens:
> * CA xyz, which is trusted by Mozilla and other root stores, issues a
>   sub-certificate for company SuperShady Inc. Immediately after that
>   CA xyz asks Mozilla to include it into OneCRL and Google to include
>   it in CRLsets.
> * SuperShady Inc. starts selling certificates. Their offer is that you
>   can get a certificate for every domain you want, the price depends on
>   how popular the domain is. If you pay enough you can get a
>   certificate that's valid for google.com or facebook.com.
> * SuperShady Inc. advertises their certificates with the fact that
>   while they won't be valid in mainstream browsers due to revocation
>   lists they still work in many situations, i.e. they will be
>   considered valid by commandline tools or API calls from many
>   programming languages as they don't include a mechanism like OneCRL.
>
> I'm aware that this goes into the tricky topic of people consuming the
> Mozilla CA root store without implementing the full certificate
> validation logic, which is already a problem with deprecated CAs like
> the old Symantec roots that are phased out.
> But this is much more sever. While we don't expect that the
> Symantec roots have been operated with the care we expect from a CA we
> also don't have any indication that they're used for outright malicious
> purposes.
>
> Yet I feel what you and others here are implying is that once a subca
> is part of OneCRL and revoked they're no longer bound to any standards
> at all.
>

How is this different from CA xyz asks for their root to be removed from
Mozilla products and other root stores, but applications and devices use
older versions?

The simple answer is that those commandline tools and API calls for
programming language are responsible for their application security. They
always have been. They don't get a free pass now. A root store is as much a
product decision as the choice of programming language to write it in.

The same argument you're making here is if CA xyz revokes SuperShady Inc's
certificate. The same commandline tools and APIs for programming languages
don't do revocation checking (often times because their design is such that
it's impossible for them to do so, because making network requests is the
caller's job or shouldn't be done in the batch processing)

We've had the discussion on m.d.s.p. in a variety of ways in the past
regarding consumption of the root stores and program decisions. There's
even a FAQ about it to cover this question which is periodically raised, as
it is now -
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

"""Therefore, anyone considering bundling Mozilla's root store with other
software needs to be aware of the issues surrounding providing a root
store, and committed to making sure that they maintain security for their
users by carefully observing Mozilla's actions and taking appropriate steps
of their own. On a best-efforts basis, Mozilla maintains a list of the
additional things users of our store might need to consider. """

OneCRL is a way that attempts to address impact and risk for Mozilla
Firefox users. It is not inherently going to be guaranteed to be
appropriate for other use cases - each application vendor needs to evaluate
their community of users, the expectations, the stability contracts, the
impacts, etc when it decides to handle revocation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

[Hanno Böck via dev-security-policy]

On Thu, 8 Feb 2018 15:50:08 +
Gervase Markham via dev-security-policy
 wrote:

> In this case, the certificates are revoked in Firefox via OneCRL and
> Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
> noticed.

Hi Gerv,

Independent of this specific case, which I guess is mostly harmless, I
find this worrying.

Let's assume something like this happens:
* CA xyz, which is trusted by Mozilla and other root stores, issues a
  sub-certificate for company SuperShady Inc. Immediately after that
  CA xyz asks Mozilla to include it into OneCRL and Google to include
  it in CRLsets.
* SuperShady Inc. starts selling certificates. Their offer is that you
  can get a certificate for every domain you want, the price depends on
  how popular the domain is. If you pay enough you can get a
  certificate that's valid for google.com or facebook.com.
* SuperShady Inc. advertises their certificates with the fact that
  while they won't be valid in mainstream browsers due to revocation
  lists they still work in many situations, i.e. they will be
  considered valid by commandline tools or API calls from many
  programming languages as they don't include a mechanism like OneCRL.

I'm aware that this goes into the tricky topic of people consuming the
Mozilla CA root store without implementing the full certificate
validation logic, which is already a problem with deprecated CAs like
the old Symantec roots that are phased out.
But this is much more sever. While we don't expect that the
Symantec roots have been operated with the care we expect from a CA we
also don't have any indication that they're used for outright malicious
purposes.

Yet I feel what you and others here are implying is that once a subca
is part of OneCRL and revoked they're no longer bound to any standards
at all.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

[Wayne Thayer via dev-security-policy]

On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:
>
>> On 08/02/18 13:47, Hanno Böck wrote:
>>
>> OneCRL additions normally have an associated bug but I can't see one for
>> this...
>>
>
> https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed)
> suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.
>
> This bug explains the recent addition of this subordinate CA to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1397969

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

Re: Misissuance/non-compliance remediation timelines

[Wayne Thayer via dev-security-policy]

On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> So, how long is too long?
>

This is the crux of the issue for me. If a CA (that really should have
stopped responding 'good' for unknown certs back in 2013) needs to select,
purchase, and deploy an entirely new OCSP system, is 5 months a really long
time? From their perspective, probably not.

I don't believe there is a standard answer to this question that can apply
to a whole class of issues, but I do think we could do a better job of
communicating our expectations when a situation like this arises by making
a statement such as 'being a CA that has been granted the public's trust,
Mozilla expects problem X to be resolved in Y days'. Responsible CAs will
meet the deadline and thus distinguish themselves from CAs that simply
aren't taking the problem seriously.

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

Re: Certificate for com and it

[Rob Stradling via dev-security-policy]

On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:

On 08/02/18 13:47, Hanno Böck wrote:

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.


In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.


The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.


If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...


I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.


OneCRL additions normally have an associated bug but I can't see one for
this...


https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed) 
suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

[Gervase Markham via dev-security-policy]

On 08/02/18 13:47, Hanno Böck wrote:
> Is a revoked intermediate cert a license for operating a yolo CA that
> signs everything? Given the fragility of revocation checking I'd find
> that a problematic precedent.

In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.

> The OCSP seems operational and replies with "Good" and the issuance
> happened before it's being added to OneCRL.

If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...

> I don't find a reference why this intermediate had been added to
> OneCRL, but I think this deserves more clarification what's going on
> here.

OneCRL additions normally have an associated bug but I can't see one for
this...

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

Re: Misissuance/non-compliance remediation timelines

[Gervase Markham via dev-security-policy]

On 07/02/18 15:14, Alex Gaynor wrote:
> That said, given the issues Paul highlighted in his original mail (which I
> wholeheartedly concur with), it seems the place to focus is the folks who
> are getting Ds right now. Therefore I think the essential part of your
> email is your agreement that CAs which are persistently low performing need
> to be recognized and potentially penalized for the sum total of their
> behaviors.

This is, in a reasonably strong sense, what happens now. We require each
incident in which a CA is involved to be documented in a public bug, so
all can see the timeline, outcomes, how the CA reacted and other factors
which might be taken into account when determining a CA's competence.

Occasionally, we decide that some CA's list of recent[0] problems is
sufficiently serious[0] that we need to run an investigation. We do so,
and invite the CA to more formally comment on the sum total of the
problems. We assess the responses and the style and level of response,
and make a determination[0]. This is what happened to WoSign, Symantec
and PROCERT:
https://wiki.mozilla.org/CA:WoSign_Issues
https://wiki.mozilla.org/CA:Symantec_Issues
https://wiki.mozilla.org/CA:PROCERT_Issues

I therefore expect and hope that CAs in our program have noted what
happened in those cases, particularly PROCERT (which is probably the
clearest case of simple "general incompetence" that we have had), and
want to make sure they are not next.

Gerv


[0] Yes, this is vague. But so is the concept of "trust".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[westmail24--- via dev-security-policy]

Also, it should be understood that on Linux OS no transitional periods will be 
made, but simply to removes all Symantec certificates from a certain date.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
> The subCAs that we know of that fall into this category belong to Google
> and Apple. If there are any other subCAs that fall into this category,
> please let us know immediately. Google has one such subCA; Apple has seven.

Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted
on 2017-10-17, has Mozilla learned about any additional subCAs that will
require a similar treatment?

I assume that the end of the primary development phase for Firefox 60,
which is early March 2018, will be the deadline to add whitelisting for
any such subCAs.

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

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 16.10.2017 20:26, Eric Mill via dev-security-policy wrote:
> Adding code to Firefox to support the distrust of specified subCAs seems
> like it would be a good long-term investment for Mozilla, as it would give
> Mozilla a lot more flexibility during future distrust events.

I think this isn't about distrust of specified subCAs, but rather about
keeping subCAs actively trusted, despite their issueing roots being no
longer trusted.

Kai

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

Re: Certificate for com and it

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 6 Feb 2018 16:56:48 +0100
Kurt Roeckx via dev-security-policy
 wrote:
> I should probably more clear, the certificates of the CA have been
> revoked.

I'm wondering what that means.

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.

The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.
I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 16.10.2017 19:33, Gervase Markham via dev-security-policy wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
> 
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
> 
> * January 2018 (Firefox 58): Notices in the Developer Console will warn
> about Symantec certificates issued before 2016-06-01, to encourage site
> owners to migrate their TLS certs.
> 
> * May 2018 (Firefox 60): Websites will show an untrusted connection
> error if they have a TLS cert issued before 2016-06-01 that chains up to
> a Symantec root.

My understanding is, this will be done without making any changes to the
Mozilla CA list. Firefox will implement these initial phases by changing
its certificate validation code.

It seems likely that many other consumers of the Mozilla CA list, which
use their own implementation for certificate validation, will likely not
implement these initial phases. I'm probably stating the obvious.

I'd like to thank the developers who can implement this initial distrust
phase in their software, as it will clear the way for the later phase of
distrust, benefitting other TLS client software which cannot easily
implement the initial phases.


> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.

This is the milestone that will affect also the secondary consumers of
the Mozilla CA list. I assume the updated CA list with the removed
Symantec roots will be published as part of NSS 3.39 around mid October.


> However, there are some subCAs of the Symantec roots that are
> independently operated by companies ... [snip] ...> There are two ways that 
> we can provide a smoother transition for these
> subCAs.

I haven't seen a follow up message with a decision on this detail. I
assume it's still open for discussion.


> Option 1)
> Temporarily treat these subCAs as directly-included trust-anchors.
> ... [snip]
> 
> Option 2)
> Add code to Firefox to disable the root such that only certain subCAs
> will continue to function. So, the final dis-trust of Symantec roots may
> actually involve letting one or two of the root certs remain in
> Mozilla’s trust store, but having special code to distrust all but
> specified subCAs. ... [snip]

I assume that these subCAs are used on the public web. IIUC, after
secondary consumers of the Mozilla CA list update to the newer version,
they will also require a solution that allows them to continue to trust
these subCAs.

Option 2 solves the issue for Firefox, but it isn't a practical solution
for secondary consumers of the Mozilla CA list.

There are too many implementations of certificate validation, and I
think it's unrealistic that each implementation can implement Option 2.

Without implementing option 2, but to keep compatibility with the public
web, those secondary consumers would have to modify the Mozilla CA list.
There's risk they might decide to continue to trust the Symantec CAs, as
that would be the easiest and most compatible approach. I think we
should avoid that secondary consumers might consider this solution, as
it would be counterproductive to this initiative.

I understand that secondary consumers of the Mozilla CA list aren't the
primary focus of Mozilla and of this policy list, but in the interest of
applying the Symantec distrust initiative to the majority of the open
source software ecosystem, it might be prererable to implement Option 1
in the Mozilla CA list.

Gerv mentioned the following concerns on Option 1:

> Mozilla prefers *not* to take this approach, because even if clearly
> explained up front that it is a temporary solution with deadlines, it
> would be very easy for people to start treating such a subCA as a
> regular trust anchor, and thereby have that subCA become a de facto
> included CA. 

If consumers of the Mozilla CA list usually followed Mozilla's removal
decisions, why would they not follow Mozilla's removal of these CAs at a
later time?

Why would this be more risky than Option 2? Couldn't we similarly argue,
if a secondary consumer of the Mozilla CA list decided to implement
whitelisting of these subCAs in their certificate validation code, isn't
there similar risk that they wouldn't remove such whitelisting from
their code? I'd even argue that a code implementation has a higher risk
of surviving for a longer amount of time, because changing code is more
difficult than changing configuration files that contain a list of
trusted CAs.


> Additionally, it could become very complicated to remove
> such subCAs in the future, especially if they have not performed the
> recommended transitions.

This message was sent in October 2017. By the time we reach October
2018, the owners of the subCAs will have known about the need to
transition away from the classic Symantec PKI for one year. In the 

Re: Statement on DigiCert’s Proposed Purchase of Symantec

[Kai Engert via dev-security-policy]

On 01.11.2017 00:58, Jeremy Rowley via dev-security-policy wrote:
> A couple of points of clarification (as it seems to have stirred some 
> questions)
> 1. Migration to the DigiCert issuing and validation process only applies to 
> certs intended for browser use, meaning the infrastructure may issue code 
> signing, email, etc certs post Dec 1. These certs will be validated and 
> issued from existing Symantec infrastructure using Symantec validation 
> processes, at least until we finish migration to DigiCert.
> 2. When I refer to "infrastructure" I mean Symantec's validation and issuing 
> systems related to TLS certificates.  We may reuse the front end systems and 
> hardware used to provide these systems post day 1.  Note that we definitely 
> plan to migrate customers to a consolidated experience, but I want to be 
> clear and transparent about what is migrating when. Dec 1 is only the TLS 
> backend.

Jeremy, you said the classic Symantec infrastructure may continue to be
used for email certificates.

Because Mozilla maintains trust flags for email security, I conclude
that some of the Symantec Root CAs cannot be removed from the CA list in
October 2018 for Firefox 63, but rather they will have their web site
trust bit removed, only. Is this correct?

If yes, what is the subset of Root CAs that are used for email and must
continue to be included as trusted for email? Is that subset equivalent
to the set of CAs that currently have the email trust bit enabled?

Is there a schedule for the removal of Symantec's email trust bits, or
do you assume that the relevant set of Symantec Root CAs will need to be
trusted for email until they expire?

(Because code signing trust is no longer part of the Mozilla CA store,
the continued issueing of code signing certs using Symantec
infrastructure seems irrelevant for the Mozilla trust store.)

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