<div dir="ltr"><div>Hi Rob,</div><div><br></div><div>Answering your questions, inline, below. Please let me know if I've missed anything!</div><div><br></div>> 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”).<br><br><div>This is the correct read.<br><br>> 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”?<br><br>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.<br><br>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.<br><br>> 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?<br><br>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. <br><br>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? <br><br>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. <br><br>> 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.<br>> This lends support to deprecating email as a method, if said email was sent via “Trustworthy Email” would that be acceptable?<br>> 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?<br>> 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<br>> 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.<br><br>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.<br><br>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.<br><br>> 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?<br> <br>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. <br><br>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").<br><br></div><div>If I’ve missed anything, please let me know!<br><br>- Ryan<br><br>[1] <a href="https://cabforum.org/2016/09/15/2016-09-15-minutes/#:~:text=(a)%20Inadvertent%20domain%20validation%20by,validation%20by%20email%20scanning%20applications">https://cabforum.org/2016/09/15/2016-09-15-minutes/#:~:text=(a)%20Inadvertent%20domain%20validation%20by,validation%20by%20email%20scanning%20applications</a>.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 9, 2024 at 8:00 AM Rob B <<a href="mailto:PlanD@sgnr.org">PlanD@sgnr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-8212286523789079814">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_-8212286523789079814WordSection1">
<p class="MsoNormal">>Hi Rob!<u></u><u></u></p>
<p class="MsoNormal"><br>
>Welcome to the community, we’re glad to have you!<br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">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.<br>
<br>
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.
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
Obviously, strictly adhering to the CABForum’s Baseline requirements is a critical requirement here.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
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.<u></u><u></u></p>
<p class="MsoNormal"><br>
<br>
>Can you offer more detail on: <br>
>- How specifically will the proposed changes weaken security?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">Delivering Objective 1 will mitigate several significant threats to relying parties and it’s clear the consensus is that it should be enacted ASAP.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
<br>
We do have some questions around the wording and the goals of Objective 2<br>
<br>
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”).<br>
<br>
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”? <br>
<br>
I suspect we’re misreading the requirements, but clarification is very much appreciated if we are.<br>
<br>
<br>
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?<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">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.
<br>
<br>
This lends support to deprecating email as a method, if said email was sent via “Trustworthy Email” would that be acceptable?<br>
<br>
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?<br>
<br>
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<br>
<br>
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.
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
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?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>- What precisely is the exception that should be considered?<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">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. <br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">This leaves the door open for compliance using these methods, but responsibility for using them rests with the CA and must be justified.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>- What are you referring to by the phrase “extended validation?"
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">See above, that was a poor choice of words on my part. Apologies.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>- How do the proposed changes impact “extended validation?<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><br>
Likewise.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><br>
Many thanks again & kind regards,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Rob<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></blockquote></div>