Subject: [Sip] Question about refernce in draft-ietf-sip-domain-certs-00

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Mar 2008 10:32:08 -0400

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.

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.

Cullen <with my individual contributor hat on>

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Mar 2008 11:30:07 -0500

> even whether it MUST be implemented, so it seems like a bad idea to

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.

> 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 19 Mar 2008 11:50:20 -0500

> if they do so, they MUST do so according to the process in [9]."

I have not talked to Scott about this yet, but my thoughts mirror

> we try to tie them together in this way.

I was also wondering if a happy medium would be reached if we made
the normative dependency on I-D.sip-eku a function of an EKU being
present at all in the certificate.  Text of the form you suggest
above sounds eminently reasonable.  Those implementations that want
to go beyond the call of duty for services such as SIPConnect will
be conscientious enough to then implement I-D.sip-eku.

Regarding making the drafts essential corrections and whether or
not to pack both drafts into one, I will defer to the WG.  I
certainly had not viewed the drafts as an essential correction,
but did view them as work that updates rfc3261.  However, and I
believe I also speak for Scott here, our preference is to keep
them standards track.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 19 Mar 2008 18:01:06 +0100

Cullen, 

The remaining key part to understanding what you what you are trying to
do here is to bottom out your assertion that

> 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.

For any of the material to be an essential correction to RFC 3261, it is
implicit that domain-certs would currently contains statements in RFC
2119 language that we would write in RFC 3261 so that all
implementations of RFC 3261 took account of those requirements (these
could be any of MUST, SHOULD, MAY).

You apparently believe that some of the requirements do fall into this
category. I did ask you to identify those requirements, and so far you
have not done so. I do believe that if you assertion is correct, that we
must have the discussion before we proceed any further.

The philosophy. We currently have a number of RFC 2119 requirements
split between eku and domain certs. We need to understand the dependency
of these on each other and on RFC 3261. Currently the division assumes
that none of the information is required for all implementations, merely
for those in scope of the domain-certs draft, and also for connect-reuse
that calls up these documents.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: Wednesday, March 19, 2008 2:32 PM
> To: SIP
> Subject: [Sip] Question about refernce in 
> draft-ietf-sip-domain-certs-00
> 
> 
> 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.
> 
> 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.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Mar 2008 19:56:30 -0400

> "essential correction" according to the current process.

OK - no worry , that is fine. I think I must have got the wrong idea  
from part of the draft where it quotes parts of 3261 and says that  
3261 is incorrect.  It was my sense of where I suspected things where  
going from the discussion but clearly I must have got this wrong. I  
wasn't trying to say anything about how we move the domain-certs  
document forward - just commenting on dependency issue.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Mar 2008 19:56:33 -0400

On Mar 19, 2008, at 1:01 PM, DRAGE, Keith (Keith) wrote:

> of these on each other and on RFC 3261.

agree. When I read these, what I see is that EKU and Domain-Certs are  
fairly orthogonal to each other.

EKU has an informative reference to domain-certs and the text

    Section 7.1 of [8] contains two steps for finding an identity (or a
    set of identities) in an X.509 certificate.  In order to determine
    whether a SIP proxy is authoritative for its domain, implementations
    MUST perform the step given below first, and then proceed with the
    steps in Section 7.1 of [8].

This could easily be written to point at 3261 instead of domain-certs  
with no change in functionality of the systems that implemented either  
of these two drafts.

And certs has the text

which seems to me like it could be changed to

So my view is that both documents could easily be written such that  
they only required informative references to each other with no change  
to the functionality of devices that implemented them. Let's imagine  
that we make these changes and that the EKU draft becomes RFC EEEE and  
the domain certs draft becomes RFC CCCC. Devices that implement RFC  
EEEE will support EKU. Device that don't do RFC EEEE will still  
support the PKIX documents that deal with the issues of handling  
certificates with unknown extensions with the critical bit set.

I don't understand the need for RFC CCCC to say that you MUST support  
RFC EEEE any more than it needs to mandate any other SIP security RFC  
such as RFC 5090. There is nothing in the domain-certs draft that  
won't work if you don't implement EKU so I don't see the need for the  
dependency.

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Mar 2008 00:45:22 -0500

On Mar 19, 2008, at 6:56 PM, Cullen Jennings wrote:

> 3261 is incorrect.  It was my sense of where I suspected things  
> where going from the discussion but clearly I must have got this  
> wrong. I wasn't trying to say anything about how we move the domain- 
> certs document forward - just commenting on dependency issue.
>

Oddly enough, making a normative change to RFC 3261 does not qualify a  
document as part of the "Essential Corrections" process, as I  
understand it.

One could reasonably argue that this is the proper determinant, but  
that doesn't seem to be what we're using, and it certainly isn't the  
format that the current domain-certs draft is written in.

You may be right in that this draft should be an "Essential  
Correction". Far be it from me to make that determination -- Keith and  
Robert seem to be driving the essential corrections process, and I'd  
like to hear their opinions on this point of procedure.

Help!

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Mar 2008 00:52:19 -0500

>    Usage values found in the certificate for a SIP domain.

So the above text means to me "If you receive a certificate for a SIP  
domain that contains any Extended Key Usage values, you MUST validate  
them according to the procedures of I-D-sip-eku [9]."

Inserting EKU in a cert would seem to be optional. This is good, since  
getting EKU into a cert appears to be very hard.

If you receive a cert that contains EKU, it appears that validating it  
is mandatory (at least according to the current text).

It could be that I (or the text) have this wrong, and EKU may safely  
be ignored. However, even if validation of the EKU is optional, the  
only process we have for validating it is the process defined in [9],  
so that still seems like a normative reference rather than an  
informative reference to me, even though it's only a 2119 SHOULD or  
MAY level of requirement.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Mar 2008 13:12:31 -0400

On Mar 20, 2008, at 1:52 AM, Dean Willis wrote:

> So the above text means to me "If you receive a certificate for a  
> SIP domain that contains any Extended Key Usage values, you MUST  
> validate them according to the procedures of I-D-sip-eku [9]."

I'm assuming that be above text you mean my proposed change, not the  
the current text in the draft. I would have interpreted my proposed  
change to mean something closer to  "As a FYI to the reader,  there is  
another specification you might be interested in. If you want to do  
Extended Key Usages there is this other specification, sip-eku, that  
can be implement but implementation of the domain-certs specification  
does not require you to implement sip-eku". If you and I are reading  
this differently ways perhaps you could propose some  text for this   
sentence so that there is no chance of ambiguity.

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Mar 2008 00:51:49 -0500

On Mar 20, 2008, at 12:12 PM, Cullen Jennings wrote:
> change to mean something closer to  "As a FYI to the reader,  there  
> is another specification you might be interested in. If you want to  
> do Extended Key Usages there is this other specification, sip-eku,  
> that can be implement but implementation of the domain-certs  
> specification does not require you to implement sip-eku". If you and  
> I are reading this differently ways perhaps you could propose some   
> text for this  sentence so that there is no chance of ambiguity.

Yes, I was referring to your proposed change.

There's a reason we have 2119 language -- for reducing ambiguity in  
the discussion of requirements.

I think what you're saying is:

If the certificate presented for a SIP domain contains Extended Key  
Usage values [need a ref here for , implementations MAY validate those  
values using the techniques described in I-D.sip-eku[9].

If so, it's definitely weaker than what the original text has -- and  
qualifies (just barely) as an informative reference, IMHO.

What I had proposed is that the EKU draft have a SHOULD level  
requirement for EKU in SIP certificates (and I'd take a MAY), and that  
domain-certs have a MUST level requirement for evaluating certs that  
contain EKU. If the domain went to all the trouble to include an EKU  
in their cert, they did so for a reason. It's their cert, and people  
referring to it should us it in the manner intended by the signer. The  
signer intended the EKU constraints be applied to that cert, or they  
wouldn't have bothered putting them there.

For example, if I use a cert that says "Use only for email" to sign an  
application, are you really stupid enough to run that code?

I know you're trying to prevent a publication deadlock by changing the  
requirements here. I don't understand why you think we'll have a  
deadlock, and that might be pertinent to the discussion.

But I'm fairly sure that the requirements I think you are suggesting  
are inconsistent with reasonable handling of EKU. Of course, I could  
be wrong about that too :-).

Let's look at what RFC 3280 has to say:

4.2.1.13  Extended Key Usage

    This extension indicates one or more purposes for which the  
certified
    public key may be used, in addition to or in place of the basic
    purposes indicated in the key usage extension.  In general, this
    extension will appear only in end entity certificates.  This
    extension is defined as follows:

    id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

    ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

    KeyPurposeId ::= OBJECT IDENTIFIER

    Key purposes may be defined by any organization with a need.  Object
    identifiers used to identify key purposes MUST be assigned in
    accordance with IANA or ITU-T Recommendation X.660 [X.660].

    This extension MAY, at the option of the certificate issuer, be
    either critical or non-critical.

    If the extension is present, then the certificate MUST only be used
    for one of the purposes indicated.  If multiple purposes are
    indicated the application need not recognize all purposes indicated,
    as long as the intended purpose is present.  Certificate using
    applications MAY require that a particular purpose be indicated in
    order for the certificate to be acceptable to that application.

    If a CA includes extended key usages to satisfy such applications,
    but does not wish to restrict usages of the key, the CA can include
    the special keyPurposeID anyExtendedKeyUsage.  If the
    anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD  
NOT
    be critical.

    If a certificate contains both a key usage extension and an extended
    key usage extension, then both extensions MUST be processed
    independently and the certificate MUST only be used for a purpose
    consistent with both extensions.  If there is no purpose consistent
    with both extensions, then the certificate MUST NOT be used for any
    purpose.

This seems pretty darned normative about what it means to process an  
EKU -- if present, EKU MUST be respected. Failure to do so has  
potential severe security consequences; potentially as severe as not  
paying attention to the domain name part of the certificate.
If I'm understanding the way you want to write the requirements,  
they're in direct conflict with RFC 3280. Now, it may well be that  
we've decided that this art of RFC 3280 is a Bad Idea andshould  
therefore be ignored. If that's so, then I'd like the drafts to say  
that clearly and distinctly, rather than trying to diminish-by- 
reference a MUST level requirement in another RFC.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Mar 2008 01:05:29 -0500

Let me restate this with fewer typos:

I think what Cullen is saying is:

If the certificate presented for a SIP domain contains Extended Key
Usage values [RFC 3280] , implementations MAY validate those
values using the techniques described in I-D.sip-eku[9].

and if that's what he's saying, I think this is in conflict with the  
text of RFC 3280, which makes validation a MUST.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 09:06:01 -0700

On Mar 20, 2008, at 10:51 PM, Dean Willis wrote:

>> I'm assuming that be above text you mean my proposed change, not  
>> the the current text in the draft. I would have interpreted my  
>> proposed change to mean something closer to  "As a FYI to the  
>> reader,  there is another specification you might be interested in.  
>> If you want to do Extended Key Usages there is this other  
>> specification, sip-eku, that can be implement but implementation of  
>> the domain-certs specification does not require you to implement  
>> sip-eku". If you and I are reading this differently ways perhaps  
>> you could propose some  text for this  sentence so that there is no  
>> chance of ambiguity.
>
>
> Usage values [need a ref here for , implementations MAY validate  
> those values using the techniques described in I-D.sip-eku[9].
>
> requirement for EKU in SIP certificates (and I'd take a MAY), and  
> that domain-certs have a MUST level requirement for evaluating certs  
> that contain EKU. If the domain went to all the trouble to include  
> an EKU in their cert, they did so for a reason. It's their cert, and  
> people referring to it should us it in the manner intended by the  
> signer. The signer intended the EKU constraints be applied to that  
> cert, or they wouldn't have bothered putting them there.
>
> For example, if I use a cert that says "Use only for email" to sign  
> an application, are you really stupid enough to run that code?
>
> I know you're trying to prevent a publication deadlock by changing  
> the requirements here. I don't understand why you think we'll have a  

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.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 09:06:06 -0700

> text of RFC 3280, which makes validation a MUST.

This is not at all what I was saying. I was saying that the EKU work  
is an orthogonal extensions to SIP with very little to do with the  
text in the domain-certs document and there is no need for this work  
to mandate support for sip-eku. I have not heard a technical argument  
why some part of the doamin-certs draft is not implementable without  
implementing sip-eku. I have heard people say, "sip-eku is a good  
idea" which is fine and assuming it becomes an RFC, devices that want  
to implement will implement that RFC.  There are also lots of other  
drafts that are good ideas and we wish people would do them, however,  
we don't add as a note to the end over every draft that says "You MUST  
also implement draft x, y, and z even though they have little to do  
with this one".

In my mind, the point of domain-certs is largely about to clarify how  
certain parts of 3261 related to certificates for TLS. People had  
implemented and were doing more or less all the major parts of domain- 
certs over 5 years ago - long before folks started even thinking about  
sip-eku. I think sip-eku is a fine document and should become an RFC.  
I also think there is a need for a document with roughly the advice in  
domain-certs. However, I see no reason that domain-certs, something  
people have been doing for several years, has to mandate  
implementation of sip-eku. These are very separable issues and should  
be kept that way.

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Mar 2008 11:25:57 -0500

On Mar 21, 2008, at 11:06 AM, Cullen Jennings wrote:
>> and if that's what he's saying, I think this is in conflict with  
>> the text of RFC 3280, which makes validation a MUST.
>>
>> --
>> Dean
>>
>>
>
> to mandate support for sip-eku. I have not heard a technical  
> argument why some part of the doamin-certs draft is not  
> implementable without implementing sip-eku. I have heard people say,  
> "sip-eku is a good idea" which is fine and assuming it becomes an  
> RFC, devices that want to implement will implement that RFC.  There  
> are also lots of other drafts that are good ideas and we wish people  
> would do them, however, we don't add as a note to the end over every  
> draft that says "You MUST also implement draft x, y, and z even  
> though they have little to do with this one".
>
> In my mind, the point of domain-certs is largely about to clarify  
> how certain parts of 3261 related to certificates for TLS. People  
> had implemented and were doing more or less all the major parts of  
> domain-certs over 5 years ago - long before folks started even  
> thinking about sip-eku. I think sip-eku is a fine document and  
> should become an RFC. I also think there is a need for a document  
> with roughly the advice in domain-certs. However, I see no reason  
> that domain-certs, something people have been doing for several  
> years, has to mandate implementation of sip-eku. These are very  
> separable issues and should be kept that way.
>

Ok, is this what you mean?

Discussion of Extended Key Usage in certificates used with SIP is  
outside the scope of this document. See I-D.sip-eku[9] for further  
discussion of this topic.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 09:32:22 -0700

> discussion of this topic.

Yes, that seems to pretty much capture what I was trying to say.  
Thanks you for getting that nice and crisp.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Mar 2008 13:40:43 -0500

> Thanks you for getting that nice and crisp.

Cullen: So what I think I am gathering from the seminal conversation
between you and Dean are the following points:

  1) Keep domain-certs and sip-eku separate.
  2) In domain-certs, have a pointer text of the form Dean outlines
   above referencing sip-eku.
  3) domain-certs updates rfc3261 (i.e., not essential correction);
   proceeds as a PS.
  4) sip-eku stands on its own as a PS.
  5) Revise domain-certs and sip-eku based on WGLC and PHL IETF
   discussion (of course.)

