Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> > So I would like to ask again if there is any possibility to implement some > > type of exceptions handling as asked in [2]. > > > > This has been repeatedly and unambiguously answered: categorically, the > answer is no. Could you please provide me a link to a previous discussion where the negative was stated, maybe by the module owner?. But note that I'm not asking for a bespoke or improvised exception for the current issue but for the possibility to introduce a procedure to handle any type of low breach/high disruption violations now and in the future?. ___ 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
Hi Daymion, in [1] you said before: > For the DER format the first two (0)s of the value is the positive sign of > the integer. In our case if the un-signed integer value is 64bit and the most > significant bit is set, two additional (0)s will be prepended to demonstrate > a positive sign. In this case it will be 9bytes instead of 8bytes. Always a > minimum of 8bytes (64bits) of entropy. You do still have to manage zero > compression for integer values less than 72057594037927936, which will result > in 7bytes instead of 8bytes. Implying that you were preventing an encoding shorter than 8 bytes by filtering values lower than 01 00 00 00 00 00 00 00 (which, by the way, is unnecesarily high to avoid compression as 80 00 00 00 00 00 00 suffices). But then you said: > RS - The reduction from >1.8M certificates to 12K certificates is a statement > that only those 12K certificates lacked a 64-bit entropy contribution? > DR – Yes, the 12k certs are only 7bytes or less and therefor do not meet the > BRs. Confirming that you were not filtering out serial numbers shorter than 8 bytes, which contradicts the previous. Can you please clarify?. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/E7uzTWDDBwAJ ___ 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
> >Again, maths were wrong here, sorry. Correct calculation is: > > > >log2(18446744073708551615) = 63.93 > > I love the way that people are calculating data on an arbitrarily-chosen value > pulled entirely out of thin air Can you confirm if the motivation for the "64 bits of output from a CSPRNG" can be found in [1]?. > to 14 decimal places. It's like summing a > diverging series. Or calculating how many angels can fit on the head of a > pin. Or something. > > Peter. [1] https://www.mail-archive.com/search?l=pub...@cabforum.org=subject:%22Re%5C%3A+%5C%5Bcabfpub%5C%5D+Pre%5C-Ballot+164+%5C-+Certificate+Serial+Number+Entropy%22=newest ___ 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
> So you can argue that it's not possible to comply with the BRs by > just generating a 64 bit random number, you would need to generate > at least 65. Yes, that's right, because the 64 bit entropy won't be left intact after any filtering, even the very basic zero value removal. > But I would argue that such an implementation that > only generates 64 bits and does the checks is in the spirit of what > was intended. I'm not sure if that could be the intent because it would allow the following to happen: Let's say that the biggest CA in the universe (serving other planets too) has issued the following number of certificates to the time, 18446744073709551614 (2^64 - 2), and now they need to generate a new certificate and there is only one possible serial number to choose from (the other value is the forbidden zero) and the purpose of ballot 164 (i.e. protect against https://fahrplan.events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf) is defeated. Anyway, the previous is a non-realistic example and I'm well aware that the mass violation under discussion won't affect security in the real world now, but given that in this very moment this is the formally implemented requirement, all violations should be treated according to the regular procedure, unless... The Mozilla Root Store Policy gets updated with an exceptions handling procedure which could "forgive" retroactively (possible?) this massive violation, e.g. allowing a minimum entropy of 62 bits (or less) for certificates issued until a given date (in the near future) with the purpose to accomodate to the 62 bits [1] of entropy being guaranteed by a default EJBCA <7.0.1 or to the entropy provided by any other known PKI implementation. So I would like to ask again if there is any possibility to implement some type of exceptions handling as asked in [2]. [1] log2(0x7FFF - 0x80 + 1) = 62.99435343685886 (or less if certificates has been previously generated) [2] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7WuWS_20758/erK0-f0GCwAJ ___ 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
On Thursday, March 14, 2019 at 6:09:21 PM UTC-5, Jaime Hablutzel wrote: > > 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. > > "uniqueness and non zero checks" have crippled the effective 64 bit output > from the CSPRNG, so, as I can see it, all of your previously generated serial > numbers (according to the algorithm you disclosed [1]) could be considered > non-compliant to current BRs as explained below: > > First, according to your algorithm, if the MSB in the fully random 8 octets > is 1 you add a leading 00 byte, so until that time you have 64 full bits of > entropy, i.e. 18446744073709551616 possible different values. > > Then, you have to filter out some values. To begin with, you filter out the > value 0, leaving you with 18446744073709551615 possible values. > > Now, you filter the previosly generated serial numbers (known to potential > attackers thanks to current CT deployment), let's say 100 at a given > point in time, so now you are left with 18446744073708551615 possible values. > > And if we do the math: > > 18446744073708551615 / 18446744073709551616 * 64 = > 63.9996530549578599433858 Again, maths were wrong here, sorry. Correct calculation is: log2(18446744073708551615) = 63.93 > Which is less than the required 64 bits. > > So any filtering operation (e.g. previously generated serial numbers) > actually reduce effective entropy and overall security as illustrated in the > fictional and forced scenario in [2]. > > And finally, we can realize that serial number generation algorithms, among > others requirements, have to be foresee the number of certificates intended > to be generated all along the CA lifetime. > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/mgQaADsCCwAJ ___ 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
On Thursday, March 14, 2019 at 5:13:51 PM UTC-5, Jaime Hablutzel wrote: > > 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a > > CSPRNG with at least one bit in the highest byte set to 1 > > > > is, strictly speaking, not true. The best possible implementation for > > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, > > not 64. > > > > Can you share how did you get the previous 63.994353?. > > I'm trying the following and I'm getting a different value: > > a = 2^64 = 18446744073709551616 > b = 0x80 = 36028797018963968 > > (a - b) / a * 64 = 63.875 > > Maybe I'm misunderstanding something. Maths were wrong, sorry. I got your same calculation: min = 0100 = 72057594037927936 max = 00 = 18446744073709551615 log2(max - min + 1) = 63.99435343685886 ___ 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
> 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. "uniqueness and non zero checks" have crippled the effective 64 bit output from the CSPRNG, so, as I can see it, all of your previously generated serial numbers (according to the algorithm you disclosed [1]) could be considered non-compliant to current BRs as explained below: First, according to your algorithm, if the MSB in the fully random 8 octets is 1 you add a leading 00 byte, so until that time you have 64 full bits of entropy, i.e. 18446744073709551616 possible different values. Then, you have to filter out some values. To begin with, you filter out the value 0, leaving you with 18446744073709551615 possible values. Now, you filter the previosly generated serial numbers (known to potential attackers thanks to current CT deployment), let's say 100 at a given point in time, so now you are left with 18446744073708551615 possible values. And if we do the math: 18446744073708551615 / 18446744073709551616 * 64 = 63.9996530549578599433858 Which is less than the required 64 bits. So any filtering operation (e.g. previously generated serial numbers) actually reduce effective entropy and overall security as illustrated in the fictional and forced scenario in [2]. And finally, we can realize that serial number generation algorithms, among others requirements, have to be foresee the number of certificates intended to be generated all along the CA lifetime. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/mgQaADsCCwAJ ___ 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
> 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a > CSPRNG with at least one bit in the highest byte set to 1 > > is, strictly speaking, not true. The best possible implementation for > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, > not 64. > Can you share how did you get the previous 63.994353?. I'm trying the following and I'm getting a different value: a = 2^64 = 18446744073709551616 b = 0x80 = 36028797018963968 (a - b) / a * 64 = 63.875 Maybe I'm misunderstanding something. ___ 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
> 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
> 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: DarkMatter Concerns
On Thursday, March 7, 2019 at 6:35:13 PM UTC-5, Matt Palmer wrote: > On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote: > > Let's Encrypt does not quite provide certificates to everyone around the > > world. They do prevent issuance to and revoke prior certificates for those > > on the United States various SDN (specially designated nationals) lists. > > For example, units of the Iraqi government or those acting at their behest > > may not receive Let's Encrypt certificates. > > > > Obviously that is not an issue for the UAE or its people. At least not > > today. But it always could be that it will be an issue someday. > > > > What the people of the UAE don't have today is the ability to acquire > > globally trusted certificates from a business in their own legal > > jurisdiction who would be able to provide them with certificates even in > > the face of exterior political force. > > In the face of exterior political force, the people of the UAE couldn't get > *globally trusted* certificates full-stop. Off the top of my head, all of > the widely-adopted web PKI trust stores are managed by US organisations. > One directive from the US government, and a trust anchor is *gone*. Thus, > having a trust anchor is not even a *sufficient* condition to produce the > outcome you're advocating for, let alone a necessary one. Maybe it is time for root programs to start thinking in moving their operations to more neutral countries, e.g. Switzerland. > > if the UAE government, or its people, wishes to ensure their supply of > "globally trusted" certificates, they need to start running their own PKI > trust store. > > - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Thursday, March 7, 2019 at 1:27:42 PM UTC-5, Kristian Fiskerstrand wrote: > On 3/7/19 6:59 PM, Jaime Hablutzel via dev-security-policy wrote: > > So the following holds true and (from my point of view) very critical > > indeed. Quoting Benjamin Gabriel: > > > >> ...that sovereign nations have the fundamental right to provide > >> digital services to their own citizens, utilizing their own > >> national root, without being held hostage by a provider situated in > >> another nation. You should note that DarkMatter's request is also > >> for the inclusion of UAE's national root > > I would question the assertion of any "fundamental right" of a sovereign > nation in this context; But sidestepping that there are still > alternative ways to achieve it than exposing all users globally to risk; > E.g nothing would stop a local linux distribution, or a localized > Microsoft product version, from including the root, This wouldn't help UAE's companies providing their services abroad. > or the user to > install it locally by choice, This is a burden for end users. > as its citizens are more likely to accept > the local laws as they are governed by them already. > > Trust is ultimately a subjective consideration, and no list of > requirement can ever be the full set of requirement, as any system based > on such a method can and will be gamed. > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Thursday, March 7, 2019 at 10:17:21 AM UTC-5, Ryan Sleevi wrote:
> On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > I would just like to remind you all the universally accepted concept of
> > "Presumption of innocence". Quoting from
> > https://en.wikipedia.org/wiki/Presumption_of_innocence:
> >
> > >The presumption of innocence is the legal principle that one is
> > considered innocent unless proven guilty. It was traditionally expressed by
> > the Latin maxim ei incumbit probatio qui dicit, non qui negat (“the burden
> > of proof is on the one who declares, not on one who denies”).
> >
> > Where it is useful to highlight the following phrases:
> >
> > - one is considered innocent unless *proven* guilty
> > - the *burden of proof is on the one who declares*, not on one who denies
> >
> > So, unless MDSP is the jury responsible for proving DM guilty, I think
> > they should be accepted until their mischief can be proved, although I'm
> > not sure who should/could be responsible for such a task.
> >
>
> Thanks for sharing this, Jaime, and thank you for engaging in this
> discussion.
>
> Unfortunately, there are a number of flaws with this thinking, which I want
> to highlight, although I hope it does not discourage further participation.
>
> As you seem to acknowledge, MDSP is not a jury and this is not a legal
> proceeding. On that basis, the application of a "Presumption of Innocence"
> is not necessary nor relevant - we're not discussing legal proceedings
> here, nor is the goal to assess "guilt" or "innocence". The fundamental
> question of a root program is whether or not an organization is trustworthy.
>
> In some ways, you may wish to think of CAs as custodians of a given root
> programs' trust, and since we're applying Latin concepts, the phrase "Quis
> custodiet ipsos custodes" is perhaps applicable here. The answer is that
> the root program supervises the CAs, through consultation with the public.
> If it helps to frame this in concepts that may be more familiar - even if
> they are far from a perfect match - you might think of this as how officers
> of organizations or politicians are held to higher standards, and things
> which might be acceptable in the general case are not acceptable for such
> parties.
>
> However, I think it's more fundamentally flawed to see the process as
> "default trust". The answer is rather the opposite; the default answer is
> "do not trust", and it is the CAs duty to provide sufficient evidence to
> demonstrate both their trustworthiness and utility to a root program, such
> that the vendor is willing to enter into a business relationship with them
> and entrust them with protecting the security of their users.
Fair enough, after all, Mozilla's root program is a private initiative, but
could you please just confirm to me if the "default deny" policy is clearly and
formally documented as part of the Mozilla Root Store Policy?.
>
> A good example of this principle ("default deny") at play is in the
> reliance upon audits. As practiced by WebTrust practitioners, the
> professional standards of auditors actually work from a view of assuming
> that none of the principles or criteria have been met by the organization.
> The organization being audited has a duty to produce and demonstrate
> sufficient evidence so as to convince a "reasonable" auditor that the CA is
> and has been meeting the various requirements. Using the AICPA as an
> example (and similar examples exist for ISAE and CPA Canada and other
> professional auditing bodies), you can see this at [1], and in particular,
> AT-C 105.10a or 105.25iii.
>
> As noted elsewhere, the programs goals are not necessarily to include any
> entity who meets some perfunctory checklist, but to ensure that the
> benefits outweigh the risks for the typical user. As such, there is an
> inherent burden to highlight the benefits, just as there is a
> responsibility to evaluate solutions to mitigate risks, as some have
> offered [3]. Going back to legal concepts, as inappropriate for this
> discussion as they are, one might say that the "burden of proof" exists
> with each CA participating or applying to participate in a given root
> program to demonstrate their value and to produce evidence counter to the
> claims provided.
>
> My previous message [4] highlighted some approaches that CAs might use to
> do that, while also highlighting that, fundamentally, audits alone do not
> and have never met that fundamental sufficiency.
>
> I hope th
Re: DarkMatter Concerns
On Thursday, March 7, 2019 at 12:30:03 PM UTC-5, James Burton wrote: > I'm talking about someone from a restricted country using a undocumented > domain name to obtain a Let's Encrypt certificate and there is nothing that > can be done about it. Until they get caught and their certificates revoked (with the corresponding service disruption) as indicated in https://community.letsencrypt.org/t/according-to-mcclatchydc-com-lets-encrypt-revoqued-and-banned-usareally-com/81517/10?u=hablutzel1: > When it is brought to our attention that we are serving an entity on the SDN > list, and if we can confirm the report, we will respond by revoking > outstanding certs and banning future issuance to the entity. > >... > >This happens to maybe one domain per month, to give you some idea of the >frequency. So in the best case scenario they could keep getting free LE certificates at the expense of the quality of the service they provide, e.g. because of the need to renew domains constantly. > We can't predict the future. > > Thank you, > > Burton > > On Thu, Mar 7, 2019 at 5:23 PM Matthew Hardeman wrote: > > > > > On Thu, Mar 7, 2019 at 11:11 AM James Burton wrote: > > > >> Let's be realistic, anyone can obtain a domain validated certificate from > >> Let's Encrypt and there is nothing really we can do to prevent this from > >> happening. Methods exist. > >> > > > > I am continuing to engage in this tangent only in as far as it illustrates > > the kinds of geopolitical issues that already taint this space and in as > > much as that, I believe has some relevance for the larger conversation. > > Now that I've said that, please, by all means, if I'm wrong about the > > referenced assertion that I've posted, reach out to the usareally.com > > people and help them get a Let's Encrypt certificate. Good luck with that. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Thursday, March 7, 2019 at 11:20:54 AM UTC-5, Matthew Hardeman wrote: > On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > There isn't any monopoly that prevents citizens and organizations in the > > United Arab Emirates to get certificates from CAs and they are not > > expensive. Let's Encrypt provides free domain validated certificates to > > everyone around the world. Next. > > > > This is not entirely accurate and the manner in which it is inaccurate may > be material to this discussion. > > Let's Encrypt does not quite provide certificates to everyone around the > world. They do prevent issuance to and revoke prior certificates for those > on the United States various SDN (specially designated nationals) lists. > For example, units of the Iraqi government or those acting at their behest > may not receive Let's Encrypt certificates. > > Obviously that is not an issue for the UAE or its people. At least not > today. But it always could be that it will be an issue someday. > > What the people of the UAE don't have today is the ability to acquire > globally trusted certificates from a business in their own legal > jurisdiction who would be able to provide them with certificates even in > the face of exterior political force. I think that the information you provided made it clear that there actually exists a *benefit for the consumers* allowing UAE's national root to be included in the program, because it provides safeguards to their citizens and companies (in the context of UAE's national cyber security strategy) in the event of an international conflict (e.g. a war for whatever reason), where adversary countries could impose sanctions for them, provoking disruption in their services because of their certificates (obtained from foreign CAs) getting revoked. Although it is worth noting that the advantages of managing their own national root for the sake of sovereignty defense would be clearly diminished if the Mozilla root program (or the company behind?) could be obliged by any government at that point to retire UAE's national root from the program too. So the following holds true and (from my point of view) very critical indeed. Quoting Benjamin Gabriel: > ...that sovereign nations have the fundamental right to provide digital > services to their own citizens, utilizing their own national root, without > being held hostage by a provider situated in another nation. You should note > that DarkMatter's request is also for the inclusion of UAE's national root. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
I would just like to remind you all the universally accepted concept of "Presumption of innocence". Quoting from https://en.wikipedia.org/wiki/Presumption_of_innocence: >The presumption of innocence is the legal principle that one is considered >innocent unless proven guilty. It was traditionally expressed by the Latin >maxim ei incumbit probatio qui dicit, non qui negat (“the burden of proof is >on the one who declares, not on one who denies”). Where it is useful to highlight the following phrases: - one is considered innocent unless *proven* guilty - the *burden of proof is on the one who declares*, not on one who denies So, unless MDSP is the jury responsible for proving DM guilty, I think they should be accepted until their mischief can be proved, although I'm not sure who should/could be responsible for such a task. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
I would just like to remind you all the universally accepted concept of "Presumption of innocence". Quoting from https://en.wikipedia.org/wiki/Presumption_of_innocence: >The presumption of innocence is the legal principle that one is considered >innocent unless proven guilty. It was traditionally expressed by the Latin >maxim ei incumbit probatio qui dicit, non qui negat (“the burden of proof is >on the one who declares, not on one who denies”). Where it is useful to highlight the following phrases: - one is considered innocent unless *proven* guilty - the *burden of proof is on the one who declares*, not on one who denies So, unless MDSP is the jury responsible for proving DM guilty, I think they should be accepted until their mischief can be proved, although I'm sure who should/could be responsible for such a task. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
