G’day Folks,
It was a pleasure meeting many of the Mozilla community face to face at the CAB
Forum meeting at Apple HQ last week. There are many others of you however,
whose interface to the community is right here on this list, and so I wanted to
share my perspective and feedback here on the
On 18/03/2019 02:05, Nick Lamb wrote:
On Fri, 15 Mar 2019 19:41:58 -0400
Jonathan Rudenberg via dev-security-policy
wrote:
I've noted this on a similar bug and asked for details:
https://bugzilla.mozilla.org/show_bug.cgi?id=1524733
I can't say that this pattern gives me any confidence that t
On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote:
> On 18/03/2019 17:05, Kurt Roeckx wrote:
>> On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via
>> dev-security-policy wrote:
>>>
>>> When a value in column E is 100%, this is pretty solid evidence of
>>> noncompliance with
On Sat, Mar 16, 2019 at 12:49 PM Wayne Thayer wrote:
> Ryan - Thank you for the feedback.
>
> On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote:
>
>> While I realize the thinking is with regards to the recent serial number
>> issue, a few questions emerge:
>>
>> 1) Based on the software vendor r
On 18/03/2019 17:05, Kurt Roeckx wrote:
> On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via
> dev-security-policy wrote:
>>
>> When a value in column E is 100%, this is pretty solid evidence of
>> noncompliance with BR 7.1.
>> When the values in column E and G are both approximately 50%,
On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy
wrote:
>
> When a value in column E is 100%, this is pretty solid evidence of
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this
> suggests (but does not prove) that th
On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote:
> On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:
>
>> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>>
If any other C
On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:
> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>
>>> If any other CA wants to check theirs before someone else does, then now is
>>> surely
On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>> If any other CA wants to check theirs before someone else does, then now is
>> surely the time to speak up.
>
> Someone else is in the process of checking...
On 15/03/2019 13:26, Peter Gutmann via dev-security-policy wrote:
I actually thought it was from "Chosen-prefix collisions for MD5 and
applications" or its companion papers ("Short chosen-prefix collisions for MD5
and the creation of a rogue CA certificate", "Chosen-Prefix Collisions for MD5
and
On 15/03/2019 07:13, Jaime Hablutzel via dev-security-policy 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 descri
On 18/03/2019 16:42, Corey Bonnell wrote:
Perhaps not very elegant, but you can encode an “allow all issuers” CAA
RRSet by specifying a single iodef CAA record without any
issue/issuewild records in the RRSet, which will probably be treated as
permission to issue for CAs. I say “probably” beca
Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet
by specifying a single iodef CAA record without any issue/issuewild records in
the RRSet, which will probably be treated as permission to issue for CAs. I say
“probably” because the RFC wasn’t clear on the proper handl
13 matches
Mail list logo