Subject: [Sip] I-D Action:draft-ietf-sip-eku-00.txt

From: [email-masked]
Date: Thu, 08 Nov 2007 10:40:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title           : Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
	Author(s)       : S. Lawrence, V. Gurbani
	Filename        : draft-ietf-sip-eku-00.txt
	Pages           : 10
	Date            : 2007-11-08

This memo documents an extended key usage (EKU) X.509 certificate
extension for identifying the holder of a certificate as
authoritative for a Session Initiation Protocol (SIP) service in the
domain named by the DNS name in the certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-eku-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-eku-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2007 14:20:06 -0600

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