On Mar 20, 2008, at 10:51 PM, Dean Willis wrote:
>
> 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
>
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.
_______________________________________________
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
