[cabf_validation] Underscores, DNSNames, and SRVNames

Mon Oct 15 10:39:25 MST 2018

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.

However, I do think that after the failure of ballot 202 it was pretty clear that the BRs did not allow the practice, at least it should have been to any CA who was a member of this Forum at that time, and that’s why after that ballot failed Comodo stopped issuing certs with underscores.  As such I’m in agreement with Ryan that a sunset period is unwarranted.  If one was needed it’s been provided since the failure of Ballot 202.  I am in favor of a ballot which clearly states that underscores are not allowed, but I think it should take immediate effect.  I strongly disagree with Wayne that the existence of ~4k certs issued w/underscores represents a use case that we need to account for.  To put it in perspective, Comodo CA issued ~8k certs/hour yesterday.

Regards,

Rich

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Thursday, October 11, 2018 10:00 AM
To: jeremy rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Underscores, DNSNames, and SRVNames

If CAs are unable to correctly implement the RFCs, which have been clear and unambiguous with respect to their expectations for 2 decades - that is, there is a documented, explicit grammar as to acceptable characters, supported throughout multiple dependent RFCs - I fail to see how any change to the Baseline Requirements would improve that scenario or improve the security of the ecosystem.

The issue, it seems, is not a question about whether or not it's been permitted by the RFCs - there has yet to be a response that can provide any text supporting an interpretation of the clear, technically specified language that has already existed - but rather a question of whether auditors are expected to examine and report on RFC5280 compliance, and whether browser programs will accept material non-conformities such as this issue and continue to trust the CA. Alternatively, if the view is that it would substantially improve security to explicitly deviate from the consensus-driven standards such as RFC5280, then it is necessary for such parties to demonstrate why this is so. The closest comparison we have is the misuse of the dNSName to contain IP addresses - which at least observed the explicit syntax of RFC5280 even though it violated the semantics within the text - and no such sunset was necessary because it was never permitted nor was it, in fact, necessary.

I find it impossible to believe that there's going to be some ecosystem wide difficulty if "*.s1._domainkey.ayakkabionline.com <http://domainkey.ayakkabionline.com> " [1] can't be issued (_domainkey is for TXT records; this is clearly a misconfigured server) or if American Express can't get one for "a_18-04-27-385077-rray-cert.aexp.com <http://a_18-04-27-385077-rray-cert.aexp.com> " [2]. Simply counting misissued certs doesn't actually provide any insight into whether there's an actual need.

Perhaps the best approach is to start filing problem reports with CAs for unrevoked misissued certificates, such as [3], so that the CA must respond to the substance. Any CA that fails to revoke should be flagged, particularly by auditors. If the belief is that auditors can't/shouldn't be expected to catch this - perhaps because the auditor is opining in their view, it's OK to ignore RFC 5280, or because they don't understand why it's a clear, cut, and dry violation of RFC 5280 - and thus not qualifying their opinion, that should be a concern with that particular auditor. If the view is that auditors shouldn't be expected to detect this because they only have to do sampling, then we browsers should be re-evaluating whether more prescriptiveness as to the suitability for sampling is necessary - and no doubt with cost being incurred by CAs to support that.

As I said, it's no different than any other RFC 5280 or BR violation - such as invalid characters in the domain (e.g. double dots), explicitly DER encoded default values in sequences, or a failure to validate domain names. If it has to be spelled out for a given CA, that's not a good sign - for that CA.

[1] https://crt.sh/?id=424701236 <https://crt.sh/?id=424701236&opt=cablint> &opt=cablint

[2] https://crt.sh/?id=426483081 <https://crt.sh/?id=426483081&opt=cablint> &opt=cablint

[3] https://crt.sh/?id=836901244 <https://crt.sh/?id=836901244&opt=ocsp> &opt=ocsp

On Thu, Oct 11, 2018 at 5:17 AM Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Why? Would it change your mind? It’s probably an unreasonable argument. 

Plus we already stopped issuing certs with underscore characters. The writing is on the wall on this one so the main question for me is how should we prevent having this discussion again in another two years? 

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Thursday, October 11, 2018 3:02 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >
Subject: Re: [cabf_validation] Underscores, DNSNames, and SRVNames

On Thu, Oct 11, 2018 at 4:57 AM Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

“Incorrect extensions” is hardly prohibitive of underscore characters especially where the only mention of underscores is 5280 is:

   When the subjectAltName extension contains a domain name system

   label, the domain name MUST be stored in the dNSName (an IA5String).

   The name MUST be in the "preferred name syntax", as specified by

   Section 3.5 of [RFC1034] and as modified by Section 2.1 of

   [RFC1123].

plus the BRs

7.1.2.4. All Certificates

All other fields and extensions MUST be set in accordance with RFC 5280. 

Can you remind me again where there's any possible interpretation of the above that would result in underscores being permitted?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181015/b6e6c0d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5705 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20181015/b6e6c0d2/attachment-0001.p7s>