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 <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] <mailto:[email protected]>] > Sent: Wednesday, January 10, 2018 4:49 PM > To: Daymion T. Reynolds <[email protected] <mailto:[email protected]>> > Cc: CA/Browser Forum Public Discussion List <[email protected] > <mailto:[email protected]>>; Kirk Hall <[email protected] > <mailto:[email protected]>>; Tim Hollebeek > <[email protected] <mailto:[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] > <mailto:[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] <mailto:[email protected]>] > Sent: Wednesday, January 10, 2018 1:50 PM > To: Daymion T. Reynolds <[email protected] <mailto:[email protected]>> > Cc: CA/Browser Forum Public Discussion List <[email protected] > <mailto:[email protected]>>; Kirk Hall <[email protected] > <mailto:[email protected]>>; Tim Hollebeek > <[email protected] <mailto:[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] > <mailto:[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] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
