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

Phillip philliph at comodo.com
Mon Oct 22 10:04:06 MST 2018


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181022/32edcc4e/attachment.html>


More information about the Servercert-wg mailing list