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 traditional
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 traditiona
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 Emirat
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 revoke
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 o
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:
> >
> >>
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 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 rep
> 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
> 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.
>
C
> 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 c
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
> > GetRan
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
> 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 a
> >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
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 t
> > 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 neg
17 matches
Mail list logo
