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

[Ryan Sleevi]

On Mon, Oct 22, 2018 at 1:04 PM Phillip <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:
>
> *Appendix B* <https://tools.ietf.org/html/rfc5280#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
   instead of 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" - 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/20181022/31581ace/attachment.html>