Subject: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 5 Aug 2009 13:39:28 +0200

I vaguely remember that Adam mentioned this draft at the IETF75  
meeting... ;-)

Here's a few comments from someone who hasn't followed previous  
discussion on it:

A bit more of education needed
------------------------------------------
I think that since the area of security in SIP is covered in multiple  
documents that are hard to navigate through, this document needs to  
act a bit more as a hitchhiker's guide for both developers and  
implementors - administrators of servers. Currently it requires a  
great deal of TLS/PKI knowledge to be useful, something I humbly  
suggest we should try to work around, to lower the bar. We actually  
want people to implement this, and to do it correctly.

The document starts quickly and the reader is lost in section 4.1  
where we throw a text encoding of a CA certificate in his face. The  
really important information is hidden in section 7 and 8 after page  
up and down with various encoding schemes that for most people will  
look and feel like a strange Swedish dialect from Knäckebrödshult...  
Can we restructure and move these sections up front?

Relationship between server host name, served domain and SRV/NAPTR  
records needs to be explained
----------------------------------------------------------------------------------------------------------------------------------------------
Even though this is propably explained in five other documents, I  
think we could clarify this a bit.

- how does one host serve multiple domains? Is this reflected at all  
in the server certificate?
- If SRV for example.com points to stockholm.example.com - which CN  
and which subjAltName should be used?

The example used for domain "example.com" with hostname "example.com"  
is avoiding this...

Explain the certificate request (CSR)
-------------------------------------------------
In the real world, not in developer labs, the procedure for creating  
the key pair and generating a CSR on the host and the actual routine  
that signs and produces a certificate are two different procedures.  
This is not covered at all in this draft. In order to get the  
necessary Subject Alternative Names in the cert, and the EKU  
information, the CSR needs to reflect that. If you parse the scripts  
and the OpenSSL config file in the back, you can find out how this  
fits together. I think it would help all of us to actually have some  
examples of the parsed CSR as well to clearly explain the procedure.

Small changes
--------------------

Page 4, section 1:

..."this document provides a common certificate that can be"... I  
would change that to
..."this document provides a common certificate and private key that  
can be"...

Page 5, section 4.1

"Note that the basic constraints allow it to be used as a CA"
-> "Note that the X.509v3 Basic Constraints in the certificate allows  
it to be used as a CA, certificate authority."

I would insert a sentence at the end:

"This certificate is used to verify client and host certificates, it's  
not used directly in the TLS call flow."

Page 10, Section 4.3 - User certs

"This is necessary for interoperating with CPIM gateway"
Now, english is not my native language, but I want a small "a" before  
"CPIM" ;-)

I would change the first sentence to:

"The user certificate, used in many apps, for [email-masked] is  
shown below"

This would explain why we have other apps and data in there and also  
point out that one user cert can be used for many different apps.

Also, the last sentence:

"Note that the X509v3 Extended Key Usage attribute refers to the SIP  
OID introduced in [12] - 1.3.6.1.5.5.7.3.20

Page 28, section 7

The last paragraph seems to be about S/MIME but it doesn't say so. I  
think that could be clarified.

Page 33

"These could be in two PEM files or one .p12 file."

Many servers actually has both PEM sections - the private key and the  
cert - in one combined file. Yes, it's confusing, but it's done.

-------
Well, that was the result of reading and drinking a Nice Cup of Tea  
(TM) :-)

/Olle