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

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 3 Sep 2009 17:00:07 +0200

I haven't gotten any feedback on my feedback, but that may be the way  
it should be. I'm just curious on who's taking care of the progress of  
this document.

Regards,
/O

Vidarebefordrat brev:

> Från: "Olle E. Johansson" <[email-masked]>
> Datum: on 5 aug 2009 13.39.28 GMT+02:00
> Till: SIPCORE <[email-masked]>
> Ämne: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback
>
> 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
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Brian Hibbard <[email-masked]>
Date: Tue, 8 Sep 2009 14:04:31 -0500

Hello Olle,

Thank you very much for your feedback.  Unfortunately, there is no  
prize for being the first and only reviewer so far.  I apologize for  
taking so long to respond.  For the time being, I am the custodian of  
the draft.

Please see my comments below.

-Brian

On Sep 3, 2009, at 10:00 AM, Olle E. Johansson wrote:

> I haven't gotten any feedback on my feedback, but that may be the  
> way it should be. I'm just curious on who's taking care of the  
> progress of this document.
>
> Regards,
> /O
>
> Vidarebefordrat brev:
>
>> 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?
>>
>> - how does one host serve multiple domains? Is this reflected at  
>> all in the server certificate?
>> 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.

These are good ideas, but my understanding is that this draft is not  
intended to be tutorial in nature.  It is intended only to provide  
concrete reference examples.  A new tutorial document would probably  
be helpful  and well received by the community, but the SIP Sec Flows  
draft does not purport to be that document.  Is this OK with you?

>> ..."this document provides a common certificate and private key  
>> that can be"...
>>
>> Page 5, section 4.1
>>
>> 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 all sound good.  I will go make these changes.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 14 Sep 2009 19:12:24 +0200

8 sep 2009 kl. 21.04 skrev Brian Hibbard:

> taking so long to respond.  For the time being, I am the custodian  
> of the draft.
You're welcome.

--see below

/Olle

>>> 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.
>>>
>>> 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  
>>> - If SRV for example.com points to stockholm.example.com - which  
>>> CN and which subjAltName should be used?
>>>
>>> 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.
>
> be helpful  and well received by the community, but the SIP Sec  
> Flows draft does not purport to be that document.  Is this OK with  
> you?

Let's agree on having examples of parsed CSR requests then :-)

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

/O