[cabf_validation] Underscores, DNSNames, and SRVNames

[Richard Smith]

Ryan I mostly agree with you except that the underscore issue is fairly esoteric and Jeremy has already pointed out that at least one of those RFCs is neither clear nor unambiguous. If there is a point that we consider critical to a CAs operation let’s clarify it and throw it in the BR as well, especially since I am also reasonably confident that most auditors have not spent significant time spelunking the RFCs so if it’s not codified in the BR and the CA hasn’t clearly stated it in their CP the auditor will likely miss it if we don’t make it clear.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Ryan Sleevi <sleevi at google.com>
Sent: Monday, October 15, 2018 8:34:24 PM
To: Richard Smith
Cc: CA/Browser Forum Validation WG List; jeremy rowley
Subject: Re: [cabf_validation] Underscores, DNSNames, and SRVNames



On Mon, Oct 15, 2018 at 1:39 PM Richard Smith <rich at comodoca.com<mailto:rich at comodoca.com>> wrote:
I take exception to characterizing anything that requires spelunking through multiple RFCs which span years (decades?) to figure out whether one particular character is allowed or not as clear and unambiguous.

The BRs directly reference one RFC, which directly references two more RFCs. There's no ecclesiastical knowledge of the high priesthood of PKI needed to make sense of what the requirements are, nor dowsing rods to figure out where to find the restrictions are.

Our ETSI friends seem to survive the fact that EN 319 411-1 is going to reference both EN 319 412-* and EN 319 401, and that each precisely defines their terms and expectations. While Comodo has adopted a single CPS, I note many members of the Forum have adopted one-or-more CP and one-or-more CPS, and the world does not end.

I'm pushing back here precisely because all CAs are expected to understand the RFCs relevant to the operation of a CA. If there's a view that it's too hard to find what's needed, there's a process that CAs can try and bring clarity - proposing a document that incorporates these changes and clarity to the IETF, trying to find consensus, and publishing as an RFC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181016/9a29d1a5/attachment.html>