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

Ryan Sleevi sleevi at google.com
Mon Oct 22 21:58:47 MST 2018


On Tue, Oct 23, 2018 at 12:44 AM Phillip <philliph at comodo.com> wrote:

> 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’.
>

Because you suggested that it has some bearing on RFC 5280, which was not
updated or influenced by this, as has been repeatedly shown. I'm not sure
your goals here - do you believe there was some discussion of RFC 5280
being updated to support prefixed labels, which it clearly does not
support, that was shut down? I've asked you to provide further details to
help illustrate that.


> 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.
>

This is also a nonsensical statement, in the context of this discussion.
The question of SRV records had already been addressed, by Microsoft and
subsequently PKIX, in 2005 - 2008. It's simply not accurate to suggest they
were not considered or had not been explicitly addressed, especially as
below.


> 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.
>

If you mean that RFC 5280 should have explicitly called out prefixed
records because it was somehow ambiguous, then you're ignoring that it
explicitly refers to - as had all prior versions - Section 3.5 of RFC 1034
as modified by Section 2.1 of RFC 1123. There is no way you can read
explicit text, which both of those sections lay out an ABNF grammar - and
somehow think that it was reasonable to conclude it was permitted.

If it's unclear why email addresses would be called out, as such, it's
because the representation being explicitly forbidden is one that conforms
to the grammar, but not the semantics. That should have been obvious
through the normative references and illustrative examples.

Prefixed records for non-host names conform neither to the grammar nor
semantics. There's no need to exclude those, because they already were, and
have always been, excluded.


> 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.
>

And they can be - by using SRVNames. Both cases you mentioned were already
addressed by the XMPP specification, with specific considerations given to
RFC 3280 and 5280. You can see this discussion at
https://www.ietf.org/mail-archive/web/xmpp/current/msg01843.html and
https://www.ietf.org/mail-archive/web/xmpp/current/msg01844.html and
https://www.ietf.org/mail-archive/web/xmpp/current/msg01846.html

Regardless of your view that these are services that should be 'protected'
by the Web PKI, the relevant specifications already describe how they can
be:
- https://tools.ietf.org/html/rfc3920#section-5 ( 2004, predating SRVName
representation, explicitly calling out the ID should not be the service
name )
- https://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 (2011, explicitly
calling out the ID should usr the SRVName extension)
- https://tools.ietf.org/html/rfc7590#section-3.4 (which updates it to
bring in https://tools.ietf.org/html/rfc7712#section-1 , which emphasizes
https://tools.ietf.org/html/rfc6125#section-6.5.1 )

Are all examples how "using prefixed labels" was not anticipated, required,
or needed, and how at every step of the standardization process, a
compliant solution was offered to support such clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181023/cf605742/attachment.html>


More information about the Servercert-wg mailing list