[Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”

[Ryan Dickson]

Hi Rob,

Answering your questions, inline, below. Please let me know if I've missed
anything!

> Some were addressed by prior clarifications, but the wording appears to
sunset 3.2.2.4.2 and 3.2.2.4.15 entirely next summer (vs prohibiting the
contact information coming from WHOIS at a higher level in the basic
requirements as a “Pending Prohibition”).

This is the correct read.

> If  3.2.2.4.2 and 3.2.2.4.15 are entirely deprecated – Doesn’t that all
but eliminate “out of band” verification using data from “Reliable Data
Sources” sources via “Reliable Methods of Communication” or even using “DNS
SOA” as currently defined in “Domain Contact”?

My understanding is that “Reliable Data Sources" are applicable for
verifying Subject Identity Information (e.g., the name or address of an
organization, and DBA/Tradenames). Processes intended to validate Subject
Identity Information are considered separate from validating domain
authorization or control, which is the scope of the proposed changes.

The phrase “Domain Contact," and by extension, DNS SOA, is still referenced
in 3.2.2.4.12 - although it seems unlikely to be relied upon.

> Also, regardless of “WHOIS”, if a registrar doesn’t have, or publish
accurate data, or is potentially not permitted to release it to a CA (eg
Certain jurisdictions with strong Privacy Regulations or other legal
obligations) or for that matter and equally valid reasons certain domain
owners are publicly tight lipped and don’t publish contact information via
CAA tags what would be the process?

I’m having a hard time understanding the question or position being made.
Can you please phrase this differently? The limited reliability of
registration data is one of the motivating factors for sunsetting these
methods.

The BRs support domain control validation methods that do not rely on
contact information, either persistently or temporarily posted, for
example, 3.2.2.4.7 (“DNS Change"), 3.2.2.4.18 (“Agreed‑Upon Change to
Website v2", and 3.2.2.4.19 (“Agreed‑Upon Change to Website ‑ ACME"). If
privacy concerns are a significant factor for these subscribers, can you
share why these other methods should not be considered useful alternatives?

Beyond potential privacy concerns, other methods are better equipped for
automation, dealing with certificate lifecycle management needs at scale,
and offer improved security properties like multi-perspective issuance
corroboration that don't always translate well to “contact-based” methods
like phone and email.

> This next scenario is almost certainly out of scope, but it’s not unheard
of for mid-large publicly listed companies to have poor oversight of shared
/ “special” mailboxes and mediocre OPSEC.
> This lends support to deprecating email as a method, if said email was
sent via “Trustworthy Email” would that be acceptable?
> EG Email compliant with NIST 800-177 or using something like the EU’s PEC
mitigates a substantial amount of risk, or is the risk being mitigated
something else?
> It appears that as it stands, prohibiting “email” entirely would prohibit
these too without further clarification – an attempt to say they’re not
“Email” in the conventional sense appears run afoul of the prohibition in
3.2.2.4.11
> However In cases where there is doubt that a request is made with
appropriate authority, using a “well known” fax or postal address (ideally
via certified/registered service) feels a viable alternate path to
verifying the Applicant’s control is legitimate.

The other email-based validation methods (and phone methods) have
challenges and limitations (like all methods do), some of which have been
discussed before [1]. The scope of this ballot was specific to only those
methods relying on registration data lookups. However, we do think it’s
worthwhile to take a closer look at the other “contact-based” methods in
the future.

For the sake of staying focused on only the contents in-scope of this
ballot, I hope we can defer these discussions to the future.

> Finally, does the proposed prohibition on using information obtained from
HTTPS websites mean the use of ANY site that is accessed via HTTPS or are
we again over-reading this?

The scope of obtaining information from HTTPS websites is limited to
lookuping up registration data in the specific domain control validation
methods where the prohibition is described.

This proposal does not cast a sweeping prohibition against obtaining
information from HTTPS websites. For example, this doesn’t prevent a CA
from relying on HTTPS when performing Method 3.2.2.4.18 (“Agreed-Upon
Change to Website V2").

If I’ve missed anything, please let me know!

- Ryan

[1]
https://cabforum.org/2016/09/15/2016-09-15-minutes/#:~:text=(a)%20Inadvertent%20domain%20validation%20by,validation%20by%20email%20scanning%20applications
.

On Wed, Oct 9, 2024 at 8:00 AM Rob B <PlanD at sgnr.org> wrote:

> >Hi Rob!
>
>
> >Welcome to the community, we’re glad to have you!
>
>
> Thank you for the kind words. The level of experience and expertise in
> this WG is daunting and for the most part I’ll stick to reading along with
> the odd question here or there.
>
> Without getting too specific, we’re working through the steps of building
> several “Trust Services” in a lab environment (Baremetal) that don’t
> reinvent the wheel, honor and most importantly conform to prior art and
> best current practices.
>
>
> Obviously, strictly adhering to the CABForum’s Baseline requirements is a
> critical requirement here.
>
>
> The use cases and scenarios we’re looking at aren’t “mainstream”, so may
> be entirely out of scope for this discussion, but then again maybe not.
>
>
>
> >Can you offer more detail on:
> >- How specifically will the proposed changes weaken security?
>
>
>
>
>
> Delivering Objective 1 will mitigate several significant threats to
> relying parties and it’s clear the consensus is that it should be enacted
> ASAP.
>
>
>
> We do have some questions around the wording and the goals of Objective 2
>
> Some were addressed by prior clarifications, but the wording appears to
> sunset 3.2.2.4.2 and 3.2.2.4.15 entirely next summer (vs prohibiting the
> contact information coming from WHOIS at a higher level in the basic
> requirements as a “Pending Prohibition”).
>
> If  3.2.2.4.2 and 3.2.2.4.15 are entirely deprecated – Doesn’t that all
> but eliminate “out of band” verification using data from “Reliable Data
> Sources” sources via “Reliable Methods of Communication” or even using “DNS
> SOA” as currently defined in “Domain Contact”?
>
> I suspect we’re misreading the requirements, but clarification is very
> much appreciated if we are.
>
>
> Also, regardless of “WHOIS”, if a registrar doesn’t have, or publish
> accurate data, or is potentially not permitted to release it to a CA (eg
> Certain jurisdictions with strong Privacy Regulations or other legal
> obligations) or for that matter and equally valid reasons certain domain
> owners are publicly tight lipped and don’t publish contact information via
> CAA tags what would be the process?
>
>
>
> This next scenario is almost certainly out of scope, but it’s not unheard
> of for mid-large publicly listed companies to have poor oversight of shared
> / “special” mailboxes and mediocre OPSEC.
>
> This lends support to deprecating email as a method, if said email was
> sent via “Trustworthy Email” would that be acceptable?
>
> EG Email compliant with NIST 800-177 or using something like the EU’s PEC
> mitigates a substantial amount of risk, or is the risk being mitigated
> something else?
>
> It appears that as it stands, prohibiting “email” entirely would prohibit
> these too without further clarification – an attempt to say they’re not
> “Email” in the conventional sense appears run afoul of the prohibition in
> 3.2.2.4.11
>
> However In cases where there is doubt that a request is made with
> appropriate authority, using a “well known” fax or postal address (ideally
> via certified/registered service) feels a viable alternate path to
> verifying the Applicant’s control is legitimate.
>
>
> Finally, does the proposed prohibition on using information obtained from
> HTTPS websites mean the use of ANY site that is accessed via HTTPS or are
> we again over-reading this?
>
>
>
>
>
> >- What precisely is the exception that should be considered?
>
> Instead of sunsetting 3.2.2.4.2 and 3.2.2.4.15 entirely, which appears to
> prevent compliance if these methods are used in Sensitive / High Risk
> Certificate requests we suggest changing the language to recommend these
> methods SHOULD NOT be used.
>
> This leaves the door open for compliance using these methods, but
> responsibility for using them rests with the CA and must be justified.
>
>
>
> >- What are you referring to by the phrase “extended validation?"
>
> See above, that was a poor choice of words on my part. Apologies.
>
>
>
> >- How do the proposed changes impact “extended validation?
>
>
> Likewise.
>
>
>
>
> Many thanks again & kind regards,
>
>
>
>
>
>
>
> Rob
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241009/6436a90e/attachment-0001.html>