I think the desire to categorize these is more to make sense of where the
distrust line is. No one wants to end up on the same boat as Symantec, and
there aren't clear guidelines on how to prevent that from happening to a CA.
Pretty much every CA mis-issues at some point on an infinite
I disagree that a series of categories is good or helpful to the community.
I think the framing is generally adopted by CAs that want to see shades of
gray in non-compliance, in order to downplay risk or downplay their lack of
compliance.
As to the Forum, browsers have tried multiple times to
I agree.
I've actually thought about adding definitions of categories of misissuance
to the BRs before. Some of the requirements like revocation are really hard
to write and understand if you don't first categorize all the misissuance use
cases, many of which are very, very different. And just
Thanks Jakob, I think you summed things up well.
-tom
On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy
wrote:
> On 26/07/2018 23:04, Matthew Hardeman wrote:
>>
>> On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
Hello,
we successfully completed the new audits. As requested, we modified the audit
period to ensure that there aren't gaps since the creation date of the new Root.
The Webtrust seals are available here:
Webtrust for CA:
https://www.cpacanada.ca/webtrustseal?sealid=10026
Webtrust SSL BR:
On 26/07/2018 23:04, Matthew Hardeman wrote:
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The party actually running the authoritative DNS servers is in control
of the domain.
I'm not sure I agree. They can control the
6 matches
Mail list logo
