Re: EJBCA defaulting to 63 bit serial numbers

[Jaime Hablutzel via dev-security-policy]

> I believe Root programs have the necessary policy in place to treat 
> incidents -in exceptional circumstances- on a case-by-case basis. Wayne 
> had mentioned in a previous post [4] that Mozilla doesn't want to be 
> responsible for assessing the potential impact, but that statement took 
> for granted that there was a definite violation of a requirement.

It looks like it would be useful to have this exceptions handling procedure in 
place, especially for situations like the current one with with low security 
impact but a high potential for producing service disruption everywhere.

Is Mozilla reassessing to introduce a procedure to handle exceptions?.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Jaime Hablutzel via dev-security-policy]

> The rule as written requires that the output bits have come from a CSPRNG.  
> But it doesn't say that they have to come from a single invocation of a 
> CSPRNG or that they have to be collected as a contiguous bit stream from the 
> CSPRNG with no bits of output from the CSPRNG discarded and replaced by 
> further invocation of the CSPRNG.

This reasoning has the potential to decrease the security that is provided by a 
requirement for a given minimum entropy and I'll try to illustrate my point 
better with the following fictional situation where the requirement would be 
something like this:

> ... CAs SHALL generate non-sequential Certificate serial numbers greater than 
> zero (0) containing at least 8 bits of output from a CSPRNG.

So we think that we can comply by generating serial numbers with exactly 1 byte 
fixed size as the requirement asks for 8 bits.

Then we start generating serial number candidates, but we need to perform some 
filtering:

1. First, as we want to produce one byte constant length positive serial 
numbers we filter out values where the high-order bit is 1 and we are left with 
only 128 possible values.
2. Then, we filter out the 0 value and now we have 127 possible values to 
choose from.
3. Finally, we have to discard serial numbers assigned to previously issued 
certificates and let's say we've issued 126 certificates previously, so now 
we're left with only one possible serial number to choose from.

And there it is, full predictability for the next serial number to be generated.

Now, this is just an example but my point is that the interpretation that 
allowed for one byte fixed size serial numbers was a clear mistake in the 
context of this fictional requirement.

Nevertheless, in real life we would be reducing 64 bits by just a little (e.g. 
to 63 bits), but anyway, the security is being reduced, maybe not enough to 
allow for a real attack... but there is a reduction.

Finally, as I see it, CA's should ellaborate their serial numbers generation 
strategy guaranteeing that generated serial numbers at all times, now and in 
the future (after issuing many quadrillions of certificates), will always 
contain at least 64 bits of unfiltered entropy within them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Ryan Sleevi via dev-security-policy]

On Wed, Mar 13, 2019 at 6:09 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Richard Moore via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >If any other CA wants to check theirs before someone else does, then now
> is
> >surely the time to speak up.
>
> I'd already asked previously whether any CA wanted to indicate publicly
> that
> they were compliant with BR 7.1, which zero CAs responded to (I counted
> them
> twice).  This means either there are very few CAs bothering with
> dev-security-
> policy, or they're all hunkering down and hoping it'll blow over, which
> given
> that they're going to be forced to potentially carry out mass revocations
> would be the game-theoretically sensible approach to take:


To be fair, this is not an either/or proposition. The third option is that
they could be ignoring you specifically, which may not be an unreasonable
position, game-theoretically speaking of course.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Peter Gutmann via dev-security-policy]

Richard Moore via dev-security-policy  
writes:

>If any other CA wants to check theirs before someone else does, then now is
>surely the time to speak up.

I'd already asked previously whether any CA wanted to indicate publicly that
they were compliant with BR 7.1, which zero CAs responded to (I counted them
twice).  This means either there are very few CAs bothering with dev-security-
policy, or they're all hunkering down and hoping it'll blow over, which given
that they're going to be forced to potentially carry out mass revocations
would be the game-theoretically sensible approach to take:

Option 1: Keep quiet case 1 (very likely): -> No-one notices, nothing happens.
  Keep quite case 2 (less likely): -> Someone notices, revocation 
issues.
Option 2: Say something -> Revocation issues.

