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