$Id: draft-ietf-sip-eku-01-rev.txt,v 1.1 2008/03/13 12:59:19 ekr Exp $
S 2.
equivalent in another domain. In Figure 1, proxyA.example.com
performs certain DNS queries to arrive at proxyB.example.net.
Because of the answers to the DNS queries, proxyA has a certain
expectation that proxyB is a valid proxy in the example.net domain
and is authorized to receive inbound requests targeted to that
domain.
However, the problem for proxyB is different; it is presented with a
connection from a specific host, but what it needs to determine is
whether or not that connection can be treated as coming from a
particular SIP domain. If it receives a certificate that contains
only the name proxyA.example.com, then it cannot determine that
proxyA is authorized to act as a SIP outbound proxy for example.com,
because example.com may use different systems for inbound messages so
SIP DNS resolution of example.com may not lead to proxyA.example.com
(if this is the case, proxyB should not reuse this connection if it
needs to send a request to example.com). The certificate usage in
SIP should not require that every outbound proxy for a domain must
also be an inbound proxy for that domain, but should provide for
certificate based binding of the SIP domain name to a particular
connection.
I don't think this is the issue in this draft at all. The only
purpose for the EKU that makes sense is to distinguish SIP from
non-SIP certificates, not to distinguish inbound from outbound
proxies.
S 4.
o If the certificate contains the id-kp-sipDomain EKU extension,
then the certificate MUST be accepted as valid for use as a SIP
s/MUST be accepted/is acceptable/.
After all, you could reject it for some entirely other reason.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