So keeping your head down would be the sensible/best policy.

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Thursday, March 7, 2019 at 7:01:41 PM UTC-7, Daymion Reynolds wrote:
> As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
> Serial Number issue. We have identified a significant quantity of 
> certificates (> 1.8million) not meeting the 64bit serial number requirement. 
> We are still performing accounting so certificate quantity is expected to 
> change before we finalize the report. 
>  
> 1.How your CA first became aware of the problem (e.g. via a problem 
> report submitted to your Problem Reporting Mechanism, a discussion in 
> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
> time and date.
>  
> 9pm 3/6/2019 AZ Time, due to reviewing a discussion in 
> mozilla.dev.security.policy.
>  
> 2.A timeline of the actions your CA took in response. A timeline is a 
> date-and-time-stamped sequence of all relevant events. This may include 
> events before the incident was reported, such as when a particular 
> requirement became applicable, or a document changed, or a bug was 
> introduced, or an audit was done.
>  
> 9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla 
> group. 
> 10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified 
> root cause.
> 6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial 
> number issue.
> We are still quantifying and classifying the certificate scope of impact. 
>  
> 3.Whether your CA has stopped, or has not yet stopped, issuing 
> certificates with the problem. A statement that you have will be considered a 
> pledge to the community; a statement that you have not requires an 
> explanation.
>  
> We have deployed a fix to the issue, and are no longer issuing certificates 
> with the defect. 
>  
> 4.A summary of the problematic certificates. For each problem: number of 
> certs, and the date the first and last certs with that problem were issued.
>  
> Issue was introduced with a change in 2016. Impacted certificates still being 
> aggregated. Will update with information and timeline on issue closure.
>  
> 5.The complete certificate data for the problematic certificates. The 
> recommended way to provide this is to ensure each certificate is logged to CT 
> and then list the fingerprints or crt.sh IDs, either in the report or as an 
> attached spreadsheet, with one list per distinct problem.
>  
> Still being aggregated. Will update with certificate information on issue 
> closure.
>  
> 6.Explanation about how and why the mistakes were made or bugs 
> introduced, and how they avoided detection until now.
>  
> Ambiguity in language led to different interpretations of BR 7.1. It was 
> believed a unsigned 64bit integer was sufficient to satisfy the new 
> requirement. Additionally, industry tools like CABLint/ZLint were not 
> catching this issue, which provided a false sense of compliance. We are 
> submitting CABLint/Zlint updates as part of the fix. 
>  
> 7.List of steps your CA is taking to resolve the situation and ensure 
> such issuance will not be repeated in the future, accompanied with a timeline 
> of when your CA expects to accomplish these things.
>  
> Defect has been resolved, we are also updating linting tools (CABLint/Zlint) 
> and upstreaming to patch for other peoples usage.

In accordance with our conversations to date, prior to 3/7 6:30pm AZ we 
utilized raw 64 bit output from CSPRING, with uniqueness and non zero checks. 
This new understanding of the rules calls for us to modify our original 
disclosure to 0 affected certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Richard Moore via dev-security-policy]

On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote:
> 
> The expected distribution when generating a random 64 bit integer
> and properly encoding that as DER is that:
> - about 1/2 integers require 9 bytes
> - about 1/2 integers require 8 bytes
> - about 1/512 integers require 7 bytes
> - about 1/131072 integers require 6 bytes
> - about 1/33554432 integers require 5 bytes
> - [...]
> 
> That a serial is smaller than 8 bytes is not an indication that it
> doesn't contain enough entropy.

This is true, but the situation is surely worse - any CA who's serial numbers 
do not have a significant length variation is almost certainly not providing 64 
bits of entropy with the exception of those who are add a prefix to ensure it 
is positive, and even those are not providing it unless they have lots of 
serial numbers with a big block of zeros.

If any other CA wants to check theirs before someone else does, then now is 
surely the time to speak up.

Kind Regards

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

Pre-Incident Report - AT GlobalSign customer CA Serial Number Entropy

[Doug Beattie via dev-security-policy]

When the serial number issue was first disclosed we reviewed all GlobalSign
certificates issued from our systems and found no issues wrt serial number
length.  While all GlobalSign systems are compliant, one of our customers
running an on-premise CA that chains to a GlobalSign root, AT, uses EJBCA
and has been using the default configuration.  They have been notified to
immediately stop issuance, update their configurations, replace and then
revoke all affected certificates.

Their Intermediate CA is: https://crt.sh/?caid=10154

Under that CA they have 3 CAs, and here is the estimated number of
non-compliant active certificates:
https://crt.sh/?caid=10155 (fewer than 200 active certificates)
https://crt.sh/?caid=12658 (14 active 10-day certificates)
https://crt.sh/?caid=10157  (4 active certificates) 


 
1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.
 
When performing self-compliance check on our Trusted Root customers based on
emails to mdsp list with similar issues.
 
2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.
 
3/1/2019: GlobalSign self-assessment on certificates issued from our data
center.  All certificates are compliant as we had set sufficient serial
number lengths prior to the CABF requirement to move to 64 bits of entropy.

3/13/2019: GlobalSign initiated and completed assessment of SSL certificates
issued by our 3 remaining customers that have CAs chaining to GlobalSign
roots.  We observed that one of these customers, AT, uses EJBCA with the
default serial number settings.


3. Whether your CA has stopped, or has not yet stopped, issuing certificates
with the problem. A statement that you have will be considered a pledge to
the community; a statement that you have not requires an explanation.
 
We have informed AT to stop issuance and will confirm that this is the
case tomorrow morning.

4. A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued.

Initial reporting indicates there are fewer than 200 active certificates.
The links above can be used to identify the detailed list of certificates
and we will compile a complete list based on input from AT
 
5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem.

We will compute a report shortly, but currently the scope is limited to the
3 CAs are listed above.  Every active certificate under these CAs has serial
numbers that contain fewer than 64 bits of entropy.
 
6. Explanation about how and why the mistakes were made or bugs introduced,
and how they avoided detection until now.

We will collect this information from AT in the coming days
 
7. List of steps your CA is taking to resolve the situation and ensure such
issuance will not be repeated in the future, accompanied with a timeline of
when your CA expects to accomplish these things.
 
We are working with AT to correct this problem.  Our plans to revoke these
CAs and to terminate all Trusted Root SSL CAs is on track for August.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Pre-Incident report: PKIoverheid Serial Number Entropy

[Berge, J. van den (Jochem) - Logius via dev-security-policy]

Hello MDSP,

Logius PKIoverheid wants to report a potential issue that we've found with one 
of our TSPs issuing certificates under the Staat der Nederlanden Root CAs

All times are in UTC +1


