On Mar 19, 2008, at 9:32 AM, Cullen Jennings wrote: > > The draft contains the text: > > I-D.sip-eku [9] describes the method to validate any Extended Key > Usage values found in the certificate for a SIP domain. > Implementations MUST perform the checks prescribed by that > specification. > > This last sentence creates a normative dependency of domain certs on > EKU. My read of the WG discussion was that domain certs clarified > important issues about TLS cert verification from 3261, and it was > fairly likely that it the WG would decide that the domain-certs draft > was an essential correction to 3261. We haven't really had a > discussion about whether EKU is essential or an correction to 3261 or > even whether it MUST be implemented, so it seems like a bad idea to > have this dependency. >
My sense that the WG was somewhat shocked by the proposal that we place this draft into the essential corrections process. I'm not exactly certain we had agreement on making domain-certs an "essential correction" according to the current process. Doing so would certainly require an almost complete rewrite of the draft to comply with the essential corrections documentation process -- for example, describing the line-by-line changes to RFC 3261 as "normative" behavior, and removing all normative statements from the explicative text. > I propose we strike the last sentence and make the reference to I- > D.sip-eku informative. I think that will be the best path to allow > both the EKU and the domain-certs document get finished faster than if > we try to tie them together in this way. From a 2119 perspective, are you saying we change the "MUST" to a "SHOULD" or perhaps a "MAY"? Or are you suggesting that the text be rewritten to say something like: I-D.sip-eku [9] describes the method to validate any Extended Key Usage values found in the certificate for a SIP domain. Implementation of this method is optional. (Note: This is a MAY in 2110 language) My personal preference would be to pack both drafts back into one standards-track document that updates RFC 3261 but is not done using the "essential corrections" process. I also think that the process described for handling EKU is a MUST if EKU is present, so it is something like "Implementations SHOULD be prepared to handle EKU, and if they do so, they MUST do so according to the process in [9]." -- Dean _______________________________________________ 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
