[Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

[Phillip]

This is hardly going to be a productive discussion when you simply ignore the fact that the document I referenced, RFC 5507 was written by the IAB. It sets out precisely the architectural approach that I stated had been insisted on by the DNS community at that time. The claim that you stated was ‘ahistorical’.

 

I am really not interested in playing the game where you ignore the evidence I provide and demand more. 

 

I do not see the passage you cite as supporting the case you are attempting to make here. The question of SRV records is not explicitly addressed in RFC5280 which is hardly surprising as the use of prefixed labels was deprecated by the IAB until the release of RFC 6335 in 2011 effectively acknowledged that it was the preferred means of designating services superseding the use of port numbers.

 

The passage you quote explicitly calls out email addresses but does not consider prefixed records. If there had been an intention to exclude prefixed records from SANs then one would expect them to be treated in the same way.

 

I really don’t think we need to go into a hermeneutical exegesis or RFC 5032 since regardless of what the intent was when it was written, at the time it was written, the architectural approach described in RFC5507 was considered to be the consensus view of the IETF. RFC 6335 reversed those conclusions and represents the current view.

 

 

Like I said earlier, rather than argue about what the IETF intended in decades past, let’s ask them what they think the approach should be now.

 

I really don’t care about certificates for example_broken.com. But a dozen of those certs are certs for Jabber servers which are using _xmpp or CISCO equivalent prefixes. Those are services that should be protected by the WebPKI.

 

 

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, October 22, 2018 5:55 PM
To: Phillip <philliph at comodo.com>
Cc: servercert-wg at cabforum.org
Subject: Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

 

 

On Mon, Oct 22, 2018 at 1:04 PM Phillip <philliph at comodo.com <mailto:philliph at comodo.com> > wrote:

I don’t have access to my email from my time at VeriSign and couldn’t share it even if I did. Since I was one of the main proponents of using prefixes in place of port numbers for service discovery at the time, it was a subject I had many conversations with people about.

 

Also, I find things go rather better when I don’t repeatedly remind people that the position that they accept as valid today is actually the opposite of the one that they argued ten years ago.

 

 

While I was not winning that particular argument in the wider IETF at the time, I was on the look out for attempts to insert prohibitions on prefixes into other specs and especially PKIX.

 

Lets look at RFC 5280:

 

The string underscore only appears here:

 <https://tools.ietf.org/html/rfc5280#appendix-B> Appendix B.  ASN.1 Notes

   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.

 

I can’t see a passage with a further restriction in the Subject Alt Names section.

 

   SubjectAltName ::= GeneralNames

 

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

 

   GeneralName ::= CHOICE {

        otherName                       [0]     OtherName,

        rfc822Name                      [1]     IA5String,

        dNSName                         [2]     IA5String,

        x400Address                     [3]     ORAddress,

        directoryName                   [4]     Name,

        ediPartyName                    [5]     EDIPartyName,

        uniformResourceIdentifier       [6]     IA5String,

        iPAddress                       [7]     OCTET STRING,

        registeredID                    [8]     OBJECT IDENTIFIER }

 

I am aware that SRV names are invalid Internet HOST NAMES according to RFC 1034/5. That is precisely why the underscore character was chosen in the first place. And the proposal here is for SRV names which are not host names but are DNS labels.

 

The DNS was designed from the start to support resolution of more than just hosts. It also services Heisod and so on. Now much of that code is now legacy and the documentation is confused as heck. But underscores have always been legal DNS labels, they are just not legal Internet hosts.

 

 

I think that we should push this back to IETF.

 

Thank you for sharing your perspective, Phillip. The information you've shown certainly doesn't support your claims regarding PKIX or RFC5280, so I think it's useful that I've provided you the citations about where your claims, of personal experience, are directly contradicted by the IETF's own process documentation. As the IETF is meticulous about recording minutes for in-person meetings and for hosting decisions on the list, I would have certainly expected that any relevance to an actual mainstream discussion would be supported.

 

I'm glad you acknowledge that underscores are valid and legal DNS labels, but are not legal Internet hosts, and not in the preferred name syntax. I'm surprised to see you make the mistaken and irrelevant argument that because 5280 fails to explicitly mention underscores, it's somehow not relevant. I say mistaken and irrelevant, because this has already been discussed on list, with the text being provided:

 

   When the subjectAltName extension contains a domain name service

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

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

   1034 [RFC 1034]. Note that while upper and lower case letters are

   allowed in domain names, no signifigance is attached to the case.  In

   addition, while the string " " is a legal domain name, subjectAltName

   extensions with a dNSName " " are not permitted.  Finally, the use of

   the DNS representation for Internet mail addresses (wpolk.nist.gov <http://wpolk.nist.gov> 

   instead of wpolk at nist.gov <mailto:wpolk at nist.gov> ) is not permitted; such identities are to

   be encoded as rfc822Name.

 

I should hope that just as it's rather obvious that CAs that have issued certificates for "www..example..com" and " " are in violation of the profile of RFC2459, so to are any CAs that issue for "www!example!com" or "_www._tcp.example.com <http://tcp.example.com> " - all of these are clearly incompatible with the above text.

 

With that said, while I appreciate your perspective that I don't know anything, it doesn't seem particularly germane to this discussion, as I do know that this prohibition was introduced well-before any such discussions, and was maintained throughout - as one would expect of a compliant and restrictive protocol. Given that the IETF has a successful track record of introducing new name types when the syntax is altered in such a way as to affect backwards compatibility - both the SRVName subjectAltName extension (RFC 4985) and the representation of EAI addresses (RFC 8398) - I think it's also fair to say that the consensus view of the IETF, as demonstrated through both historical and current practice, is to define new name types when responding to such use cases. Not, as some have suggested, by repurposing existing fields.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181023/593f9bd1/attachment-0001.html>