Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
draft-ietf-pkix-srvsan-05

[Ballot discuss]
I have been convinced that UTF8String is the wrong encoding to use in
this SubjectAltName form.  Storing the punycode in an IA5String seems
like a much better solution.

[Ballot comment]
This specification is doing almost exactly the same thing as
draft-ietf-kitten-gssapi-domain-based.  However there are many ways in
which the two specs are not aligned:

1) Different selection of service names: this uses the port number
registry, while kitten uses the GSS-API service registry.  I think this is unavoidable

2)  Handling of internationalization.

3) Statement of applicability.

This conflict may become problematic because this name form is an
ideal candidate for implementing GSS domain-based names for PKIX certificates.

I'd strongly encourage the authors of these two proposals to work
together.  This is not a discuss, but a strong last call comment.

[Ballot discuss]
First, the motivating example is wrong and needs to be removed.  RFC
4556 defines the appropriate name form for Kerberos KDC certificates.
While that discussion is in the context of pkinit the name form should
be used for other cases where Kerberos KDCs need to be identified.
Implying that this spec would be appropriate for Kerberos means that
we have two standards where only one is needed.

This leads me to the more general question of when is it appropriate
to use this name form.RFC 2782 has a very clear applicability statement.
This specification does not.

[Ballot discuss]
The document says:

This section defines the SRVName name as a form of otherName from the
  GeneralName structure in SubjectAltName defined in RFC 3280 [N2].

      id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }

      SRVName ::= UTF8String    (SIZE (1..MAX))

  The SRVName, if present, MUST contain a service name and a domain
  name in the following form:

      _Service.Name

There are two issues here.  One it, is not clear that UTF8String is appropriate
without further limitations. RFC 2782 derives services from the old Assigned
Numbers (STD 2/RFC 1700).  None of the services assigned are beyond the ascii
range there.  The Name portion above uses IDNA to encode UTF8; are the authors
and working group confident that a UTF8 Service string with prepended _ would
be an appropriate choice?  Or do they believe that UTF8 characters outside the
ascii range  will not occur in a PKIX context unless it has occurred in the DNS context?

The larger issue is that this seems to elide one aspect of RFC 2782; the PROTO
field.  A common SRV lookup has the form _ldap._tcp.example.com (see the
overview section of 2782).  There are cases where the service name may be associated
with multiple protocols and where the target hosts will not be the same.  Why
is this facility not replicated here?

[Ballot discuss]
> Example: The "mail" service at na(LATIN SMALL LETTER I WITH
> DIAERESIS)ve.net (an IDN, which becomes xn--nave-6pa.net when encoded
> as an IDNA) would use the following 15-character SRVName value:

This violates our policy of not using other
domain names than those officially allocated
for examples. Use na(something)ve.example.net
instead, for instance.

[Ballot discuss]
> Example: The "mail" service at na DIAERESIS>ve.net (an IDN, which becomes xn--nave-6pa.net when encoded
> as an IDNA) would use the following 15-character SRVName value:

This violates our policy of not using other
domain names than those officially allocated
for examples. Use nave.example.net
instead, for instance.