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 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
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
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
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 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
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
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
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”
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
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
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
12 matches
Mail list logo
