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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
