At Fri, 21 Mar 2008 16:19:41 -0500, Dean Willis wrote: > > > On Mar 21, 2008, at 11:06 AM, Cullen Jennings wrote: > > > > Dean - this conversation is beyond bizarre. In no way do I want to > > write requirements that are in conflict with 3280 or a system that > > implements it. I don't think anything I said should be construed > > that way. Obviously I-D.sip-eku[9] fully depends on 3280. > > Well that's good, because the wording of your previous proposal was > misleading into thinking otherwise. > > The question as I understand it: to what extent does draft-ietf-sip- > domain-certs depend on sip-eku and transitively on 3280? > > I really want this answered clearly in the domain certs draft.
I don't think these are the same question. - draft-ietf-sip-domain-certs clearly has a normative dependency on RFC 3280, since otherwise how would one be able to discuss matters such as SubjectAltName or Common Name. RFC 3261 should have required PKIX validation and to the extent it doesn't, domain certs should. - draft-ietf-sip-domain-certs should not have a normative dependency on the EKU draft. Just so we're all clear on the semantics, there are two purposes EKU serves in this context: - Stopping certificates targeted for other purposes for being used with SIP. - Stopping certificates targeted for SIP for being used with other services. The former purpose can be served by tagging the cert with an EKU key purpose other than SIP and marking the EKU extension critical. Any compliant 3280 implementation of SIP will therefore refuse to accept this. The second purpose is served by the definition of a new EKU key purpose for SIP. Now, as discussed above, any compliant non-SIP implementation will reject this certificate. Unfortunately, only a SIP stack which has been upgraded to support this particular purpose. So, in order for the SIP EKU kp to be useful, it needs to eventually be mandatory for SIP implementations. However, this seems like a separable question from domain certs, which I read to be primarily about clarifying/fixing existing functionality, rather than creating new functionality, which the new EKU kp does. -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
