Subject: [Sip] Comments on draft-ietf-sip-eku-01

From: Paul Hoffman <[email-masked]>
Date: Sat, 22 Mar 2008 16:09:27 -0700

Greetings. Robert Sparks mentioned to me that this document is in WG 
Last Call. I am familiar with PKIX and make these comments based on 
my knowledge of PKIX, not based on my small knowledge of SIP.

1) On using EKU instead of a regular extension

The choice of using an EKU to day "the party associated with this 
public key is an authorized SIP proxy for the domain named in the 
certificate" is creative but probably not what the SIP WG wants for 
two reasons:

- Lots of software for relying parties ignores EKUs because many of 
the defined ones are poorly defined and often misused. It is likely 
that some PKIX libraries that you would want to use will not actually 
hand the EKU to proxyB, thus making the entire document useless. The 
complete lack of use of the EKUs defined long ago for VPN gateways is 
testament to this being a bad idea.

- This is an overly-creative use of EKUs. The definition of the key 
usage extension in RFC 3280 is:
    The key usage extension defines the purpose (e.g., encipherment,
    signature, certificate signing) of the key contained in the
    certificate.  The usage restriction might be employed when a key that
    could be used for more than one operation is to be restricted.
Note that this document does not define a purpose of the key or a 
restriction on the key: it binds the key to an additional semantic 
("this party is an authorized SIP proxy").

It would be much clearer if you used an actual extension, not an EKU, 
to make the binding. That is, create an extension that goes into the 
"extensions" field at the end of the TBSCertificate. This is a common 
way of extending PKIX without overloading existing PKIX functionality.

2) On marking the extension critical

If there is a good reason to mark this extension as critical, I 
missed it. Section 3.1 says:
    but if it is included, it MUST be
    marked as critical so that implementations that do not understand it
    will not accept the certificate for any other purpose.

This is a terrible idea for the identity binding described in the 
document. Why force a proxy to have two certificates, one for 
partners that understand this extension and one for those who don't? 
This will cause extra round trips, lack of communication with older 
servers, and so on. It seems much better to have the semantics of the 
extension be "if you can understand this, you'll know that this proxy 
is an authorized SIP proxy, but if you don't understand this, carry 
on".

I hope these comments help. It should not be hard to recast the 
document as one that defines an extension instead of an EKU, and to 
say "don't mark this as critical so that you can still talk to older 
proxies".

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Sip mailing list  https://www.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