[cabfpub] CA-Browser Forum conference call on January 7th - misissued certificates
Rick_Andrews at symantec.com
Mon Jan 11 16:50:53 UTC 2016
You said " There are also no obligations on the CABForum - incidents at cabforum.org might bounce, or forward to some other organization." There are at least some obligations on the CABForum, to handle requests to subscribe to this list, filter spam, etc. To be effective, I imagine the list will allow anyone to post to it and anyone to subscribe to it. Maybe Wayne can comment on how much work that might be for him.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Sigbjørn Vik
Sent: Monday, January 11, 2016 1:51 AM
To: public at cabforum.org
Subject: Re: [cabfpub] CA-Browser Forum conference call on January 7th - misissued certificates
On 08-Jan-16 22:54, Peter Bowen wrote:
>> This mostly seems like a way for CAs to avoid transparency; based on
>> the current practices with respect to disclosing intermediates, it's
>> clear that a number of CAs are having trouble following root program
>> requirements with respect to disclosure and documentation.
>> I find it interesting that the CA/Browser Forum would have an entire
>> workgroup dedicated to information sharing, but then be opposed to
>> sharing information.
So how about this proposal:
CAs need to list their location for incident reports in the CPS, as previously outlined. All reports are published there. Additionally, CAs must send a mail to incidents at cabforum.org, with a link, whenever there is a new report.
This means CAs are still in charge of their own reports and infrastructure, and it is not the CABForum which publishes reports. The ability is equal for all CAs. There are also no obligations on the CABForum - incidents at cabforum.org might bounce, or forward to some other organization. Yet there is a central location where all incidents are reported. It is important that the CABForum is made aware of misissuances and issues surrounding that, so it can respond with updating the BRs when relevant.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5749 bytes
Desc: not available
More information about the Public