1.How your CA first became aware of the problem (e.g. via a problem 
report submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.

3/8/2019 12.30, due to reviewing discussions in mozilla.dev.security.policy.

2.A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.


30/9/2016 Ballot 364 came into effect. The CP of Logius PKIoverheid already 
stipulated the use of 64-bit serial numbers and as such, no change was deemed 
necessary to the CP. Our CP (Programme of Requirements) is a baseline document, 
stating the absolute minimum. This ballot predates the incident which 
PKIoverheid had about serial numbers with one of her other TSP's in 2017 [1]. 
Measures which were taken then didn't apply retroactively.

3/8/2019 12.30 While reading MSDP the Logius PKIoverheid started an 
investigation if it was possible that her TSP's had this 
implementation/interpretation issue

3/8/2019 13.15 Logius PKIoverheid suspects that this issue could potentially 
impact one or more of the TSPs under PKIoverheid. Logius PKIoverheid asked the 
TSP KPN to launch an investigation if said issue was applicable to certificates 
issued by KPN.

3/11/2019 09:53 Logius PKIoverheid asked KPN for an update following statements 
from both Google and Mozilla representatives stating that in their view the 
matter as reported by several other CAs violates the BRG.

3/11/2019 16:55 KPN answers that this issue is potentially impacting all of 
their issued TLS certificates issued between September 30, 2016 and March 5, 
2019. On March 5, 2019 KPN switched to using 96 bit serial numbers (already 
planned a while ago, this was not related to the current issue at hand).

3/12/2019 10:30 Due to the potential impact of revoking (and replacing) the 
PKIoverheid certificates from KPN issued in the period an incident is raised 
within Logius. KPN PKIoverheid certificates are in use by many Dutch government 
parties including the national ID system (DigiD), the tax services and Dutch 
customs. Because of this a crisis team is formed (also due to the fact that 
March/April is the month in which most tax returns need to be filed and the 
ever increasing change of a no-deal Brexit, which would greatly impact Dutch 
Customs) .

3/13/2019 12:00 Logius PKIoverheid orders KPN to further investigate which 
certificates are exactly affected and order KPN to revoke the certificates in 
question.

3.Whether your CA has stopped, or has not yet stopped, issuing 
certificates with the problem. A statement that you have will be considered a 
pledge to the community; a statement that you have not requires an explanation.

All certificates issued by KPN after March 5 08:30 are using 96-bit serial 
numbers. As mentioned this was a change unrelated to the current issue. As far 
as we know there are no TSPs within PKIoverheid other than KPN were up to 
recently issuing certificates with this issue. Further investigation is ongoing 
to see if there are possible historic issuance that might be impacted by this 
issue. We will post an update when we have more information.

4.A summary of the problematic certificates. For each problem: number 
of certs, and the date the first and last certs with that problem were issued.

Potentially 22.000 TLS certificates issued by KPN CAs 
https://crt.sh/?id=63094369 and https://crt.sh/?id=16678400. Also potentially 
~350 EV certificate issued by CA https://crt.sh/?id=15971988. Investigation is 
still ongoing to which certificates are exactly affected.

5.The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

Still being collected. Will update when available.

6.Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now.

As stated in the timeline, the Programme of Requirements (PoR, CP) PKIoverheid 
already stipulated the use of a serial number with a 64-bit length. When ballot 
264 went into effect, both the PA and the TSPs determined that PKIoverheid was 
already compliant. The conversations about the underlying thoughts or intent of 
the ballot were seen at the time but not taken into account when deciding the 
final impact. The final 

[fyi] Mozilla TLS Observatory downtime on march 14th

[Julien Vehent via dev-security-policy]

Hi everyone,

We are migrating TLS Observatory to a new infrastructure on March 14th, which 
will induce a 24 hours downtime.

I'll post an update when we're back online.

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

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

[Rob Stradling via dev-security-policy]

On 13/03/2019 03:04, Peter Gutmann wrote:
> Rob Stradling via dev-security-policy  
> writes:
> 
>> I've been working on an alternative proposal for a serial number generation
>> scheme, for which I intend to write an I-D and propose to the LAMPS WG.
> 
> This seems really, really complicated.

Yes, SNOT adds complexity, but this was necessary to achieve the 
security/transparency properties that I set out to achieve.

Whether or not all of those security/transparency properties are 
desirable enough to warrant (some or all) CAs taking on the burden of 
this added complexity is of course worthy of discussion.

CT, for example, is complicated, and yet the security/transparency 
properties have been deemed desirable enough to warrant burdening the 
ecosystem with the added complexity.

> In all of the endless debate over this, the one thing that hasn't actually 
> come > under question is how to generate the random values themselves. What 
has come up over> and over is how to encapsulate those values as an 
ASN.1 integer.

I'm not sure I agree that dropping 1-bit of entropy falls entirely into 
the "encapsulating those values as an ASN.1 integer" part.

> So I really prefer the
> Modest Proposal version, which directly addresses the bit-bagging problems
> that are the real issue with 7.1.
> 
> Peter.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

[Rob Stradling via dev-security-policy]

On 13/03/2019 03:18, Matthew Hardeman wrote:
> Overall I think it's a neat scheme.
> 
> It does impose some trade-offs beyond the mechanism that I proposed:
> 
> 1.  It leaves the implementing CA with no space within the serial number 
> field to include a CA significant sequence number, timestamp, or other 
> value.  That may not be a bad thing, but it's other than capabilities 
> that they have today.

To comply with today's BRs, SNOT requires that R MUST be 64-bits of 
(fresh and unfiltered!) output from a CSPRNG.

However, if using SNOT in any environment where today's BRs don't apply, 
the purpose of R is simply to act as a disambiguator; so it could be any 
string of 64-bits chosen by the CA (because the TRUNCATE_TO_64BITS(D) 
part of the algorithm is, I believe, sufficient by itself to thwart 
chosen-prefix attacks).

(For clarity: Whilst I can imagine a possible future in which the BRs 
are updated to relax the CSPRNG requirement when SNOT is used, I am *not 
proposing that here* because m.d.s.p is the wrong venue to discuss 
updating the BRs).

> 2.  It necessarily requires that the TBS certificate data be available 
> to the serial number generation routine.  This would seem to lock in 
> some architectural changes  as the system element producing the serial 
> number necessarily has to have all the TBSCertificate data), which may 
> not necessarily be the case today.

