On 04/10/2010 05:30 PM, Bernard Aboba wrote:
> I reviewed the document draft-ietf-sip-domain-certs-06 in general
> and for its operational impact.
Dear Bernard: Thank you for your time in reviewing this
document. Please see inline for more information.
> IMHO, a better prescription would be to require that
> implementations be capable of accepting identities in any of
> the permitted formats (though a given deployment might choose
> to further constrain identity placement by policy).
SIP WG consensus was very clear that given a choice between an
identity in the CN and SAN, the identity in SAN is accorded
higher preference. The draft reflects that consensus.
> [BA] Where an SRV or NAPTR RR is used, it is possible for a domain
> to be delegated so that the matching process described above would
> fail, yet the delegation would still be legitimate (e.g. the
> SRV/NAPTR RRs could be signed via DNSSEC,and might point to an
> FQDN that matches the identifier extracted from the certificate,
> rather than the FQDN in the SIP URI.
When SRV or NAPTR RR is used, it is possible to end up at a
delegated domain whose identity does not match the domain portion
of a SIP AUS query. This is true, but there was strong consensus
in the SIP WG that either the delegated domain possess an appropriate
identity in the SAN of the certificate, or that the matching
fails.
> [BA] At this point, 8 years after the issuance of RFC 3261, wildcards
> are widely deployed within SIP certificates. It is therefore
> not appropriate to prohibit them.
We had discussed this in the SIP WG as well, and there was good
consensus to prohibit wildcards. Unlike HTTP, SIP already has a well
defined and uniform way to to map a domain (the right side of a SIP URL)
to one or more hosts that provide service for that domain - the
NAPTR/SRV mechanisms in RFC 3263. HTTP, by contrast, uses a variety of
mechanisms with a range of formality to their definition. As a result,
HTTP more or less informally adopted wildcard certificates as a
'solution' to the problem that fully qualified host names didn't always
exactly match the domain part of the HTTPS URL. In the case of SIP, we
don't have that problem - the mapping from the domain address part to
the hostname(s) that provides service for that domain is well defined
and widely used (of course, sometimes the mapping is just 1-1, but
that's the easy case) - in large part, this specification is intended to
clarify for implementers that it is the original domain they should be
looking for in the server cert because the DNS translations of that name
may be unreliable.
Once again, thank you for your time to reviewing the draft.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf