Skip to main content

Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
RFC 4985

Discuss


Yes

(Tim Polk)

No Objection

Lars Eggert
(Bill Fenner)
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert
No Objection
Ted Hardie Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-01-10)
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?
Tim Polk Former IESG member
Yes
Yes ()

                            
Bill Fenner Former IESG member
No Objection
No Objection ()

                            
Brian Carpenter Former IESG member
No Objection
No Objection ()

                            
Cullen Jennings Former IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Jon Peterson Former IESG member
No Objection
No Objection ()

                            
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Mark Townsley Former IESG member
No Objection
No Objection ()

                            
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
(was Discuss, Yes) No Objection
No Objection ()

                            
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection (2007-01-11)
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.