On Fri, Mar 15, 2019 at 12:36 AM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
> > 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
Jaime Hablutzel via dev-security-policy
writes:
>>>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
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
On Thu, Mar 14, 2019 at 4:33 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:
>
> > I'd already asked previously whether any CA wanted to indicate publicly
> that
> > they were compliant
> >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
On Thu, Mar 14, 2019 at 11:16 PM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
> 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
Jaime Hablutzel via dev-security-policy
writes:
>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 to 14 decimal places.
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
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
> >
(Forgot to post it to m.d.s.p)
Your right that we all failed to conduct the proper due diligence source
code checks on EJBCA and therefore missed this important issue. We all need
to learn from this past mistake and implement better checks which prevents
issues like this that might arise in the
On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via
dev-security-policy 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
> 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
On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Let's Encrypt CA software 'Boulder' is open source for everyone to browse
> and check for issues. All other CAs should follow the Let's Encrypt lead
> and open source their own
Let's Encrypt CA software 'Boulder' is open source for everyone to browse
and check for issues. All other CAs should follow the Let's Encrypt lead
and open source their own CA software for everyone to browse and check for
issues. We might have found the serial number issue sooner.
Thank you,
On Thursday, March 14, 2019 at 3:13:51 PM UTC-7, 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
> >
> 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.
>
On Wednesday, March 13, 2019 at 9:09:35 PM UTC-4, Peter Gutmann wrote:
> 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
On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:
> 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).
Peter,
Mozilla Root Store Policy section 2.3 [1] requires CAs
On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
> 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
>> -
Hello MDSP,
Taiwan-CA wants to report an incident about mississued certificates with
invalid SAN.
Times below are in UTC+8
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
No one wants to paint a target on their back. If I announce we're 100%
compliant with everything, that's asking to be shot in the face. You're
welcome to look at ours. I think we fully comply with 7.1 (I've double
checked everything) and would love to find out if we're not. I like the
feedback and
23 matches
Mail list logo
