Please provide citations that you believe support such an interpretation.
If you cannot provide such citations, then it seems as if interpretations
are being made up, which is no more productive than me suggesting that a CA
may have interpreted the relevant sections to mean that every third
Hello,
My comments in blue.
Od: Ryan Sleevi
Wysłane: czwartek, 11 października 2018 04:53
Do: Grabowski Piotr
DW: Wayne Thayer; mozilla-dev-security-policy
Temat: Re: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)
On Wed, Oct 10, 2018 at 4:33 PM
On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie wrote:
>
>
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I believe that may be misunderstanding the concern.
>>
>> Once these certificates expire, there's not a good way to
On Fri, 12 Oct 2018 at 16:41, Ryan Sleevi wrote:
>
>
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie wrote:
>
>>
>>
>> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> I believe that may be misunderstanding the concern.
>>>
Wojciech,
Thank you for the incident report. I believe it does a good job of
explaining how you will prevent this specific problem from happening again,
but it does not address the broader problem of misissuance and Certum's
failure to detect it. How can the Mozilla community be assured that
Comodo responded to my question about disclosure of incidents to their
auditor with the following statement [1]:
It turns out that we did not disclose these to EY. That was down to
Comodo CA not offering the evidence of these events during the audit
evidence gathering phase. It was not our
I understand the OP's concern and will respond to the bug shortly.
Regards
Robin Alden
Comodo CA Ltd.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Another interpretation, which would result in this situation being
not a Mozilla/BR violation is this (I am /not/ saying this is a a
better interpretation, just a possible one).
Mozilla and BR policy requires only that:
1. The DER encoding is technically correct as if no ASN.1 module was
On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I believe that may be misunderstanding the concern.
>
> Once these certificates expire, there's not a good way to check whether or
> not they were revoked, because such revocation
On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> I believe
On 12/10/18 13:53, Jakob Bohm via dev-security-policy wrote:
On 12/10/2018 14:33, Ben Laurie wrote:
This is one of the reasons we also need revocation transparency.
Or just a crt.sh enhancement to remember the previously collected
revocations.
crt.sh already remembers previously collected
On 12/10/2018 14:33, Ben Laurie wrote:
On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I believe that may be misunderstanding the concern.
Once these certificates expire, there's not a good way to check whether or
not they were
12 matches
Mail list logo
