[cabf_validation] Underscores, DNSNames, and SRVNames

Thu Oct 11 01:57:18 MST 2018

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

“Implementers should note that the at sign ('@') and underscore ('_')

   characters are not supported by the ASN.1 type PrintableString.

   These characters often appear in Internet addresses.  Such addresses

   MUST be encoded using an ASN.1 type that supports them.  They are

   usually encoded as IA5String in either the emailAddress attribute

   within a distinguished name or the rfc822Name field of GeneralName.

   Conforming implementations MUST NOT encode strings that include

   either the at sign or underscore character as PrintableString.“

But, we’ve been over the rationale and language a lot since we started the discussion back in 2016 (ex. https://cabforum.org/pipermail/public/2017-June/011200.html). I doubt any additional argument will change minds, but I can find at least 3935 instances where some peoples didn’t think underscores were prohibited by the BRs. Whether the instances are “reasonable” probably depends on your view.  This confusion about underscores is one of the ideas behind passing the original version of ballot 202, as I didn’t think the language was clearly prohibitive. Adding srv_name support was gravy on top. Ultimately ballot 202, but this just adds to the confusion on whether underscores are permitted.

For “reasonable assurance”, the auditors do check profiles. But there’s enough confusion that this (from the BR audit criteria):

“The CA maintains controls to provide reasonable assurance that with exception  to the requirements stipulated in the Baseline Requirements Sections 7.1.2.1,  7.1.2.4 

7.1.2.2, and 7.1.2.3, all other fields and extensions of certificates generated are  set in accordance with RFC 5280.”

Leaves sufficient wiggle room that no auditor would check for underscore characters in fields as part of their routine review. Why would they? It’s not directly in 5280 and only incorporated by reference through another RFC.  There’s also the already mentioned 202 fiasco.  Until the prohibition is more clearly stated, I think you’re going to find this a reoccurring issue as personnel change within CAs. 

To prevent future issuance, do you want:

1.	To create a documented Google policy against it? 
2.	Have Mozilla add it to their CA policy?
3.	Add it to the BRs?
4.	Ignore it and hope everyone reads the validation working group minutes?
5.	Something else? 

My preference is #3 so we can finally get a form of ballot 202 passed, and the change becomes part of the audit criteria. The Google policy is probably faster. 

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

Regardless of personal views of it, "reasonable assurance" is what the auditors provide, and the existence of such certificates necessarily show that the control objectives are not and cannot be met.

With respect to 1.0, the answer is "incorrect extensions". Unlike things that the CA/Browser Forum has sunset - things that were once valid but presented undue risk - there is no reading of the relevant RFCs that can support the notion that they were ever valid.

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

Where is it forbidden in the Mozilla policy 1.0, I ask realizing I’m walking into a trap…

I also liked how you added “reasonable” to ensure all other interpretations are considered unreasonable by default.

From: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > On Behalf Of Ryan Sleevi via Validation
Sent: Wednesday, October 10, 2018 11:23 PM
To: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Underscores, DNSNames, and SRVNames

I disagree that the existence of 3935 BR violating certificates is justified or a reason to change the BRs. If anything, it states that anything forbidden will be permitted, so long as you misissue enough of it. This is no different than if a CA were to issue 1024-bit RSA certificates in contravention of the BRs - there's no reasonable basis to change the BRs based on hardship that 'some' customers may face.

There is no reasonable basis to assume it's permitted, so CAs have (and have had) a responsibility to ensure that organizations are educated, and are aware that they cannot replace/renew these certificates. This is a failure, by CAs, to both adhere to the standards and to help their customers avoid disruption.

There's zero evidence to suggest it requires any form of sunset or delay. CAs should have stopped ages ago - because it's never been permitted. Unlike internal server names, this is not the result of some "technically correct, but semantically undesirable" process - Mozilla itself has forbidden this practice since 1.0 of its policy ( https://wiki.mozilla.org/CA:CertificatePolicyV1.0 ). I think that's a huge point that needs to be acknowledged by CAs - unlike RSA-1024, unlike SHA-1, unlike internal server names - there's no reasonable interpretation of the relevant RFCs to believe this has ever been permitted. At best, the only reason to believe permissiveness is because they haven't been taken to the carpet by auditors or browsers, but that's an unacceptable standard for CA operations and compliance - that you only have to comply when you get called out.

CAs should revoke these certificates. They should receive qualified audits for the issuance, and for the lack of revocation. Auditors that fail to acknowledge these 3935 certificates should be suspect, because there's no reasonable basis to believe the control objectives have been met.

On Thu, Oct 11, 2018 at 12:06 AM Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > wrote:

According to crt.sh, 3935 certificates containing underscores have been issued in 2018 [1]. Characterizing this as an attempt to compromise with CAs ignores the fact that a lot of organizations apparently rely on such certs, and need education and time to fix the problem, much as they did with internal names. Was the internal name deprecation perfect? Obviously not. Did it succeed? Yes. You can ignore the reality of this situation and blame CAs and auditors for allowing it, but that doesn't solve the problem methodically.

- Wayne

[1] https://crt.sh/?cablint=62 <https://crt.sh/?cablint=62&minNotBefore=2018-01-01> &minNotBefore=2018-01-01

On Wed, Oct 10, 2018 at 6:46 PM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

On Wed, Oct 10, 2018 at 7:50 PM Wayne Thayer via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

Following up on the thread that Doug started [1] on reviving Ballot 202, I would summarize the current situation as follows:

* My memory of ballot 202 going down in flames for unrelated reasons was only partially correct. Erwann voiced a strong objection to violating standards and voted against, and Ryan later stated that his vote for that ballot was in spite of the exception permitting underscore characters in DNSNames.

* Later on in the thread that Doug started, Erwann pointed out specific implementations that do not tolerate underscores [2].

* While Comodo stated that they stopped issuing these certificates after the ballot failed, some CAs continue the practice [3].

As I stated on our last call, I'm unhappy with the current lack of clarity and consistency. Some of the options for fixing this are:

* Put forth another ballot creating an exception for this and see if it passes. (TBH, now that I've read the history on this issue, I would be inclined to vote against)

* Add language explicitly forbidding this to the BRs.

* Focus on adding support for SRVNames which would at least partially solve this problem in a standards-compliant fashion. Unfortunately, this breaks existing TCSCs in a way that is difficult to fix quickly [4] [5].

My proposal is this: Recognize the existence, use of, and reliance on certificates with underscores encoded in DNSNames much as we did with internal names. Update the BRs to explicitly permit issuance of these certificates for some sunset period with deadlines for ceasing new issuance and for revoking remaining certificates. I have Jan 1, 2020 in mind as the date after which new issuance is forbidden, with revocation of existing certificates required 1 year later, but we can debate this. We'll also have to decide if an exception process is really necessary.

As much as I appreciate the attempt at compromise, I think the discussion previously unquestionably highlighted for both auditors and CAs that such certificates are expressly forbidden by the relevant standards. Further, these certificates cannot be used with the SNI extension, as they violate the TLS specification.

Further, given that significant failure by a number of CAs to respond appropriately to both the sunset of issuance for internal server names and the revocation of existing internal server name certificates [1][2][3][4][5][6][7][8][9][10][11][12][13], an attempt at a sunset seems naive, at best. Given CAs' and auditors failure to follow the relevant decades-old RFCs, which have been clearly provided and are unambiguous in their support, and given CAs' failures to timely and effectively adhere to previous sunsets - c.f. internal server names and SHA-1 certificates - we can see no reason to support a sunset.

With respect to auditors, it's unconscionable to not see this as a failure of the controls to ensure Criterion 7.1 of the WebTrust for CAs, Criterion 2.1 of the WebTrust for CAs - SSL Baseline, GEN-6.6.1-01 of ETSI EN 319 411-1, and that of Section 4.1 of ETSI EN 319 412-4. There is no supported interpretation that an auditor can take that reasonable assurance or compliance, as appropriate, has been met with such certificates, nor can there be reasonable assurance that controls exist and are functioning properly.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1335132

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1389172

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1397963

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1397960

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1495524

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1390977

[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1393557

[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

[9] https://bugzilla.mozilla.org/show_bug.cgi?id=1390974

[10] https://bugzilla.mozilla.org/show_bug.cgi?id=1391074

[11] https://bugzilla.mozilla.org/show_bug.cgi?id=1391067

[12] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ

[13] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

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