Good point.  I think this can be addressed by changing steps 7 and 8 to...

7. Perform a binary search for the first occurrence of H || A || R || D 
in the DER(TBSCertificate) that was produced in step 6, and replace that 
first occurrence with H || A || R || TRUNCATE_TO_64BITS(D).

8. Sign the (modified by step 7) DER(TBSCertificate).

> On Tue, Mar 12, 2019 at 12:10 PM Rob Stradling via dev-security-policy 
>  > wrote:
> 
> Hi all.  I've been working on an alternative proposal for a serial
> number generation scheme, for which I intend to write an I-D and
> propose
> to the LAMPS WG.  However, since other folks' proposals are already
> flowing, I will share the gist of mine here.  Comments welcome!
> 
> - Serial Number Origin Transparency (SNOT ;-) ): Generation -
> 1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte
> that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies
> "DE7Erministic".
> 
> 2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the
> TLS HashAlgorithm registry
> 
> (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18).
> 
> 3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and
> unfiltered!) output from a CSPRNG.
> 
> 4. Let M (meaning "Magic"; uint64) be the magic constant:
>     0x0102030405060708
> 
> 5. Generate the TBSCertificate template with the serial number value
> set to:
>     H || A || R || M
> 
> 6. Let D (meaning "Digest") be the thumbprint of the DER-encoded
> TBSCertificate, calculated using the hash algorithm denoted by A.
>     e.g., D = SHA-256(DER(TBSCertificate))
> 
> 7. Change the serial number value in the TBSCertificate template to:
>     H || A || R || TRUNCATE_TO_64BITS(D).
> 
> 8. Calculate DER(TBSCertificate), then sign it.
> --
> 
> Since this mechanism includes 64-bits of (fresh and unfiltered!) output
> from a CSPRNG, it is compatible with today's BRs.  The randomness also
> ensures that this mechanism doesn't yield multiple certs with the same
> serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact
> same TBSCertificate multiple times using a nondeterministic signature
> algorithm.
> 
> In terms of preventing certificate forgery (see [1]), which is the
> thing
> that unpredictable serial numbers are designed to prevent, this
> mechanism gives CAs two chances to not screw up:
>     1) if the CA implements this mechanism wrongly but nonetheless does
> successfully include 64-bits of (fresh and unfiltered!) output from a
> CSPRNG, then the desired level of security is still achieved.
>     2) or, if the CA correctly implements the deterministic parts of
> this
> mechanism but mishandles the output from their CSPRNG, then the desired
> level of security is still achieved (although let me stress that this
> would of course not be compliant with today's BRs).
> 
> Whilst this mechanism does add complexity for the CA (compared to only
> using a CSPRNG to generate serial numbers), I think that the additional
> operations on the TBSCertificate are less complicated than most CAs
> have
> already had to deal with to issue CT precertificates and embed SCTs in
> certificates.
> 
> *** ADVANTAGES OF THIS MECHANISM ***
> When implemented correctly by the CA, this 

Re: A modest proposal for a better BR 7.1

[Piotr Kucharski via dev-security-policy]

On Wed, Mar 13, 2019 at 5:52 AM Ryan Sleevi  wrote:

>
>
> On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> FWIW, the easiest would've been to remove "positive" aspect of serials.
>> Who really cares? A random number is a random number.
>>
>
> RFC 5280 cares, as it's been a long-standing source of compat issues,
> which is why RFC 5280 itself made the 'positive' requirement.
>
> https://tools.ietf.org/html/rfc5280#section-4.1.2.2
>

Oh, I know RFC is the source of this requirement (and even in that, it says
"should handle").
All I was saying, a number is a number, and making this exception only
solidified wrong implementations (said compat issues), instead of healing
the ecosystem (forcing wrong implementations to be fixed).

But I understand that's not the battle to be won or even fought here. :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy