Question about refernce in draft-ietf-sip-domain-certs-00

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Dean Willis wrote:
> 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]."

I have not talked to Scott about this yet, but my thoughts
mirror
yours closely.  Regarding Cullen's proposed change:

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

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.al
catel-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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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: sip-bouncesietf.org [mailto:sip-bouncesietf.org]
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
> 
> 
> 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 
> sip-implementorscs.columbia.edu for questions on current
sip 
> Use sippingietf.org for new developments on the
application of sip
> 
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Mar 19, 2008, at 12:30 PM, Dean Willis wrote:

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

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.

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

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

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

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

    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.

which seems to me like it could be changed to

    I-D.sip-eku [9] describes the method to validate any
Extended Key
    Usage values found in the certificate for a SIP domain.

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.

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

>
> On Mar 19, 2008, at 12:30 PM, Dean Willis wrote:
>
>>
>> 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.
>
> 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.
>

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!


--
Dean
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Mar 19, 2008, at 6:56 PM, Cullen Jennings wrote:
>
> And certs has 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.
>
> which seems to me like it could be changed to
>
>    I-D.sip-eku [9] describes the method to validate any
Extended Key
>    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

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

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

>
> On Mar 19, 2008, at 6:56 PM, Cullen Jennings wrote:
>>
>> And certs has 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.
>>
>> which seems to me like it could be changed to
>>
>>   I-D.sip-eku [9] describes the method to validate
any Extended Key
>>   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]."

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.




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

On Mar 20, 2008, at 12:12 PM, Cullen Jennings wrote:
>
> On Mar 20, 2008, at 1:52 AM, Dean Willis wrote:
>
>>
>> On Mar 19, 2008, at 6:56 PM, Cullen Jennings
wrote:
>>>
>>> And certs has 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.
>>>
>>> which seems to me like it could be changed to
>>>
>>>  I-D.sip-eku [9] describes the method to
validate any Extended Key
>>>  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]."
>
> 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.


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




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