In reading through the procedures described in the SIP EKU document,
there's some apparent strangeness around the handling of
anyExtendedKeyUsage. Perhaps I'm just being dense, but here's what's
bothering me:
2. If EKU is present and contains id-kp-sipDomain, accept the
certificate.
3. If any EKU is present and contains both id-kp-anyExtendedKeyUsage
and id-kp-sipDomain, accept the certificate.
To me, this would be reduced to code that looks something like:
if (sipDomain || (sipDomain && anyExtendedKeyUsage))
{
acceptCertificate();
}
By my reading, this is unnecessarily complex, and functionally identical to:
if (sipDomain)
{
acceptCertificate();
}
In all of the text in this draft, I can't see any situation in which the
presence of "anyExtendedKeyUsage" has any impact on processing at all.
(There's some additional confusion in here; draft-ietf-sip-eku mandates
that certs containing a sipDomain extended key usage MUST mark the
extended key usage extension as critical; on the other hand, RFC 3280
indicates that the extended key usage extension SHOULD NOT be marked as
critical if it contains "anyExtendedKeyUsage" -- it would seem to me
that the extensions are fundamentally immiscible. In other words, a
natural consequence of the current text in draft-ietf-sip-eku and the
text in RFC 3280 is that sipDomain SHOULD NOT appear in the same cert as
anyExtendedKeyUsage).
It is potentially the case that the document goes through all this
verbiage in an attempt to say something like, "anyExtendedKeyUsage is
insufficient to indicate suitability of the certificate for use in
identifying SIP hosts." If this is the case, then I think that should be
stated more clearly (and suitably motivated).
Similarly, it's not clear to me why a certificate with a *non-critical*
EKU is required (at a MUST strength) to be rejected for use in
identifying a SIP domain. It seems far more in keeping with the
intention of EKU criticality to leave such situations up to local policy
(that is, hosts should be free to treat a certificate with a
*non-critical* EKU as if it had no EKU at all).
/a
_______________________________________________
Sip mailing list https://www1.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
