Thanks for the feedback, Henry!  We will work on some updates to see how we can 
add some of these thoughts in.

 

Cheers,

Andrew

 

 

From: Henry Birge-Lee <[email protected]>
Date: Wednesday, February 4, 2026 at 5:51 PM
To: "[email protected]" <[email protected]>
Subject: [EXTERNAL] [DNSOP] Re: Requesting feedback on 
draft-ietf-dnsop-integration

 

Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 

Hi all, 

 

I reviewed this document and think it's a good draft.

 

One clause I noticed that I don't take issue with but wanted to comment on is:

3.2.  Domain Control Validation

"Some examples of domain control
   validation include storing data in DNS
   [I-D.ietf-dnsop-domain-verification-techniques] or storing evidence
   on a server referenced by a domain name, e.g., at a well-known
   endpoint as described in [RFC8615]."
In the PKI community, there is a subtle difference between webserver control 
and DNS control. 
For example, DCV methods that use evidence from web servers (e.g., http-01) are 
not permitted for the use of subdomain certificates.
Some would argue that evidence in the .well-known dir of a webserver proves 
control of the HTTP(S) server at that domain but not control of the domain 
itself. Since the draft is about DNS names
in applications, I think there are some applications where that type of control 
(webserver control) is not appropriate (or at least would not be sufficient 
evidence for the CAB/F).
I think the cleanest stance would be to recommend control be established in DNS 
and not other channels.
This text is also very vague and there are a bunch of ways of showing domain 
control that we no longer think are good ideas, although vagueness does allow 
the draft to avoid being prescriptive with this aspect.
 
 
Best,
Henry
 
https://henrybirgelee.com/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to