Given that it would be a new method, and not within the realm of presently permitted, it seems better to separate it out from the removal of existing methods - would you agree?
On Wed, Jan 10, 2018 at 8:02 PM, Peter Bowen <[email protected]> wrote: > Can we also include a validation method based on the one I suggested a > couple of months ago in https://cabforum.org/ > pipermail/public/2017-October/012423.html ? That method would provide a > strong link between Registry/Registrar and CA even when they are not > affiliates. > > Thanks, > Peter > > On Jan 10, 2018, at 4:32 PM, Daymion T. Reynolds via Public < > [email protected]> wrote: > > I am in agreement with this approach. Thanks Ryan for wrapping this up. > Daymion > > *From:* Ryan Sleevi [mailto:[email protected] <[email protected]>] > *Sent:* Wednesday, January 10, 2018 4:49 PM > *To:* Daymion T. Reynolds <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]>; Kirk > Hall <[email protected]>; Tim Hollebeek < > [email protected]> > *Subject:* Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5 > > So to make sure I've captured the discussion points of 3.2.2.4.1 for the > "things that would be disruptive" > > For situations like GoDaddy (in which the CA is the Registrar as well) - > or for situations like, say, Google Trust Services/Google, in which the CA > is an Affiliate of the Registrar (I think; I'm sure folks like Amazon with > its Amazon Trust Services is in a similar space, and no doubt others) - the > 'goal' is that if the CA believes the Applicant is the same entity as the > Domain Owner, then it can use that as an effective authorization by virtue > of the fact that it's the same account that would approve that operation. > > For situations like the ccTLDs, particularly those that lack WHOIS, or for > situations like .gov, it's seen as acceptable that contacting the registry > to determine who the Domain Name Registrant is, and then using > 3.2.2.4.2/3.2.2.4.3 methods of validation/contact is seen as viable. > > Finally, we have the issue that most folks (all?) seem to agree that > 3.2.2.4.1 Option 1/Option 2 are not reliably secure, and neither is > 3.2.2.5. Unfortunately, because of the 'grandfathering' validation clause, > this makes it difficult to unambiguously ensure (re)validation of domains > if they use an insecure method. > > Daymion, do you think a ballot that: > - Deprecated 3.2.2.4.1 as previously proposed (e.g. "adding not after > March") > - Deprecated 3.2.2.4.5 as previously proposed (e.g. "adding not after > March") > - Make the change to Contact as previously discussed, namely: "Domain > Contact: The Domain Name Registrant, technical contact, or administrative > contract (or the equivalent under a ccTLD) as listed in the WHOIS record of > the Base Domain Name or in a DNS SOA record, or as obtained through direct > contact with the Domain Name Registrar." > - Introduce 3.2.2.4.11 (a new method), which reads (to be smithed a little > if necessary): > > "3.2.2.4.11 Validating Applicant as a Domain Contact > Confirming the Applicant's control over the FQDN by validating the > Applicant is the Domain Contact. This method may only be used if the CA is > also the Domain Name Registrar, or an Affiliate of the Registrar, of the > Base Domain Name. > > Note: Once the FQDN has been validated using this method, the CA MAY also > issue Certificates for other FQDNs that end with all the labels of the > validated FQDN. This method is suitable for validating Wildcard Domain > Names." > > > Yes, this doesn't describe how the CA/Registrar (or > CA-Affiliate/Registrar) precisely performs this validation, but I'm > hesitant to add wording such as 'accounts' or 'usernames' or equivalent > access control levels at this time, and can live with being permissive here > and then iterating to be tighter around this language. My goal here would > be to make it clear that Option #1 and Option #2 of 3.2.2.4.1 are > unacceptable, but unfortunately the poor wording of 3.2.2.4 and 4.2.1 means > we have to effectively remove/forbid 3.2.2.4.1 entirely and then re-add the > bits that make sense. > > On Wed, Jan 10, 2018 at 6:16 PM, Daymion T. Reynolds < > [email protected]> wrote: > > Ryan, > > Q: Can you explain why you do not believe it is more secure? > A: I am not stating its more secure, but .1 Option #3 is on par with other > deemed secure options. It is secure because only the domain owner is the > authorized user to a registrars account, and only they can order a cert for > a specific domain. If more transparency is a concern, let’s discuss what > would be acceptable. > > Q: I don't believe this is universally the case. Consider the situation of > registrars and registries that allow signing in without a 2FA, but require > changes to use a 2FA. I realize a response might be "Well, the registrar > could just require 2FA for issuing a cert" - and while that would be in > theory possible, there's absolutely zero assurance for relying parties and > browsers as to the registrars (and CAs) practices. I hope you can see why > this remains a fundamentally problematic proposal. > A: I agree, everyone should be using 2FA. Unpacking this a bit further, as > your statement is close to the crux of my argument. If the registrar > account is compromised, everything about the domain is in question. If > registrar account compromise is a concern for .1 option #3 then it also a > question for .4 Domain Contact, .7 DNS Change and .8 IP Address validation. > All of these require the registrar account to be secure. I believe .4, .7, > and .8 are secure practices. > > Q: I think it's important to be precise here when talking about .1. Is it > correct to say you are only concerned with retaining some notion of .1 > Option 3? When we say "don't eliminate .1", I think that carries with it > the significant (and insecure) suggestion of retaining .1 Option 1 and .1 > Option 2. > A: Agreed, and sorry for not being precise. You are correct I am only > concerned with Option #3, as I believe it is a secure practice on par with > .7 and .8. I agree with your position on option #1 & #2. > > Thanks for your time discussing this, > Daymion > > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Wednesday, January 10, 2018 1:50 PM > *To:* Daymion T. Reynolds <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]>; Kirk > Hall <[email protected]>; Tim Hollebeek < > [email protected]> > *Subject:* Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5 > > > > On Wed, Jan 10, 2018 at 2:37 PM, Daymion T. Reynolds < > [email protected]> wrote: > > Ryan, > Thank you for replying as this is a good discussion to have. > “Direct contact” is great method when you don’t have a clean, reliable data > source to validate ownership. For Registrar / CA combos, whereby the same > account ordered the domain and the cert, knowledge of ownership is robust. > Requiring a second contact doesn’t seem more secure, but rather seems more > cumbersome for an already complex process. > > > Can you explain why you do not believe it is more secure? > > > If you are concerned about the possibility of a customer account being > compromised, it doesn’t change the risk. If there was a compromise they > would have control over DNS and could then domain validate a cert order > from anyone. > > > I don't believe this is universally the case. Consider the situation of > registrars and registries that allow signing in without a 2FA, but require > changes to use a 2FA. I realize a response might be "Well, the registrar > could just require 2FA for issuing a cert" - and while that would be in > theory possible, there's absolutely zero assurance for relying parties and > browsers as to the registrars (and CAs) practices. I hope you can see why > this remains a fundamentally problematic proposal. > > > Rather than eliminate .1, I believe a better course of > action would be to add transparency and lock down when you can and cannot > use the registrar validation method. > > > I think it's important to be precise here when talking about .1. Is it > correct to say you are only concerned with retaining some notion of .1 > Option 3? When we say "don't eliminate .1", I think that carries with it > the significant (and insecure) suggestion of retaining .1 Option 1 and .1 > Option 2. > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
