Doesn’t Ryan and Dimitris’ fix handle that? Direct communication with the registrar is easy if you are the registrar.
-Tim From: Peter Bowen [mailto:p...@amzn.com] Sent: Monday, January 8, 2018 9:49 PM To: Wayne Thayer <wtha...@mozilla.com>; CA/Browser Forum Public Discussion List <public@cabforum.org> Cc: Tim Hollebeek <tim.holleb...@digicert.com> Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5 On Jan 8, 2018, at 9:20 AM, Wayne Thayer via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: On Mon, Jan 8, 2018 at 9:46 AM, Tim Hollebeek via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: I’m not sure there are other valid cases (in fact I suspect there are not), but Wayne mentioned on the validation WG call that he’s concerned that this change could be very disruptive if not handled carefully, and I’m sympathetic to that concern. Especially since on the same call he also pointed out the same flaw that Dimitris did … My concern is based on a small sample size, but in reviewing CPS' I've noted that government CAs often rely on 3.2.2.4.1. Other than Dimitris, they are not participating in this discussion and may not be aware of it. That isn't a good excuse to delay needed fixes, but I do think that the outright elimination of method #1 on Mar 1st will catch a number of these CAs by surprise and we'll see compliance issues. The approach that Ryan and Dimitris are discussing helps to address my concern. I know I’m really late to this conversation, but I think we need to split 3.2.2.4.1. It currently has one very strong validation method combined with two that are under discussion. While I know it does not apply to many CAs, I think option 3 in 3.2.2.4.1 is excellent validation when available. If the CA is also the registry or registrar, then they can have a very high assurance that a certificate requester has control of the domain. I would hate to see this method go away, as I personally see this as the potentially the strongest proof of domain control. Thanks, Peter
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