Is this an accurate and representational summary of the discussion?

Thanks,

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 12:04:28 -0700

Hmm, you might be reading slightly too much into this thread. I think  
the summary of the thread from my point of view is simply

As an individual contributor, I'm sending you comment which amounts to

1) I think it is good to keep domain-cert and sip-eku as separate drafts

2) I would suggest changing

OLD

NEW

And move the I-D.sip-eku[9] reference to be informative.

There's a bit more in the thread on why I think this change is good  
that I won't repeat here. My implication that domain-certs might  
become an essential correction was clearly wrong and should just be  
ignored.

Thanks, Cullen <with my individual contributor hat on>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Mar 2008 14:40:57 -0500

Cullen Jennings wrote:
> 
> Hmm, you might be reading slightly too much into this thread. 

Cullen: In the words of a British ITV sitcom character I used to
watch as a kid, "A thousand apologies, please!" (beer in Dublin for
the first correct guess)  More serious stuff inline...

> I think the summary of the thread from my point of view is simply
> 
[...]

OK; noted these two points.

> My implication that domain-certs might become an essential correction 
> was clearly wrong and should just be ignored.

OK; with the essential corrections bit out of the way, we have
made some progress from where we started off when we had our
initial phone conference on this back in Nov/Dec 2007.  The
guidance back then was split the drafts and have domain-certs
proceed as Informational.  The drafts were split soon after.

