Re: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements

[Dan York <dyork at voxeo.com>]

Richard,

On May 2, 2008, at 9:18 AM, Richard Barnes wrote:

> The issue here is that "self-signed" certificates and "3rd-party- 
> issued" certificates are indistinguishable -- in order to be an  
> issuer for a certificate (including itself!) a certificate MUST be a  
> CA certificate, so all self-signed certs are CA certs.

DY> Okay, so that is technically true, although perhaps we need to  
clarify the thinking around a "CA cert".  Let's call a spade a spade  
and spell out this issue like this:

DY> We don't want a key exchange mechanism that absolutely requires  
endpoints to have to buy potentially expensive certs from central CAs  
simply in order to communicate.  It is a requirement that any media  
key exchange mechanism allow the use of self-signed certs.

DY> That's the net of it.  And while all the *current* proposals for  
key exchange comply with that idea, I think we need to state that in  
our requirements because there undoubtedly will be future proposals  
for key exchange that may look at these requirements.

DY> While I personally like the idea of using certs that can be traced  
back to central CAs as is done in SSL/TLS today, I also think we need  
self-signed certs for academic usage, for testing/labs, for private  
networks, for environments that don't need the central authentication,  
for startups with no money, etc., etc.

> That means that this requirement has no effect as a selector among  
> protocols (no protocol would violate it), and it creates precisely  
> the confusion that you have described, namely that the question of  
> which certificates are authorized signers is one of protocol design,  
> not local policy.  This is why I think that the requirement should  
> just be removed: It's a no-op technically, and it creates confusion.


DY> I guess I could see the possibility of a "protocol" being created  
where it was mandated that the endpoints had to do a check of a cert  
against central public CAs.  That's not what I think we want.    
Perhaps I am using a wider definition of a "protocol" than you are.

Regards,
Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     dyork at voxeo.com
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free





_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip