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.