The drafts can proceed in the split format with the changes noted
above (speaking for myself here as 1/2 of the editor team -- I have
not conversed with Scott yet.)  However, we need to now converge on
which track to put domain-certs on: Info, BCP, or PS?  Both Scott
and I believe that it should be at least BCP, if not PS; and
others that reviewed the draft also assumed it was PS.

What would be the best way to close this one administrative issue
so we can submit the revised drafts accordingly: list discussion or
phone conference?  If the latter, I can send email out to the chairs,
you, Scott and me, and any interested list participants to
converge on a time and date.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Mar 2008 16:19:41 -0500

On Mar 21, 2008, at 11:06 AM, Cullen Jennings wrote:
> 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'd also like the answer to this question to be agreeable to the  
working group. So far, there seems to be some disagreement on the  
answer to this question between you and the authors of the domain- 
certs draft. There may or may not be any disagreement, as the  
appearance of disagreement may stem from a miscommunication.

The best way I know to do that is by paraphrasing and restating the  
proposal until we have something we agree is clear.

  Then you and Scott and Vijay can argue about whether or not you  
agree with it.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 15:33:15 -0700

> Then you and Scott and Vijay can argue about whether or not you  

Yep, agree, I send a new proposal (with your wording  - thank you).  
And Vijay, Scott, and the rest of the WG can decide what they think of  
it.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Mar 2008 15:42:46 -0700

At Fri, 21 Mar 2008 16:19:41 -0500,
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Mar 2008 09:08:36 -0700

On Mar 21, 2008, at 12:40 PM, ext Vijay K. Gurbani wrote:
> However, we need to now converge on

Agree we need to have a look at this and sort it out - it's not  
obvious to me what is the best thing to do yet. I want to read the  
draft from point of view of figuring out what recommendation in it  
change 3261 or not. This might sound easy but it is often not because  
3261 is less than clear on some of these topics (this is the big   
reason we need this draft in the first place). For example, this draft  
clearly requires implementations to do RFC 3280. The question is does  
3261 require implementations to do some RFC that got updated or  
replaced by 3280? I suspect the answer is "no" - however, tracing the  
tangled web of this is time consuming.

I am going to be on vacation all next week and trying to minimize  
email so I don't really plan to do much with this till the week after.  
I suspect that this is something  where the authors, chairs, and ADs  
should figure out a plan off list then bring it back to the list to  
check the WG is OK with it.

Cullen <in my AD role>